Gestion de la_production_agricole_avec_openerp

Dédicaces
Page I
Au nom d’Allah, le Miséricordieux, par essence et par excellence
Dédicaces
Merci avant tout à Dieu.
À mes très chers parents
Je vous dois ce que je suis aujourd’hui grâce à votre amour, à votre patience et vos
innombrables sacrifices.
Que ce modeste travail, soit pour vous une petite compensation et reconnaissance
envers ce que vous avez fait d’incroyable pour moi.
Que Dieu, le tout puissant, vous préserve et vous procure santé et longue vie afin que je
puisse à mon tour vous combler.
À mon frère et mes amis
Pour vos encouragements tout le long de mon stage et pour tout ce que vous faites pour
une meilleure ambiance. Vous m’avez accompagnée dans mes bêtises comme dans mes
exploits.
À mes très proches amis que je ne les oublierais jamais
Oussama, 7ama, Walid, Raouf, Amin, Elyes, Safouenne, Youssef, Bouaoun, khaoula
Rym
Je vous aime mes chers, pour votre sincère amitié. J’ai passé avec vous des moments
extraordinaires, qui resteront gravés dans mon cœur.
Que dieu vous protège et que je reste fidèle à vos attentes.
ABDALLAH GHRIR

Remerciement
Page II
Remerciements
C’est avec un grand plaisir que je tiens tout d’abord à exprimer toute ma
reconnaissance à mes encadrants que ce soit au sein de la société NetPixcels : Messieurs
Hichem SFAYHI et Mehdi SFAYHI ou bien à ESPRIT : Madames Emna MARZOUK et
Mariem ELABED, pour l'attention qu'ils ont apportée à mon projet tout au long de ses divers
stades de réalisation et pour leurs précieux conseils.
Je suis redevable à tous mes enseignants d’ESPRIT pour leurs efforts qui ont guidé mes
pas tout au long de mes études universitaires.
Que tous ceux qui m'ont soutenu de près ou de loin, trouvent dans ce travail
l’expression de ma reconnaissance infinie.
Je tiens enfin, à exprimer l'honneur que me font les membres du jury pour avoir
accepté de me prêter leur attention et évaluer mon travail.

Résumé
Page III
Résumé
Le travail présenté dans ce rapport, s’inscrit dans le cadre du projet de fin d’étude à
l’école supérieure privée d’ingénierie et de technologies (ESPRIT), qui a été effectué au sein
de l’entreprise NETPIXCELS, entre dans le cadre du projet de fin d’études pour l’obtention
du diplôme national d’ingénieur en informatique. Il concerne la conception, le
développement, la réalisation et l’intégration d’un module de gestion de la production agricole
sous le progiciel OpenERP.
Ce module permet aux agriculteurs de gérer leurs biens et leurs production agricoles
quel que soit son type : animales ou végétale, cyclique ou non cyclique ainsi que la gestion
des couts et les quantités enlevées pour atteindre à la fin au bénéfice de chaque production.
La conduite du projet a suivi la méthode agile SCRUM qui aide à répondre le
plus fidèlement possible aux exigences du client dans les plus brefs délais.
Mots-clefs: OpenERP, agriculture, plate-forme, progiciel, système d'information,
Python, xml, open-server, Ubuntu, workflow, Scrum.

Abstract
Page IV
Abstract
The work presented in this report is part of the final project study on private
engineering and technology (ESPRIT) College, which was carried out within the company
NETPIXCELS enters the project graduation to obtain the national diploma in computer
engineering. It involves the design, development, implementation and integration of a
management module of agricultural production in the OpenERP platform.
This module allows farmers to manage their human resources and even their entire
stock based manage their assets and agricultural produce whatever its type: animal or
vegetable, cyclic or non-cyclic and management costs and quantities removed from each
production.
The conduct of the project followed the Scrum agile method that helps to answer as
accurately as possible the requirements of the customer in the shortest possible time.
Keywords: OpenERP, farming, platform, software package, information systems,
Python, xml, open-server, Ubuntu, workflow, Scrum.

Table des Matières
Page V
Table des Matières
Dédicaces...........................................................................................................................I
Remerciements................................................................................................................. II
Résumé............................................................................................................................ III
Abstract...........................................................................................................................IV
Table des Matières........................................................................................................... V
Listes des Figures............................................................................................................IX
Listes des Tableaux.........................................................................................................IX
Introduction générale ........................................................................................................ 1
Chapitre 1 : Présentation générale .................................................................................... 3
Introduction................................................................................................................... 3
1. Contexte du projet ................................................................................................ 3
2. Présentation de l’organisme d’accueil [1]......................................................... 3
3. Présentation du client ........................................................................................... 4
4. Problématique....................................................................................................... 4
5. Solution proposée................................................................................................. 5
Conclusion..................................................................................................................... 5
Chapitre 2 : Etat De L’art ................................................................................................. 6
Introduction................................................................................................................... 6
1. Etude de l’existant................................................................................................ 6
1.1. Etude du marché ........................................................................................... 6
1.2. Critique et Objectif ....................................................................................... 7
2. Méthodologie et choix de modélisation ............................................................... 7
2.1. Approche Agile vs. Séquentielle [2]............................................................. 7
2.2. Choix de méthodologie : Approche Agile .................................................... 9
2.3. Langage de modélisation ............................................................................ 15
Conclusion................................................................................................................... 15
Chapitre 3 : Sprint 0........................................................................................................ 16

Table des Matières
Page VI
Introduction................................................................................................................. 16
1. Pilotage du projet avec Scrum............................................................................ 16
1.1. Organisation................................................................................................ 16
1.2. Les moyens de communications ................................................................. 16
1.3. Features....................................................................................................... 17
1.4. Backlog Product.......................................................................................... 17
1.5. Décomposition en sprints............................................................................ 19
2. Choix technologique .......................................................................................... 22
2.1. ASP.NET .................................................................................................... 22
2.2. OpenERP..................................................................................................... 22
2.3. Choix........................................................................................................... 24
3. Environnement de développement..................................................................... 24
3.1. Outils de réalisation du projet..................................................................... 24
3.2. Langage et architecture de développement des modules............................ 29
4. Mise en place de l’environnement du travail ..................................................... 32
5. Conception ......................................................................................................... 33
5.1. Diagramme de packages ............................................................................. 33
5.2. Diagramme de cas d’utilisation général ........................................................... 34
5.3. Diagramme de classe général ........................................................................... 35
Conclusion................................................................................................................... 37
Chapitre 4 : Sprint 1........................................................................................................ 38
Introduction................................................................................................................. 38
1. Backlog Sprint.................................................................................................... 38
2. Analyse et spécification des besoins .................................................................. 39
2.1. Besoins fonctionnels ................................................................................... 39
2.2. Besoins non fonctionnels ............................................................................ 39
2.3. Identification des acteurs ............................................................................ 39

Table des Matières
Page VII
2.4. Diagramme de cas d’utilisation .................................................................. 39
2.5. Diagramme de séquence système ............................................................... 44
3. Conception ......................................................................................................... 45
3.1. Diagramme de packages ............................................................................. 45
3.2. Diagramme de classe .................................................................................. 45
3.3. Diagramme de séquence objet .................................................................... 47
4. Réalisation.......................................................................................................... 48
Conclusion................................................................................................................... 49
Chapitre 5 : Sprint 2........................................................................................................ 50
Introduction................................................................................................................. 50
1. Backlog Sprint.................................................................................................... 50
3. Conception ......................................................................................................... 58
3.1. Diagramme de packages.................................................................................. 58
3.4. Diagramme d’activités................................................................................ 61
4. Réalisation.......................................................................................................... 62
Conclusion................................................................................................................... 64
Chapitre 6 : Sprint 3........................................................................................................ 65
Introduction................................................................................................................. 65
1. Backlog Sprint.................................................................................................... 65

Table des Matières
Page VIII
3. Conception ......................................................................................................... 73
3.3. Diagramme d’activités................................................................................ 76
4. Réalisation.......................................................................................................... 77
Conclusion................................................................................................................... 80
Chapitre 7 : Sprint 4........................................................................................................ 81
Introduction................................................................................................................. 81
1. Backlog Sprint.................................................................................................... 81
2. Analyse et spécification des besoins....................................................................... 82
2.1. Besoins fonctionnels .................................................................................. 82
3. Conception .............................................................................................................. 86
3.1. Diagramme de packages................................................................................... 86
3.2. Diagramme de séquence objet.......................................................................... 87
4. Réalisation............................................................................................................... 88
Conclusion................................................................................................................... 91
Conclusion Générale....................................................................................................... 92
Netographie..................................................................................................................... 93
Glossaire ......................................................................................................................... 94

Liste des Figures
Page IX
Listes des Figures
Figure 1: Positionnement des méthodes agiles par rapport aux quatre critères agiles...... 9
Figure 2: Comparaison entre les mehodes agile selon la taille du projet ....................... 10
Figure 3:Vue globale de Scrum ...................................................................................... 12
Figure 4: Liste des pratiques Scrum................................................................................ 14
Figure 5: Les sprints de développement ......................................................................... 20
Figure 6: Ubuntu 12.10................................................................................................... 24
Figure 7: Eclipce Kepler................................................................................................. 25
Figure 8: OpenERP 7.0................................................................................................... 26
Figure 9: Fonction recherche .......................................................................................... 26
Figure 10: Flux des changements ................................................................................... 27
Figure 11: Configuration ................................................................................................ 27
Figure 12: Interface Sale Order....................................................................................... 28
Figure 13: Postgres ......................................................................................................... 28
Figure 14: Python............................................................................................................ 29
Figure 15: Modèle-Vue-Contrôleur graphique............................................................... 31
Figure 16: Exemple d'architecture d'un module ............................................................. 31
Figure 17: Installation d’Open ERP sous Ubuntu .......................................................... 32
Figure 18: Intégration de l’Open ERP sous Eclipse ....................................................... 33
Figure 19: OpenERP stable pour développer notre module ........................................... 33
Figure 20: Diagramme de packages................................................................................ 34
Figure 21: Diagramme de cas d'utilisation générale....................................................... 35
Figure 22 : Diagramme de classe générale ..................................................................... 36
Figure 23 : Diagramme de cas d'utilisation : sprint 1 ..................................................... 40
Figure 24: Diagramme de cas d’utilisation : gérer ferme ............................................... 40
Figure 25 : Diagramme de cas d’utilisation système: gérer centre................................. 42
Figure 26 : Diagramme de séquence système : créer ferme, centre et bâtiment............. 44
Figure 27: Digrammes de packages sprint1.................................................................... 45
Figure 28 : Diagramme de classe du sprint 1.................................................................. 46
Figure 29 : Diagramme séquence objet de l'ajout d'une ferme, centres et bâtiments .... 47
Figure 30 : Interface Création du module Agriculture ................................................... 48
Figure 31 : Interface création d’une ferme ..................................................................... 48

