• Save
Gestion de la_production_agricole_avec_openerp
Upcoming SlideShare
Loading in...5
×
 

Gestion de la_production_agricole_avec_openerp

on

  • 371 views

Travail de fin d'étude Développement avec openerp d'un module permet aux agriculteurs de gérer leurs biens et leurs production agricoles ...

Travail de fin d'étude Développement avec openerp d'un 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

Statistics

Views

Total Views
371
Views on SlideShare
371
Embed Views
0

Actions

Likes
0
Downloads
20
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Gestion de la_production_agricole_avec_openerp Gestion de la_production_agricole_avec_openerp Document Transcript

  • 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. View slide
  • 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. View slide
  • 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 2. Analyse et spécification des besoins .................................................................. 51 2.1. Besoins fonctionnels ................................................................................... 51 2.2. Besoins non fonctionnels ............................................................................ 51 2.3. Identification des acteurs ............................................................................ 52 2.4. Diagramme de cas d’utilisation .................................................................. 52 2.5. Diagramme de séquence système ............................................................... 57 3. Conception ......................................................................................................... 58 3.1. Diagramme de packages.................................................................................. 58 3.2. Diagramme de classe .................................................................................. 59 3.3. Diagramme de séquence objet .................................................................... 60 3.4. Diagramme d’activités................................................................................ 61 4. Réalisation.......................................................................................................... 62 Conclusion................................................................................................................... 64 Chapitre 6 : Sprint 3........................................................................................................ 65 Introduction................................................................................................................. 65 1. Backlog Sprint.................................................................................................... 65 2. Analyse et spécification des besoins .................................................................. 66
  • Table des Matières Page VIII 2.1. Besoins fonctionnels ................................................................................... 66 2.2. Besoins non fonctionnels ............................................................................ 66 2.3. Identification des acteurs ............................................................................ 66 2.4. Diagramme de cas d’utilisation .................................................................. 66 2.5. Diagramme de séquence système ............................................................... 72 3. Conception ......................................................................................................... 73 3.1. Diagramme de classe .................................................................................. 73 3.2. Diagramme de séquence objet .................................................................... 74 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 2.2. Besoins non fonctionnels ............................................................................ 82 2.3. Identification des acteurs ............................................................................ 83 2.4. Diagramme de cas d’utilisation .................................................................. 83 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 Figure 68 : Vue graphique 2 ........................................................................................... 90 Figure 69 : Vue graphique 3 ........................................................................................... 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
  • Chapitre 1 : Présentation Générale 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
  • Chapitre 1 : Présentation Générale 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.
  • Chapitre 2 : Etat de L’Art 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
  • Chapitre 2 : Etat de L’Art 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
  • Chapitre 2 : Etat de L’Art 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.
  • Chapitre 2 : Etat de L’Art 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
  • Chapitre 2 : Etat de L’Art 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.
  • Chapitre 2 : Etat de L’Art 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
  • Chapitre 2 : Etat de L’Art 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
  • Chapitre 2 : Etat de L’Art 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
  • Chapitre 2 : Etat de L’Art 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 Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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 :
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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.
  • Chapitre 3 : Sprint 0 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é.
  • Chapitre 3 : Sprint 0 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,…
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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.
  • Chapitre 3 : Sprint 0 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.
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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)
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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 :
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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>>
  • Chapitre 3 : Sprint 0 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
  • Chapitre 3 : Sprint 0 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 primordiales à la définition d’une production animale non cyclique Végétale Classe contient toutes les informations primordiales à la définition d’une production 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.
  • Chapitre 4 : Sprint 1 Page 38 Chapitre 4 : Sprint 1 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
  • Chapitre 4 : 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
  • Chapitre 4 : Sprint 1 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>>
  • Chapitre 4 : Sprint 1 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. - L’administrateur saisit les informations générales concernant les centres. - L’administrateur clique sur le lien « ajouter un élément», c’est pour ajouter les bâtiments affectés aux centres. - L’administrateur saisit les informations générales 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
  • Chapitre 4 : Sprint 1 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
  • Chapitre 4 : Sprint 1 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». - L’administrateur saisit les informations générales 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. - L’administrateur saisit les informations générales 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.
  • Chapitre 4 : Sprint 1 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()
  • Chapitre 4 : Sprint 1 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
  • Chapitre 4 : Sprint 1 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
  • Chapitre 4 : Sprint 1 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() 7 : formulaire fourni 8 : saisir les donées() 9 : agriculture_batiment() 10 : agriculture.batiment.form() 11 : formulaire fourni 12 : saisir les données et valider() 13 : requette de validation() 14 : agriculture.ferme,agriculture.centre,agriculture.batiment()
  • Chapitre 4 : Sprint 1 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
  • Chapitre 4 : Sprint 1 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.
  • Chapitre 5 : Sprint 2 Page 50 Chapitre 5 : Sprint 2 Introduction Ce deuxième sprint s’étale sur cinq semaines. Nos efforts se focalisent sur le développement de la partie du workflow des différents types de production. Nous présentons en premier lieu le Backlog sprint. Par la suite nous attaquons la phase d’analyse et spécifications des besoins, suivie de la phase de conception de notre application. Finalement, au cours de la phase de réalisation, nous présentons des captures d’écran présentant des scénarios d’utilisation qui nous montre l’accomplissement de ce sprint. 1. Backlog Sprint Le deuxième sprint consiste à réaliser les 8, 9 et 10 du Product Backlog. Les tâches à réaliser sont présentées dans le tableau suivant : Story id Nom Description 8 Gestion production animale cyclique - Conception de rubrique de gestion de la production animale cyclique - Développement de workflow de la production animale cyclique - Réalisation des interfaces de la rubrique - Intégration de la rubrique de production avec les biens de l’agriculteur - Test unitaire - Tester l’intégration 9 Gestion production animale non cyclique - Conception de rubriques de gestion de la production animale non cyclique - Développement de la rubrique gestion de production animale non cyclique - Réalisation des interfaces de la rubrique - Intégration de la rubrique de production avec les biens de l’agriculteur - Test unitaire
  • Chapitre 5 : Sprint 2 Page 51 Tester l’intégration 10 Gestion production végétale - Conception de rubrique de gestion de la production végétale - Développement de workflow de la production végétale - Réalisation des interfaces de la rubrique - Intégration de la rubrique de production avec les biens de l’agriculteur - Test unitaire - Tester l’intégration Tableau 12: Backlog sprint 2 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 :  Offrir deux workflow pour les productions animales cycliques et les productions végétales.  Offrir une rubrique des productions animales non cycliques. 2.2. Besoins non fonctionnels Au cours de notre étude du système actuel nous avons recensé les besoins non fonctionnels suivants :  L’ergonomie et la convivialité : C’est l’une des clés du succès de notre application. Lorsque le client se trouve face à notre application, l'objectif est de lui permettre une consultation simple, claire et efficace, l'incitant à poursuivre ses recherches et à lancer une production avec la moindre clique.  La richesse informationnelle : Elle se définit par la présence d'informations utiles pour le client à fin de l’aider à choisir le produit dont il veut produire.  L’aide
  • Chapitre 5 : Sprint 2 Page 52 L’utilisateur va être en contact direct et unique avec l’interface. Pour lui l’application c’est une interface à manipuler, ce qui la rend d’une grande importance dans la conception de notre application. Certains critères doivent être respectés à savoir:  Clarté et bonne lisibilité des boutons, des labels.  Tous les boutons, label, expriment les actions qu’ils exécutent.  Facilité de manipulation et rapidité d’exécution. 2.3. Identification des acteurs - Le gestionnaire de production de notre application : Cet acteur est en contact avec l’application, Il peut consulter et gérer tous types de productions, et affecter chaque production au centre spécifié. 2.4. Diagramme de cas d’utilisation La Figure représente le cas d’utilisation général du sprint 2. Il sera raffiné d’avantage dans ce qui suit. Figure 33: Diagramme de cas d'utilisation système: sprint 2 Cas d’utilisation détaillé « gérer les production animales cyclique » : System gestionnaire de production Gérer les productions animales cyclique Gérer les productions végétales s'authentifierGérer les productions animales non cyclique <<include>> <<include>> <<include>>
  • Chapitre 5 : Sprint 2 Page 53 Ce cas d’utilisation inclut la création, la modification, la suppression et la recherche des productions animales cycliques. Les Tableaux expliquent les cas d’utilisation la création, la modification et la recherche d’une production animale cyclique :  Description textuelle du cas d’utilisation « créer une production animale cyclique » Use case 8 créer une production animale cyclique Acteur - Gestionnaire de production. Scénario principal - Le gestionnaire clique sur le module Agriculture - Le gestionnaire clique sur le lien production animale cyclique - Le gestionnaire clique sur le bouton « créer» - Le gestionnaire saisit le titre de la production en affectant le type de production au produit créé en stock ensuite en affectant l’emplacement de cette production au centre spécifié. - Le gestionnaire clique sur le bouton « lancer la production», et une date de début de cycle sera créée par défaut suivant la date du système, ainsi l’état de la production sera « En cours» - Le gestionnaire aura l’accès sur une autre page de dépense gestionaire de production ajouter production aimale cyclique modifier production aimale cyclique supprimer production aimale cyclique rechercher production aimale cyclique s'authentifier <<include>> <<include>> <<include>> <<include>> lancer la production finaliser la production <<include>> <<include>> Figure 35: Diagramme de cas d'utilisation : gérer production animale cyclique
  • Chapitre 5 : Sprint 2 Page 54 qu’on va la développer dans le prochain sprint. - Le gestionnaire saisit la date des entré des effectifs et ainsi il a l’accès sur une autre page des enlèvements qu’on va la développer dans le prochain sprint. - Le gestionnaire clique sur le bouton « Finaliser la production», et une date de fin de cycle sera créée par défaut suivant la date du système, ainsi l’état de la production sera « Fin». - Le gestionnaire clique sur le bouton « enregistrer & fermer ». Pré-condition - L’administrateur authentifié. Post -condition - Production créée - Affectation de la production au lieu de la création - Statut de la production transformée suivant son état Tableau 13 : Cas d'utilisation créer une production animale cyclique  Description textuelle du cas d’utilisation « modifier une production animale cyclique» : Use case 8 modifier une production animale cyclique Acteur - Le gestionnaire Scénario principal - Le gestionnaire demande la vue de modification d’une production en choisissant la production depuis la liste - Le gestionnaire clique sur le bouton « modifier ». - Le gestionnaire complète les champs nécessaires et valide. - Le gestionnaire est redirigé vers la liste des productions afin de vérifier la modification. Pré-condition - Le gestionnaire authentifié. Post -condition - Production animale cyclique modifiée Tableau 14: Cas d'utilisation modifier une production animale cyclique
  • Chapitre 5 : Sprint 2 Page 55  Description textuelle du cas d’utilisation « rechercher une production animale cyclique» Use case 8 rechercher une production animale cyclique Acteur - Le gestionnaire Scénario principal - Le gestionnaire demande l’attribut de recherche de la production - Le gestionnaire saisit la valeur de l’attribut destiné à chercher - Le gestionnaire clique sur le bouton « appliquer ». - Le gestionnaire est redirigé vers la production dédiée Pré-condition - Le gestionnaire authentifié. Post -condition - Production animale cyclique trouvée Tableau 15: Cas d'utilisation rechercher une production animale cyclique Cas d’utilisation détaillé « gérer les production animales non cyclique » : gestionaire de production ajouter production animale non cyclique supprimer production animale non cyclique modifier production animale non cyclique rechercher production animale non cyclique s'authentifier <<include>> <<include>> <<include>> <<include>> Figure 36 : Diagramme cas d’utilisation:gérer les productions animales non cycliques
  • Chapitre 5 : Sprint 2 Page 56  Description textuelle du cas d’utilisation « créer une production animale non cyclique» Use case 9 créer une production animale non cyclique Acteur - Gestionnaire de production. Scénario principal - Le gestionnaire clique sur le module Agriculture - Le gestionnaire clique sur le lien production animale non cyclique - Le gestionnaire clique sur le bouton « créer» - Le gestionnaire saisit le titre de la production en affectant le type de production au produit crée en stock ensuite il affecte l’emplacement de cette production au centre spécifié et remplit tout le formulaire spécifié à cette production - Le gestionnaire clique sur le bouton « enregistrer & fermer » Pré-condition - Le gestionnaire authentifié. Post -condition - Production créée - Affectation de la production au lieu de la création Tableau 16:Cas d'utilisation créer une production animale non cyclique  Description textuelle du cas d’utilisation « supprimer une production animale non cyclique » Use case 9 Supprimer une production animale non cyclique Acteur - Le gestionnaire de production Scénario principal - Le gestionnaire sélectionne la production désirée pour la supprimer - Le gestionnaire clique sur le bouton « retirer ». - Le gestionnaire clique sur le bouton « oui » après qu’un message d’alerte s’affiche pour être sûr de la suppression.
  • Chapitre 5 : Sprint 2 Page 57 Pré-condition - Le gestionnaire authentifié. Post -condition - Production retirée Tableau 17: Cas d'utilisation supprimer une production animale non cyclique Nous avons choisi un cas d’utilisation qui va être modélisé ci-dessous par un diagramme de séquence système concernant le scénario d’une production végétale. 2.5. Diagramme de séquence système Figure 37: Diagramme de séquence : créer une production végétale Le digramme de séquence figure met en exergue le scénario du wokflow de production végétale dès le lancement du cycle. créer une production végétaleref Authentificationref systéme : gestionaire production 1 : saisir les informations relatives à la production végétale() 2 : enregister() 3 : production enregistrée en état "debut" 4 : modifier() 5 : cliquer sur le bouton "lancer la production"() 6 : transmettre la production en état "En cours"() 7 : afficher l'interface de la dépense et afficher la date debut du cycle 8 : saisir la date de semer des graines() 9 : afficher l'interface de l'enlévement 10 : enregister() 11 : modifier() 12 : cliquer sur le bouton "finaliser la production"() 13 : transmettre la production en état "Fin"() 14 : afficher la date du fin du cycle 15 : enregister & fermer()
  • Chapitre 5 : Sprint 2 Page 58 Le gestionnaire de production saisit les informations générales de la production et depuis il lance le cycle en s’aidant du bouton du lancement de cycle, le cycle passe alors de son état initiale (Début) vers l’état qui le suit (En cours) et puis un nouvelle page de dépense s’affiche, (sera développé dans le prochain Sprint). Suivant cette action la date de lancement du cycle va se créer automatiquement suivant la date du système. Ensuite le gestionnaire a l’accès pour saisir la date de semée des graines, et confirme les enlèvements. Suivant cette action une autre page des enlèvements s’affiche (sera également développé dans le prochain sprint). Enfin dès que le cycle de production végétale touche à sa fin, le gestionnaire finalise le cycle en cliquant au bouton de finalisation du cycle d’où le passage de son état précédant (En cours) vers l’état qui le suit (Fin cycle), et par suite il n’as pas le droit ni de modifier aucun attribut de ce cycle ni de le supprimer. 3. Conception 3.1. Diagramme de packages Figure 38: Diagramme de package sprint 2 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_workflow_view.xml : Fichier XML où nous avons développé les vues des workflows.  Agriculture.py : Fichier Python où nous avons développé les objets et les fonctions des workflows  Agriculture_db : ORM spécifié à OpenERP pour générer les objets en des tables dans la base de donnés. Agriculture_workflow_view.xml Agriculture.py Agriculture_db
  • Chapitre 5 : Sprint 2 Page 59 3.2. Diagramme de classe Le diagramme de classe illustre la conception de l’application pour le sprint 2 comme l’indique le schéma ci-dessous. Le diagramme de classes précèdent se compose de 8 classes, qui constituent le cœur même de notre application à savoir les classes : ( animale_cycle ), ( végétale ), (aniamle_non_cycle) , qui sont reliées à la classe centre, sous une cardinalité de (1..*), car un centre peut avoir une ou plusieurs productions. Ces classes aussi sont reliées à la classe ( product_product ) qui est prédéfinie dans le module stock , afin de préciser la nature du production : soit animale soit végétale. . centre +id_centre: int_pk +titre_centre: string +unit_mesure: string +surface: string +emplacement: string +image: bit animale_cycle +id: int_pk +image: bit +date_entre_effectifs: date +effectifs entres: int +mal: int +femelle: int +date_debut_cycle: date +date_fin_cycle: date +valid_date: boolen +state: string animale_non_cycle +id: int_pk +image: bit +mal: int +femelle: int +effectifs entres: int +date_entre_effectifs: date vegetale +id: int_pk +image: bit +date_plante: date +date_recolte: date +date_debut_cycle: date +date_fin_cycle: date +valid_date: boolen +state: string product__product +id: int product__category +id: int group +id: int +privileges hr_hr +id: int +noml: string +login: string +password: string 0..* 1 0..* 1 0..* 1 Figure 39 : Diagramme de classe du sprint 2 Les classes développées dans notre module Les classes prédéfinies chez OpenERP
  • Chapitre 5 : Sprint 2 Page 60 3.3. Diagramme de séquence objet Figure 41: Diagramme de séquence objet : production animale cyclique Authentificationref Agriculture.py Agriculture_workflow_view.xml Agriculture_db : administrateur 1 : animale_cycle_debut() 2 : animale.cycle.form() 3 : Formulaire généré 4 : saisir les donées et valider() 5 : requette de validation 6 : animale.cycle() 7 : production aniamle cyclique ajouté 8 : animale_cycle_encours() 9 : lancer production() 10 : date_debut_cycle , state 11 : defaults: date_debut_cycle ,state=en_cours() 12 : date debut cycle , status : en cours() 13 : date et status généré 14 : date_entré_effectis() 15 : Date entré effectifs() 16 : depense.form() 17 : date généré 18 : saisr la date et valider() 19 : requette de validation 20 : animal.cycle.date_entree_effectifs() 21 : date_debut_cycle ,depense 22 : valide_date=true() 23 : commencer les enlévements() 24 : donnés saisies 25 : enlévement.form() 26 : requette de validation 27 : aniamle.cycle.valide_date() 28 : enlévement() 29 : animale_cycle_fin() 30 : finaliser production() 31 : date_fin_cycle , state() 32 : defauls:date_fin_cycle , state =fin() 33 : unlik : readonly_animal_cycle()
  • Chapitre 5 : Sprint 2 Page 61 Diagramme de séquence objet du workflow de production animale cyclique nous montre quelles sont les étapes par lesquelles doit passer l’utilisateur afin de créer un cycle de production, dès le lancement du cycle jusqu’au la fin du cycle. 3.4. Diagramme d’activités Ce diagramme d’activité nous montre le séquencement des actions entre l’utilisateur (gestionnaire de production), l’interface d’utilisation et la base de données de lancements d’un cycle de production végétale. Gestionnaire de production Interface demander l'interface d'authentification affichager l'interface saisir le login et le mot de passe message d'erreure accéder à l'application demander la rubrique du production végétale affichager le formulaire spécifié saisir les donées du production et liéer les champs spécifiés aux autres modules confirmation du lancement du production oui non Figure 42: Diagramme d'activité du lancement d'une production végétale
  • Chapitre 5 : Sprint 2 Page 62 4. Réalisation Figure 43 : Interface création d’un cycle animale La figure précédente représente l’interface de création d’un cycle en affectant le type de production animale au produit en stock, et l’emplacement de cette production (centre). Figure 44 : Interface lancement d’un cycle animale La figure précédente représente l’interface de lancement d’un cycle et la transition de l’état du cycle de (début) vers (en cours) et la récupération automatique de la date de début de ce cycle suivant la date du système.
  • Chapitre 5 : Sprint 2 Page 63 Figure 45 : Interface finalisation d’un cycle animale La figure précédente représente l’interface de la finalisation d’un cycle et la transition de l’état du cycle de (en cours) vers (fin cycle) et la récupération automatique de la date de fin de ce cycle suivant la date du système. Figure 46 : Interface rechercher cycle sous une vue de calendrier La figure précédente représente l’interface de la recherche d’un cycle sous une vue calendrier qui nous donne les statuts des cycles en paramètre. Il suffit de cocher un type de ces statuts et par suite les cycles s’affichent sur le calendrier suivant sa date de début.
  • Chapitre 5 : Sprint 2 Page 64 Figure 47 : Interface interdiction de la suppression d’un cycle finalisé La figure précédente représente l’interface d’exception c’est l’interdiction de la suppression d’un cycle lorsque son état est (fin). Conclusion A la fin de ce sprint, les tâches planifiées dans le Backlog sprint sont développées testées et validées par notre client et par le testeur faisant partie de notre équipe. Nous avons présentés à la fin de ce chapitre une partie démonstrative soutenue avec des captures d’écran, où nous avons met en exergue les différentes fonctionnalités de notre application réalisées durant ce sprint. Le chapitre suivant sera consacré pour la présentation de troisième sprint
  • Chapitre 6 : Sprint 3 Page 65 Chapitre 6 : Sprint 3 Introduction Le troisième sprint a pour durée cinq semaines, nous allons dans ce chapitre traiter le cœur même de notre projet , c’est à dire terminer les workflow faits dans le chapitre précédant par la conceptions et le développement des rubriques des dépenses et enlèvements de chaque production et les intégrer avec le mouvement en stock. Nous commençons d’abord par évoquer les besoins fonctionnels et non fonctionnels de l’application, ensuite nous abordons la phase de conception et nous finissons avec la phase de réalisation. 1. Backlog Sprint. Le troisième sprint consiste à réaliser les entrées 11, 12,13, 14 et 15 du Product Backlog. Les tâches à réaliser sont présentées dans le tableau suivant : Story id Nom Description 11 Gestions des dépenses - Conception de rubrique des gestions des dépenses par production - Développement des rubriques des gestions des dépenses - Réalisation des interfaces de la rubrique - Test unitaire - Tester l’intégration 12 Gestions des enlèvements - Conception de rubrique des gestions des enlèvements par production - Développement de rubrique des gestions des enlèvements - Réalisation des interfaces de la rubrique - Test unitaire - Tester l’intégration 13 Installation module stock - Installation, configuration et mise en place du module stock - Test unitaire - Tester l’intégration 14 Intégration module - Intégration du module stock avec le module Agriculture - Test unitaire
  • Chapitre 6 : Sprint 3 Page 66 stock - Tester l’intégration 15 Intégration mouvements du stock - Intégration des dépenses et enlèvements aux mouvements du stock de l’OpenERP. - Synchroniser le module stock de l’OpenERP avec le module Agriculture. - Réalisation des interfaces de la rubrique Tester l’intégration - Test unitaire - Tester l’intégration Tableau 18: Backlog sprint 3 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 :  Offrir deux workflow complets pour les productions animales cycliques et les productions végétales.  Offrir une rubrique des productions animales non cycliques complètes.  Offrir un mouvement de stock chez la Platform OpenERP via notre module d’agriculture à travers les dépenses et les enlèvements. 2.2. Besoins non fonctionnels L’application doit assurer d’autres besoins qui ne sont pas fonctionnels mais ils ne manquent pas d’importance. En effet, il faut que notre application :  Soit précise, il faut que toute information fournie soit précise et détaillée.  Optimise les traitements pour avoir un court temps de réponse. 2.3. Identification des acteurs Durant ce sprint les acteurs de notre application sont l’administrateur et le gestionnaire de production. Ce dernier est en contact avec l’application, Il peut consulter, gérer les workflow de tous types de productions et gérer les dépenses et les enlèvements de chaque production qui sont intégrer au module stock, auquel il a aussi le droit de consultation. 2.4. Diagramme de cas d’utilisation La Figure représente le cas d’utilisation général du sprint 3. Il sera raffiné d’avantage dans ce qui suit.
  • Chapitre 6 : Sprint 3 Page 67 Figure 48 : Diagramme de cas d'utilisation système : sprint 3 Cas d’utilisation détaillé « gérer les dépenses d’un workflow complet des productions animales cyclique » : System Gestionnaire de production Gérer les productions animales cycliques Gérer les productionanimales noncyclique Gérer les productions végétales Gérer les dépenses animales cyclique gérer les enlèvements aniamles cyclique s'authentifier Gérer les dépenses végératles Gérer les enlévements végétales Gérer les dépenses animales noncyclique Gérer les enlèvements aniamles noncyclique <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<include>> <<include>> <<include>>
  • Chapitre 6 : Sprint 3 Page 68 Figure 49: Digramme de cas d’utilisation: gérer les dépenses de production animale cyclique Ce cas d’utilisation inclut la création, la modification, la suppression et l’affichage des dépenses de chaque production animale cyclique. Le Tableau explique le cas d’utilisation de la création d’une dépense :  Description textuelle du cas d’utilisation « créer une dépense» Use case 11 créer une dépense pour la production animale cyclique Acteur - Gestionnaire de production. Scénario principal - Le gestionnaire clique sur le module Agriculture - Le gestionnaire clique sur le lien production animale cyclique - Le gestionnaire sélectionne la production dont il veut ajouter une dépense. - Le gestionnaire clique sur le bouton « modifier ». - Le gestionnaire clique à la rubrique « dépense » via le bouton rubrique « ajouter élément ». gestionaire de production ajouter une dépense supprimer une dépense modifier une dépense lancer la production finaliser la production modifier une production animale cyclique ajouter une production animale cyclique supprimer une production animale cyclique afficher la liste des productions animales cyclique s'authentifier afficher la liste des dépenses <<extend>> <<extend>> <<extend>> <<extend>> <<include>> <<include>> <<include>> <<include>> <<include>>
  • Chapitre 6 : Sprint 3 Page 69 - Le gestionnaire saisit le titre de la dépense en affectant le type de dépense au produit créé en stock. - Le gestionnaire saisit la quantité, l’unité de mesure.Par suite notre application lui fournit la quantité disponible en stock et le prix d’achat unitaire du produit désiré pour faire cette dépense ainsi que la date de cette dépense et le chargé de cette action, et bien sûr non modifiable. Pour but d’avoir une bonne traçabilité aux dépenses faites. - Le gestionnaire clique sur le bouton « enregistrer ». - Le gestionnaire clique sur le bouton « enlever» relative à la dernière dépense qu’il a fait afin d’enlever la quantité du produit saisie auparavant pour faire le mouvement en stock Pré-condition - Gestionnaire de production authentifié. - Production lancée Post -condition - Ajout des dépenses relatives à la production. - Quantité du produit désiré à la dépense diminué en stock. Tableau 19:Créer une dépense de cycle de production animale cyclique Cas d’utilisation détaillé « gérer les enlèvements d’un workflow complet des productions végétales» :
  • Chapitre 6 : Sprint 3 Page 70 Figure 50 : Diagramme de cas d’utilisation : gérer les enlèvements de production végétale Ce cas d’utilisation inclus la création, la modification, la suppression et l’affichage des enlèvements au sein d’un cycle de production végétale. Les Tableaux expliquent création et la suppression ce cas d’utilisation.  Description textuelle du cas d’utilisation « créer un enlèvement» Use case 12 créer un enlèvement pour la production végétale Acteur - Gestionnaire de production. Scénario principal - Le gestionnaire clique sur le module Agriculture - Le gestionnaire clique sur le lien production végétale - Le gestionnaire sélectionne la production dont il veut ajouter un enlèvement. - Le gestionnaire clique sur le bouton « modifier ». - Le gestionnaire coche l’attribut du commencement des enlèvements. gestionnaire de production lancer la production ajouter une production végétale afficher la liste des production végétales modifier une production végétale finaliser la production supprimer une production végétale ajouter un enlévement supprimer un enlévement afficher la liste des enlévements modifier un enlévement s'authentifier <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<extend>> <<extend>> <<extend>> <<extend>>
  • Chapitre 6 : Sprint 3 Page 71 - Le gestionnaire clique à la rubrique « enlèvement» via le bouton rubrique « ajouter élément ». - Le gestionnaire saisit la quantité du produit de cet enlevé, et le prix de vente unitaire du produit par suite notre application lui fournit la date de cet enlèvement. - Le gestionnaire clique sur le bouton « enregistrer & fermer ». - Le gestionnaire clique sur le bouton « ajouter» relativf au dernier enlèvement qu’il a fait afin d’ajouter la quantité du produit de cette production saisie auparavent pour faire le mouvement en stock chez OpenERP. Pré-condition - Le gestionnaire authentifié - Production lancée - Enlèvement commencé Post -condition - Ajout des enlèvements en relation à la production. - Quantité du produit désiré à la dépense augmente en stock. Tableau 20: Créer un enlèvement d'une production végétale  Description textuelle du cas d’utilisation « supprimer un enlèvement» Use case 12 Supprimer un enlèvement d’une production végétale Acteur - Le gestionnaire de production Scénario principal - Le gestionnaire sélectionne la production désirée pour la modifier - Le gestionnaire clique sur le bouton « modifier». - Le gestionnaire sélectionne l’enlèvement désirée pour le supprimer - Le gestionnaire clique sur l’icône de suppression après qu’un message d’alerte s’affiche pour être sûr de la suppression. - Le gestionnaire clique sur le bouton « enregistrer & fermer ». Pré-condition - Le gestionnaire authentifié - Production lancée
  • Chapitre 6 : Sprint 3 Page 72 - Enlèvement commencé Post -condition - Enlèvements retirés Tableau 21: Supprimer un enlèvement d'une production végétale Nous avons choisi quelques cas d’utilisations qui seront modélisés ci-dessous par des diagrammes de séquence système concernant des scénarios spécifiques à ce sprint. 2.5. Diagramme de séquence système Figure 51 : Diagramme de séquence de l’ajout d’une dépense au sein d’une production animale cyclique Après s’être authentifié et une fois la production est lancée, le gestionnaire de la production demande la vue d’ajout d’une nouvelle dépense, il saisit les données de la dépense relatives à la production à laquelle elles appartiennent. Ensuite il demande la vue du mouvement du stock, pour enlever la quantité du produit dépensé du stock. Authentficationref lancement du productionref : gestionaire production systéme 1 : saisir le non du produit de la dépense() 2 : fournir la quantité disponible et le prix unitaire d'achat de produit seléctioné() 3 : confirmation() 4 : dépense ajoutée 5 : enléver la quantité du produit de la dépense du stock() 6 : quantité du produit diminué du stock
  • Chapitre 6 : Sprint 3 Page 73 3. Conception 3.1. Diagramme de classe Le diagramme de classe illustre la conception de l’application pour le sprint 3 comme l’indique le schéma ci-dessous. Figure 52 : Diagramme de classe sprint 3 D’après le diagramme de classes ci-dessus, nous constatons que nous avons pour ce troisième sprint trois classes principales qui illustrent les trois types du production (végétale, animale cyclique, animales non cyclique), dont chaque classe de ces derniers s’associés deux classes qui montrent les spécifications des dépenses et des enlèvement spécifiques à chaque type de production suivant ces attributs.Ces classes développées dans notre module communiquent avec la classe (product_product) prédéfinie chez Openerp que nous utilisons pour la sélection du produit suivant son type. Aussi nos classes communiquent avec la classe (stock_move) qui nous sert à mettre le mouvement du stock pour chaque dépense et enlèvement. 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 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 stock__move +id: int product__product +id: int product__uom +id: int product__category +id: int 1..* 1 1..* 1 1..*1 1..* 1 1..* 1 1..*1 Les classes développées dans notre module Les classes prédéfinies chez OpenERP
  • Chapitre 6 : Sprint 3 Page 74 3.2. Diagramme de séquence objet Figure 53 : Diagramme de séquence objet de l’ajout d’un enlèvement au sein d’une production animale cyclique créer un enlévementsd Authentificationref selection et lancement du productionref comencement des enlévementsref : gestionaire production Agriculture.py Agriculture_view.xml Agriculture_db 1 : animale_cycle_enlévement() 2 : animale.cycle.enlévement.form() 3 : formualire fourni() 4 : saisr les données() 5 : requette de validation() 6 : animale.cycle.enlévement() 7 : enlévement ajouté() 8 : animale_cycle_enlev() 9 : stock.move.view() 10 : formulaire mouvement du stock fournie() 11 : valider() 12 : requette de validation() 13 : augmenter la quantité du produit enlevé en stock() 14 : quantité du produit augmenté en stock
  • Chapitre 6 : Sprint 3 Page 75 Le diagramme de séquence objet précédant nous montre quelles sont les étapes par lesquelles doit passer le gestionnaire de production afin d’ajouter un enlèvement au sein d’un workflow d’une production animale cyclique. Après que notre utilisateur se soit authentifié et que la production soit dans l’état (en cours), il demande la vue de l’enlèvement il saisit les données spécifiques à cet enlèvement c’est de mettre la quantité produite. Enfin il doit créer le mouvement du stock pour cette action, afin que la quantité de ce produit s’augmente en stock, et dans l’objectif but d’avoir une traçabilité d’inventaire de stock à la fin.
  • Chapitre 6 : Sprint 3 Page 76 3.3. Diagramme d’activités Figure 54 : Diagramme d’activité d’une production végétale avec dépense Gestionnaire de production Interface demander l'interface d'authentification affichager de l'interface saisir le login et le mot de passe message d'erreure accéder à l'application demander la rubrique du production végétale afficher le formulaire spécifié saisir les donées du production et liéer les champs spécifiés aux autres modules confirmer le lancement du production cocher l'icône du lancement des enlévement saisir les donnés relative à cet enlévement : la quantité produite et le prix unitaire de vente affichage de la rubrique des enlévements confirmer afficher de la somme totale des vents et la quantité produite de cette production synchroniser l'ajout de la dérniére quantité produite avec la quantité en stock demander l'interface du mouvement du stock affichage l'interface du mouvement du stock augmentation de la quantité du produit au stock transmettre l'état de la production en (en_cours)ouinon non oui non oui
  • Chapitre 6 : Sprint 3 Page 77 Ce diagramme d’activité nous montre le séquencement des actions entre l’utilisateur (gestionnaire de production), l’interface d’utilisation et la base de données d’un workflow complet d’une production végétale en interrogeant une dépense. 4. Réalisation Figure 55 : Interface de création d’une dépense La figure précédente représente l’interface da création d’une dépense au sein d’une production animale cyclique. Il suffit de saisir le produit de la dépense qui hérite des produits ajoutés en stock et la quantité désirée, l’utilisateur remarque que la quantité disponible en stock et le prix unitaire d’achat vont être saisis automatiquement. Dès que l’utilisateur valide son opération la somme totale des dépenses de ce cycle s’affiche.
  • Chapitre 6 : Sprint 3 Page 78 Figure 56 : Interface de création d’un mouvement de stock pour une dépense La figure précédente représente l’interface da création d’un mouvement de stock pour une dépense, il suffit de cliquer sur le bouton « enlever », ensuite la quantité du produit de la dépense saisie auparavant va se diminuer du stock. Figure 57 : Interface de création d’un enlèvement
  • Chapitre 6 : Sprint 3 Page 79 La figure précédente représente l’interface da création d’un enlèvement au sein d’une production animale cyclique. La quantité désirée et le prix unitaire de vente. Et dès que l’utilisateur valide son opération la somme totale des quantités produites et la somme totales des ventes de ce cycle s’affichent. Figure 58 : Interface de création d’un mouvement de stock pour un enlèvement La figure précédente représente l’interface da création d’un mouvement de stock pour un enlèvement, il suffit de cliquer sur le bouton « ajouter », ensuite la quantité du produit de l’enlèvement saisit au paravent va augmenter en stock. Figure 59: Interface du bénéfice du cycle
  • Chapitre 6 : Sprint 3 Page 80 La figure précédente représente l’interface du bénéfice du cycle c’est de faire soustraire le total des ventes par rapport au total du dépense, et cette figure ne s’affiche que lorsque le cycle en état Fin, cette figure alors nous montre la rentabilité du cycle. Conclusion Nous avons, tout au long de cette partie, cherché à expliquer les spécifications du sprint étudié à travers les différents diagrammes et fonctionnalités dont il se compose. Pour cela, nous avons donné un aperçu sur le dénouement du sprint à travers les diverses interfaces qui le constituent. Ce sprint nous a permis de mettre en avant les connaissances en matière de génie logiciel et de conduite de projet. Ce sprint est finalisé par une réunion avec notre client aboutissant à son accord et son validation sur les fonctionnalités réalisées dans ce sprint, et nous donne son accord au passage au sprint suivant.
  • Chapitre 7 : Sprint 4 Page 81 Chapitre 7 : Sprint 4 Introduction Le quatrième sprint a pour durée cinq semaines, nous allons dans ce chapitre développer un autre module de reporting qui met en évidence les critères de chaque cycle de production dans un document PDF, nous avons généré les rapports de notre module via utilisation de l’outil de reportnig (OpenOffice 4.0.1) qui est la dernière version dont de nombreux bogues et des failles de sécurité sont corrigés. [9] Aussi durant ce sprint nous avons développé des rubriques spécifiques aux dépenses totales de chaque type production, de plus développer et intégrer des vues graphique de statistique pour avoir des vues plus simples pour les quantités totales enlevées pour chaque type de production. Dans ce chapitre alors nous récoltons les besoins, nous présentons l’analyse et la conception de notre application. Une partie démonstrative soutenue par des captures d’écran est évoquée à la fin. 1. Backlog Sprint Le quatrième sprint consiste à réaliser les entrées 16, 17, 18,19 et 20 du Product Backlog. Les tâches à réaliser sont présentées dans le tableau suivant : Story id Nom Description 16 Totalités des dépenses par type de productions - Conception des rubriques qui mettent en évidence la totalité des dépenses de chaque type de production - Développement des rubriques - Réalisation des interfaces des rubriques. - Test unitaire - Tester l’intégration 17 Statistiques - Développement et génération des vues graphiques pour avoir une analyse de données de statistiques des quantités totales enlevées pour chaque type de production. - Test unitaire
  • Chapitre 7 : Sprint 4 Page 82 - Tester l’intégration 18 Reporting - Développement d'un autre module de Reporting qui met en évidence les critères de chaque cycle de production dans un document PDF - Test unitaire - Tester l’intégration 19 Test intégration - Test de l’intégration inter modulaire et de la synchronisation 20 Droits d’accès et privilèges - Configuration et mise en place des droits d’accès de chaque acteur de l’application - Test unitaire - Test de l’intégration Tableau 22: Backlog Sprint 4 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 afin de finaliser le projet :  Offrir trois rubriques montrant les dépenses totales de chaque type de production (animale cyclique, animale non cyclique, végétale) avec tous ces critères.  Offrir trois rubriques montrant une bonne analyse des données sous des vues graphiques de statistiques pour les quantités totales enlevées à chaque type de production.  Offrir un autre module de Reporting complet qui met en évidence les critères de chaque cycle de production dans un document PDF. 2.2. Besoins non fonctionnels Les besoins non fonctionnels que notre application doit offrir sont :  L’ergonomie et la souplesse : l’application doit offrir des interfaces conviviales et ergonomiques exploitables par l’utilisateur.  L’optimisation des traitements pour avoir un court temps de réponse.
  • Chapitre 7 : Sprint 4 Page 83 2.3. Identification des acteurs Les acteurs de notre application sont l’administrateur et le gestionnaire de la production qui ont les mêmes droits d’accès durant ce sprint. Notre acteur par exemple le gestionnaire de la production consulte la totalité des dépenses de chaque type de production et consulte les statistiques des totalités des quantités enlevés pour chaque production. Notre acteur aussi peut générer chaque production cyclique sous un format PDF. 2.4. Diagramme de cas d’utilisation La Figure représente le cas d’utilisation général du sprint 4. Il sera raffiné d’avantage dans ce qui suit. Figure 60 : Diagramme de cas d'utilisation système sprint 4 D’après le diagramme précédent, nous pouvons voir que le système permet à un gestionnaire de production /administrateur d’accéder à un certain nombre de fonctionnalités :  Générer des vues graphiques de statistiques des enlèvements de chaque type de production (animale cyclique, animale non cyclique, végétale) c'est-à-dire la quantité totale enlevée par matricule de production.  Générer les totalités des dépenses de toutes les productions, de plus la possibilité d’une vue de calendrier montrant toutes les dépenses en fonctions de leur chargés. System gestionaire de production s'authentifier Consulter les totalites des depenses par type de production Consulter les statistiques des enlévements générer copie PDFde chaque production Consulter les dépenses par date <<include>> <<include>> <<include>> <<include>>
  • Chapitre 7 : Sprint 4 Page 84  Générer un rapport en PDF contenant les différents critères des cycles lancés (matricule du cycle, Nom de Production, Date Début Cycle, Date entrée effectif, Date Fin Cycle, Total de Dépense, Quantité enlevée et Total de Vente). Ce même Sprint se compose des divers use cases, que voici :  Description textuelle use case «générer les dépenses par des vue de calendrier» : Use case 16 générer les dépenses animales non cycliques par des vue de calendrier Acteur - Gestionnaire de production. Scénario principal - Le gestionnaire clique sur le module Agriculture - Le gestionnaire clique sur le lien listes des dépenses animales non cycliques. - Le gestionnaire sélectionne la vue « calendrier ». - Le gestionnaire consulte toutes les dépenses animales non cycliques par date. - Le gestionnaire coche le chargé des dépenses pour consulter les dépenses qu’il a fait. - Le gestionnaire bénéficie d’une vue très claire des dépenses par date et par chargé de dépenses. Pré-condition - Gestionnaire de production authentifié. - Production lancée Post -condition - Affichage de toutes les dépenses animales non cycliques dans une vue de calendrier très claire Tableau 23: Cas d'utilisation générer les dépenses par des vue de calendrier  Description textuelle use case «générer les vues graphiques des enlèvements végétales» : Use case 17 générer les vues graphiques des enlèvements végétales Acteur - Gestionnaire de production.
  • Chapitre 7 : Sprint 4 Page 85 Scénario principal - Le gestionnaire clique sur le module Agriculture - Le gestionnaire clique sur le lien listes enlèvements végétales - Le gestionnaire se bénéficie d’une vue très claire des quantités enlevées par matricule de production sous beaucoup de forme de graph qu’on va bien le clarifier dans le chapitre réalisation. Pré-condition - Gestionnaire de production authentifié. - Production lancée Post -condition - Affichages des statistiques des quantités enlevés par matricule de production suivant des graphes selon plusieurs types. Tableau 24: Générer les vues graphiques des enlèvements végétales  Description textuelle use case «générer copie PDF» : Use case 18 générer copie PDF de production végétale Acteur - Gestionnaire de production. Scénario principal - Le gestionnaire clique sur le module Agriculture - Le gestionnaire clique sur le lien production végétale - Le gestionnaire sélectionne la production désirée pour avoir son rapport - Le gestionnaire clique sur le bouton « imprimer ». - Un rapport nommé : Dossier de production sera téléchargé. Pré-condition - Gestionnaire de production authentifié. - Production lancée - Dépense et enlèvement saisies Post -condition - Génération de fichiers sous format PDF contenant les critères de la production. Tableau 25: Générer copie PDF
  • Chapitre 7 : Sprint 4 Page 86 3. Conception Nous avons choisi quelques cas d’utilisations qui seront modélisés ci-dessous par des diagrammes de séquence système consternant des scénarios spécifiques à ce sprint. 3.1. Diagramme de packages Le diagramme de packages précédant nous montre les différentes entités développés qui interagissent pour réaliser le rapport de la production végétale :  Végétale.rml : Fichier RML où nous avons mis les attributs spécifiés du rapport qui vont être généré par OpenOffice.  Végétale.py : Fichier Python où nous avons développé la génération de la classe végétale et le bouton d’impression. Le diagramme de packages précédant nous montre les différentes entités développés qui interagissent pour réaliser le rapport de la production animale :  Animale .rml : Fichier RML où nous avons mis les attributs spécifiés du rapport qui vont être généré par OpenOffice.  Animale .py : Fichier Python où nous avons développé la génération de la classe animale et le bouton d’impression. Végétale.rml Végétale.py Animale.rml Aniamle.py Figure 61:Diagramme de packages rapport production végétale Figure 62:Diagramme de packages rapport production animale
  • Chapitre 7 : Sprint 4 Page 87 3.2. Diagramme de séquence objet Ci-dessous le diagramme de séquences système pour la génération de copie PDF pour la production animale cyclique. Figure 63 : Diagramme de séquences système pour la génération de copie PDF Le digramme de séquence Figure met en exergue le scénario de la génération d’un cycle de production sous un format PDF, après l’authentification de l’utilisateur et la sélection du cycle désiré et son lancement, l’utilisateur à simplement besoin de cliquer sur le bouton « Imprimer », une copie qui illustre toutes les caractéristiques techniques et d’analyse du cycle va alors se télécharger en format PDF. authentificationref production lancéeref Frame1alt : gestionaire production module agriculture module reporting agriculture 1 : selectioner la production() 2 : cliquer sur le bouton imprimer() 3 : charger le module de reporting() 4 : rechercher les attributs spécifié pour les imprimés() 5 : attributs manquant non saisies 6 : dossier agriculture imprimé 7 : choix d'emplacement pour le téléchargement() 8 : dossier agriculture téléchargé
  • Chapitre 7 : Sprint 4 Page 88 4. Réalisation Figure 64 : Interface de totalités de toutes les dépenses végétales La figure précédente représente l’interface montrant toutes les dépenses végétales faites dès que nous avons utilisé notre module ainsi que la somme totales des prix de toutes les dépenses faites. Figure 65 : Interface rechercher dépense sous une vue de calendrier La figure précédente représente l’interface de la recherche sous une vue calendrier qui nous donne les chargés des dépenses en paramètre. Il suffit de cocher le nom du chargé voulu et par suite les dépenses s’affichent sur le calendrier avec tous ces attributs.
  • Chapitre 7 : Sprint 4 Page 89 Figure 66 : Rapport d’une production animale cyclique La figure précédente représente la copie PDF du rapport d’une production animale cyclique qui illustre toutes les caractéristiques techniques de ce cycle (Matricule de la production, Nom de la production, Date début cycle, Date entré effectifs, Date fin cycle. Un tableau détaillé décrit tous les dépenses faites. Un tableau détaillé décrit tous les enlèvements faits Un tableau récapitulatif décrit le Total des dépenses, Total des ventes, Total des quantités enlevés Et enfin le Bénéfice du cycle.
  • Chapitre 7 : Sprint 4 Page 90 Figure 67 : Vue graphique 1 Figure 68 : Vue graphique 2 Figure 69 : Vue graphique 3 Les figures précédentes représentent les interfaces d’analyses des données de la somme de quantités enlevées par chaque cycle de production végétales sous forme de statistiques.
  • Chapitre 7 : Sprint 4 Page 91 Conclusion Ce sprint est le dernier sprint du processus Scrum. A la fin de ce sprint toutes les fonctionnalités attendues par le client et déterminées dans le Backlog Product lors du sprint zéro, sont développées et testées en respectant les limites de temps. Ainsi, notre client est bien satisfait.
  • Conclusion Générale Page 92 Conclusion Générale A l’issue de la réalisation de ce travail, nous pouvons affirmer que notre projet nous a été d’une grande utilité dans la mesure où il nous a permis de nous familiariser avec le travail sur une nouvelle plate-forme à savoir la plate-forme OpenERP et un nouveau langage de programmation à savoir Python. Non seulement, les bénéfices ont été réalisés sur le plan technique mais aussi sur le plan relationnel. Nous avons pu avoir un aperçu autour du travail au sein d’une boîte de développement. L’intégration d’une équipe de travail a été une expérience qui marquera la période de réalisation du projet au sein de l’organisme d’accueil. Ce projet de fin d’études, qui s’est déroulé chez la société NETPIXCELS, avait pour but la conception, développement, réalisation et intégration d’un nouveau module de gestion de production agricole sous la plate-forme OpenERP. Nous avons commencé en premier lieu par l’étude de l’existant afin de mettre le projet dans son environnement général ainsi que pour déterminer la problématique à résoudre. Après le choix de la solution, nous nous sommes ensuite penchés sur l’analyse minutieuse des besoins de l’application afin de garantir une conception fiable. En outre, nous avons fait le choix de la méthodologie à adopter à savoir le processus unifié dans sa version simplifiée, qui convient à nos besoins. Suite à l’analyse des besoins, nous avons entamé la partie conception qui s’est divisé en deux parties : conception générale et conception détaillée. Ceci fait, la phase de réalisation est devenue claire et réalisable. Cette partie du travail met en évidence les pratiques adoptées et les aspects de développement ainsi que les interfaces utilisateurs. Certes, plusieurs difficultés se sont présentées à nous et nous ont compliqué la tâche surtout lors de l’intégration des dépenses et les enlèvements de notre module avec le module Entrepôt de OpenERP et lors de la réalisation module du Reporting. Mais grâce à notre motivation et à la mise en collaboration de nos différentes expériences, tous nos travaux ont été gratifiés de succès. Enfin, bien que notre travail offre plusieurs avantages à l’utilisateur, les perspectives d’amélioration et de développement de ce travail sont multiples : - L’intégration des écritures comptables et ainsi le module comptabilité d’OpenERP - La mise en place d’une structure de planification des cycles de production : alertes, vaccination, alimentation, taches ouvriers par cycle….
  • Netographie Page 93 Netographie [1] : http://netpixcels.com/ : Document de référence de Netpixcels (consulté en Janvier 2014) [2] : http://www.access-dev.com/access-dev/la-gestion-de-projet-methodes- classiques-vs-methodes-agiles/ : (consulté en Janvier 2014) [3] : http://www.ubuntu-fr.org/ : (consulté en Janvier 2014) [4] : http://www.eclipse.org/kepler/ : (consulté en Janvier 2014) [5] : http://openerp.com : (consulté en Février 2014) [6] : http://pydev.org/ : (consulté en Février 2014) [7] : http://xml.com/ : (consulté en Février 2014) [8] : http://openerp-server.readthedocs.org/en/latest/02_architecture.html/: (consulté en Février 2014) http://stackoverflow.com/ : (consulté en Mars 2014) http://developpez.com/ : (consulté en Mars 2014) http://www.open-net.ch/ :(consulté en Avril 2014) https://code.launchpad.net/: (consulté en Mai 2014) [9] : http://www.openoffice.org/fr/: (consulté en Juin 2014)
  • Glossaire Page 94 Glossaire A ASP.NET : Un ensemble de technologies de programmation Web créé par Microsoft. E ERP : Planification des ressources de l'entreprise ( Enterprise Resource Planning). F FRAMEWORK: Un espace de travail modulaire. I IDE : Un environnement de développement (Integrated Development Environment ). M MVC : un modèle destiné à répondre aux besoins des applications interactives (Model- Vue-Contrôleur). O OpenERP : Anciennement Tiny ERP, est un progiciel libre de gestion intégré . P Progiciel: Programme destiné à un même type d'applications et conçu pour différents u tilisateurs Plate-forme: Une base de travail à partir de laquelle on peut écrire, lire, développer et utiliser un ensemble de logiciels. Plugin: Un paquet qui complète un logiciel hôte pour lui apporter de nouvelles fonctionnalités. PYHTON: Un langage de programmation orienté objet. U UML: Un langage de modélisation graphique dans le cadre de la conception orientée objet (Unified Modeling Language ) W Workflow : La représentation d'une suite de tâches ou opérations effectuées par une personne, un groupe de personnes, un organisme etc… X XML : un langage informatique qui sert à enregistrer des données textuelles (eXtensible Markup Language )