Gestion de la_production_agricole_avec_openerp

3 021 vues

Publié le

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

0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 021
Sur SlideShare
0
Issues des intégrations
0
Intégrations
19
Actions
Partages
0
Téléchargements
20
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Gestion de la_production_agricole_avec_openerp

  1. 1. 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
  2. 2. 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.
  3. 3. 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.
  4. 4. 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.
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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.
  15. 15. 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
  16. 16. 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
  17. 17. 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.
  18. 18. 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.
  19. 19. 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
  20. 20. 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
  21. 21. 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.
  22. 22. 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
  23. 23. 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.
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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é.
  28. 28. 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
  29. 29. 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 :
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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.
  36. 36. 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é.
  37. 37. 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,…
  38. 38. 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
  39. 39. 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.
  40. 40. 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.
  41. 41. 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
  42. 42. 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)
  43. 43. 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
  44. 44. 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
  45. 45. 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 :
  46. 46. 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
  47. 47. 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>>
  48. 48. 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
  49. 49. 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.
  50. 50. 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
  51. 51. 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
  52. 52. 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>>
  53. 53. 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
  54. 54. 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
  55. 55. 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.
  56. 56. 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()
  57. 57. 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
  58. 58. 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
  59. 59. 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()
  60. 60. 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
  61. 61. 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.

×