Liste des Figures
Page X
Figure 32 : Interface gestion des centres......................................................................... 49
Figure 33: Diagramme de cas d'utilisation système: sprint 2 ......................................... 52
Figure 34:Diagramme de cas d'utilisation production animales cyclique ...................... 52
Figure 35: Diagramme de cas d'utilisation : gérer production animale cyclique............ 53
Figure 36 : Diagramme cas d’utilisation:gérer les productions animales non cycliques 55
Figure 37: Diagramme de séquence : créer une production végétale ............................. 57
Figure 38: Diagramme de package sprint 2 .................................................................... 58
Figure 39 : Diagramme de classe du sprint 2.................................................................. 59
Figure 40:Diagramme de sequence objet « workflow production animale cyclique »... 60
Figure 41: Diagramme de séquence objet : production animale cyclique...................... 60
Figure 42: Diagramme d'activité du lancement d'une production végétale.................... 61
Figure 43 : Interface création d’un cycle animale .......................................................... 62
Figure 44 : Interface lancement d’un cycle animale....................................................... 62
Figure 45 : Interface finalisation d’un cycle animale ..................................................... 63
Figure 46 : Interface rechercher cycle sous une vue de calendrier................................. 63
Figure 47 : Interface interdiction de la suppression d’un cycle finalisé ......................... 64
Figure 48 : Diagramme de cas d'utilisation système : sprint 3 ....................................... 67
Figure 49: Digramme de cas d’utilisation: gérer les dépenses de production animale
cyclique .................................................................................................................................... 68
Figure 50 : Diagramme de cas d’utilisation : gérer les enlèvements de production
végétale..................................................................................................................................... 70
Figure 51 : Diagramme de séquence de l’ajout d’une dépense au sein d’une production
animale cyclique....................................................................................................................... 72
Figure 52 : Diagramme de classe sprint 3....................................................................... 73
Figure 53 : Diagramme de séquence objet de l’ajout d’un enlèvement au sein d’une
production animale cyclique .................................................................................................... 74
Figure 54 : Diagramme d’activité d’une production végétale avec dépense................. 76
Figure 55 : Interface de création d’une dépense ............................................................. 77
Figure 56 : Interface de création d’un mouvement de stock pour une dépense.............. 78
Figure 57 : Interface de création d’un enlèvement ......................................................... 78
Figure 58 : Interface de création d’un mouvement de stock pour un enlèvement.......... 79
Figure 59: Interface du bénéfice du cycle....................................................................... 79
Figure 60 : Diagramme de cas d'utilisation système sprint 4 ......................................... 83
Figure 61:Diagramme de packages rapport production végétale .................................. 86

Liste des Figures
Page XI
Figure 62:Diagramme de packages rapport production animale .................................... 86
Figure 63 : Diagramme de séquences système pour la génération de copie PDF .......... 87
Figure 64 : Interface de totalités de toutes les dépenses végétales ................................. 88
Figure 65 : Interface rechercher dépense sous une vue de calendrier............................. 88
Figure 66 : Rapport d’une production animale cyclique ................................................ 89
Figure 67 : Vue graphique 1 ........................................................................................... 90

Liste des Tableaux
Page IX
Listes des Tableaux
Tableau 1 : Approche Agile vs. Séquentielle.................................................................... 9
Tableau 2:Comparatif entre les différentes méthodologies ............................................ 12
Tableau 3:Cadre du Scrum ............................................................................................. 13
Tableau 4: Explication détaillée des features................................................................. 17
Tableau 5: Backlog Product............................................................................................ 19
Tableau 6: Déroulement des sprints................................................................................ 21
Tableau 7: Les diverses entités ....................................................................................... 37
Tableau 8: Backlog Sprint 1 ........................................................................................... 38
Tableau 9: Cas d'utilisation créer ferme ......................................................................... 41
Tableau 10: Cas d'utilisation Supprimer ferme............................................................... 42
Tableau 11:description textuelle du d'utilisation créer centre ........................................ 43
Tableau 12: Backlog sprint 2.......................................................................................... 51
Tableau 13 : Cas d'utilisation créer une production animale cyclique ........................... 54
Tableau 14: Cas d'utilisation modifier une production animale cyclique....................... 54
Tableau 15: Cas d'utilisation rechercher une production animale cyclique.................... 55
Tableau 16:Cas d'utilisation créer une production animale non cyclique ...................... 56
Tableau 17: Cas d'utilisation supprimer une production animale non cyclique ............. 57
Tableau 18: Backlog sprint 3.......................................................................................... 66
Tableau 19:Créer une dépense de cycle de production animale cyclique ...................... 69
Tableau 20: Créer un enlèvement d'une production végétale......................................... 71
Tableau 21: Supprimer un enlèvement d'une production végétale................................. 72
Tableau 22: Backlog Sprint 4 ......................................................................................... 82
Tableau 23: Cas d'utilisation générer les dépenses par des vue de calendrier................ 84
Tableau 24: Générer les vues graphiques des enlèvements végétales ............................ 85
Tableau 25: Générer copie PDF...................................................................................... 85

Introduction Générale
Page 1
Introduction générale
ujourd’hui, les innovations technologiques sont basées surtout sur le
développement des domaines informatiques créés pour automatiser les
tâches humaines.
Les machines sont capables de collecter un ensemble d’informations, créant une
grande base de données. Celle-ci peut être gérée par un programme informatique pour
augmenter la performance de la gestion des informations, minimiser l’erreur humaine et
faciliter la circulation de ces informations.
L’informatisation, c'est l'installation d'un système de traitement automatique de
l'information. En d’autres termes, c’est avoir recours aux moyens informatiques pour traiter
des données, pour gérer aux mieux une entreprise. Elle se fait, principalement, pour gérer plus
d’une fonction dans le but de gagner du temps, de la productivité et surtout une amélioration
de la qualité du service. Par souci de compétitivité et dans le but d’assurer une
meilleure production, les entreprises se construisent aujourd’hui, par un recours à la fois plus
fréquent et plus intensif à des technologies de gestion avancées.
Les entreprises sont acculés à concentrer leurs efforts sur l’introduction des
technologies d’informatisation dans leurs procédures de travail. Ce besoin s’avère nécessaire
pour garantir une meilleurs maîtrise des coûts de revenus, pour disposer d’une meilleure
réactivité leur permettant d’une part, de réduire les coûts temporels et financiers, pour
accroître la qualité de service et d’autre part d’améliorer et faciliter les conditions de travail.
L'informatisation touche et touchera de plus en plus les fonctions de gestion, de
planification, d'organisation et d'administration tout en continuant de s'implanter dans
toutes les activités des entreprises. En ce sens, nous pouvons parler d'un bond qualitatif
dans la conception, la mise au point et l'usage de cette technologie.
Les ERP open sources permettent à des petites PME de disposer d’outils de gestion
complets au meilleur coût, leur apportant rapidement un vrai bénéfice en termes de
compétitivité.
C’est dans ce cadre que notre projet s’inscrit :
L'objectif de ce module intitulé «NETAGRIPLUS » est d’apporter un outil de
gestion simple aux agriculteurs.
Le projet porte sur la gestion de production des agricoles quel que soit son type :
animales ou végétale, cyclique ou non cyclique. Il s’intéresse à la gestion des couts de
A

Introduction Générale
Page 2
production, tout en intégrant le module de gestion de stock nommé « Entrepôt » et le module
de gestion des ressources humaines.
Ce projet vise à développer, intégrer et mettre en place un module de gestion agricole
sur un progiciel de gestion intégrée open source qui porte le nom «OpenErp»
La suite de ce rapport sera divisée en sept chapitres.
Le premier chapitre sera consacré à la présentation du contexte du projet au cours
duquel nous présenterons l’organisme d’accueil. Nous proposerons une étude de l’existant et
nous présenterons la problématique.
Le deuxième chapitre nous dégagerons la solution que nous avons adoptée, et la
méthodologie du travail à appliquer durant le développement de notre application.
Le reste du rapport sera organisé en cinq sprints. Le sprint zéro est consacré à la
présentation du Backlog Product, les différents choix techniques et la description de
l’architecture de l’application.
Pour chacun des sprints un, deux, trois et quatre, nous exposerons en premier lieu, une
étude fonctionnelle de notre application. Par la suite nous présenterons la conception des
différents modules à réaliser durant le sprint correspondant. Vers la fin nous ferons l’étalage
de quelques captures d’écran de la solution à laquelle le sprint a abouti.
Une conclusion générale sera évoquée au terme de ce rapport.

Chapitre 1 : Présentation Générale
Page 3
Chapitre 1 : Présentation générale
Introduction
Nous présentons dans ce chapitre une étude préliminaire du projet. Dans un premier
temps, nous présentons l’entreprise d’accueil. Par la suite, nous décrivons la problématique,
ainsi que les principaux objectifs du projet.
1. Contexte du projet
Dans le cadre de la formation d’ingénieurs informaticiens à l’École Supérieure
Privée d’ingénierie et de Technologies (ESPRIT), nous avons eu l’occasion d’effectuer notre
projet de fin d’études pour l’obtention du diplôme national d’ingénieur en informatique
au sein de la société NetPixcels. Ce projet vise à compléter notre formation universitaire
acquise, durant cinq ans, en nous introduisant dans la vie professionnelle grâce à une mise en
pratique de nos connaissances, à l’utilisation de logiciels de développement
informatique, tout en mettant en épreuve notre esprit d’ingénieur. Le projet consiste à
concevoir et réaliser un module fiable et facile à utiliser pour agriculteurs qui leur permet de
gérer leurs productions animales et végétales ainsi que leurs dépenses quotidiennes et leurs
mouvements de stock.
2. Présentation de l’organisme d’accueil [1]
Netpixcels, SSII en Tunisie, est considérée comme étant un acteur dynamique dans le
secteur de l’ingénierie informatique et télécom. La société a pour mission de concevoir et de
mettre en place des solutions parfaitement adaptées aux besoins de ses clients et partenaires.
En effet, et dans le cadre du conseil informatique, elle propose toute sorte solutions
performantes et innovantes : Des solutions web, du développement spécifique en
informatique, de la domotique informatique...L'entreprise offre aussi du conseil pour la
maintenance et la gestion des parcs informatiques.
IT Solutions :
Les interventions et services de gestion de parc et d'infogérance
• Fourniture et mise en production des serveurs (Windows, linux ou Snap Server)
• Fourniture et mise en production des postes clients
• Prestations de conseils et d'audit en informatique

Page 4
• Fourniture, installation et gestion du matériel réseau (switch, câbles, etc.)
• Administration réseau
• Maîtrise d'œuvre de projets informatique
• Maintenance bureautique
• Support utilisateur : helpdesk, dépannages sur site
• Formations aux logiciels bureautiques MS Office et OpenOffice
• Configuration de services d'email, d'antivirus, de firewall ou d'intranet,
• Achats de matériels et logiciels sur devis
• Gestion des garanties
RESEAUX INFORMATIQUES :
• Conception et Déploiement d’infrastructures réseaux
• Administration et Maintenance d’infrastructures réseaux
• Câblages réseaux (conception, déploiement)
• Solutions de sauvegarde et récupération des données
• Déploiement d’Intranet & Secs Associés
• Solutions de messagerie d’entreprise
• Solutions collaborative (groupware, ERP…)
3. Présentation du client
Notre client est un agriculteur de grande culture qui est un propriétaire de fermes multi-
élevages dont sa ferme se situe dans un village au nord de la Tunisie nommé « KALAAT
LANDLOSS».
Cet Agriculteur produit plusieurs types d’agricultures cycliques et non cycliques (variés
que ce soit dans son aspect « saisonnier ou non saisonnier », « géographique », « climatique »
« type de production » de plus c’est un éleveur qui possède divers types d’élevages dans
divers endroit de la Tunisie.
4. Problématique
Après notre étude du marché, nous avons constaté qu’il y a un grand manque de
traçabilité chez les gestionnaires en agriculture. Ceci est dû en partie au manque d’outil
complet de prise de décision ainsi que la faiblesse d’outils de contrôle de stock. Les
agriculteurs ne peuvent pas contrôler instantanément leurs productions. Ils n’ont pas un bon
suivie de la production de leurs produits que ce soit sur le plan commercial pour faire le bilan
des bénéfices, ou en relation avec les productions des ventes immédiates dans les marchés de

Page 5
gros. La majorité des agriculteurs tunisiens n’ont pas un système d’information aussi
développé pour gérer leurs données, les statistiques, les prévisions annuel.
.
5. Solution proposée
La solution proposée sera une application web nommée NETAGRIPLUS avec des
interfaces graphiques conviviales fiable, simple et facile à utiliser.
Notre application va nous offrir une bonne gestion d’une production agricole complète
qui se base en totalité sur des modules de dépenses, ventes, de quantités enlevées de chaque
type de production.
Ainsi elle va nous fournit une intégration de gestion des ressources humaine de plus
qu’elle va nous garantir une bonne traçabilité des donnés pour améliorer la qualité
d’approvisionnement grâce à sa gestion du stock
Conclusion
Ce chapitre nous a servi à mettre le projet dans son cadre. Nous continuons dans
la partie suivante la présentation du contexte du projet et de la problématique liée à
l'élaboration de notre projet.

Chapitre 2 : Etat de L’Art
Page 6
Chapitre 2 : Etat De L’art
Introduction
Pour présenter notre travail, notre projet doit être impliqué dans son contexte
général. Ce sera l'objet de cette partie qui est l'entrée principale.
1. Etude de l’existant
Dans cette partie, nous présenterons le cadre de notre projet, et ensuite nous
allons commencer par une description de l’environnement existant.
Bien que les systèmes de gestion évoluent de jour en jour, la sécurité et la
fiabilité reste parmi les priorités d'une application de gestion.
1.1. Etude du marché
Notre client agriculteur n’a pas une solution de gestion pour son système d’information,
et de ses données en relation avec productions cycliques et la gestion de ses notes de frais
ainsi que la gestion des ressources humaines.
Le marché Tunisien est également dépourvu d’une solution informatisée aussi
développée qui englobe tous les besoins nécessaires de l’agriculteur pour la gestion de ses
fermes et ses centres pour la production animale ou végétale.
Les grandes boites de production animales installées en Tunisie sont censées se procurer
chez les éditeurs étrangers des solutions informatiques pour leur gestion de production en
agriculture.
En effet après notre recherche sur les solutions informatisées dédié à la gestion des
productions agricoles, on a pu distinguer la fiche technique d’une solution française qui se
distribue par tous dans le monde : AGI - InteGraal AGREO
Cette solution propose des avantages et des inconvénients. Pour cela nous avons décidé
de mettre l'accent sur et l’étudier avec notre client.
Agreo est un outil informatique de gestion technique destiné aux filières agricoles et
agro-industrielles, présente plutôt un environnement simple et convivial.
Les fonctionnalités offertes tournent globalement autour de la gestion de stock, contrôle
de la qualité, une gestion précise de la traçabilité et des process.

Page 7
Agreo est aujourd’hui utilisé par de nombreuses structures de type organisation de
producteurs, coopératives, négoces, industrie de l’agroalimentaire à l’échelle nationale et
internationale.
Agreo est une plate-forme d'échange d'informations et s'adapte au profil de chaque
utilisateur. Quelle que soit sa filière (vitivinicole, végétale, animale, grandes cultures, ...), son
métier (agriculteurs/éleveurs, coopératives, négoces, industriel de l'agroalimentaire,
semenciers, professionnel des vins & spriritueux, AGC...)
Gérer les parcellaire et les contrats
Planifier et gérez les récoltes
Disposer d'outils d'analyse
1.2. Critique et Objectif
De plus que Agreo est une solution existante à l’étranger, elle très couteuse par rapport à
ces fonctionnalités et ces modules offerts, de plus elle n’obéit pas aux besoins spécifiques de
notre client.
L'étude précédente nous mène à la création d'une application web de Gestion de
Production agricole qui permet de planifier, d'organiser et de superviser les productions, à
travers un ensemble de modules intégrés dans un système d'information bien structuré,
Notre application qui va s’intitulé NetAgriPlus va nous garantir une bonne traçabilité
des donnés et améliorer la qualité d’approvisionnement, dont les principaux objectifs du
projet sont :
Gérer les productions agricoles
Gérer les ressources humaines
Gérer le stock
Disposer d'outils de statistiques des quantités enlevés par
type production
Disposer un inventaire de mouvement de stock.
2. Méthodologie et choix de modélisation
Nous allons détailler dans cette partie la méthode agile choisie et le langage de
modélisation.
2.1. Approche Agile vs. Séquentielle [2]
Pour bien choisir notre type de méthodologie de travaille nous avons dressé le tableau 1
qui présente une comparaison entre les deux approches par thème

Page 8
Thème Approche Séquentielle Approche agile
Cycle de vie
En cascade ou en V, sans
rétroaction possible, phases
séquentielles.
Itératif et incrémental.
Planification
Prédictive, caractérisée par
des plans plus ou moins détaillés
sur la base d’un périmètre et
d’exigences définies au début du
projet.
Adaptative avec plusieurs
niveaux de planification avec
ajustements si nécessaires au fil de
l’eau en fonction des changements
survenus.
Documentation
Produite en quantité
importante comme support de
communication, de validation et
de contractualisation.
Réduite au strict nécessaire
au profit d’incréments fonctionnels
opérationnels pour obtenir le
feedback du client.
Équipe
Une équipe avec des
ressources spécialisées, dirigées
par un chef de projet.
Une équipe responsabilisée
où l’initiative et la communication
sont privilégiées, soutenue par le
chef de projet.
Qualité
Contrôle qualité à la fin du
cycle de développement. Le
client découvre le produit fini.
Un contrôle qualité précoce et
permanent, au niveau du produit et
du processus. Le client visualise les
résultats tôt et fréquemment.
Changement
Résistance voir opposition
au changement.
Processus lourds de
gestion des changements
acceptés.
Accueil favorable au
changement inéluctable, intégré
dans le processus.
Suivi de l’avancement
Mesure de la conformité
aux plans initiaux.
Analyse des écarts.
Un seul indicateur
d’avancement : le nombre de
fonctionnalités implémentées et le
travail restant à faire.
Processus distinct,
rigoureux, de gestion des
Gestion des risques intégrée
dans le processus global, avec

Page 9
Gestion des risques risques. responsabilisation de chacun dans
l’identification et la résolution des
risques.
Pilotage par les risques.
Mesure du succès
Respect des engagements
initiaux en termes de coûts, de
budget et de niveau de qualité.
Satisfaction client par la
livraison de valeur ajoutée.
Tableau 1 : Approche Agile vs. Séquentielle
Maintenant que nous connaissons mieux les différences majeures entre approches
traditionnelles et approches agiles à travers la comparaison faite ci-dessus nous avons opté
pour une approche agile pour gérer notre projet.
2.2. Choix de méthodologie : Approche Agile
Le terme agile est apparu dans le domaine du logiciel en 2001 avec le Manifest Agile .
Le mouvement a pris l’ampleur depuis quelques années, il est maintenant diffusé, au-delà des
pionniers, dans de très nombreuses organisations impliquées dans le développement
informatiques.
Figure 1: Positionnement des méthodes agiles par rapport aux quatre critères agiles
Une étude de ces différentes méthodologies révèle qu’elles ont un tronc commun, mais
elles se différencient par leur degré de formalisme, les revues, le rythme du projet, le nombre
et la longueur des itérations et à la taille de projets.
Pour mettre l’accent sur leurs différences, la figure présente un ordonnancement des
méthodes agiles, les plus utilisées, en fonction de la taille du projet à réaliser.

Page 10
Figure 2: Comparaison entre les mehodes agile selon la taille du projet
La figure illustre Positionnement des méthodes agiles par rapport aux quatre critères de
l’agilité.
Le Manifest Agile énonce douze principes :
1. Satisfaire le client en livrant tôt et régulièrement des applications utiles, qui offrent
une véritable valeur ajoutée
2. Accepter les changements, même tard dans le développement
3. Livrer fréquemment une application qui fonctionne
4. Collaborer quotidiennement entre clients et développeurs
5. Bâtir le projet autour de personnes motivées en leur fournissant environnement et
support et en leur faisant confiance
6. Communiquer par conversation face à face
7. Mesurer la progression avec la version qui fonctionne
8. Garder un rythme de travail durable
9. Rechercher l’excellence technique et la qualité de la conception

Page 11
10. Laisser l’équipe s’auto-organiser
11. Rechercher la simplicité
12. A intervalle de temps réguliers, réfléchir aux moyens de devenir plus efficace.
Le but d’une méthode agile est de maximiser la valeur ajoutée : le développement
s’effectuant par itérations successives. Il est possible, à la fin de chaque itération, de changer
les priorités en faisant en sorte que les éléments apportant le plus de valeur soient réalisés en
premier.
Plusieurs méthodes AGILE existent, les plus connues sont:
 Extreme programing (XP)
 Rational Unified Process (RUP)
 Feature-Driven Development (FDD)
 SCRUM
Ci-dessous un tableau comparatif entre les différentes méthodes citées auparavant :
Méthode Points Clés Caractéristiques imperfections
RUP
(Rational
Unified
Process)
- Modèle complet du
développement de logiciel
assisté par outils.
- Rôle bien défini.
-Modélisation
d’affaires, soutien
d’outils.
-Convient pour les
gros projets qui génèrent
beaucoup de documents
-Coûteux à
personnaliser.
Peu de place pour
le code et la technologie.
XP
(Extreme
Programming
)
Développement
réduit par client, petite
équipe, des développeurs
en binôme, construction
quotidienne.
- Refactoring :
Devoir refaire la
conception du système de
façon continue pour
améliorer sa performance
et sa capacité de réponse
aux changements.
Les pratiques
individuelles sont bien
adaptées dans plusieurs
situations mais les
pratiques de gestion et de
vue général sont moins
attentives.
FDD Processus avec 5
étapes, développement se
basant sur les composants
La simplicité de
méthode, conception et
implémentation du
FDD ne concentre
que sur le
développement.

Page 12
(Feature
Driven
Development)
orientés objet. Très courte
itération : de quelques
heures à 2 semaines.
système par des
caractéristiques,
modélisation d’objet.
Scrum
Indépendant petites
équipes à organisation
automatique de
développement, cycles de
30jours.
Transférer de
« défini et répétitif » à la
vue de développement de
produits nouveaux de
Scrum.
Scrum spécifie en
détail comment gérer les
cycles de 30 jours mais
l’intégration et le test
d’acceptation ne sont pas
détaillés.
Tableau 2:Comparatif entre les différentes méthodologies
2.2.1. Critère de choix de la méthodologie Scrum
D’après le tableau comparatif précédent, nous avons éliminé le RUP qui néglige la
technologie et les contraintes techniques présentant une grande partie de notre projet. Nous
avons aussi éliminé aussi l’XP qui néglige, pour sa part, l’étude fonctionnelle et la capture des
besoins fonctionnels et techniques.
De plus, une grande importance est accordée dans le FFD au développement aux dépens
de la phase d’analyse et de conception.
Nous avons, alors opté pour la méthodologie SCRUM qui est incrémentale et itérative
ainsi qu’adaptable aux changements des fonctionnalités.
2.2.2. La méthode Agile Scrum
Figure 3:Vue globale de Scrum

Page 13
On est naturellement tenté de parler de méthode agile et de processus agile pour Scrum.
En effet, la définition officielle, celle donnée par la Scrum Aliance et son fondateur Ken
Shwaber est légèrement différente. Scrum n’est présenté ni comme un processus ni comme
une méthode.
Si la vraie nature de Scrum est difficile à définir, il est beaucoup plus simple d’expliquer
la mécanique de mise en œuvre.
 Scrum sert à développer des applications, généralement en quelques mois.
Les fonctionnalités sont collectées dans le backlog de produit et classées
par priorité. C’est le Product Owner qui est responsable de la gestion de ce
backlog.
 Une version (release) est produite par une série d’itérations appelées des
sprints. Le contenu d’un sprint est défini par l’équipe, avec le Product
Owner, en tenant compte des priorités et de la capacité de l’équipe. A partir
de ce contenu, l’équipe identifie les tâches nécessaires et s’engage pour
réaliser les fonctionnalités sélectionnées pour le sprint.
 Pendant un sprint, des points de contrôle sur le déroulement des tâches sont
effectués lors des mêlées quotidiennes (Scrums). Cela permet au Scrum
Master, l’animateur chargé de faire appliquer Scrum, de déterminer
l’avancement par rapport aux engagements et d’appliquer, avec l’équipe,
des ajustements pour assurer le succès du sprint.
 A la fin de chaque sprint, l’équipe obtient un produit partiel (un
incrément) qui fonctionne. Cet incrément du produit est potentiellement
livrable et son évaluation permet d’ajuster le backlog du produit pour le
sprint suivant.
Le cadre Scrum consiste en une équipe avec des rôles bien définis, des blocs de temps
(timeboxes) et des artefacts.
Rôles Timeboxes Artifacts
Product Owner
ScrumMaster
Equipe
Planification de release
Planification de sprint
Scrum quotidien
Revue de sprint
Rétrospective
Backlog de produit
Plan de release
Plan de sprint
Burndown de sprint
Burndown de release
Tableau 3:Cadre du Scrum

Page 14
Equipe et rôles – L’équipe a un rôle capital dans Scrum : elle est constituée dans le
but d’optimiser la flexibilité et la productivité ; pour cela, elle s’organise elle-même et doit
avoir toutes les compétences nécessaires au développement du produit. Elle est investie avec
le pouvoir et l’autorité pour faire ce qu’elle a à faire.
Un équipier peut créer des histoires (stories) dans le backlog du produit, créer des tâches
dans le plan du sprint, créer des tests d’acceptation, noter le résultat des tests et enregistrer un
obstacle.
Le ScrumMaster a la responsabilité supplémentaire de gérer l’élimination des obstacles
et d’indiquer qu’un nouveau build est utilisable.
Le Product Owner est le seul habilité à créer un release, à définir les grands traits d’une
application (features), à changer les priorités dans le backlog et à déclarer une story finie.
Timeboxes – Scrum utilise des blocs de temps pour créer de la régularité. Le coeur du
rythme de Scrum est le sprint, une itération d’un mois ou moins. Dans chaque sprint, le cadre
est donné par un cérémonial léger mais précis basé sur des réunions.
Artifacts – Scrum exige peu d’artefacts lors du développement : le plus remarquable
est le backlog de produit, pivot des différentes activités.
L’inspection, afin de faire des adaptations, est la base de la théorie de Scrum. A la fin
d’un sprint, le résultat obtenu est un incrément du produit final, qui est potentiellement
livrable.
Figure 4: Liste des pratiques Scrum

Page 15
2.3. Langage de modélisation
Dans cette partie, nous décrivons deux différentes méthodes de modélisation: Merise et
UML.
Nous allons préciser le choix fait entre eux.
2.3.1. Merise
MERISE n'est pas un langage mais une méthode de conception, de développement et de
mise en œuvre de projets informatiques. Le but de cette méthode est de parvenir à une
conception d'un système d'information. Méthode MERISE est basée sur la séparation des
données et le traitement à effectuer en plusieurs modèles physiques et conceptuels. La
séparation des données et le modèle de traitement assure la longévité.
2.3.2. UML
Unified Modeling Language (UML) est un langage de modélisation standard à usage
général dans le domaine du génie logiciel orienté objet. La norme est gérée, et a été créé par
l'Object Management Group. Il a d'abord ajouté à la liste des technologies OMG adopté en
1997, et depuis devenu le standard industriel pour la modélisation des systèmes à logiciel
prépondérant.
2.3.3. Choix
Nous avons choisi d’utiliser UML.
On pourrait faire valoir que la communication est la partie la plus difficile de
développer des logiciels de qualité. UML est une aubaine, car il est efficace dans le traitement
de ce problème difficile. Il peut permettre à une équipe de développeurs de communiquer
efficacement et de votre situation géographique importe peu. Si vous voulez maximiser les
capacités d’UML, vous devez l'utiliser d'une manière qui permet à votre équipe de
communiquer avec un degré de précision élevé. Il y a un certain nombre de façons dont UML
peut permettre à votre équipe de développement à mieux communiquer.
Conclusion
Dans ce chapitre, nous avons fait une présentation qui a fait une première approche du
projet.
Bien qu'on part de la problématique, on a aussi mis l'accent sur la méthodologie de
développement qu'on va adopter ainsi que le langage de modélisation.
Dans le prochain chapitre, nous détaillons la spécification du produit désiré.

Chapitre 3 : Sprint 0
Page 16
Introduction
Afin de développer une application de haute qualité répondant aux attentes et aux
exigences du notre client, il est nécessaire d’adopter une méthodologie de développement. En
effet, celle-ci constitue le pilier de toute activité qui conduit au déploiement d’un logiciel de
qualité. Après une étude de différentes méthodes Agiles nous avons choisi la méthode Scrum.
En effet l’application de cette méthodologie constitue la base de ce sprint. Dans un
premier temps nous définissons les différents rôles et nous présentons la décomposition de
notre projet en quatre sprints. Par la suite nous présentons les grands choix techniques ainsi
que l’architecture générale de notre application.
1. Pilotage du projet avec Scrum
1.1. Organisation
La méthodologie Scrum fait intervenir trois rôles principaux qui sont :
 Le Product Owner qui est notre chef d’activité et le manager de l’organisme
d’accueil.
 Le Scrum Master, notre chef de projet, il a pour responsabilité, dans le cadre du
développement de l’application, de nous aider à travailler de façon autonome et à
s’améliorer constamment.
 L’équipe : c’est moi l’intégrateur et le développeur de l’application.
1.2. Les moyens de communications
Pour réussir et finaliser l'application, chaque jour, nous organisons une réunion à la fin
de la journée pour les membres du groupe, dons laquelle nous devons montrer au Scrum
Master notre état d’avancement sur le projet.
De plus nous faisons une réunion chaque début de semaine pour planifier les buts que
nous devons les atteindre à la fin de la semaine et distinguer ainsi les difficultés rencontrées et
les taches finalisées.
Vu que notre client se trouve loin de la capitale, le moyen de communication que nous
avons utilisé pour l’échange de documents :
 Gmail

Page 17
Ainsi que l’organisation des réunions chaque deux semaine.
1.3. Features
Une feature est une caractéristique ou un service du produit qui répond à un besoin des
utilisateurs. Une feature est généralement décomposé en plusieurs stories de notre projet.
Nom Rang Description Type Valeur Effort
Préparation
de
l’environnem
ent du travail
1
Installation, configuration et
intégration d’OpenERP avec les
Framework de développement.
Fonctionnel 20 50
Gestion des
biens
2
Réalisation du module de
gestion des biens et son
intégration au module
ressources humaines.
Fonctionnel
50 30
Gestion des
workflows de
production
3
Réalisation des modules de
workflow des productions
animales cyclique et végétales,
ainsi que la réalisation du
module de production animale
non-cyclique.
Fonctionnel
70 60
Gestion des
dépenses et
des
enlèvements
4
Réalisation des modules des
dépenses et des enlèvements
pour chaque production, et leur
intégration aux mouvements en
stock.
Fonctionnel
90 80
Génération
du module de
reprorting et
de
Statistiques.
5
Réalisation d’un autre module
de reporting spécifie à chaque
production cyclique ainsi
l’analyse des données des
enlèvements sous forme de
statistiques.
Fonctionnel
80 70
Tableau 4: Explication détaillée des features
1.4. Backlog Product
Le Backlog Product est le point d’entrée du projet, il présente une liste priorisée
d’exigences, de caractéristiques qui récapitulent les besoins du client. Le Backlog Product est
spécifié par le Product Owner. Cet artefact est montré dans le tableau ci-dessous :

Page 18
Rang Nom Estimation Type Feature
1 - Comparaison entre les Plateformes de
réalisation du projet
10 Story
utilisateur
Préparation
de
l’environne
ment du
travail
2 - Choix de la technologie du Platform et
environnements du travaille
10 Story
utilisateur
Préparation
de
l’environne
ment du
travail
3 - Préparation de l’environnement du
travail
7 Story
utilisateur
Préparation
de
l’environne
ment du
travail
4 - Test de la stabilité de l’environnement
de travail et la mise en place du
Framework au sein de le l’organisme
d’accueil
3 Story
utilisateur
Préparation
de
l’environne
ment du
travail
5 - Création du module Agriculture 5
Story
utilisateur
Gestion des
biens
6 - Développement de la rubrique de la
gestion des biens de l’agriculteur
15
Story
utilisateur
Gestion des
biens
7 - Installation, configuration et intégration
du module ressources humaines avec le
module Agriculture
10
Story
utilisateur
Gestion des
biens
8 - Développement du workflow de la
rubrique de gestion de production
animale.
20
Story
utilisateur
Gestion des
productions
9 - Développement de la rubrique gestion de
production animale non cyclique
7
Story
utilisateur
Gestion des
productions
10 - Développement du workflow de la
rubrique gestion de production végétale.
13
Story
utilisateur
Gestion des
productions
11 - Développement de gestion des dépenses
par rapport à la production
5
Story
utilisateur
Gestion des
dépenses et
enlèvements

Page 19
12 - Développement de gestion des
enlèvements par rapport à la production
5
Story
utilisateur
Gestion des
dépenses et
enlèvements
13 - Installation, configuration et mise en
place du module stock
4
Story
utilisateur
Gestion des
dépenses et
enlèvements
14 - Intégration du module stock avec le
module Agriculture
6
Story
utilisateur
Gestion des
dépenses et
enlèvements
15 - Intégration et configuration des ventes et
des dépenses par rapport aux productions
et la configurer avec le mouvement en
stock
25
Story
utilisateur
Gestion des
dépenses et
enlèvements
16 - Développement des vues graphiques
pour avoir une analyse de données de
statistiques des quantités totales enlevées
pour chaque type de production
6
Story
utilisateur
Statistiques
et reporting
17 - Développement des rubriques des
dépenses qui mettent en évidence la
totalité des dépenses de chaque type de
production
4
Story
utilisateur
Statistiques
et reporting
18 - Développement d’un autre module de
Reporting qui met en valeur les critères
du cycle de production
27
Story
utilisateur
Statistiques
et reporting
19 - Tester l’intégration inter modulaire et la
synchroniser
1
Story
utilisateur
Statistiques
et reporting
20 - Configuration et mise en place des droits
d’accès de chaque acteur de l’application
2
Story
utilisateur
Statistiques
et reporting
Tableau 5: Backlog Product
L’estimation est présentée en nombre de jour, notre estimation n’est pas totalement
exacte car nous avons estimé aussi le temps de formation sur les différents points
fonctionnels.
1.5. Décomposition en sprints
Avec Scrum chacun des sprints a un objectif qui porte sur un point qui fonctionne (et
pas seulement sur des documents), ce qui nécessite du travail dans toutes les activités de

Page 20
développement pendant un sprint. Un cycle de développement se présente comme un
enchainement de phases dans lesquelles nous effectuons ces activités :
 Spécification fonctionnelle (S) : dans cette partie nous allons parler de quelques
user stories spécifiques à chaque sprint.
 Architecture (conception) : dans cette partie, nous allons spécifier les diagrammes
des classes participantes dans la réalisation de chaque sprint.
 Codage (et test unitaire)
 Test (d’intégration et de recette)
Notre projet se déroule sur cinq Sprint allant du Sprint0 jusqu’au Sprint4 comme le
montre la Figure .Chaque sprint sera expliqué d’avantage dans les prochains chapitres.
Figure 5: Les sprints de développement
Le tableau ci-dessous décrit le déroulement des sprints et décrit les différentes tâches à
réaliser.
Id Sprint Description Estimation
(Nb jours)
0 Préparation de
l’environnement
du travail
 Comparaison entre les Platform de
réalisation du projet
 Choix de la technologie du Platform et
environnements du travail
 Préparation de l’environnement de travail
 Test de la stabilité de l’environnement de
travail et la mise en place du Framework au
sein de le l’organisme d’accueil
30
sprint0 sprint1 sprint2 sprint3 sprint4

Page 21
1
Conception et
Réalisation de la
gestion des biens
de l’agriculteur
 Création du module agricole
 Développement de la rubrique de la gestion
des biens de l’agriculteur
 Installation, configuration et l’intégration du
module ressources humaines avec le module
agricole
30
2
Conception et
Réalisation de la
gestion de
production
 Développement du workflow de la rubrique
de gestion de production animale cyclique.
 Développement du workflow de la rubrique
de gestion de production végétale.
 Développement de la rubrique de gestion de
production animale non cyclique.
40
3
Conception et
Réalisation de la
gestion des
dépenses et des
enlèvements de
chaque
production avec
l’intégration du
mouvement en
stock
 Développement de gestion des dépenses par
rapport à la production
 Développement de gestion des enlèvements
par rapport à la production
 Installation, configuration et mise en place
du module stock
 Intégration et configuration des enlèvements
et des dépenses par rapport aux productions
et les intégrer avec le mouvement en stock
40
4
Statistique et
repoting pour
chaque
production.
Configuration des
privilèges de
chaque acteur de
l’application.
 Développement des vues graphiques pour
avoir une analyse de données de statistiques
pour chaque production
 Développement d’un autre module de
Reporting spécifié à chaque production
 Test de l’intégration inter modulaire et de la
synchronisation
 Configuration des droits d’accès de chaque
acteur de l’application
40
Tableau 6: Déroulement des sprints

Page 22
2. Choix technologique
Au début nous avons fait une étude comparative afin de choisir une technologie pour
réalisation de notre projet.
Une technologie de réalisation qui doit satisfaire notre client pour tous ces besoins
fonctionnels au plus bref délai.
2.1. ASP.NET
ASP.NET est un cadre d'applications Web côté serveur conçu pour le développement
Web pour produire des pages Web dynamiques. Il a été développé par Microsoft pour
permettre aux programmeurs de construire des sites Web dynamiques, des applications Web
et des services Web. Il a été d'abord publié en Janvier 2002, avec la version 1.0 du. NET
Framework, et est le successeur de Active Server Pages de Microsoft (ASP) de la technologie.
ASP.NET est construit sur le Common Language Runtime (CLR), qui permet aux
programmeurs d'écrire du code ASP.NET en utilisant n'importe quel langage. NET pris en
charge.
L’approche MVC sous ASP.NET apporte de réels avantages:
 . Une conception claire et efficace grâce à la séparation des données de la vue et du
contrôleur
 Un gain de temps de maintenance et d’évolution du site
 Une plus grande souplesse pour organiser le développement du site entre différents
développeurs (indépendance des données, de l’affichage (webdesign) et des actions)
Aussi qu’ils existent beaucoup des inconvénients :
 Couts : Une solution payante
 Temps : nécessite un large temps de développement
 Visibilité : L’inconvénient majeur du modèle MVC n’est visible que dans la
réalisation de petits projets, de sites internet de faible envergure.
2.2. OpenERP
Open ERP est un logiciel Open Source de gestion commerciale et comptable très
complet, et dispose de nombreux modules pour aider votre entreprise à mieux gérer ses
ressources, qu'elles soient financières, matérielles ou humaines. Open ERP est intégrable avec

Page 23
la solution e-commerce pour une gestion entièrement automatisée de votre process
commercial de A à Z.
Open ERP, un ERP différent, Les Workflows de la logistique s'adaptent sans
programmation. Sur la solution open source OpenERP , le design des formulaires et des
rapports se modifie directement dans la partie client par l'intermédiaire d'un programme
rapide d'utilisation et d'une bonne ergonomie.
Open ERP logiciel libre innovateur, innove notamment au niveau de la gestion des
stocks avec sa gestion double entrée. Celle-ci vous permet de gérer simplement tous les cas de
figure que vous pouvez rencontrer dans la gestion de votre société : entrepôts multiples,
contrôle qualité, stocks consignés, gestion de stocks des fournisseurs / clients. La
comptabilité est aussi multi-vues et multidevises.
Une solution Open source, avec Open ERP, aucune licence annuelle à payer, une
diminution du coût d'intégration de 40% comparativement aux solutions propriétaires, ainsi
qu'une maîtrise du produit en interne et une accessibilité libre aux documentations, forums,
mails.
Open ERP apporte de réels avantages:
 Temps : Simplicité d'utilisation
 Flexibilité : Un logiciel libre innovateur
 Couts : Une solution Open source
 Technologie : Une solution techniquement avancée
Mais il présente également des inconvénients :
 Documentation : L’inconvénient chez OpenERP est son manque de documentation et
au cas où elle est disponible, elle est souvent non mise à jour par rapport aux nouvelles
versions. De plus beaucoup de versions sont instables…
 Connaissance et la remise en cause des processus de l’entreprise : le fait qu’une
entreprise qui utilise Open Source ERP ne peut pas prendre les avantages des services
offerts par un fournisseur parce que l’entreprise gère l’ensemble de ses activités de
manière indépendante. Dans ce cas, si une simple erreur n’est pas corrigée
immédiatement il peut y avoir des effets désastreux et des couts conséquents.

Page 24
2.3. Choix
Le choix que nous avons fait, c'est pour l'utilisation du Platform OpenERP.
A part le fait que cette solution est gratuite, C’est essentiellement grâce à la disposition
de nombreux modules pour aider l’entreprise à mieux gérer ses ressources. L'utilisateur a
également la possibilité de récupérer des données de manière immédiate, ou encore de les
enregistrer.
Un avantage important, les mises à jour dans la base de données sont effectuées en
temps réel et propagées aux modules concernés, de plus Un ERP est un outil
multilingue et multidevise, il est donc adapté au marché mondial, en particulier aux
multinationales,
Open ERP permet de maîtriser les stocks, élément important pour la plupart des
entreprises car les stocks coûtent chers
3. Environnement de développement
3.1. Outils de réalisation du projet
3.1.1. Ubuntu 12.10 [3]
Figure 6: Ubuntu 12.10
Ubuntu est un système d’exploitation libre commandité par la société Canonical et une
marque déposée par cette même société.

Page 25
Fondé sur la distribution Linux Debian et utilisant le bureau Unity, Ubuntu se
veut
« Convivial, intuitif et sûr ». Il est constitué de logiciels libres, est disponible
gratuitement y
Compris pour les entreprises, et bénéficie d'une nouvelle version (appelée « mise à
niveau ») tous les six mois.
La version d’Ubuntu utilisée pour ce projet est la 12.10 ayant pour nom de code : The
Quantal Quetzal) est la dix-septième version d'Ubuntu. Elle est sortie le 18 octobre 2012.
Cette version amorce un nouveau méta-cycle de développement de quatre versions.
3.1.2. Eclipse kepler [4]
Figure 7: Eclipce Kepler
Eclipse est un environnement de développement intégré dont le but est de fournir une
plate-forme modulaire pour permettre la réalisation des développements informatiques.
Eclipse utilise énormément le concept de modules nommés "plug-ins" dans son
architecture. D'ailleurs, hormis le noyau de la plate-forme nommé "Runtime", tout le reste de
la plate-forme est développé sous la forme de plug-in. Ce concept permet de fournir
un mécanisme pour l'extension de la plate-forme et fournir ainsi la possibilité à des
tiers de développer des fonctionnalités qui ne sont pas fournies en standard par Eclipse.
Eclipse possède de nombreux points forts qui sont à l’origine de son énorme succès dont
les principaux sont :
 L’extensibilité de plate-forme grâce au mécanisme de plug-ins
 La cohabitation entre plusieurs versions d'un même plug-in sur une même plateforme
 Le support de plusieurs langages grâce à des plug-ins dédiés : Python, Java,
Cobol, C, PHP, ...
 Le support de plusieurs plates-formes d'exécution :Linux, Windows,…

Page 26
 La construction incrémentale des projets grâce à un compilateur interne qui
permet de compiler un code même avec des erreurs, de générer des messages
d'erreurs personnalisés…
3.1.3. OpenERP 7.0 [5]
Nous avons fait une recherche de comparaisons entre les versions 7.0 et 6.1.1
d’OpenERP et nous avons distingué une liste 4 des nouveautés qui ont retenues notre
attention pour la version 7.0 :
Figure 8: OpenERP 7.0
 La fonction de recherche simplifiée :
Dans la version 6.1.1 les champs de recherche prenaient énormément de place dans les
écrans. Dans la version 7.0 il y a un champ unique de recherche qui permet de faire des
recherches intelligentes à travers le module. Par exemple en tapant la lettre "U" la recherche
va nous proposer différents résultats regroupés par sous-menu du module (partenaire, bons de
commandes, pistes etc.).
Figure 9: Fonction recherche

Page 27
 Le flux de nouvelles :
OpenERP a incorporé un nouveau module de gestion des flux de nouvelles. Il est
possible de communiquer rapidement avec n'importe quel utilisateur en utilisant ce module.
Chaque utilisateur peut voir en un coup d'oeil tout ce qui a été fait dans OpenERP et qui
le concerne. Il peut répondre et consulter les messages à partir de cet écran.
Figure 10: Flux des changements
 Le module configuration :
Finis également les menus configuration repartis dans chaque module. Il existe
maintenant un menu unique pour toutes les configurations de modules dans OpenERP. La
gestion des rôles n'en sera que simplifiée.
Figure 11: Configuration
 La nouvelle interface :
OpenERP s'est refait une beauté! Les écrans sont plus au gout du jour, épurés, simples
et avec des couleurs sobres. Également, les boutons d'actions se retrouvent toujours au même
endroit dans les différents écrans, ce qui améliore grandement l'expérience des utilisateurs et
facilite l'appropriation du progiciel par ceux-ci.

Page 28
Figure 12: Interface Sale Order
La première avancée d'OpenERP version 7.0 est de supprimer la complexité inhérente à
tout ERP.
Avec la version 7.0, OpenERP passe d'un ERP à une suite d'applications commerciales
intégrées.
Jusqu'à présent, le monde était divisé entre les ERP et les meilleures applications
spécifiques. Avec la version 7.0, OpenERP combine les avantages clés des applications
autonomes (facilité d'utilisation, rapide à déployer, hautement personnalisable, ...) avec la
couverture fonctionnelle et la qualité d'intégration de différents modules caractérisant un ERP.
Cela permet aux entreprises de déployer rapidement un ou deux modules à un coût très faible
et d'augmenter progressivement leur couverture fonctionnelle.
L'intégration des réseaux sociaux, des alias e-mail pour chaque objet, de Google Docs et
de LinkedIn, la gestion des contrats, la gestion d'événements, la gestion de points de vente, le
carnet d'adresses, ou la gestion d'une flotte de véhicule ne sont que quelques-unes des
nombreuses améliorations apportées par OpenERP 7.0.
3.1.4. PostgresSql
Figure 13: Postgres
PostgreSQL est un serveur de bases de données SQL (Structured Query Language) qui a
acquis une popularité croissante au fil des années, notamment par sa gratuité et son
exploitation sur Internet [www.Postgres.com].
Il consiste en un serveur de base de données SQL Multi-Utilisateur et multi-
thread.

Page 29
3.2. Langage et architecture de développement des modules
3.2.1. Python [6]
Figure 14: Python
Python est un langage de programmation multi-paradigme. Il favorise la
programmation impérative structurée, et orientée objet. Il est doté d'un typage dynamique fort,
d'une gestion automatique de la mémoire par ramasse-miettes et d'un système de
gestion d'exceptions il est ainsi similaire à Perl, Ruby, Scheme, Smalltalk et Tcl.
Python est un langage :
 conçu pour produire du code de qualité, portable et facile à intégrer : grâce à sa
syntaxe claire, cohérente et concise, Python permet aux développeurs de
produire du code de qualité, lisible et maintenable. Écrire du code Python est un
exercice agréable, même en respectant les conventions de codage.
Fourni dès le départ avec des modules de tests, Python est un langage agile. Le
terme agile est originellement issu de la méthodologie de programmation agile (Beck
et Al.), très proche de la programmation itérative. Cette méthodologie, qui réduit les
risques liés à la conception de logiciels, introduit entre autres des principes de tests
continus du code.
 De haut niveau, orienté objet et totalement libre : même si elle n’est pas
imposée, Python permet la programmation orientée objet. Tous les mécanismes objet
essentiels sont implémentés et toutes les données manipulées sont des instances
de classes, comme pour les langages Small Talk ou Ruby.
Enfin, le code peut être structuré en modules (fichiers) qui sont ensuite
importables dans l’interpréteur. Ce découpage, permet d’organiser le code et son
utilisation par des espaces de noms, et aussi de faciliter l’extension du langage
par des bibliothèques tierces compilées dans d’autres langages.
 Dynamique : dans la plupart des implémentations, le code source n’est pas
compilé contrairement à des langages comme C ou Pascal, mais exécuté à la volée. On
parle alors de langage interprété. Ce mode de fonctionnement rend la
programmation beaucoup plus souple puisqu’il est possible de changer un
programme en cours d’exécution, ou de tester du code en mode interactif sans

Page 30
disposition particulière. L’interprétation rend aussi l’exécution plus lente, mais ce
défaut est surmontable grâce à de bonnes pratiques de programmation et des
techniques d’optimisation.
3.2.2. XML [7]
XML (eXtensible Markup Language) est en quelque sorte un langage HTML amélioré
permettant de définir de nouvelles balises. Il s'agit effectivement d'un langage permettant de
mettre en forme des documents grâce à des balises (markup).
Contrairement à HTML, qui est à considérer comme un langage défini et figé (avec un
nombre de balises limité), XML peut être considéré comme un métalangage permettant
de définir d'autres langages, c'est-à-dire définir de nouvelles balises permettant de
décrire la présentation d'un texte (Qui n'a jamais désiré une balise qui n'existait pas ?).
La force de XML réside dans sa capacité à pouvoir décrire n'importe quel
domaine de données grâce à son extensibilité. Il va permettre de structurer, poser le
vocabulaire et la syntaxe des données qu'il va contenir.
En réalité les balises XML décrivent le contenu plutôt que la présentation
(contrairement À HTML). Ainsi,XML permet de séparer le contenu de la présentation, ce qui
permet par exemple d'afficher un même document sur des applications ou des périphériques
différents sans pour autant nécessiter de créer autant de versions du document que l'on
nécessite de représentations !
XML fait partie du code des modules composants OpenERP, les vues par lesquelles
sont représentés les différents objets sont écrites en XML, ainsi nous y trouvons la description
détaillée de l’affichage des arbres, formulaires, menus et autres actions.
3.2.3. Architecture de développement [8]
Un système OpenERP est basé sur un trois niveaux d'architecture: niveau base de
données pour le stockage de données, niveau d'application pour le traitement et les
fonctionnalités et couche de présentation fournissant l'interface utilisateur. Ce sont des
couches distinctes à l'intérieur d'OpenERP.
En outre, OpenERP suit le Modèle-Vue-Contrôleur (MVC) modèle architectural
Un modèle-vue-contrôleur (MVC) est un modèle architectural utilisé en génie logiciel".
Dans les applications informatiques complexes présentant beaucoup de données à l'utilisateur,
on souhaite souvent séparer les données (modèle) et l'interface utilisateur (voir)

Page 31
préoccupations. Les modifications apportées à l'interface utilisateur n'a pas d'impact
conséquent la gestion des données, et les données peuvent être réorganisées sans changer
l'interface utilisateur. Le modèle-vue-contrôleur résout ce problème en découplant l'accès aux
données et la logique métier de la présentation des données et l'interaction de l'utilisateur, par
l'introduction d'un composant intermédiaire: le contrôleur.
Figure 15: Modèle-Vue-Contrôleur graphique
OpenERP suit la sémantique avec MVC
Modèle : un serveur de base de données PostgreSQL qui peut contenir plusieurs bases
de données
Vue : un serveur de présentation qui permet à l'utilisateur de se connecter à OpenERP
avec n'importe quel navigateur internet
Contrôleur : un serveur d'applications contenant les objets de gestion, le moteur de
workflow, le générateur d'édition, etc.
Figure 16: Exemple d'architecture d'un module

Page 32
4. Mise en place de l’environnement du travail
Nous notons maintenant les principales étapes de la mise en place de l’environnement
de travail :
• Créer l'utilisateur qui sera propriétaire d’OpenERP et exécutera l'application
• Installer et configurez le serveur de base de données, PostgreSQL
• Installer les bibliothèques nécessaires pour le langage Python
• Installer le serveur Open-server
• Configurer le progiciel OpenERP
• Installer du script de démarrage
• Tester du serveur
• Automatisation du démarrage et de l'arrêt Open ERP
• Installer Éclipse Kepler et py-dev plugin
• Intégrer et configurer OpenERP sous Éclipse
Figure 17: Installation d’Open ERP sous Ubuntu

Page 33
Figure 18: Intégration de l’Open ERP sous Eclipse
Figure 19: OpenERP stable pour développer notre module
5. Conception
5.1. Diagramme de packages
Un diagramme de packages est un diagramme UML qui fournit une représentation
graphique de haut niveau de l'organisation de notre application, et nous aide à identifier les
liens de généralisation et de dépendance entre les packages.
Le diagramme de packages correspondant à notre application est dans la figure qui suit :

Page 34
Figure 20: Diagramme de packages
Notre diagramme de packages comporte plusieurs entités qui sont :
 Présentation : Contient l’ensemble des pages Web développés en XML.
 Contrôleur: Contient le service et les contrôleurs développés en Python
 Modèle : Contient les objets métiers ou entités qui seront persisté.
5.2. Diagramme de cas d’utilisation général
Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous-
système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Il scinde la
fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant un sens pour les
acteurs. Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système, ils
sont donc une vision orientée utilisateur de ce besoin au contraire d’une vision informatique.
Controller
View Model

Page 35
Figure 21: Diagramme de cas d'utilisation générale
Comme nous pouvons le constater, notre module admet 5 fonctionnalités principales :
 La gestion des biens de l’agriculteur.
 La gestion de tous types de productions.
 La gestion des dépenses.
 La gestion des enlèvements.
 La génération de rapports
5.3. Diagramme de classe général
Nous allons à présent présenter, dans la figure qui suit, notre diagramme des classes
après le raffinement final. En effet, nous avons précisé tous les attributs dont nous allons avoir
besoin pour les entités de notre système.
System
Gérer le stock
Gérer les productions animales cycliques
Gérer les enlévementsGérer les dépenses
s'authentifier
Administrateur
Gestionnaire de production
Gérer les biens
Gérer les productions végétales
Gérer les productions animales non cycliques
Générer copie pdf
<<extend>>
<<extend>>
<<extend>>
<<extend>> <<extend>>
<<extend>>
<<extend>>
<<extend>>
<<include>>
<<include>>
<<include>>
Consulter les statistiques des enlévements
Générer les totalites des dépenses par type de production
<<include>>
<<include>>
<<include>>
<<include>>

Page 36
Figure 22 : Diagramme de classe générale
OpenERP
Module Agriculture
Ferme
+id_ferme: int
+titreferme: string
+gérant: string
+unite_mesure: string
+surface: string
+gouvernerat: string
+adresse: string
+desc: string
+image: bit
+nb_centre: int
+nb_batiment: int
Batiment
+id_batiment: int
+titre_batiment: string
+unité de surface: string
+surface: string
+emplacementstring
Animale_cycle
+id: int
+image: bit
+date_entre_effectifs: date
+effectifs entres: int
+femelle: int
+mal: int
+date_debut_cycle: date
+date_fin_cycle: date
+valid_date: boolen
+state: string
Animale_non_cycle
+id: int
+image: bit
+effectifs entres: int
+date_entre_effectifs: date
+mal: int
+femelle: int
Vegetale
+id: int
+image: bit
+date_plante: date
+date_recolte: date
+date_debut_cycle: date
+date_fin_cycle: date
+valid_date: boolen
+state: string
Centre
+id_centre: int
+titre_centre: string
+unit_mesure: string
+surface: string
+emplacement: string
+image: bit
+chef: string
avoir
1..*
1
avoir
1..*
1
Module Stock
Module Resourses Humaines
product__product
+id: int
product__uom
+id: int
stock__move
+id: int
product__category
+id: int
hr__hr
+id
+nom
+prenom
+login
+password
Depense
+id: int
+date_dep: date
+prix_unit_dep: float
+prod_qty: int
+qte_dispo: float
+total_depense: float
+prop_depense: string
+flag: string
Enlèvement
+id: int
+date_env: date
+prix_unit_ev: float
+prod_qty_enlv: float
+total_vente: float
+prop_env: string
+flag: string
produire
1
1..*
produire
1..*
1
contenir
1..*
1
contenir
1..*
1
contenir
1..*
1
produire
1..*
1
contenir
1..*
1
utilisateur
group
+id: int
+privileges: string
1 1..*
contenir
1..*
1
contenir
1..*
1
1..*
1
1
1..*
Les classes développées dans notre module Les classes prédéfinies chez OpenERP

Page 37
Le diagramme de classes d’analyse précédant représente les entités de notre système
ainsi que l’interaction entre ces dernières
Table Description
Ferme Classe contenant les informations nécessaires
à une ferme.
Centre Classe contenant les informations nécessaires
à un centre.
Bâtiment Classe contenant les informations nécessaires
à un bâtiment.
Animale_cycle Classe contient toutes les informations
primordiales à la définition d’une production
animale cyclique
Animalenon_cycle Classe contient toutes les informations
animale non cyclique
Végétale Classe contient toutes les informations
végétale
Dépense Classe contient toutes les informations
relatives à la dépense pour chaque type de
production
Enlèvement Classe contient toutes les informations
relatives à l’enlèvement pour chaque type de
production
Tableau 7: Les diverses entités
Conclusion
Lors de ce chapitre, nous avons présenté l’application de la méthodologie
SCRUM pour notre projet à savoir le Backlog Produit et la décomposition des
sprints. De plus nous avons présenté les diverses choix techniques ainsi que
l’architecture globale de notre application.
Ensuite nous avons présenté la mise en place et la stabilité de l’environnement
du travaille suite à des imprimes écran, et à la fin nous avons démontré des
diagrammes généraux qu’on les suivre tout au long du projet.

Page 38
Introduction
Ce premier sprint s’étale sur quatre semaines. Nous abordons dans un premier temps
l’identification des acteurs et nous passons à la récolte des besoins fonctionnels ainsi que les
besoins non fonctionnels. Par la suite nous entamons la partie d’analyse des besoins. Vers la
fin nous présentons la conception de notre application et la phase de réalisation relatives à ce
sprint.
1. Backlog Sprint
Le premier sprint consiste à réaliser les entrées 5, 6 et 7 du Product Backlog. Les tâches
à réaliser sont présentées dans le tableau suivant :
Story id Nom Description
5
Création du
module
Agriculture
- Création de la base de données
- Création du module Agriculture
6 Gestion des
biens
- Conception de la rubrique de gestion des biens de
l’agriculteur
- Développement de la rubrique de gestion des biens de
l’agriculteur
- Test unitaire
- Réalisation des interfaces de la rubrique
- Test unitaire
7
Intégration
module RH
- Installation et configuration du module ressources
humaines
- Intégration du module ressource humaines aux attributs
désirés dans le module agricole
- Test unitaire
- Test de l’intégration
Tableau 8: Backlog Sprint 1

Page 39
2. Analyse et spécification des besoins
2.1. Besoins fonctionnels
Pour ce sprint, notre application doit offrir un ensemble de fonctionnalités qui répondent
à des besoins bien définis, à savoir :
 Création du module agricole.
 Offrir une rubrique bien finalisée pour la gestion des biens de l’agriculture
 Offrir un module de gestion de ressources humaines.
2.2. Besoins non fonctionnels
Les besoins non fonctionnels décrivent souvent les besoins d’utilisation qui font référence
à des aspects généraux de l’application. Notre application, doit offrir :
 Maintenabilité et scalabilité :
Le code de l’application doit être lisible et compréhensible afin d’assurer son état évolutif et
extensible par rapport aux besoins des sprints suivants.
 Ergonomie :
Les interfaces graphiques doivent être agréables et simples à manipuler.
2.3. Identification des acteurs
Notre application est manipulée par un seul acteur durant ce sprint :
• un administrateur qui a tous les droits d’accès de gestion de cette application qui est
notre client. En fait c’est le gérant de la ferme.
Durant ce sprint nous nous focalisons sur la partie de l’administrateur :
Il peut ainsi ajouter supprimer ou modifier : les fermes, les centres et les bâtiments,
aussi il peut gérer le module des ressources humaines.
2.4. Diagramme de cas d’utilisation

Page 40
Figure 23 : Diagramme de cas d'utilisation : sprint 1
La Figure représente le cas d’utilisation général du sprint 1. Il sera raffiné d’avantage
dans ce qui suit.
Cas d’utilisation détaillé « gérer les fermes » :
Ce cas d’utilisation inclut la création, la modification, la suppression et la recherche des
fermes.
Figure 24: Diagramme de cas d’utilisation : gérer ferme
Les Tableaux expliquent les cas d’utilisation de la création et la suppression d’une
ferme:
System
administrateur
Gérer les fermes
Gérer les centres
Gérer les batiments
Gérer les services du resources humaines
s'authentifier
include
include
include
include
Administrateur
Créer ferme
Modifier ferme
supprimer ferme
rechercher ferme
S'authentifier
<<include>>
<<include>>
<<include>>
<<include>>

Page 41
 Description textuelle du cas d’utilisation « créer ferme » :
Use case 6 Créer ferme
Acteur
- Administrateur.
Scénario principal
- L’administrateur clique sur le module agricole
- L’administrateur clique sur le lien ferme
- L’administrateur clique sur le bouton « créer».
- L’administrateur saisit les informations générales
concernant la ferme et remplit les champs obligatoires et
non obligatoires.
- L’administrateur affecte le responsable de la ferme qui
hérite du module ressources humaines au champ
responsable.
- L’administrateur télécharge une image de la ferme
- L’administrateur clique sur le lien « ajouter un élément»,
c’est pour ajouter les centres affectés à la ferme.
concernant les centres.
- L’administrateur clique sur le lien « ajouter un élément»,
c’est pour ajouter les bâtiments affectés aux centres.
concernant les bâtiments.
- L’administrateur clique sur le bouton « enregistrer &
fermer ».
Pré-condition - L’administrateur authentifié.
Post -condition
- Ferme créée
- Centre et bâtiment créés (suivant le choix
d’administrateur)
Tableau 9: Cas d'utilisation créer ferme

Page 42
 Description textuelle du cas d’utilisation « supprimer ferme» :
Use case 6 Supprimer ferme
Acteur
- Administrateur
Scénario
principal
- L’administrateur sélectionne la ferme désirée pour la
supprimer
- L’administrateur clique sur le bouton « retirer ».
- L’administrateur clique sur le bouton « oui » après qu’un
message d’alerte s’affiche pour être sûr de la
suppression.
Pré-condition
- L’administrateur authentifié.
Post -condition - Ferme retiré
Tableau 10: Cas d'utilisation Supprimer ferme
Cas d’utilisation détaillé « gérer les centres » :
Ce cas d’utilisation inclut la création, la modification et la suppression des centres,
ainsi que leurs affectations à la ferme.
Le Tableau explique ce cas d’utilisation la création d’un centre :
 Description textuelle du cas d’utilisation « créer centre » :
Administrateur
Supprimer centre
Modifier centre
Ajouter centre
s'authentifier
Affecter centre au ferme
<<include>>
<<include>>
<<include>>
<<include>>
Créer batiment
<<include>>
Figure 25 : Diagramme de cas d’utilisation système: gérer centre

Page 43
Use case 6 Créer centre
Acteur - Administrateur
Scénario
principal
- L’administrateur clique sur le module agricole
- L’administrateur clique sur le lien centre
- L’administrateur clique sur le bouton « créer».
concernant la ferme et remplit les champs obligatoires et
non obligatoires.
- L’administrateur affecte le centre à la ferme dans
laquelle elle se situe situe ou il saisit les informations
générales concernant la ferme en cliquant au bouton
« créer ou modifier» au cas où il n’y a pas de ferme
créée au paravent.
concernant les bâtiments.
- L’administrateur clique sur le bouton « enregistrer &
fermer ».
Pré-condition - L’administrateur authentifié.
Post -condition
- Centre crée
- Bâtiments crées (suivant le choix d’administrateur)
Tableau 11:Description textuelle du d'utilisation créer centre
La spécification des besoins s’apparente à la phase d’analyse. Celle-ci permet de décrire
l’enchainement des différents cas d’utilisations, via plusieurs diagrammes. Nous avons choisi
quelques cas d’utilisations qui seront modélisés ci-dessous par des diagrammes de séquence
système.

Page 44
2.5. Diagramme de séquence système
Figure 26 : Diagramme de séquence système : créer ferme, centre et bâtiment
Le digramme de séquence met en exergue le scénario d’ajout d’une ferme, centres et
bâtiment à la fois. L’administrateur saisit les informations générales de ces biens, c’est selon
son choix il peut créer des centres et des bâtiments sous sa ferme à la fois c’est à dire notre
administrateur peut ajouter une ferme, centres et bâtiment avec un clique d’enregistrement.
créer ferme , centre et batimentsd
Athentificationref
: administrateur
Systéme
1 : saisir les informations relatives au ferme()
2 : lier le propriétaire à son compte RH()
3 : cliquer : bouton ajouter élément()
4 : ouvrir l'interface de création du centre
5 : saisir les informations relatives au centre()
6 : lier le chef centre à son compte RH()
7 : cliquer : bouton ajouter élément()
8 : ouvrir l'interface de création du batiment
9 : saisir les informations relatives au batiment()
10 : enregistrer et fermer()

Page 45
3. Conception
3.1. Diagramme de packages
Figure 27: Digrammes de packages sprint1
Le diagramme de packages précédant nous montre les différentes entités développés qui
interagissent pour réaliser ce sprint :
 Agriculture_view.xml : Fichier XML où nous avons développé les vues.
 Agriculture.py : Fichier Python où nous avons développé les objets.
 Agriculture_db : ORM spécifié à OpenERP pour générer les objets en des tables
dans la base de donnés.
3.2. Diagramme de classe
Le diagramme de classe illustre la conception de l’application pour le sprint 1 comme
l’indique le schéma ci-dessous.
Agriculture_view.xml
Agriculture.py
Agriculture_db

Page 46
Figure 28 : Diagramme de classe du sprint 1
Le diagramme de classes précèdent se compose de 3 classes développées dans notre
module d’agriculture qui font les biens de notre client agriculteur et nous les avons intégré
aux 2 autres classe prédéfinie sous OpenERP l’une est spécifique au module de ressources
humaines(hr_hr) qui hérite de l’autre classe (group) qui permet l’authentification pour la
sécurité de l’application et le privilège d’utilisation de chaque utilisateur.
.
ferme
+id: int
+titreferme: string
+gérant: int
+unite_mesure: string
+surface: string
+gouvernerat: string
+adresse: string
+image: bit
+nb_centre: int
+nb_batiment: int
centre
+id: int
+titre_centre: string
+unit_mesure: string
+surface: string
+emplacement: string
+image: bit
+chef: string
batiment
+id: int
+titre_batiment: string
+unité de surface: string
+surface: string
+emplacementstring
hr__hr
+id: int
+nom: string
+prenom: string
+login: string
+password: string
group
+id: int
+privileges: string
1 1..* 1 1..*
Les classes développées dans notre module
Les classes prédéfinies chez OpenERP

Page 47
3.3. Diagramme de séquence objet
Figure 29 : Diagramme séquence objet de l'ajout d'une ferme, centres et bâtiments
Le diagramme suivant illustre le scénario de l'ajout d'une ferme, d’un centre et d’un
bâtiment à la fois et leur insertion dans la base de données. Après s’être authentifié,
l’administrateur accède à l’interface d’ajout d’une nouvelle ferme, il saisit les données
relatives à la ferme puis de la même interface il peut saisir les données des centres et
bâtiments existant au sein de cette ferme, et enfin valide le tout.
Athentificationref
Diagramme de séquense object de l'ajout dune ferme , centres et batimentsseq
Agricuture.py Agricuture_view.xml Agriculture_db
: administrateur
1 : agriculture_ferme()
2 : agriculture.ferme.form()
3 : formulaire fourni
4 : saisir les données()
5 : agriculture_centre()
6 : agriculture.centre.form()
8 : saisir les donées()
9 : agriculture_batiment()
10 : agriculture.batiment.form()
12 : saisir les données et valider()
13 : requette de validation()
14 : agriculture.ferme,agriculture.centre,agriculture.batiment()

Page 48
4. Réalisation
Figure 30 : Interface Création du module Agriculture
Cette interface présente la création et la mise en place de notre nouveau module
d’agriculture.
Figure 31 : Interface création d’une ferme
La figure précédente représente l’interface de création d’une ferme, à partir de cette
interface, nous pouvons aussi ajouter un ou plusieurs centres aussi que un ou plusieurs
bâtiments

Page 49
Figure 32 : Interface gestion des centres
La figure précédente représente l’interface de gestion des centres. Nous pouvons, à
partir de cette interface, ajouter, modifier ou bien supprimer un centre, nous pouvons aussi
via cette interface après la création d’un centre, affecter ce dernier à la ferme spécifiée et créer
les bâtiments inclus dans ce centre.
Conclusion
Durant ce chapitre qui est consacré à la présentation de premier sprint, l’étude et
l’analyse fonctionnelle nous a permis d’identifier les différents acteurs de notre application
ainsi que leurs rôles. Nous nous sommes basés sur des diagrammes de cas d’utilisation
illustrés par des tableaux explicatifs, et des diagrammes de séquence. Nous avons procéder
ensuite à la conception, suivit par la phase de réalisation ou nous avons des captures d’écran
pour la rubrique des biens de l’agriculture ainsi que module ressources humaine.
Le chapitre suivant sera consacré pour la présentation de deuxième sprint.

Gestion de la_production_agricole_avec_openerp

Gestion de la_production_agricole_avec_openerp

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to Gestion de la_production_agricole_avec_openerp

Similar to Gestion de la_production_agricole_avec_openerp (20)

More from HORIYASOFT

More from HORIYASOFT (20)

Gestion de la_production_agricole_avec_openerp