SlideShare une entreprise Scribd logo
1  sur  82
Télécharger pour lire hors ligne
‫رة ا‬
     105 ‫ا‬




Master Spécialisé : Qualité du Logiciel       Rapport de Stage 2008/2009
                                          1
Dédicaces

            Pour les grands sacrifices que tu as faits pour nous,
        Pour les nuits où tu es resté sans dormir pour veiller sur nous,
                      Pour la formidable mère que tu es

                         Toi qui es toujours fier de moi,
                Pour le symbole respectueux que tu es pour moi,
                             Pour le père que tu es

                 Nul mot ne reflète ma reconnaissance vers vous
                     Pour votre temps et encouragement
                      Pour le frère et sœur que vous êtes

                             Pour votre soutien
                          Vous membres de ma famille
                             Je dédie ce travail




Master Spécialisé : Qualité du Logiciel             Rapport de Stage 2008/2009
                                          2
Remerciement
     Avant d’entamer ce rapport, je tiens à témoigner ma profonde gratitude à toutes les
personnes qui ont participé de loin ou de près à l’élaboration de ce projet de fin d’études.

     Mes sincères remerciements sont à adresser à Mr. Abderrahman ELKAFIL, directeur de
la société NEXTMA et mon encadrant professionnel, pour l’intérêt et le professionnalisme
avec lesquels il a suivi la progression de mon travail, et pour ces aides et ces conseils
fructueux qu’il n’a cessé de me prodiguer durant toute la durée de mon Projet de Fin
d’Études.

     Je tiens à exprimer ma profonde gratitude à Mr. Kamal Eddine EL KADIRI, mon
encadrant universitaire et responsable du Master Spécialisé : Qualité du Logiciel à la Faculté
des Sciences de Tétouan, pour son excellent suivi, ses remarques pertinentes et ses
recommandations fortes enrichissantes dont j’ai bénéficié tout au long de ce stage,
qu’il trouve, ainsi, mes vifs remerciements et mes sentiments les plus respectueux.

     Je remercie tout particulièrement Mr. Mohamed KHALDI, professeur à la Faculté des
Sciences de Tétouan pour sa disponibilité, ses nombreux conseils et ses indications
précieuses qui m’ont permis de mener mon travail à bien.

     Mes vis remerciements vont également à tout le cadre professoral de la faculté des
sciences de Tétouan, pour la formation prodigieuse qu’il nous a prodiguée.

     Que messieurs les membres de jury trouvent ici l’expression de ma reconnaissance
pour avoir accepté de juger mon travail.

     Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement
de ce travail, trouvent    l’expression de mes remerciements les plus chaleureux.


                                                                            Hatim EL BOUANANI




Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                   3
Résumé
     On ne présente plus les logiciels libres, aujourd’hui reconnus pour leur qualité et leur
ouverture. Ils ont démontré leur efficacité dans plusieurs domaines, notamment Internet, avec
par exemple, le serveur web Apache et le système d’exploitation Linux. Aussi, de nombreuses
entreprises et gouvernements ont commencé la migration de leurs systèmes d’information
vers des solutions libres.

     En conséquence, on commence à trouver ces logiciels dans des secteurs
traditionnellement réservés aux logiciels propriétaires, en particulier Les ERP (en anglais
Enterprise Resource Planning), aussi appelés Progiciels de Gestion Intégrés (PGI). Ainsi,
OpenERP, les GNU Entreprise, Compiere et autres viennent empiéter sur les terres de BAAN,
SAP, ORACLE, etc. Cependant, ce type d’application joue un rôle stratégique au sein des
entreprises qui les utilisent. Il requiert un très haut niveau de technicité et de compétences que
ces dernières ne sont pas prêtes à laisser aux mains de développeurs éparpillés aux quatre
coins du monde.

     C’est pourquoi, comme pour les logiciels propriétaires, est apparue la nécessité d’avoir
des entreprises prestataires de services spécialisées en logiciels libres. Ce besoin s’est renforcé
avec la rationalisation des coûts liés aux systèmes d’information depuis l’éclatement de la
«Bulle Internet».

     NEXTMA, société dans laquelle j’ai effectué mon stage de fin d’études du 16 mars au
01 juillet 2009, est une de ces nouvelles SSLL (Société de Services en Logiciels Libres). Elle
propose à ses clients un PGI basé sur le logiciel libre « OpenERP » pour lequel elle peut
développer des besoins spécifique pour chacun d’entre eux.

     Au cours de ce stage, mon travail a consisté à comprendre le fonctionnement de
l’OpenERP, et à concevoir et développer un module de gestion de transit à l’aide de l'ERP
open source OpenERP. Ce stage m’a aussi permis de mieux comprendre comment fonctionne
une société de services et comment une SSLL peut vivre du logiciel libre.

Mots clés :
       ERP open source OpenERP ;
       Framework OpenObject ;
       Python ;
       XML.


Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                                   4
Abstract
     It is no longer open source software, today recognized for their quality and openness.
They have demonstrated their effectiveness in several areas, including the Internet, for
example, the Apache Web server and the Linux operating system. Also, many companies and
governments have begun migrating their information systems to open source solutions.

     Accordingly, we begin to find these programs in areas traditionally reserved for
proprietary software, especially ERP (Enterprise Resource Planning), also called Integrated
Management Software (IMS). Thus, OpenERP, GNU Enterprise, Compiere and others from
encroaching on the lands of BAAN, SAP, Oracle, etc... However, this application plays a
strategic role within companies that use them. It requires a very high level of technology and
skills that they are not ready to leave in the hands of developers scattered around the world.

     Therefore, as with proprietary software, has emerged the need for service providers
specializing in open source software. This need has increased with the rationalization of costs
associated with information systems since the bursting of the "Internet bubble".
NEXTMA, in which I conducted my internship graduation from 16 March to 30 June 2009, is
one of these new SSLL (in french Société de Services en Logiciels Libres). It offers its
customers an ERP system based on free software "OpenERP" for which it can develop
specific needs for each of them.

     During this stage, my job was to understand the functioning of the OpenERP and realize
the design and dévloppement the Module transit Management using the open source ERP
OpenERP.

     This internship also allowed me to better understand how a service company and how a
SSLL can live free software.

Keywords :
      ERP open source OpenERP ;
       Framework OpenObject ;
       Python ;
       XML.




Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                  5
Liste des abréviations
 Sigle         Définition
 ERP           Enterprise Resource Planning
 PGI           Progiciels de Gestion Intégrés
 GNU           General Public License
 SAP           Systeme Anwendungen Produkte in der Datenverarbeitung(en anglais
               Systems, Applications and Products in Data Processing)
 SSLL          Société de Services en Logiciels Libres
 PME           Petites et Moyennes Entreprises
 CRM           Customer Relationship Management
 BI            Business Intelligence
 UML           Unified Modeling Language
 2TUP          Two Track Unified Process
 RUP           Rational Unified Process
 XP            eXtreme Programming
 FOB           Free On Board
 DHS           Dirhams
 DUM           Déclaration Unique de la Marchandise
 SADOC         Système de l'Administration des Douanes et de l'Office des Changes
 ODEP          Office d'Exploitation des Ports
 SI            Système d’Information
 MVC           Model View Controller
 XML           eXtensible Markup Language
 RPC           Remote Procedure Call
 LDAP          Lightweight Directory Access Protocol
 OLAP          Online Analytical Processing
 SGBD          Système de Gestion de Base de Données
 IDE           Itegrated Development Environment
 SWT           Standard Widget Toolkit
 SQL           Structured Query Language
 SGML          Standard Generalized Markup Language
 HTML          Hypertext Transfer Protocol
 DTD           Document Type Definition




Master Spécialisé : Qualité du Logiciel              Rapport de Stage 2008/2009
                                          6
Liste des figures
 Figure 1 :    Cycle de développement en Y………………………………………                            20
 Figure 2 :    Diagramme de Gantt…………………………………………….......                            21
 Figure 3 :    Circuit d’un dossier………………………………………………….                              26
 Figure 4 :    Les acteurs principaux du système                                     34
 Figure 5 :    Diagramme des cas d’utilisation Cycle de vie d’un dossier client…..   35
 Figure 6 :    Architecture technique d’un ERP……………………………...........                 43
 Figure 7 :    Architecture modulaire d’un ERP……………………………….......                    44
 Figure 8 :    Fonctionnalités de base d’un ERP…………………………………..                       44
 Figure 9 :    les relations structurelles entre les trois objets………………………           45
 Figure 10 :   Environnement d’exploitation de l’ERP open source OpenERP……           46
 Figure 11 :   Diagramme de séquences du scénario Authentification…………….             51
 Figure 12 :   Diagramme de séquences du scénario Paramétrage…………………                 51
 Figure 13 :   Diagramme de séquences du scénario Gestion des dossiers………...         52
 Figure 14 :   Diagramme de séquences du scénario Ventilation…………………..               53
 Figure 15 :   Diagramme de séquences du scénario Déclaration………………….                54
 Figure 16 :   Diagramme de séquences du scénario Gestion de la facturation……        55
 Figure 17 :   Diagramme de classes………………………………………………                                56
 Figure 18 :   Diagramme d’activité Cycle de vie d’un dossier……………………                57
 Figure 19 :   Diagramme d’état Cycle de vie d’un dossier                            58
 Figure 20 :   Page d’authentification………………………………………….......                        63
 Figure 21 :   Page de module………………………………………………….......                              64
 Figure 22 :   Page de dossier………………………………………………………                                  64
 Figure 23 :   Détails de dossier……………………………………………………                                65
 Figure 24 :   Détails de ventilation de dossier…………………………………….                      65
 Figure 25 :   Détails de déclaration de dossier…………………………………….                      66
 Figure 26 :   Facture des ventes……………………………………………….......                           67
 Figure 27 :   Interface de configuration de la base de données……………………              75
 Figure 28 :   Interface de la connexion avec la base de données………………….             75
 Figure 29 :   Interface de configuration du profil de l’entreprise…………………           76
 Figure 30 :   Interface d’authentification des utilisateurs…………………………               76
 Figure 31 :   Représentation d’une classe…………………………………………                           78
 Figure 32 :   Représentation d’un objet……………………………………….......                       78
 Figure 33 :   Association entre deux classes………………………………………                         78
 Figure 34 :   Agrégation entre deux classes………………………..………….......                   78
 Figure 35 :   Héritage entre deux classes………………………………………….                          79
 Figure 36 :   Diagramme de séquence…………………………………………….                               79
 Figure 37 :   Diagramme de collaboration…………………………………….......                       80
 Figure 38 :   Diagramme d’états transition………………………………………..                         80
 Figure 39 :   Diagramme d’activité organisé par acteur…………………………..                  80
 Figure 40 :   Diagramme de cas d’utilisation………………………………….......                    81
 Figure 41 :   Diagramme d’objets……………………………………………........                           81
 Figure 42 :   Diagramme de classe………………………………………………..                               82
 Figure 43 :   Diagramme de composant……………………………………….......                          82
 Figure 44 :   Diagramme de déploiement……………………………………........                        82




Master Spécialisé : Qualité du Logiciel                   Rapport de Stage 2008/2009
                                               7
Liste des tableaux
 Tableau 1 :   Synthèse des méthodologies utilisées dans le cadre de
               développement Objet et Nouvelles technologies…………………….   18
 Tableau 2 :   Planning du projet……………………………………………………                   21
 Tableau 3 :   Scénario d’authentification…………………………………………..            36
 Tableau 4 :   Scénario de gérer dossier……………………………………………..             37
 Tableau 5 :   Scénario de gérer ventilation…………………………………………            38
 Tableau 6 :   Scénario de gérer déclaration………………………………………...          39
 Tableau 7 :   Scénario de gérer facturation…………………………………………            40
 Tableau 8 :   Scénario de paramétrage……………………………………………..               41




Master Spécialisé : Qualité du Logiciel          Rapport de Stage 2008/2009
                                          8
Tables des matières
Introduction générale…………………………………………….....................................     11
Partie I : Contexte général du projet…………………………………………………………..                   13
 Chapitre 1 : Présentation de NEXTMA………………………………………………..                        14
   1. Présentation générale de NEXTMA………………………………………………                         14
     1.1. NEXTMA en Bref……………………………………….................................        14
     1.2. Prestations et services…………………………………………………………                         14
   2. Secteurs d’activités ……………………………………………………………...                           16
 Chapitre 2 : Présentation du projet…………………………………………………….                       17
   1. Présentation du projet……….……………………………….................................   17
     1.1. Thème du projet……………………………………………………………….                              17
     1.2. La démarche à suivre………………………………………………………….                           17
   2. Planning du projet…………………………………………………………………                               20
Partie II : Etude fonctionnelle et technique……………………………………………………                23
 Chapitre 1 : Etude préliminaire………………………………………………………...                        24
   1. Projet de la gestion de transit……………………………………………………...                    24
   2. Procédures et circuit d’un dossier de transit……………………………………...            25
     2.1 Circuit simplifié d’un dossier import/export…………………………………..            26
     2.2 Le circuit d’un dossier…………………………………………………………                          27
   3. Problématique……………………………………………………………………..                                 30
   4. Synthèse…………………………………………………………………………...                                   31
 Chapitre 2 : Etude fonctionnelle……………………………………………………….                         32
   1. Objectifs du projet………………………………………………………………...                            32
   2. Capture des besoins fonctionnels………………………………………………….                      33
     2.1 Définition des acteurs du système……………………………………………..                   33
     2.2 Cas d’utilisation du système…………………………………………………..                      34
     2.3 Description des cas d’utilisation……………………………………………….                   36
 Chapitre 3 : Etude technique…………………………………………………………...                          42
   1. Les ERP : Entreprise Resource Planning………………………………………….                   42
     1.1 Architecture technique…………………………………………………………                           43
     1.2 Architecture modulaire………………………………………………………...                         43
     1.3 Les fonctionnalités de base…………………………………………………….                       44
   2. Solution de gestion intégrée OpenERP……………………………………………                     45
     2.1 Environnement de développement…………………………………………….                       45
     2.2 Environnement d'exécution……………………………………………………                          46
     2.3 Environnement d'exploitation………………………………………………….                       46
     2.4 Framework OpenObject………………………………………………………..                            47
Partie III : Mise en Œuvre du projet…………………………………………………………...                   49
 Chapitre 1 : Conception de la solution………………………………………………...                    50
   1. Conception des classes métiers……………………………………………………                        50
     1.1 Diagrammes de séquences…………………………………………………….                           50
     1.2 Digramme de classes……………………………………………………..........                      56
 Chapitre 2 : Réalisation de la solution…………………………………………………                     59
   1. Outils utilisés……………………………………………………………………...                              59
     1.1 IDE Eclipse…………………………………………………………………….                                 59
     1.2 SGBD PostgreSQL.……………………………………………………………                                60
     1.3 Langage Python.....…………………………………………………………….                            60


Master Spécialisé : Qualité du Logiciel              Rapport de Stage 2008/2009
                                          9
1.4 Langage XML…………………………………………………………………. 61
   2. Réalisation du système…………………………………………………………… 63
     2.1 Exemples d’illustration………………………………………………………... 63
Conclusion et Perspectives………………………………………………………………                    68
Glossaire……………………………………………………………………………........                        70
Bibliographie…………………………………………………………………………….                           71
Webographie……………………………………………………………………………..                            71
Annexes………………………………………………………………………………….                               72




Master Spécialisé : Qualité du Logiciel        Rapport de Stage 2008/2009
                                          10
Introduction générale
      Les ERP open source 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é. Mais déjà, ils remontent l'échelle, et s'adressent à des PME de plus de 1000
salariés, que ce soit dans les secteurs industriel, distribution ou services.

      Mon projet de fin d’études vise à concevoir et développer un module de gestion de
transit, qui sera incorporé et déployé sur un progiciel de gestion intégré open source, qui porte
le nom « OpenERP ».

      SECORA-TRANS, Société générale de transit, opère au sein d’un secteur concurrentiel,
à forte agressivité commerciale et en pleine évolution. La mise en place donc des procédures
et d’une organisation de système d’information sort à l’évidence pour mieux répondre aux
exigences d’un tel environnement.

      Pour cela, SECORATRANS s’est donné dés fin 2006,                 comme objectif prioritaire
l’acquisition d’un Progiciel de Gestion Intégrée open source, afin d'améliorer la qualité de la
gestion des dossiers, le partage de l'information dans le cadre des réseaux de gestion, la
communication interne, et d'assurer la traçabilité des documents et une rapidité dans leur
traitement, pour un meilleur suivi du circuit global des dossiers.

      Alors mon projet de fin d’études s’articule à concevoir et développer un module de
gestion de transit pour SECORATRANS, afin de suivre et contrôler les dossiers.

      Mon rapport s’axe principalement sur trois parties:

      La première partie présente une vue générale sur mon projet de fin d’études, elle est
composée de deux chapitres: le premier est consacré à la présentation de l’organisme
d’accueil, quant au deuxième il présente les objectifs de mon projet de fin d’études et la
démarche suivie pour assurer son bon déroulement.

      La deuxième partie est consacrée à l’étude fonctionnelle et technique, elle est constituée
de trois chapitres: le premier expose une étude préliminaire visant à donner une vue sur
l’existant, le deuxième présente l’étude fonctionnelle, à travers la capture des besoins
fonctionnels, les cas d’utilisations UML et leurs descriptions textuelles, et le troisième définit
l’architecture logicielle et le Framework utilisé.




Master Spécialisé : Qualité du Logiciel                          Rapport de Stage 2008/2009
                                                     11
La troisième partie est consacrée à la mise en œuvre du projet, elle s’articule autour de
deux chapitres: le premier est consacré à la conception des classes métiers en présentant les
différents diagrammes de séquences, le diagramme de classes, le diagramme d’activité et le
diagramme d’état, quant au deuxième il est consacré à la réalisation de la solution en
présentant les différents outils utilisés et quelques prises d’écran du système que j’ai réalisé.




Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                                   12
Contexte général du
       Partie                           projet


          1                        Cette première partie présente une vue générale sur mon
                                   projet de fin d’études intitulé « Conception et
                                   Développement d’un module de gestion de transit à
                                   l’aide de l'ERP open source OpenERP ». Elle se
                                   compose de deux chapitres :
                                          Le premier chapitre est consacré à la présentation de
                                          l’organisme d’accueil.
                                          Le deuxième chapitre présente les objectifs de mon
                                          projet de fin d’études ainsi que la démarche suivie
                                          pour assurer son bon déroulement dans les délais
                                          fixés.




Master Spécialisé : Qualité du Logiciel                       Rapport de Stage 2008/2009
                                                   13
Chapitre
       Présentation de NEXTMA


                     Dans ce chapitre, je présente de manière générale la société
                     NEXTMA en tant qu’organisme d’accueil où s’est déroulé
                     mon projet, en exposant ses domaines d’activités d’une façon
                     générale.



1. Présentation générale de NEXTMA
              1.1 NEXTMA en Bref
      NEXTMA est une Société de Services en Logiciels Libres (SSLL) qui accompagne les
entreprises et institutions dans le choix de solutions open source ainsi que dans l'intégration,
le développement, l'adaptation aux besoins spécifiques, la maintenance et le support. Afin de
bénéficier des meilleures solutions libres dans la gestion des systèmes d'information,
NEXTMA offre aux PME marocaines des services qui sont orientés sur le modèle «
ONE STOP SHOPPING ». C'est-à-dire en offrant une gamme étendue des services
complémentaires sur mesure, car chaque entreprise à sa spécificité, afin qu'elles puissent faire
face aux échéances du libre échange et soient à niveau par rapport aux normes de qualité et de
performance internationalement reconnues.


              1.2 Prestations et services
      NEXTMA offre une large palette de prestations et de services basés sur des
composants libres adaptés aux systèmes et aux réseaux des clients. La principale tâche
de cette société est d’offrir des solutions sur mesure, en matière de formation et
d’assistance, concernant    les   problématiques    relevant    des   systèmes      d’informations,
moyennant des outils libres.




Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                   14
La gamme de services de NEXTMA est articulée autour de quatre axes majeurs qui
permettent d'accompagner les clients durant toutes les phases d'un projet afin d'en assurer sa
réussite.
        Support
      En plus des offres de formations. La société propose aux équipes dédiées au
développement, des prestations de support d’aide à la maintenance, afin de réduire le
temps de résolution des interrogations ou des difficultés que les entreprises pourraient
rencontrer lors de la mise en œuvre de certains logiciels.

        Conseil
      NEXTMA possède une équipe formée de consultants techniques et fonctionnels
qui assure soit dans le cadre de projets, soit en amont, des missions de conseil dans
les domaines suivants: gestion de contenu, travail collaboratif, dématérialisation des
procédures, migration vers le libre, architecture et dimensionnement d'applications basées
sur open ERP…etc.

        Développement
      Il constitue le cœur métier de NEXTMA et comprend le développement sur la base de
logiciels libres, de portails collaboratifs Internet ou Intranet, avec des composantes de
publication web, de travail collaboratif, de gestion électronique de documents et de
workflow.

        Formation
      L’offre des formations, techniques et fonctionnelles, permet d'accompagner les
organisations qui disposent d’équipes opérationnelles capables de mener à bien des projets.
Ces formations peuvent être établies sous forme de transferts de compétences, en phases
avals des projets




Master Spécialisé : Qualité du Logiciel                      Rapport de Stage 2008/2009
                                                  15
2. Secteurs d’activités
     De part les multiples projets que NEXTMA a mené, elle a acquis un savoir
faire susceptible de lui permettre l’implantation de logiciels libres dans les différents secteurs.

       Enterprise Ressource Planning (ERP)
     En français Progiciels de Gestion Intégré (PGI). NEXTMA est le partenaire officiel de
l’ERP open source Open ERP au Maghreb depuis 2006. Elle adapte celui-ci à la législation
marocaine et aux besoins spécifiques des entreprises.

       Customer Relationship Management (CRM)
     NEXTMA propose l’offre SUGARCRM qui permet la gestion de la relation client.

       Business Intelligence (BI) ou informatique décisionnelle.

       Intranet des entreprises et gestion des contenus

       Création d’identités visuelles et sites Internet institutionnels et e-Commerce
     La solution proposée est SMARTSHOP qui une solution libre de e-commerce
(commerce électronique) qui s'appuie sur le gestionnaire contenu Joomla!

        Gestion électronique des documents
     Il s’agit d’un système informatisé d’acquisition, classement, stockage, archivage
des documents.




Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                                   16
Chapitre

                        Présentation du projet


                                 Dans ce deuxième chapitre je présente mon projet de fin
                                 d’études, ses objectifs ainsi que la démarche suivie pour son
                                 déroulement dans les meilleures conditions.



1. Présentation du projet
       1.1. Thème du projet
     Mon projet de fin d’études vise à concevoir et développer un module de gestion de
transit pour les transitaires, afin de mettre en place des indicateurs pour suivre et contrôler les
dossiers des clients. Le module permettra alors de gérer le cycle de vie             d’un dossier,
depuis l’ouverture jusqu’à la facturation de vente.


       1.2. La démarche à suivre
     Afin d’élaborer mon projet, j’ai choisi d’utiliser UML (Unified Modeling Language)
comme formalisme, et 2TUP (Two Track Unified Process) comme démarche. Dans cette
section, je commence par une brève présentation du langage de modélisation UML en
justifiant ce choix, et ensuite, je passe en revue les différentes étapes de la démarche 2TUP en
expliquant les raisons qui j’ai poussé à l’adopter. (Pour plus de détails sur le formalisme UML
voir l’annexe 2)




Master Spécialisé : Qualité du Logiciel                           Rapport de Stage 2008/2009
                                                   17
1.2.1 Le formalisme UML
      UML est considéré comme le langage standard de conception orienté objet, il est un
formalisme et pas une méthode. Il s'en suit qu'il définit un ensemble d’éléments de
modélisation et une notation graphique pour modéliser les systèmes et ne décrit pas les étapes
à suivre pour le faire.

      Les raisons qui m’ont poussé à adopter UML dans mon projet se résument en :
           UML offre un outil prêt à l'emploi basé sur une modélisation visuelle qui permet
           d'échanger des modèles compréhensibles ;
           Si on développe avec des langages Orientés Objet, il est plus approprié de concevoir
           avec des formalismes Orientés Objet.

                 1.2.2 Processus de développement
      Le succès d’un projet dépend de l’adéquation du projet au processus de développement.
Le tableau suivant (Tableau 1) présente une synthèse des processus les plus en vogue dans la
communauté Objet et Nouvelles Technologies.

                    Description              Points Forts                       Points Faibles
                                             - Itératif ;
                    - Méthodologie centrée   - Spécifie le dialogue entre les
RUP                 sur l’architecture et    différents intervenants du
                                                                                - Coûteux à personnaliser ;
Rational            couplée aux diagrammes   projet : les livrables, les
                                                                                - Très axé processus, au
Unified             UML ;                    plannings, les prototypes…
                                                                                détriment du développement.
Process             - Cible des projets de   - Propose des modèles de
                    plus de 10 personnes.    documents, et des canevas pour
                                             des projets types.
                                                                                - Ne couvre pas les phases en
                                             - Itératif ;
XP                                                                              amont et en aval au
                    - Cible des projets de   - Simple à mettre en œuvre ;
eXtreme                                                                         développement ;
                    moins de 10 personnes.   - Fait une large place aux
Programming                                                                     - Assez flou dans sa mise en
                                             aspects techniques.
                                                                                œuvre.
                                             - Itératif ;
                    -S'articule autour de
                                             - Fait une large place à la        - Plutôt superficiel sur les
2TUP                l'architecture ;
                                             technologie et à la gestion du     phases situées en amont et en
Two Track           -Propose un cycle de
                                             risque ;                           aval du développement ;
Unified             développement en Y ;
                                             - Définit les profils des          - Ne propose pas de
Process             - Cible des projets de
                                             intervenants, les livrables, les   documents types.
                    toutes tailles.
                                             plannings, les prototypes.
   Tableau 1 : Synthèse des méthodologies utilisées dans le cadre de développement Objet et Nouvelles
                                              technologies




 Master Spécialisé : Qualité du Logiciel                                Rapport de Stage 2008/2009
                                                        18
On constate que toutes ces méthodologies proposent de travailler de façon itérative, que
ce soit au niveau des plannings, des spécifications, ou du développement.

      Si l'itératif s'est imposé, c'est parce qu'il réduit la complexité de la réalisation des phases,
en travaillant par approches successives et incrémentales. Il est alors possible de présenter
rapidement aux utilisateurs des éléments de validation. De plus, l'itératif permet une gestion
efficace des risques, en abordant dès les premières itérations, les points difficiles.

      Le RUP couvre l'ensemble du processus en spécifiant les interactions entre chacune des
phases, XP se concentre sur la phase de développement, tandis que 2TUP fait une large place
à l'analyse et à l'architecture.

      Ainsi, et en prenant compte des modalités de mon projet, le 2TUP semble le plus adapté
pour mener mon projet.

      Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques
des aspects fonctionnels. Le processus en Y s'articule autour de 3 phases :
        une phase d’étude technique;
        une phase d’étude fonctionnelle;
        une phase de réalisation.




Master Spécialisé : Qualité du Logiciel                           Rapport de Stage 2008/2009
                                                    19
La figure ci-dessous (Figure 1) illustre les différentes branches du cycle de
développement en Y :




                               Figure 1 : Cycle de développement en Y


     L'objectif de la branche technique est de rassembler les besoins techniques (sécurité,
intégration à l'existant,…) dans un dossier, élaborer une architecture logicielle et applicative
qui répond aux contraintes présentées dans le dossier technique et identifier les besoins en
frameworks techniques afin de palier aux manques de la technologie (formulaires de saisie
interactifs, outils de mapping Objet / Relationnel, …). Quant à la branche fonctionnelle, elle a
pour objectif de juger de la capacité des développeurs à intégrer l'architecture applicative à
monter en compétences sur les frameworks techniques, à comprendre la conception et à suivre
les règles de développement.




Master Spécialisé : Qualité du Logiciel                          Rapport de Stage 2008/2009
                                                   20
2. Planning du projet
     Dés mon première réunion avec mon encadrant, il m’a proposé un planning prévisionnel
(Table 2) que j’ai ajusté par la suite et au fur et à mesure de l’avancement du projet. Les
tâches inscrites dans ce planning correspondent parfaitement aux phases du cycle du
développement Y.
Id   Tâche                                              Date de début       Date de fin   Durée
1    Autoformation / Formation :                        16/03/2009          04/04/2009     20j

             Langage de programmation Python ;

             Framework d’OpenERP OpenObject ;

             Fonctionnement d’OpenERP.

2    Etude de l’existant                                06/04/2009          20/04/2009     11j

3    Etude fonctionnelle                                21/04/2009          28/04/2009     6j

4    Etude technique                                    29/04/2009          05/05/2009     5j

5    Conception de la solution                          06/05/2009          18/05/2009     9j

6    Réalisation                                        19/05/2009          26/06/2009     28j

7    Validation et tests                                29/06/2009          30/06/2009     2j

8    Finalisation du rapport                            01/07/2009          02/07/2009     2j

                                         Total                                             83j

                                   Tableau 2 : Planning du projet




                                   Figure 2 : Diagramme de Gantt




Master Spécialisé : Qualité du Logiciel                             Rapport de Stage 2008/2009
                                                   21
Dans sa globalité, le sujet consiste à concevoir et développer un module de gestion de
transit à l’aide de l’ERP open source OpenERP pour les transitaires. Pour la bonne conduite
du projet, le processus adopté est le processus 2TUP vu qu’il offre l’avantage d’effectuer en
parallèle deux études technique et fonctionnelle avant d’attaquer la conception de la solution.
La partie suivante sera consacrée à l’étude fonctionnelle et technique en plus d’une étude
préliminaire.

     Dans cette partie, il était question de présenter le contexte général du projet permettant
d’avoir une idée plus claire sur le cadre entourant        mon projet, afin de   découvrir les
différentes parties qui suivent avec une vision plus claire.




Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                  22
fonctionnelle
                                   Etude fonctionnelle
       Partie                         et technique


         2                        La deuxième partie de ce rapport est consacrée à l’étude
                                  fonctionnelle et technique. Elle s’articule autour de trois
                                  chapitres :
                                      Le premier chapitre présente une étude préliminaire
                                      visant à donner une vue sur l’existant à
                                      SECORATRANS où j’ai fait l’étude de
                                      l’existant.
                                      Le deuxième chapitre présente l’étude fonctionnelle, à
                                      travers la capture des besoins fonctionnels, les cas
                                      d’utilisation UML et leurs descriptions textuelles.
                                      Le troisième chapitre définit l’architecture logicielle
                                      du système et le Framework utilisé.




Master Spécialisé : Qualité du Logiciel                     Rapport de Stage 2008/2009
                                                23
Chapitre

                    Etude préliminaire



                          Dans ce chapitre je présente une étude préliminaire sur le projet
                          en commençant par l’étude de l’existant, la problématique et
                          enfin une synthèse.



1. Projet de la gestion de transit
     SECORA-TRANS, est une société générale de transit où j’ai fait l’étude de l’existant,
opère au sein d’un secteur concurrentiel, à forte agressivité commerciale et en pleine
évolution, la mise en place donc des procédures et d’une organisation de système
d’information sort à l’évidence pour mieux répondre aux exigences d’un tel environnement.

     Les moyens mis en place pour exercer les formes de coordination au niveau de la
direction tout en laissant au personnel leur autonomie, sont de trois sortes :

             Le contrôle de performance, d’où une gestion par objectif ;
             La supervision directe, d’où la standardisation et la formalisation de toutes les
             procédures de travail ;
             Le travail de groupe pour une polyvalence des collaborateurs et un système de
             résultat.

     Ces moyens réduisent la surface de contrôle du sommet stratégique. Les qualifications
professionnelles requises et la formation continue y contribuent pour beaucoup.

     En outre toute cette organisation ne peut donner ces meilleurs fruits que si elle est
accompagnée d’un système d’information bien rodé. Cela ne peut se faire qu’à l’aide d’un
Progiciel de Gestion Intégré open source qui permettra :
             D’assurer une coordination entre tous les intervenants de l’équipe ;

Master Spécialisé : Qualité du Logiciel                            Rapport de Stage 2008/2009
                                                    24
De suivre toutes les opérations effectuées par les intervenants en temps réel ;
              D’avoir des tableaux de pilotage retraçant toute l’activité ;
              D’avoir un archivage et accès aux documents et aux informations sécurisé et
              rapide.
     Pour faire face à l’évolution des structures et des technologies du commerce
international, SECORA-TRANS a lancé d’une manière successive depuis 5 ans une série de
logiciels afin de mieux répondre à ces problèmes de gestion interne, je peux citer à titre
d’exemple :
              le logiciel « Gestion des dossiers » : qui sert seulement à l’archivage des dossiers
              validés non encore facturés.
              le logiciel « Gestion de Ventilation » : c’est un logiciel utilisé par le déclarant
              afin de répartir la valeur totale déclarée entre plusieurs articles d’une même
              facture soumis à un même régime douanier ;
              le logiciel « Gestion de la facturation » : c’est un logiciel utilisé par l’employé
              afin de l’aider à Facturer et suivre le paiement des clients.


2. Procédures et circuit d’un dossier de transit
     Le système actuel est basé sur les registres manuels, ainsi que des applications métiers
ne communiquant pas entre elles en plus des états et des tableaux réalisés sur Excel ou word.

     Le processus du métier est décrit dans les lignes qui suivent :




Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                                   25
2.1 Circuit simplifié d’un dossier import/export


                                    Secrétaire I
                              Réception des documents


                                   Secrétaire II
                           Ouverture et suivi des dossiers
                                  import/export


                                      Déclarant
                            Déclaration de la marchandise


                                Opératrice de saisie
                          Saisie de la déclaration en détail


                                     Commis
                             Dédouanement des produits


                                Agent de facturation
                         Etablissement de la facture clients :


                                     Comptable
                  Contrôle et suivi des dépenses et factures clients
                              Figure 3 : Circuit d’un dossier




Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                               26
2.2 Le circuit d’un dossier
               2.1.1 Réception des documents «la secrétaire I »
     Réception par fax, par courrier de l’ordre de transit et des documents qui
l’accompagnent (avis d’arrivée + factures fournisseur,…) afin de permettre au transitaire de
prendre les dispositions nécessaires à la déclaration (la date de réception ainsi que les
documents reçus).

     Parfois le client se présente directement au bureau de la société muni des documents
nécessaires (factures fournisseur, liste de colisage, titre d’importation, certificat d’origine,
titre de transport, …).

     Dans ce cas, «la secrétaire I» lui délivre un accusé de réception sur lequel est mentionné
le jour de réception, ainsi que les documents reçus, et garde une copie.


               2.1.2 Ouverture d’un dossier «la secrétaire II»
     Tout d’abord, elle vérifie les documents reçus et s’assure de leur caractère original,
relève les documents manquants au dossier, qui peuvent être source de blocage.

     Elle procède par la suite à leur enregistrement sur un registre contenant les indications
suivantes :
              le numéro de dossier (numéro de classement+l’année) ;
              le nom de l’importateur ;
              le bureau de dédouanement (ex casa port, casa extérieur...) ;
              la désignation de la marchandise ;
              la valeur de la marchandise en dirham et en devise ;
              le fournisseur.

     Sur ce registre sont mentionnés par la suite, le poids de la marchandise ainsi que la
nature des colis. Le régime douanier attribué à la marchandise ainsi que le numéro de la DUM
doivent également être enregistrés sur ce registre (après la validation du dossier).

     Elle ouvre enfin un dossier sous un numéro et le remplit en fonction des documents
reçus, Elle doit mentionner (sur le dossier) les indications suivantes :

              la date de réception des documents ;
              le nom et l’adresse du destinataire des marchandises ;


Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                                   27
le nom et l’adresse de l’expéditeur des marchandises ;
             la désignation de la marchandise ;
             les documents manquants.

      Après la réception du bon à délivrer, elle complète les énonciations manquantes à
savoir :

             Date d’arrivée ;
             Les marques, numéros, espèces et nombre des colis ;
             La nature et le poids brut des marchandises ;
             Le numéro du titre de transport ;
             Le dernier port ou aéroport (la provenance).

      Le numéro du titre d’importation doit également figurer sur le dossier après sa
domiciliation.

                 2.1.3 Déclaration de la marchandise « le déclarant »
                 Il s’agit pour le déclarant de procéder à :
             Exploitation de dossier par «les secrétaires» ;
             Identification de tous les éléments lui permettant d’établir la déclaration en détail
             et de choisir       le régime douanier, en fonction de l’usage que l'opérateur
             économique souhaite réserver à sa marchandise ;
             Désignation des nomenclatures : recherche de la nomenclature (numéro et
             libellé) correspondante à chaque produit figurant sur la facture ;
             Calcul de la contre valeur en monnaie nationale : par l’application du cours de
             change du jour de la déclaration ;
             Calcul du poids net total et poids brut total ;
             Calcul du montant à imputer sur le titre d’importation.


                              La valeur totale à déclarer

    Prix FOB en devise * cours de change en DHS + montant du fret en devise *
    cours de change + Frais d’assurance (0.3% du montant coût et frêt en dirhams
    + Frais d’aconage (23.4 dhs la tonne du poids brut sauf si le montant de
    l’aconage est indiqué sur la facture de la compagnie de transport)




Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                     28
2.1.4 La déclaration en détail (DUM) «L’OPÉRATRICE DE
               SAISIE»
     Le logiciel SADOC permet la saisie, la modification et la consultation des éléments de
la déclaration, il permet également la consultation des déclarations sommaires. Avant de
commencer la saisie du dossier, elle lui donne un numéro de répertoire.

     Une fois les énonciations de la DUM saisies, l’opératrice a deux possibilités. Soit mettre
la déclaration en «ATTENTE» dans ce cas le système procède à son enregistrement provisoire
et les données saisies sont gardées en mémoire pour une durée limité avant qu’elles soient
automatiquement effacées. Soit de valider définitivement la déclaration ce qui vaut signature
et enregistrement définitif par le système. Une déclaration signée et enregistrée définitivement
ne peut être ni supprimée ni modifiée par l’opératrice. Mais elle peut être consultée.


               2.1.5 La facturation : « Agent de facturation »
     Une fois le processus de dédouanement achevé, le dossier est transmis à l’agent chargé
de la facturation. La facture reprend tous les frais engagés qui sont à la charge de client. Une
fois établie une copie est adressée au client avec toutes les pièces justificatives (facture
d’échange, facture magasinage, récépissé d’envoi des lettres de réserve,…) en plus d’une
copie de l’exemplaire redevable de la DUM et l’engagement d’importation imputé. Et l’autre
copie est transmise au service comptabilité.

     La facture client comprend plusieurs frais dont on peut citer à titre d’exemple :

             frais d’ouverture de dossier ;
             manipulation ;
             frais de transport local ou national ;
             frais d’échange ;
             aconage ODEP ;
             les lettres de réserves ;
             droit de douane ;
             frais de surestarie ;
             frais de magasinage (en cas de dépotage) ;
             honoraires.




Master Spécialisé : Qualité du Logiciel                       Rapport de Stage 2008/2009
                                                      29
3. Problématique
     Le système actuel de la société SECORATRANS est basé sur les registres manuels ainsi
que des applications métiers ne communiquant pas entre elles en plus des états et des tableaux
réalisés sur Excel ou word.

     Les outils existant aujourd’hui sur le marché proposent des fonctionnalités nettement
plus avancées et mieux adaptées aux besoins de SECORATRANS, en terme de pilotage,
d’intégration de données, de partage d’information en temps réel... Ils permettent également
de répondre aux exigences des clients et partenaires de l’entreprise.

     Dans un tel contexte, l’entreprise avait plus que jamais besoin d’un nouveau système qui
correspond le plus à ses exigences.

     Car, les premiers diagnostics qui ont été effectués ont fait ressortir que les applications
informatiques actuelles, qui malgré leur contribution effective à la gestion de l’entreprise,
restent marqués par des insuffisances techniques, stratégiques et organisationnelles.

     Les principales faiblesses diagnostiquées sont :

             L’existence de diverses applications informatiques isolées ;
             un recours à l’informatique insuffisamment développé (exemple : opération du
             contrôle et du suivi des dossiers non informatisée…) ;
             Coexistence de procédures manuelles avec les applications informatiques;
             Les systèmes informatiques n’intègrent pas toutes les demandes fonctionnelles
             exprimées par l’entreprise ;
             Une large utilisation de documents non informatisés (les chemises import/export
             (vert et jaune), fiches de dépense, chèque, bulletin de réception…) ;
             Manque de traçabilité ;
             Insuffisance du contrôle et du suivi des dossiers ;
             l’absence de procédure automatisée de recoupement d'information utilisant un
             identifiant unique;




Master Spécialisé : Qualité du Logiciel                       Rapport de Stage 2008/2009
                                                 30
4. Synthèse
     Pour remédier aux problèmes cités ci-dessus, et pour améliorer le système de suivi des
dossiers pour les transitaires, SECORATRANS cherche à mettre en place un ERP open
source OpenERP qui assure la gestion de l'ensemble des services de l’entreprise depuis la
réception des documents jusqu’au recouvrement : réception des documents, suivi et contrôle
des dossiers.

     Cette étude préliminaire m’a permis de bien cerner le sujet et de dégager les principales
fonctionnalités utiles pour la mise en place de mon projet. J’entamerai dans le chapitre suivant
l’étude fonctionnelle.




Master Spécialisé : Qualité du Logiciel                       Rapport de Stage 2008/2009
                                                 31
Chapitre

                           Etude fonctionnelle


                              Ce chapitre présente l’étude fonctionnelle du projet qui
                              comprend la capture des besoins fonctionnels et la
                              formalisation de ces besoins en cas d’utilisation UML.



1. Objectifs du projet
     La solution recherchée va couvrir l’ensemble des activités de l’entreprise : suivi des
dossiers, la ventilation de la valeur déclarée, la déclaration de la marchandise et l’archivage
des dossiers facturés, suivi et contrôle des dossiers, et devra permettre la dématérialisation de
l’ensemble des opérations de l’entreprise.

     En effet, ce projet doit aussi avoir pour objectif :

             la réalisation d'une application informatique unique pour la gestion de l'ensemble
             des services de l’entreprise depuis la réception des documents jusqu’au
             recouvrement : réception des documents, suivi et contrôle des dossiers.

             mettre en place un système commun et partagé répondant aux attentes de
             l’ensemble des utilisateurs de l’entreprise

             l’introduction d’un mot de passe pour chaque utilisateur, choisi par lui-même. Et
             qui une fois attribué, il n’engage que la personne titulaire de dit mot de passe.

             mettre en place une solution complète de serveur d'entreprise comprenant des
             fonctions de messagerie et de collaboration

             un stockage de données protégé et centralisé.




Master Spécialisé : Qualité du Logiciel                             Rapport de Stage 2008/2009
                                                    32
2. Capture des besoins fonctionnels
      Après avoir cerner les besoins de la société dans le chapitre précédent (étude
préliminaire), je vais formaliser ces besoins en cas d’utilisation en définissant les acteurs
interagissant avec le système.

           2.1 Définition des acteurs du système
      À ce stade je vais déterminer les six acteurs principaux interagissant avec le système
              Utilisateur
      Cet acteur accède de manière sécurisée au système, et consulte les contenus.
              Secrétaire de réception des dossiers
      Cet acteur accède de manière sécurisée au système, recevoir les contenus, et c’est celui
qui valide ou pas les dossiers des clients.
              Déclarant
      Cet acteur accède de manière sécurisée au système, ventile les dossiers, et c’est celui qui
fait la déclaration des marchandises.
              Opérateur de saisie
      Cet acteur accède d’une manière sécurisée, obtient le numéro de la D.U.M de la
marchandise.
              Agent de facturation
      Cet acteur accède d’une manière sécurisée, établit la facture des ventes des dossiers
clients.
              Administrateur
      Cet acteur attribue les droits d'accès aux utilisateurs, gère les utilisateurs (ajout,
modification, suppression d'un utilisateur), ainsi que le contenu et l’arborescence de
l’OpenERP.




Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                  33
Remarque :

      L’opérateur de saisie n’est pas un acteur système car il n’interagie qu’avec le système
SADOC de la douane.




                             Figure 4 : Les acteurs principaux du système


        2.2 Cas d’utilisation du système
      Le diagramme des cas d’utilisation permet de structurer les besoins des utilisateurs et les
objectifs d’un système. En effet, il identifie les acteurs et leurs interactions avec le système.
Afin de mieux comprendre tous les volets du système, je l’ai décomposé en huit cas
d’utilisations. Par la suite, je vais détailler les principaux cas d’utilisation.

      La figure ci-dessous (Figure 5) représente le diagramme des cas d’utilisation :




Master Spécialisé : Qualité du Logiciel                            Rapport de Stage 2008/2009
                                                     34
Figure 5 : Diagramme de cas d’utilisation Cycle de vie d’un dossier client




Master Spécialisé : Qualité du Logiciel                          Rapport de Stage 2008/2009
                                                   35
2.3 Description des cas d’utilisation
                 2.3.1 Cas d’utilisation Authentification
Le tableau ci-dessous (Tableau 3), représente la description de ce cas d’utilisation:
 Code                  CU_Authentification
 Nom                   Authentification
 Acteurs système       Tous les acteurs
 Objectif/Résultat     Accès aux fonctionnalités attribuées.
 Description           Ce scénario permet à tout acteur de s’identifier auprès du système et d’accéder aux
                       fonctionnalités qui lui sont attribuées.
 Pré condition         Existence à dans la base de données du système
 Scénario                                  Action de l’acteur                      Action du système
 authentification      1          Se connecter au système.
                       2                                                Vérifier login et mot de passe, valider
                                                                        et autoriser l’accès selon les droits.
 Exceptions
                       1          Se connecter au système
                       2                                                Le système ne répond pas


                       1          Se connecter au système
                       2                                                Vérifier     les    informations         de
                                                                        l’utilisateur. Retour à 1 (login ou
                                                                        password incorrect)
 Fréquence             A la demande.

                                  Tableau 3 : Scénario d’authentification


                 2.3.2 Cas d’utilisation Gérer Dossier
        Ce cas d’utilisation concerne la gestion des dossiers, opération effectuée par
l’Administrateur qui peut ajouter, modifier et supprimer un dossier, ainsi que la validation
d’un dossier.

        Le tableau ci-dessous (Tableau 4), représente la description de ce cas d’utilisation:




Master Spécialisé : Qualité du Logiciel                                 Rapport de Stage 2008/2009
                                                          36
Code                     CU_Gerer_Dossier
Nom                      Gérer Dossier
Acteurs système          Administrateur
Objectif/Résultat        Suivre et contrôler les dossiers clients.
Description              Ce scénario permet de faire les opérations d’ajout, de modification et de
                         suppression d’un dossier client dans la base de données du système, ansi que la
                         validation et la clôture d’un dossier client.
Pré condition            Authentification au système avec le compte Administrateur.
Scénario Gérer_Dossier                         Action de l’acteur                  Action du système
                         1          Saisir les informations de dossier à
                                    ajouter.
                         2          Rechercher le numéro de dossier à
                                    modifier.
                         3          Rechercher le numéro de dossier à
                                    supprimer.
                         4                                                  Enregistrer les informations dans
                                                                            la base de données du système.
                         5          Valider dossier
                         6                                                  Etat dossier ouvert
Exceptions
                         1          Saisir les informations de dossier à
                                    ajouter.
                         2                                                  Le système ne répond pas.


                         1          Saisir les informations de dossier à
                                    ajouter.
                         2                                                  Données insuffisantes.


                         1          Rechercher le numéro de dossier à
                                    modifier, à supprimer et valider.
                         2                                                  Le système ne répond pas.


                         1          Rechercher le numéro de dossier à
                                    modifier, à supprimer et à valider.
                         2                                                  Erreur.


Fréquence                A la demande.

                                Tableau 4 : Scénario de gérer dossier




Master Spécialisé : Qualité du Logiciel                                  Rapport de Stage 2008/2009
                                                        37
2.3.3 Cas d’utilisation Gérer Ventilation
        Ce cas d’utilisation consiste à saisir les détails des différents articles de la marchandise
(nomenclature, quantité, poids, valeur).

        Le tableau ci-dessous (Tableau 5), représente la description de ce cas d’utilisation:

 Code                          CU_Gerer_Ventilation
 Nom                           Ventilation de la marchandise.
 Acteurs système               Déclarant.
 Objectif/Résultat             Saisie des détails des différents articles de la marchandise.
 Description                   Ce scénario permet de faire la saisie des articles qui seront utiles pour la
                               déclaration de la marchandise.
 Pré condition                 Authentification au système avec le compte Déclarant.
 Scénario Gerer_Ventilation                         Action de l’acteur                  Action du système
                               1            Lister dossiers ouverts
                               2                                                  Afficher liste dossiers
                                                                                  ouverts.
                               3            Choisir numéro dossier
                               4                                                  Afficher dossier choisi
                               5            Ajouter ventilation
                               6                                                  Enregistrer les informations
                                                                                  dans la base de données du
                                                                                  système
 Exceptions
                               1            Lister dossiers ouverts
                               2            Choisir numéro dossier
                               3            Ajouter ventilation
                               4                                                  Le système ne répond pas
                               5                                                  Données insuffisantes pour
                                                                                  la ventilation
 Fréquence                     A la demande

                                   Tableau 5 : Scénario de gérer ventilation




Master Spécialisé : Qualité du Logiciel                                  Rapport de Stage 2008/2009
                                                          38
2.3.4 Cas d’utilisation Gérer Déclaration
     Ce cas d’utilisation consiste à calculer la contre valeur, le poids net total, poids brut total
et le montant à imputer sur le titre d’importation brut.

     Le tableau ci-dessous (Tableau 6), représente la description de ce cas d’utilisation:
 Code                          CU_Gerer_Declaration
 Nom                           Déclaration de la marchandise
 Acteurs système               Déclarant
 Objectif/Résultat             Calcul des différents indicateurs de la marchandise
 Description                   Ce scénario permet de faire le calcul de la contre valeur, le poids net total,
                               poids brut total et le montant à imputer sur le titre d’importation brut. qui
                               seront utiles pour la déclaration chez le système de la douane (SADOC).
 Pré condition                 Authentification au système avec le compte Déclarant
 Scénario Gerer_Declaration                        Action de l’acteur                 Action du système
                               1           Lister dossiers à déclarer
                               2                                                  Afficher liste dossier à
                                                                                  déclarer
                               3           Choisir numéro dossier
                               4                                                  Afficher dossier choisi
                               5           Déclarer dossier
                               6                                                  Calculer paramètres
                               7                                                  Etat dossier déclaré
 Exceptions
                               1           Choisir numéro dossier
                               2           Déclarer dossier
                               3                                                  Le système ne répond pas
                               4                                                  Données insuffisantes
                                                                                  pour le calcul
                                                                                  Calcul impossible dossier
                                                                                  (déjà déclaré)
 Fréquence                     A la demande

                              Tableau 6 : Scénario de gérer déclaration




Master Spécialisé : Qualité du Logiciel                                 Rapport de Stage 2008/2009
                                                       39
2.3.5 Cas d’utilisation Gérer Facturation
       Ce cas d’utilisation reprend tous les frais engagés qui sont à la charge de client. Une fois
établie une copie est adressée au client avec toutes les pièces justificatives.

       Le tableau ci-dessous (Tableau 7), représente la description de ce cas d’utilisation:

 Code                          CU_Gerer_Facturation
 Nom                           Facture des ventes
 Acteurs système               Agent Facturation
 Objectif/Résultat             Calcul des frais de dossier
 Description                   Ce scénario permet de faire le calcul tous les frais engagés qui sont à la
                               charge de client
 Pré condition                 Authentification au système avec le compte Agent Facturation
 Scénario Gerer_Facturation                         Action de l’acteur               Action du système
                               1          Lister dossiers déclarés
                               2                                                 Afficher liste dossiers
                                                                                 déclarés
                               3          Choisir numéro dossier
                               4                                                 Afficher dossier choisi
                               5          Facturer dossier
                               6                                                 Calculer montant total
                               7                                                 Etat dossier facturé
 Exceptions
                               1          Choisir numéro dossier
                               2          Facturer dossier
                               3                                                 Le système ne répond pas
                               4                                                 Données insuffisantes
                                                                                 pour la facturation
 Fréquence                     A la demande

                               Tableau 7 : Scénario de gérer facturation




Master Spécialisé : Qualité du Logiciel                               Rapport de Stage 2008/2009
                                                       40
2.3.6 Cas d’utilisation Paramétrage
      Ce cas d’utilisation concerne le paramétrage de l’application (la gestion des accès et la
gestion de contenu).

      Le tableau ci-dessous (Tableau 8), représente la description de ce cas d’utilisation:
  Code                 CU_PARAM_APPLICATION
  Nom                  Définition des paramètres de l’application
  Acteurs système      Administrateur.
  Objectif/Résultat    Paramétrer l’application
  Description          Ce scénario permet de paramétrer l’application, la gestion des accès, la gestion de
                       contenus...
  Pré condition        Connexion avec le compte Administrateur
  Scénario                                 Action de l’acteur                   Action du système
  Paramétrage du       1         Choisir l’option Paramétrage du
  système                        Système.
                       2                                               Afficher la liste des paramètres.
                       3         Définir les paramètres.
                       4         Valider
                       5                                               Sauvegarder
  Exceptions
                       1         Définir les paramètres
                       2                                               Le système ne répond pas
                       1         Définir les paramètres
                       2                                               Paramètres désactivés
  Fréquence            A la demande.

                                     Tableau 8 : Scénario de paramétrage




      Au terme de ce chapitre, j’ai achevé les différentes phases de la branche fonctionnelle
du processus Y. L’objet du chapitre suivant est l’étude technique du projet qui a pour but de
faire apparaître le choix de l’architecture du système et les frameworks techniques qui seront
utilisés.




Master Spécialisé : Qualité du Logiciel                                Rapport de Stage 2008/2009
                                                          41
Chapitre
                       Etude technique


                      Ce chaplitre détaille la branche technique du processus Y. Je
                      présente d’abord, la technologie utilisée, puis l’architecure logicielle
                      du système pour enfin le Framework et techniques utilisés




1. Les ERP : Entreprise Resource Planning
      Les ERPs (Enterprise Resource Planning), aussi appelés Progiciels de Gestion Intégrés
(PGI), sont des applications dont le but est de coordonner l'ensemble des activités d'une
entreprise autour d'un même système d'information.

      Les Progiciels de Gestion Intégrés proposent généralement des outils de Groupware et
de Workflow afin d'assurer la transversalité et la circulation de l'information entre les
différents services de l'entreprise.

      Plus qu'un simple logiciel, un ERP est un véritable projet demandant une intégration
totale d'un outil logiciel au sein d'une organisation et d'une structure spécifique, et donc des
coûts importants d'ingénierie. D'autre part sa mise en place dans l'entreprise entraîne des
modifications importantes des habitudes de travail d'une grande partie des employés. Ainsi on
considère que le coût de l'outil logiciel représente moins de 20% du coût total de mise en
place d'un tel système.




Master Spécialisé : Qualité du Logiciel                                    Rapport de Stage 2008/2009
                                                           42
1.1 Architecture technique




                             Figure 6 : Architecture technique d’un ERP



     L'ERP est donc sur serveur. La majorité des ERP sont couplés à une base de données
ORACLE. De plus, les ERP sont compatibles packs Office, en particulier pour PowerPoint et
Excel. En effet, le premier étant utile pour personnaliser les bureaux ERP en fonction de
l'entreprise et le second pour effectuer les imports/exports de données. Enfin, les ERP sont
aussi compatibles avec des outils de reporting (CrystalReport en général). Le reporting étant
utilisé en particulier pour le module de gestion relation client, que nous verrons par la suite.


       1.2 Architecture modulaire
     Un ERP est un ensemble dont toutes les parties fonctionnent les unes avec les autres
d'où l'ergonomie et l'unicité des informations et donc la cohérence du SI.

     Un ERP est modulaire dans le sens où il est possible de n'avoir qu'une ou plusieurs
applications en même temps, ou peu à peu. Les applications modulaires telles que les ERP
permettent d'être sûr de la compatibilité des modules entre eux, ils s'imbriquent comme des

Master Spécialisé : Qualité du Logiciel                          Rapport de Stage 2008/2009
                                                   43
blocs de Lego et fonctionnent ensemble (pas de vérification de compatibilité à
effectuer).Voici un exemple d'architecture modulaire qui tend à représenter tous les ERP:




                           Figure 7 : Architecture modulaire d’un ERP



     L'architecture modulaire schématisée ci-dessus intègre plusieurs modules retouchant aux
grandes fonctions d'une entreprise : le module finance, logistique et e-commerce…


       1.3 Les fonctionnalités de base
     La figure ci-dessous (Figure x) représente les fonctionnalités de base d’un ERP :




                           Figure 8 : Fonctionnalités de base d’un ERP




Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                  44
2. Solution de gestion intégrée OpenERP
     Open ERP est un progiciel de gestion intégré en licence libre, dont la grande souplesse
est idéale aussi bien pour les indépendants que pour les PME. Il couvre pratiquement
tous les secteurs d’activité : industrie, commerce, prestations de services, e-Commerce,
négoce, etc. Comme la plupart des logiciels libres, l'accessibilité, la flexibilité et la simplicité
sont les maîtres mots du développement.


       2.1 Environnement de développement
     Un MVC est une architecture de modèle utilisée en génie logiciel. Dans des
applications complexes qui          présentent des          lots de données aux utilisateurs, on
souhaite souvent séparer les données (modèle) et l'interface utilisateur (vue), de sorte
que les changements à l'interface utilisateur n'affectent pas le traitement des données,
et que les données peuvent être réorganisées sans changer l'interface utilisateur.

     Le MVC résout ce genre de            problème en découplant l'accès               des données   et la
logique des applications de la présentation des données et de l'interaction utilisateur,
en introduisant un composant intermédiaire : « le contrôleur ».

      Dans open ERP, on peut appliquer cette sémantique de Model-View-Controller avec :

             Model : les modèles sont les objets déclarés dans OpenERP. Ils sont également
             des tables PostgreSQL ;

             View : les vues sont définies en fichiers XML dans OPENERP ;

             Controller : le contrôleur est Python qui contrôle OPENERP.




                       Figure 9 : les relations structurelles entre les trois objets




Master Spécialisé : Qualité du Logiciel                               Rapport de Stage 2008/2009
                                                       45
2.2 Environnement d'exécution
     Pour exécuter le code, l'OpenERP serveur doit être installée dans un serveur exécutant
MVC Framework Foundation et un groupe d'applications de tierce-partie que nous appelons
l'environnement d'exploitation. Les utilisateurs n'ont besoin de rien de plus qu'un OpenERP
web client ou OpenERP GTK client pour accéder aux différents modules de l’ERP.


       2.3 Environnement d'exploitation
     OpenERP a besoin d'un groupe bien connu d'applications tierces telles web services,
OpenERP web client ou OpenERP GTK client, et quelques autres utilitaires. Base de données
PostgreSQL est également nécessaire.

     Le modèle est basé sur le standard SQL, et toutes ces applications peuvent être installées
aussi bien sur Linux ou Windows.




             Figure 10 : Environnement d’exploitation de l’ERP open source OpenERP




Master Spécialisé : Qualité du Logiciel                       Rapport de Stage 2008/2009
                                                 46
2.4 Framework OpenObject
      OpenObject est le Framework d'OpenERP, ou programme permettant la génération
d'OpenERP. Il est très souple et complet, et permet la création des applications de gestion,
quelles qu'elles soient.




                           Figure 11 : Framework OpenObject d’OpenERP


               2.4.1 Rapidité de développement
      Développer des applications de gestion avec OpenObject, bien plus qu'avec n'importe
quel autre outil de ce type. On crée un fichier Python contenant la description des champs et
les règles de gestion, un fichier XML décrivant les écrans, et le tour est joué. Bien sûr, il n'y a
aucune limitation aux codes, ceci étant écrit en Python, langage très riche.

      Si on a besoin d'aller plus loin, OpenObject permet la création de Wizards (sous-
programmes), l'automatisation des tâches et leur planification, l'intégration de données.




Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                                   47
2.4.2 Génération de rapports

Les rapports sont très simplement définis et intégrés, ce sous 2 formes :

             Rapports imprimables

         Ils sont générés par le biais de reportlab. Les fichiers de génération de ces rapports
         peuvent être transformés dans OpenOffice, puis importés rapidement.

             Ecrans

         On peut définir tout type de tableau de bord, contenu des données, des listes, des
         graphiques.

               2.4.3 Gestion des workflows
     Toutes les règles de gestion peuvent être définies. Le moteur de Workflows
d'OpenObject est très puissant, et permet des imbrications de règles complexes (ou simples),
qui peuvent être ensuite modifiées par le biais de l'application elle-même.

               2.4.4 Communication avec des applications tierces
     Toutes les communications entre OpenObject et les interfaces (même vers le client GTK
officiel) sont effectuées en XMLRPC. Les types d'objets, les écrans, les données sont
transmises par ce protocole. On a besoin d'intégrer les applications OpenObject à un portail
ou à une autre application.

     Des connecteurs existent entre OpenObject et LDAP, ainsi qu'avec de nombreuses
autres applications Open Source (ezPublish, Asterisk, ...).

               2.4.5 Business Intelligence
     OpenObject est, dans sa version 5, entièrement doté des fonctionnalités pour effectuer
simplement le stockage des données dans des bases de données tierces (OLAP). Les rapports
sont donc le vrai reflet des activités, non de simples statistiques internes.

     Ce chapitre a permis de détailler les différents choix techniques, à savoir la technologie
adoptée, l’architecture logicielle et le Framework utilisé. La partie suivante détaillera la
branche réalisation du processus Y.




Master Spécialisé : Qualité du Logiciel                          Rapport de Stage 2008/2009
                                                   48
Mise en Œuvre du
       Partie                              projet


          3                       Le contenu de cette partie s’articule sur
                                  deux chapitres :
                                          Le premier est consacré à l’analyse et
                                          la conception du module métier du
                                          système, en présentant le diagramme
                                          de classes, d’activité et d’état, quelques
                                          diagrammes      de      séquences   et   la
                                          structure du système.
                                          Le   deuxième     est    consacré   à    la
                                          réalisation du système, en présentant
                                          quelques prises d’écran.




Master Spécialisé : Qualité du Logiciel                    Rapport de Stage 2008/2009
                                               49
Chapitre

            Conception de la solution



                             Ce chaplitre détaille la phase conception de la branche réalisation
                             du processus Y. Je présente d’abord la conception des classes
                             métiers puis la structure du système.


1. Conception des classes métiers
       1.1 Diagrammes de séquences
      Le diagramme de séquences permet de mettre en relief les différents messages échangés
entre les objets et acteurs du système, et ce selon un point de vue temporelle. En effet, l'ordre
d'envoi d'un message est déterminé par sa position sur l'axe vertical (axe temporel) du
diagramme ; le temps s'écoule indépendamment des événements, "de haut en bas" de l’axe
vertical. Je vais dans la suite présenter quelques diagrammes de séquences.

               1.1.1 Scénario Authentification
      Ce scénario permet à l’utilisateur de se connecter au système en saisissant son login et
mot de passe. Le système vérifie ces informations qui sont stockées dans la base de données
et affiche la page d’accueil suivant les privilèges et le rôle de l’utilisateur.

      La figure ci-dessous (Figure 12) représente le diagramme de séquences du scénario
d’authentification




Master Spécialisé : Qualité du Logiciel                               Rapport de Stage 2008/2009
                                                       50
Figure 12 : Diagramme de séquences du scénario Authentification


               1.1.2 Scénario Paramétrage

     Ce scénario est déclenché par l’administrateur du système, il consiste à faire la gestion
du contenu, et la gestion des comptes utilisateurs et les droits d’accès attribués à ces derniers.
     La figure suivante (Figure 13), présente le diagramme de séquences du cas Paramétrage.




                    Figure 13 : Diagramme de séquences du scénario Paramétrage




Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                                   51
1.1.3 Scénario Gestion des Dossiers :
     Ce scénario est déclenché par l’administrateur du système, il consiste à faire la gestion
des dossiers, et le suivi et le contrôle de ces dossiers (Figure 14).




                  Figure 14 : Diagramme de séquences du scénario Gestion des dossiers


                 1.1.4 Scénario Ventilation :
     La ventilation consiste à saisir les détails des différents articles (nomenclature, quantité,
poids, valeur)




Master Spécialisé : Qualité du Logiciel                           Rapport de Stage 2008/2009
                                                     52
Figure 15 : Diagramme de séquences du scénario Ventilation


             1.1.5 Scénario Déclaration
    La déclaration de la marchandise consiste à effectuer les opérations suivantes :

           Calcul de la contre valeur en monnaie nationale : par l’application du cours de
           change du jour de la déclaration ;

           Calcul du poids net total et poids brut total ;

           Calcul du montant à imputer sur le titre d’importation.




Master Spécialisé : Qualité du Logiciel                       Rapport de Stage 2008/2009
                                                 53
Figure 16 : Diagramme de séquences du scénario Déclaration




Master Spécialisé : Qualité du Logiciel                      Rapport de Stage 2008/2009
                                                54
1.1.6 Scénario Gestion de la facturation
     La facture reprend tous les frais engagés qui sont à la charge de client. Une fois établie
une copie est adressée au client avec toutes les pièces justificatives (facture d’échange, facture
magasinage, récépissé d’envoi des lettres de réserve,…).

     Pour créer un avoir, agent de facturation utilise le numéro de la facture correspondant à
la commande client.




              Figure 17 : Diagramme de séquences du scénario Gestion de la facturation




Master Spécialisé : Qualité du Logiciel                          Rapport de Stage 2008/2009
                                                   55
1.2 Digramme de classes
     Le diagramme de classes exprime, de manière générale, la structure statique d’un
système, en termes de classes et de relations entre elles.

     Une classe permet de décrire un ensemble d’objets (attributs et comportements), tandis
qu’une relation ou association permet de faire apparaître des liens entre ces objets.

     Le schéma ci-dessous (Figure 18) représente le diagramme de classe que j’ai établi pour
la conception du système:




                                 Figure 18 : Diagramme de classes



     Le schéma ci-dessous (Figure 19) représente le diagramme d’activité que j’ai établi pour
la conception du système:



Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                  56
Figure 19 : Diagramme d’activité Cycle de vie d’un dossier




Master Spécialisé : Qualité du Logiciel                                                                Rapport de Stage 2008/2009
                                                                      57
Le schéma ci-dessous (Figure 20) représente le diagramme d’état que j’ai établi pour la
conception du système:




                                 Figure 20 : Diagramme de classes




     Ce chapitre avait pour objectif la présentation de la conception détaillée de la solution à
travers le diagramme de classes, d’activité, d’état, et quelques diagrammes de séquences.
Dans le chapitre suivant je exposerai les outils utilisés, et quelques exemples d’illustration.




Master Spécialisé : Qualité du Logiciel                         Rapport de Stage 2008/2009
                                                  58
Chapitre


                        Réalisation de la solution


                          Ce chaplitre détaille la phase réalisation de mon projet. Je
                          présente d’abord, les outils utilisés et quelques prises d’écran du
                          système.



1. Outils utilisés
       Pour le développement du système je me suis basés sur l’ERP OpenERP et les
différentes technologies et Framework qu’il utilise, pour ajouter le système comme module au
sein de cet ERP j’ai eu recours à plusieurs outils comme l’IDE Eclipse et le SGBD
PostgreSQL, ainsi que la langage de programmation Python et la langage à balises extensible
XML, dont la présentation est détaillée dans les paragraphes suivants.


       1.1 IDE Eclipse
     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 ;




Master Spécialisé : Qualité du Logiciel                                Rapport de Stage 2008/2009
                                                       59
La cohabitation entre plusieurs versions d'un même plug-in sur une même plate-
             forme ;

             Le support de plusieurs langages grâce à des plug-ins dédiés : Python, Java,
             Cobol, C, PHP, C#, ... ;

             Le support de plusieurs plates-formes d'exécution : Linux, Windows,…

             La rapidité d'exécution grâce à l'utilisation de la bibliothèque SWT ;

             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…


       1.2 SGBD PostgreSQL
     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.
Nous avons utilisé PostgreSQL sous Linux, et nous avons utilisé l’utilitaire pgAdmin pour
l’utiliser à distance à partir d’un client Windows.


       1.3 Langage Python
     Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans
l'imposer) une approche modulaire et orientée objet de la programmation. Python est
développé depuis 1989 par Guido van Rossum et de nombreux contributeurs bénévoles.

     Détaillons un peu les principales caractéristiques du langage Python:

             Portable : Il est supporté par les différents systèmes d’exploitation ;

             Gratuit ;

             Simple : Il possède une syntaxe très simple tout en combinant des types de
             données évolués (listes, dictionnaires…) ;

             Absence des pointeurs ;

             Il est orienté objet et supporte l’héritage multiple et la surcharge des opérateurs ;


Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                  60
Dynamique : cette fonctionnalité est probablement la plus intéressante de
             Python ;

             Extensible : on peut facilement l’interfacer avec des bibliothèques C existantes ;

             Python : gère     ses   ressources (mémoire,    descripteurs de fichiers...)    sans
             intervention du programmeur, par un mécanisme de comptage de références ;

             Python : possède actuellement deux implémentations. L'une,         interprétée, dans
             laquelle les programmes Python sont compilés en instructions portables, puis
             exécutés par une machine virtuelle (comme pour Java, avec une différence
             importante:     Java    étant statiquement   typé,   il est beaucoup plus      facile
             d'accélérer      l'exécution   d'un   programme      Java   que   d'un   programme
             Python).L'autre génère directement du bytecode Java ;

             Dynamiquement typé ;

             Soutenu par la communauté d’utilisateurs qui tentent à l’évoluer.


       1.4 Langage XML
     XML (eXtensible Markup Language et en Français Langage à balises étendu, ou
Langage à balises          extensible) était lancé en 1997 par la communauté SGML
(Standard Generalized Markup Language). XML est un langage simple et puissant de
description et d’échange de documents structurés de n’importe quel domaine de
données grâce à son extensibilité, il décrit cette structure à l’aide d’un système de balises.

     Quelques points remarquables d’XML :

             Il apparaît comme un format d’échange de données universel ;

             Il a la possibilité de créer des nouvelles balises contrairement à HTML qui
             définit un nombre limité ;

             Il   garantit à ses utilisateurs l’indépendance de leurs documents de toute
             technologie propriétaire ;

             Il unifie le monde du traitement de document et celui du Web.




Master Spécialisé : Qualité du Logiciel                        Rapport de Stage 2008/2009
                                                   61
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp

Contenu connexe

Tendances

TFE. Conception et réalisation d'une application web mobile touristique. Marg...
TFE. Conception et réalisation d'une application web mobile touristique. Marg...TFE. Conception et réalisation d'une application web mobile touristique. Marg...
TFE. Conception et réalisation d'une application web mobile touristique. Marg...
Jonathan Margrève
 

Tendances (20)

TFE. Conception et réalisation d'une application web mobile touristique. Marg...
TFE. Conception et réalisation d'une application web mobile touristique. Marg...TFE. Conception et réalisation d'une application web mobile touristique. Marg...
TFE. Conception et réalisation d'une application web mobile touristique. Marg...
 
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
 
Chp1 - Introduction aux ERP
Chp1 - Introduction aux ERPChp1 - Introduction aux ERP
Chp1 - Introduction aux ERP
 
Mémoire de Projet de Fin d’Etudes
Mémoire de Projet de Fin d’EtudesMémoire de Projet de Fin d’Etudes
Mémoire de Projet de Fin d’Etudes
 
Rapport de stage societe commerciale
Rapport de stage societe commercialeRapport de stage societe commerciale
Rapport de stage societe commerciale
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
 
Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8
 
Rapport de stage .pdf
Rapport de stage .pdfRapport de stage .pdf
Rapport de stage .pdf
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
Presentation pfe application de pointage ASP.NET
Presentation pfe application de pointage ASP.NETPresentation pfe application de pointage ASP.NET
Presentation pfe application de pointage ASP.NET
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
 
E.R.P
E.R.PE.R.P
E.R.P
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique
 
Rapport de-stage-sur-transport-international-transit-et-logistique-groupe-timar
Rapport de-stage-sur-transport-international-transit-et-logistique-groupe-timarRapport de-stage-sur-transport-international-transit-et-logistique-groupe-timar
Rapport de-stage-sur-transport-international-transit-et-logistique-groupe-timar
 
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
 
Gestion des achats dans le prologiciel de gestion Odoo10
Gestion des achats dans le prologiciel de gestion Odoo10Gestion des achats dans le prologiciel de gestion Odoo10
Gestion des achats dans le prologiciel de gestion Odoo10
 
Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed AmineRapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
 

En vedette

Nos Services Transfaro
Nos Services Transfaro Nos Services Transfaro
Nos Services Transfaro
Transfaro
 
LETTRE DE PRESENTATION GTATvvv_2
LETTRE DE PRESENTATION GTATvvv_2LETTRE DE PRESENTATION GTATvvv_2
LETTRE DE PRESENTATION GTATvvv_2
GLOBAL TRANSIT GTAT
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Riadh K.
 
Rapport de stage transport-de marchandise
Rapport de stage transport-de marchandiseRapport de stage transport-de marchandise
Rapport de stage transport-de marchandise
Youssef Islam
 
Rapport de stage I. Falaize
Rapport de stage I. FalaizeRapport de stage I. Falaize
Rapport de stage I. Falaize
Ixchel Falaize
 
Presentation_OpenERP
Presentation_OpenERPPresentation_OpenERP
Presentation_OpenERP
Salhi Fadhel
 
B. Transit et milieu de vie (suite), impact sur la santé
B. Transit et milieu de vie (suite), impact sur la santéB. Transit et milieu de vie (suite), impact sur la santé
B. Transit et milieu de vie (suite), impact sur la santé
pierredo
 

En vedette (20)

Procédures douanières
Procédures douanièresProcédures douanières
Procédures douanières
 
Logistique transport
Logistique transportLogistique transport
Logistique transport
 
Nos Services Transfaro
Nos Services Transfaro Nos Services Transfaro
Nos Services Transfaro
 
LETTRE DE PRESENTATION GTATvvv_2
LETTRE DE PRESENTATION GTATvvv_2LETTRE DE PRESENTATION GTATvvv_2
LETTRE DE PRESENTATION GTATvvv_2
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...
 
Les prestations logistiques
Les prestations logistiquesLes prestations logistiques
Les prestations logistiques
 
Python et son intégration avec Odoo
Python et son intégration avec OdooPython et son intégration avec Odoo
Python et son intégration avec Odoo
 
La fidélisation et la servuction dans le Marketing des services
La fidélisation et la servuction dans le Marketing des servicesLa fidélisation et la servuction dans le Marketing des services
La fidélisation et la servuction dans le Marketing des services
 
Rapport de stage transport-de marchandise
Rapport de stage transport-de marchandiseRapport de stage transport-de marchandise
Rapport de stage transport-de marchandise
 
Le Transport
Le TransportLe Transport
Le Transport
 
Présentation de OpenERP/Odoo: Progiciel de Gestion Intégré Open Source
Présentation de OpenERP/Odoo: Progiciel de Gestion Intégré Open SourcePrésentation de OpenERP/Odoo: Progiciel de Gestion Intégré Open Source
Présentation de OpenERP/Odoo: Progiciel de Gestion Intégré Open Source
 
Rapport de stage I. Falaize
Rapport de stage I. FalaizeRapport de stage I. Falaize
Rapport de stage I. Falaize
 
Ventes négoce - Biloba
Ventes négoce - BilobaVentes négoce - Biloba
Ventes négoce - Biloba
 
ACTUALITES REGLEMENTAIRES EN ENVIRONNEMENT
ACTUALITES REGLEMENTAIRES EN ENVIRONNEMENTACTUALITES REGLEMENTAIRES EN ENVIRONNEMENT
ACTUALITES REGLEMENTAIRES EN ENVIRONNEMENT
 
Venus Transit
Venus TransitVenus Transit
Venus Transit
 
Alfresco
AlfrescoAlfresco
Alfresco
 
Presentation_OpenERP
Presentation_OpenERPPresentation_OpenERP
Presentation_OpenERP
 
B. Transit et milieu de vie (suite), impact sur la santé
B. Transit et milieu de vie (suite), impact sur la santéB. Transit et milieu de vie (suite), impact sur la santé
B. Transit et milieu de vie (suite), impact sur la santé
 

Similaire à Gestion d"une société de transit avec openerp

Ged Open Source - Documation 2010
Ged Open Source - Documation 2010Ged Open Source - Documation 2010
Ged Open Source - Documation 2010
Thomas Choppy
 
Cohabitation Logiciels Libres et propriétaires
Cohabitation Logiciels Libres et propriétairesCohabitation Logiciels Libres et propriétaires
Cohabitation Logiciels Libres et propriétaires
Michel-Marie Maudet
 
20140130 mug lyon - post-mortem d'une application métier
20140130   mug lyon - post-mortem d'une application métier20140130   mug lyon - post-mortem d'une application métier
20140130 mug lyon - post-mortem d'une application métier
Matthieu DUFOURNEAUD
 

Similaire à Gestion d"une société de transit avec openerp (20)

La Structure de l’entreprise Tech-IT Maroc - SSII, Intégrateur de Solutions I...
La Structure de l’entreprise Tech-IT Maroc - SSII, Intégrateur de Solutions I...La Structure de l’entreprise Tech-IT Maroc - SSII, Intégrateur de Solutions I...
La Structure de l’entreprise Tech-IT Maroc - SSII, Intégrateur de Solutions I...
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5
 
Nuxeo Summer Seminar 2007 - Vision And Market (FR)
Nuxeo  Summer Seminar 2007 - Vision And Market (FR)Nuxeo  Summer Seminar 2007 - Vision And Market (FR)
Nuxeo Summer Seminar 2007 - Vision And Market (FR)
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Adoption incrémentale des tests dans VS ALM
Adoption incrémentale des tests dans VS ALMAdoption incrémentale des tests dans VS ALM
Adoption incrémentale des tests dans VS ALM
 
Adoption incrémentale des tests dans VS ALM
Adoption incrémentale des tests dans VS ALMAdoption incrémentale des tests dans VS ALM
Adoption incrémentale des tests dans VS ALM
 
Rapport de pfe format doc 2013
Rapport de pfe format doc 2013Rapport de pfe format doc 2013
Rapport de pfe format doc 2013
 
Work placement bachelor's degree computer science_2009
Work placement bachelor's degree computer science_2009Work placement bachelor's degree computer science_2009
Work placement bachelor's degree computer science_2009
 
Tech-IT Academy catalogue des formations
Tech-IT Academy catalogue des formationsTech-IT Academy catalogue des formations
Tech-IT Academy catalogue des formations
 
Openerp
OpenerpOpenerp
Openerp
 
Piège dans les Nuages - Version Rebuild 2015 Nantes
Piège dans les Nuages - Version Rebuild 2015 NantesPiège dans les Nuages - Version Rebuild 2015 Nantes
Piège dans les Nuages - Version Rebuild 2015 Nantes
 
Migration des données et portage du module GMAO de OpenERP 6.1 vers Odoo 8
Migration des données et portage du module GMAO de OpenERP 6.1 vers Odoo 8Migration des données et portage du module GMAO de OpenERP 6.1 vers Odoo 8
Migration des données et portage du module GMAO de OpenERP 6.1 vers Odoo 8
 
Ged Open Source - Documation 2010
Ged Open Source - Documation 2010Ged Open Source - Documation 2010
Ged Open Source - Documation 2010
 
Cohabitation Logiciels Libres et propriétaires
Cohabitation Logiciels Libres et propriétairesCohabitation Logiciels Libres et propriétaires
Cohabitation Logiciels Libres et propriétaires
 
Déjeuner-débat EIM360 | Machine Learning et Transformation Digitale, un duo g...
Déjeuner-débat EIM360 | Machine Learning et Transformation Digitale, un duo g...Déjeuner-débat EIM360 | Machine Learning et Transformation Digitale, un duo g...
Déjeuner-débat EIM360 | Machine Learning et Transformation Digitale, un duo g...
 
Supervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec NagiosSupervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec Nagios
 
20140130 mug lyon - post-mortem d'une application métier
20140130   mug lyon - post-mortem d'une application métier20140130   mug lyon - post-mortem d'une application métier
20140130 mug lyon - post-mortem d'une application métier
 
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-ConsultingRapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
 
Tech it présentation-activités&solutions__anpme_moussanada_it_2014
Tech it présentation-activités&solutions__anpme_moussanada_it_2014Tech it présentation-activités&solutions__anpme_moussanada_it_2014
Tech it présentation-activités&solutions__anpme_moussanada_it_2014
 
Présentation open bravo
Présentation open bravoPrésentation open bravo
Présentation open bravo
 

Plus de HORIYASOFT

Plus de HORIYASOFT (20)

gnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdfgnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdf
 
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptxDeployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
 
Hackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federationHackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federation
 
7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entreprise7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entreprise
 
Telemedecine au maroc
Telemedecine au marocTelemedecine au maroc
Telemedecine au maroc
 
Amélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tmsAmélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tms
 
Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8
 
Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016
 
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
 
Openerp à la poste maroc
Openerp à la poste marocOpenerp à la poste maroc
Openerp à la poste maroc
 
Gestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerpGestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerp
 
Gestion programme moussanada avec openerp
Gestion programme moussanada avec openerpGestion programme moussanada avec openerp
Gestion programme moussanada avec openerp
 
Mise en conformité_module_finance_maroc
Mise en conformité_module_finance_marocMise en conformité_module_finance_maroc
Mise en conformité_module_finance_maroc
 
Gestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerpGestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerp
 
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrierGestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
 
Openerp pour les grossistes de médicament
Openerp pour les grossistes de médicamentOpenerp pour les grossistes de médicament
Openerp pour les grossistes de médicament
 
Odoopriting opendays2014
Odoopriting opendays2014Odoopriting opendays2014
Odoopriting opendays2014
 
Projet tempus mission openerp
Projet tempus mission openerpProjet tempus mission openerp
Projet tempus mission openerp
 
Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7 Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7
 
Plonegov projet egov
Plonegov projet egov Plonegov projet egov
Plonegov projet egov
 

Gestion d"une société de transit avec openerp

  • 1. ‫رة ا‬ 105 ‫ا‬ Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 1
  • 2. Dédicaces Pour les grands sacrifices que tu as faits pour nous, Pour les nuits où tu es resté sans dormir pour veiller sur nous, Pour la formidable mère que tu es Toi qui es toujours fier de moi, Pour le symbole respectueux que tu es pour moi, Pour le père que tu es Nul mot ne reflète ma reconnaissance vers vous Pour votre temps et encouragement Pour le frère et sœur que vous êtes Pour votre soutien Vous membres de ma famille Je dédie ce travail Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 2
  • 3. Remerciement Avant d’entamer ce rapport, je tiens à témoigner ma profonde gratitude à toutes les personnes qui ont participé de loin ou de près à l’élaboration de ce projet de fin d’études. Mes sincères remerciements sont à adresser à Mr. Abderrahman ELKAFIL, directeur de la société NEXTMA et mon encadrant professionnel, pour l’intérêt et le professionnalisme avec lesquels il a suivi la progression de mon travail, et pour ces aides et ces conseils fructueux qu’il n’a cessé de me prodiguer durant toute la durée de mon Projet de Fin d’Études. Je tiens à exprimer ma profonde gratitude à Mr. Kamal Eddine EL KADIRI, mon encadrant universitaire et responsable du Master Spécialisé : Qualité du Logiciel à la Faculté des Sciences de Tétouan, pour son excellent suivi, ses remarques pertinentes et ses recommandations fortes enrichissantes dont j’ai bénéficié tout au long de ce stage, qu’il trouve, ainsi, mes vifs remerciements et mes sentiments les plus respectueux. Je remercie tout particulièrement Mr. Mohamed KHALDI, professeur à la Faculté des Sciences de Tétouan pour sa disponibilité, ses nombreux conseils et ses indications précieuses qui m’ont permis de mener mon travail à bien. Mes vis remerciements vont également à tout le cadre professoral de la faculté des sciences de Tétouan, pour la formation prodigieuse qu’il nous a prodiguée. Que messieurs les membres de jury trouvent ici l’expression de ma reconnaissance pour avoir accepté de juger mon travail. Que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce travail, trouvent l’expression de mes remerciements les plus chaleureux. Hatim EL BOUANANI Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 3
  • 4. Résumé On ne présente plus les logiciels libres, aujourd’hui reconnus pour leur qualité et leur ouverture. Ils ont démontré leur efficacité dans plusieurs domaines, notamment Internet, avec par exemple, le serveur web Apache et le système d’exploitation Linux. Aussi, de nombreuses entreprises et gouvernements ont commencé la migration de leurs systèmes d’information vers des solutions libres. En conséquence, on commence à trouver ces logiciels dans des secteurs traditionnellement réservés aux logiciels propriétaires, en particulier Les ERP (en anglais Enterprise Resource Planning), aussi appelés Progiciels de Gestion Intégrés (PGI). Ainsi, OpenERP, les GNU Entreprise, Compiere et autres viennent empiéter sur les terres de BAAN, SAP, ORACLE, etc. Cependant, ce type d’application joue un rôle stratégique au sein des entreprises qui les utilisent. Il requiert un très haut niveau de technicité et de compétences que ces dernières ne sont pas prêtes à laisser aux mains de développeurs éparpillés aux quatre coins du monde. C’est pourquoi, comme pour les logiciels propriétaires, est apparue la nécessité d’avoir des entreprises prestataires de services spécialisées en logiciels libres. Ce besoin s’est renforcé avec la rationalisation des coûts liés aux systèmes d’information depuis l’éclatement de la «Bulle Internet». NEXTMA, société dans laquelle j’ai effectué mon stage de fin d’études du 16 mars au 01 juillet 2009, est une de ces nouvelles SSLL (Société de Services en Logiciels Libres). Elle propose à ses clients un PGI basé sur le logiciel libre « OpenERP » pour lequel elle peut développer des besoins spécifique pour chacun d’entre eux. Au cours de ce stage, mon travail a consisté à comprendre le fonctionnement de l’OpenERP, et à concevoir et développer un module de gestion de transit à l’aide de l'ERP open source OpenERP. Ce stage m’a aussi permis de mieux comprendre comment fonctionne une société de services et comment une SSLL peut vivre du logiciel libre. Mots clés : ERP open source OpenERP ; Framework OpenObject ; Python ; XML. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 4
  • 5. Abstract It is no longer open source software, today recognized for their quality and openness. They have demonstrated their effectiveness in several areas, including the Internet, for example, the Apache Web server and the Linux operating system. Also, many companies and governments have begun migrating their information systems to open source solutions. Accordingly, we begin to find these programs in areas traditionally reserved for proprietary software, especially ERP (Enterprise Resource Planning), also called Integrated Management Software (IMS). Thus, OpenERP, GNU Enterprise, Compiere and others from encroaching on the lands of BAAN, SAP, Oracle, etc... However, this application plays a strategic role within companies that use them. It requires a very high level of technology and skills that they are not ready to leave in the hands of developers scattered around the world. Therefore, as with proprietary software, has emerged the need for service providers specializing in open source software. This need has increased with the rationalization of costs associated with information systems since the bursting of the "Internet bubble". NEXTMA, in which I conducted my internship graduation from 16 March to 30 June 2009, is one of these new SSLL (in french Société de Services en Logiciels Libres). It offers its customers an ERP system based on free software "OpenERP" for which it can develop specific needs for each of them. During this stage, my job was to understand the functioning of the OpenERP and realize the design and dévloppement the Module transit Management using the open source ERP OpenERP. This internship also allowed me to better understand how a service company and how a SSLL can live free software. Keywords : ERP open source OpenERP ; Framework OpenObject ; Python ; XML. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 5
  • 6. Liste des abréviations Sigle Définition ERP Enterprise Resource Planning PGI Progiciels de Gestion Intégrés GNU General Public License SAP Systeme Anwendungen Produkte in der Datenverarbeitung(en anglais Systems, Applications and Products in Data Processing) SSLL Société de Services en Logiciels Libres PME Petites et Moyennes Entreprises CRM Customer Relationship Management BI Business Intelligence UML Unified Modeling Language 2TUP Two Track Unified Process RUP Rational Unified Process XP eXtreme Programming FOB Free On Board DHS Dirhams DUM Déclaration Unique de la Marchandise SADOC Système de l'Administration des Douanes et de l'Office des Changes ODEP Office d'Exploitation des Ports SI Système d’Information MVC Model View Controller XML eXtensible Markup Language RPC Remote Procedure Call LDAP Lightweight Directory Access Protocol OLAP Online Analytical Processing SGBD Système de Gestion de Base de Données IDE Itegrated Development Environment SWT Standard Widget Toolkit SQL Structured Query Language SGML Standard Generalized Markup Language HTML Hypertext Transfer Protocol DTD Document Type Definition Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 6
  • 7. Liste des figures Figure 1 : Cycle de développement en Y……………………………………… 20 Figure 2 : Diagramme de Gantt……………………………………………....... 21 Figure 3 : Circuit d’un dossier…………………………………………………. 26 Figure 4 : Les acteurs principaux du système 34 Figure 5 : Diagramme des cas d’utilisation Cycle de vie d’un dossier client….. 35 Figure 6 : Architecture technique d’un ERP……………………………........... 43 Figure 7 : Architecture modulaire d’un ERP………………………………....... 44 Figure 8 : Fonctionnalités de base d’un ERP………………………………….. 44 Figure 9 : les relations structurelles entre les trois objets……………………… 45 Figure 10 : Environnement d’exploitation de l’ERP open source OpenERP…… 46 Figure 11 : Diagramme de séquences du scénario Authentification……………. 51 Figure 12 : Diagramme de séquences du scénario Paramétrage………………… 51 Figure 13 : Diagramme de séquences du scénario Gestion des dossiers………... 52 Figure 14 : Diagramme de séquences du scénario Ventilation………………….. 53 Figure 15 : Diagramme de séquences du scénario Déclaration…………………. 54 Figure 16 : Diagramme de séquences du scénario Gestion de la facturation…… 55 Figure 17 : Diagramme de classes……………………………………………… 56 Figure 18 : Diagramme d’activité Cycle de vie d’un dossier…………………… 57 Figure 19 : Diagramme d’état Cycle de vie d’un dossier 58 Figure 20 : Page d’authentification…………………………………………....... 63 Figure 21 : Page de module…………………………………………………....... 64 Figure 22 : Page de dossier……………………………………………………… 64 Figure 23 : Détails de dossier…………………………………………………… 65 Figure 24 : Détails de ventilation de dossier……………………………………. 65 Figure 25 : Détails de déclaration de dossier……………………………………. 66 Figure 26 : Facture des ventes………………………………………………....... 67 Figure 27 : Interface de configuration de la base de données…………………… 75 Figure 28 : Interface de la connexion avec la base de données…………………. 75 Figure 29 : Interface de configuration du profil de l’entreprise………………… 76 Figure 30 : Interface d’authentification des utilisateurs………………………… 76 Figure 31 : Représentation d’une classe………………………………………… 78 Figure 32 : Représentation d’un objet………………………………………....... 78 Figure 33 : Association entre deux classes……………………………………… 78 Figure 34 : Agrégation entre deux classes………………………..…………....... 78 Figure 35 : Héritage entre deux classes…………………………………………. 79 Figure 36 : Diagramme de séquence……………………………………………. 79 Figure 37 : Diagramme de collaboration……………………………………....... 80 Figure 38 : Diagramme d’états transition……………………………………….. 80 Figure 39 : Diagramme d’activité organisé par acteur………………………….. 80 Figure 40 : Diagramme de cas d’utilisation…………………………………....... 81 Figure 41 : Diagramme d’objets……………………………………………........ 81 Figure 42 : Diagramme de classe……………………………………………….. 82 Figure 43 : Diagramme de composant………………………………………....... 82 Figure 44 : Diagramme de déploiement……………………………………........ 82 Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 7
  • 8. Liste des tableaux Tableau 1 : Synthèse des méthodologies utilisées dans le cadre de développement Objet et Nouvelles technologies……………………. 18 Tableau 2 : Planning du projet…………………………………………………… 21 Tableau 3 : Scénario d’authentification………………………………………….. 36 Tableau 4 : Scénario de gérer dossier…………………………………………….. 37 Tableau 5 : Scénario de gérer ventilation………………………………………… 38 Tableau 6 : Scénario de gérer déclaration………………………………………... 39 Tableau 7 : Scénario de gérer facturation………………………………………… 40 Tableau 8 : Scénario de paramétrage…………………………………………….. 41 Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 8
  • 9. Tables des matières Introduction générale……………………………………………..................................... 11 Partie I : Contexte général du projet………………………………………………………….. 13 Chapitre 1 : Présentation de NEXTMA……………………………………………….. 14 1. Présentation générale de NEXTMA……………………………………………… 14 1.1. NEXTMA en Bref………………………………………................................. 14 1.2. Prestations et services………………………………………………………… 14 2. Secteurs d’activités ……………………………………………………………... 16 Chapitre 2 : Présentation du projet……………………………………………………. 17 1. Présentation du projet……….………………………………................................. 17 1.1. Thème du projet………………………………………………………………. 17 1.2. La démarche à suivre…………………………………………………………. 17 2. Planning du projet………………………………………………………………… 20 Partie II : Etude fonctionnelle et technique…………………………………………………… 23 Chapitre 1 : Etude préliminaire………………………………………………………... 24 1. Projet de la gestion de transit……………………………………………………... 24 2. Procédures et circuit d’un dossier de transit……………………………………... 25 2.1 Circuit simplifié d’un dossier import/export………………………………….. 26 2.2 Le circuit d’un dossier………………………………………………………… 27 3. Problématique…………………………………………………………………….. 30 4. Synthèse…………………………………………………………………………... 31 Chapitre 2 : Etude fonctionnelle………………………………………………………. 32 1. Objectifs du projet………………………………………………………………... 32 2. Capture des besoins fonctionnels…………………………………………………. 33 2.1 Définition des acteurs du système…………………………………………….. 33 2.2 Cas d’utilisation du système………………………………………………….. 34 2.3 Description des cas d’utilisation………………………………………………. 36 Chapitre 3 : Etude technique…………………………………………………………... 42 1. Les ERP : Entreprise Resource Planning…………………………………………. 42 1.1 Architecture technique………………………………………………………… 43 1.2 Architecture modulaire………………………………………………………... 43 1.3 Les fonctionnalités de base……………………………………………………. 44 2. Solution de gestion intégrée OpenERP…………………………………………… 45 2.1 Environnement de développement……………………………………………. 45 2.2 Environnement d'exécution…………………………………………………… 46 2.3 Environnement d'exploitation…………………………………………………. 46 2.4 Framework OpenObject……………………………………………………….. 47 Partie III : Mise en Œuvre du projet…………………………………………………………... 49 Chapitre 1 : Conception de la solution………………………………………………... 50 1. Conception des classes métiers…………………………………………………… 50 1.1 Diagrammes de séquences……………………………………………………. 50 1.2 Digramme de classes…………………………………………………….......... 56 Chapitre 2 : Réalisation de la solution………………………………………………… 59 1. Outils utilisés……………………………………………………………………... 59 1.1 IDE Eclipse……………………………………………………………………. 59 1.2 SGBD PostgreSQL.…………………………………………………………… 60 1.3 Langage Python.....……………………………………………………………. 60 Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 9
  • 10. 1.4 Langage XML…………………………………………………………………. 61 2. Réalisation du système…………………………………………………………… 63 2.1 Exemples d’illustration………………………………………………………... 63 Conclusion et Perspectives……………………………………………………………… 68 Glossaire……………………………………………………………………………........ 70 Bibliographie……………………………………………………………………………. 71 Webographie…………………………………………………………………………….. 71 Annexes…………………………………………………………………………………. 72 Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 10
  • 11. Introduction générale Les ERP open source 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é. Mais déjà, ils remontent l'échelle, et s'adressent à des PME de plus de 1000 salariés, que ce soit dans les secteurs industriel, distribution ou services. Mon projet de fin d’études vise à concevoir et développer un module de gestion de transit, qui sera incorporé et déployé sur un progiciel de gestion intégré open source, qui porte le nom « OpenERP ». SECORA-TRANS, Société générale de transit, opère au sein d’un secteur concurrentiel, à forte agressivité commerciale et en pleine évolution. La mise en place donc des procédures et d’une organisation de système d’information sort à l’évidence pour mieux répondre aux exigences d’un tel environnement. Pour cela, SECORATRANS s’est donné dés fin 2006, comme objectif prioritaire l’acquisition d’un Progiciel de Gestion Intégrée open source, afin d'améliorer la qualité de la gestion des dossiers, le partage de l'information dans le cadre des réseaux de gestion, la communication interne, et d'assurer la traçabilité des documents et une rapidité dans leur traitement, pour un meilleur suivi du circuit global des dossiers. Alors mon projet de fin d’études s’articule à concevoir et développer un module de gestion de transit pour SECORATRANS, afin de suivre et contrôler les dossiers. Mon rapport s’axe principalement sur trois parties: La première partie présente une vue générale sur mon projet de fin d’études, elle est composée de deux chapitres: le premier est consacré à la présentation de l’organisme d’accueil, quant au deuxième il présente les objectifs de mon projet de fin d’études et la démarche suivie pour assurer son bon déroulement. La deuxième partie est consacrée à l’étude fonctionnelle et technique, elle est constituée de trois chapitres: le premier expose une étude préliminaire visant à donner une vue sur l’existant, le deuxième présente l’étude fonctionnelle, à travers la capture des besoins fonctionnels, les cas d’utilisations UML et leurs descriptions textuelles, et le troisième définit l’architecture logicielle et le Framework utilisé. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 11
  • 12. La troisième partie est consacrée à la mise en œuvre du projet, elle s’articule autour de deux chapitres: le premier est consacré à la conception des classes métiers en présentant les différents diagrammes de séquences, le diagramme de classes, le diagramme d’activité et le diagramme d’état, quant au deuxième il est consacré à la réalisation de la solution en présentant les différents outils utilisés et quelques prises d’écran du système que j’ai réalisé. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 12
  • 13. Contexte général du Partie projet 1 Cette première partie présente une vue générale sur mon projet de fin d’études intitulé « Conception et Développement d’un module de gestion de transit à l’aide de l'ERP open source OpenERP ». Elle se compose de deux chapitres : Le premier chapitre est consacré à la présentation de l’organisme d’accueil. Le deuxième chapitre présente les objectifs de mon projet de fin d’études ainsi que la démarche suivie pour assurer son bon déroulement dans les délais fixés. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 13
  • 14. Chapitre Présentation de NEXTMA Dans ce chapitre, je présente de manière générale la société NEXTMA en tant qu’organisme d’accueil où s’est déroulé mon projet, en exposant ses domaines d’activités d’une façon générale. 1. Présentation générale de NEXTMA 1.1 NEXTMA en Bref NEXTMA est une Société de Services en Logiciels Libres (SSLL) qui accompagne les entreprises et institutions dans le choix de solutions open source ainsi que dans l'intégration, le développement, l'adaptation aux besoins spécifiques, la maintenance et le support. Afin de bénéficier des meilleures solutions libres dans la gestion des systèmes d'information, NEXTMA offre aux PME marocaines des services qui sont orientés sur le modèle « ONE STOP SHOPPING ». C'est-à-dire en offrant une gamme étendue des services complémentaires sur mesure, car chaque entreprise à sa spécificité, afin qu'elles puissent faire face aux échéances du libre échange et soient à niveau par rapport aux normes de qualité et de performance internationalement reconnues. 1.2 Prestations et services NEXTMA offre une large palette de prestations et de services basés sur des composants libres adaptés aux systèmes et aux réseaux des clients. La principale tâche de cette société est d’offrir des solutions sur mesure, en matière de formation et d’assistance, concernant les problématiques relevant des systèmes d’informations, moyennant des outils libres. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 14
  • 15. La gamme de services de NEXTMA est articulée autour de quatre axes majeurs qui permettent d'accompagner les clients durant toutes les phases d'un projet afin d'en assurer sa réussite. Support En plus des offres de formations. La société propose aux équipes dédiées au développement, des prestations de support d’aide à la maintenance, afin de réduire le temps de résolution des interrogations ou des difficultés que les entreprises pourraient rencontrer lors de la mise en œuvre de certains logiciels. Conseil NEXTMA possède une équipe formée de consultants techniques et fonctionnels qui assure soit dans le cadre de projets, soit en amont, des missions de conseil dans les domaines suivants: gestion de contenu, travail collaboratif, dématérialisation des procédures, migration vers le libre, architecture et dimensionnement d'applications basées sur open ERP…etc. Développement Il constitue le cœur métier de NEXTMA et comprend le développement sur la base de logiciels libres, de portails collaboratifs Internet ou Intranet, avec des composantes de publication web, de travail collaboratif, de gestion électronique de documents et de workflow. Formation L’offre des formations, techniques et fonctionnelles, permet d'accompagner les organisations qui disposent d’équipes opérationnelles capables de mener à bien des projets. Ces formations peuvent être établies sous forme de transferts de compétences, en phases avals des projets Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 15
  • 16. 2. Secteurs d’activités De part les multiples projets que NEXTMA a mené, elle a acquis un savoir faire susceptible de lui permettre l’implantation de logiciels libres dans les différents secteurs. Enterprise Ressource Planning (ERP) En français Progiciels de Gestion Intégré (PGI). NEXTMA est le partenaire officiel de l’ERP open source Open ERP au Maghreb depuis 2006. Elle adapte celui-ci à la législation marocaine et aux besoins spécifiques des entreprises. Customer Relationship Management (CRM) NEXTMA propose l’offre SUGARCRM qui permet la gestion de la relation client. Business Intelligence (BI) ou informatique décisionnelle. Intranet des entreprises et gestion des contenus Création d’identités visuelles et sites Internet institutionnels et e-Commerce La solution proposée est SMARTSHOP qui une solution libre de e-commerce (commerce électronique) qui s'appuie sur le gestionnaire contenu Joomla! Gestion électronique des documents Il s’agit d’un système informatisé d’acquisition, classement, stockage, archivage des documents. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 16
  • 17. Chapitre Présentation du projet Dans ce deuxième chapitre je présente mon projet de fin d’études, ses objectifs ainsi que la démarche suivie pour son déroulement dans les meilleures conditions. 1. Présentation du projet 1.1. Thème du projet Mon projet de fin d’études vise à concevoir et développer un module de gestion de transit pour les transitaires, afin de mettre en place des indicateurs pour suivre et contrôler les dossiers des clients. Le module permettra alors de gérer le cycle de vie d’un dossier, depuis l’ouverture jusqu’à la facturation de vente. 1.2. La démarche à suivre Afin d’élaborer mon projet, j’ai choisi d’utiliser UML (Unified Modeling Language) comme formalisme, et 2TUP (Two Track Unified Process) comme démarche. Dans cette section, je commence par une brève présentation du langage de modélisation UML en justifiant ce choix, et ensuite, je passe en revue les différentes étapes de la démarche 2TUP en expliquant les raisons qui j’ai poussé à l’adopter. (Pour plus de détails sur le formalisme UML voir l’annexe 2) Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 17
  • 18. 1.2.1 Le formalisme UML UML est considéré comme le langage standard de conception orienté objet, il est un formalisme et pas une méthode. Il s'en suit qu'il définit un ensemble d’éléments de modélisation et une notation graphique pour modéliser les systèmes et ne décrit pas les étapes à suivre pour le faire. Les raisons qui m’ont poussé à adopter UML dans mon projet se résument en : UML offre un outil prêt à l'emploi basé sur une modélisation visuelle qui permet d'échanger des modèles compréhensibles ; Si on développe avec des langages Orientés Objet, il est plus approprié de concevoir avec des formalismes Orientés Objet. 1.2.2 Processus de développement Le succès d’un projet dépend de l’adéquation du projet au processus de développement. Le tableau suivant (Tableau 1) présente une synthèse des processus les plus en vogue dans la communauté Objet et Nouvelles Technologies. Description Points Forts Points Faibles - Itératif ; - Méthodologie centrée - Spécifie le dialogue entre les RUP sur l’architecture et différents intervenants du - Coûteux à personnaliser ; Rational couplée aux diagrammes projet : les livrables, les - Très axé processus, au Unified UML ; plannings, les prototypes… détriment du développement. Process - Cible des projets de - Propose des modèles de plus de 10 personnes. documents, et des canevas pour des projets types. - Ne couvre pas les phases en - Itératif ; XP amont et en aval au - Cible des projets de - Simple à mettre en œuvre ; eXtreme développement ; moins de 10 personnes. - Fait une large place aux Programming - Assez flou dans sa mise en aspects techniques. œuvre. - Itératif ; -S'articule autour de - Fait une large place à la - Plutôt superficiel sur les 2TUP l'architecture ; technologie et à la gestion du phases situées en amont et en Two Track -Propose un cycle de risque ; aval du développement ; Unified développement en Y ; - Définit les profils des - Ne propose pas de Process - Cible des projets de intervenants, les livrables, les documents types. toutes tailles. plannings, les prototypes. Tableau 1 : Synthèse des méthodologies utilisées dans le cadre de développement Objet et Nouvelles technologies Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 18
  • 19. On constate que toutes ces méthodologies proposent de travailler de façon itérative, que ce soit au niveau des plannings, des spécifications, ou du développement. Si l'itératif s'est imposé, c'est parce qu'il réduit la complexité de la réalisation des phases, en travaillant par approches successives et incrémentales. Il est alors possible de présenter rapidement aux utilisateurs des éléments de validation. De plus, l'itératif permet une gestion efficace des risques, en abordant dès les premières itérations, les points difficiles. Le RUP couvre l'ensemble du processus en spécifiant les interactions entre chacune des phases, XP se concentre sur la phase de développement, tandis que 2TUP fait une large place à l'analyse et à l'architecture. Ainsi, et en prenant compte des modalités de mon projet, le 2TUP semble le plus adapté pour mener mon projet. Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des aspects fonctionnels. Le processus en Y s'articule autour de 3 phases : une phase d’étude technique; une phase d’étude fonctionnelle; une phase de réalisation. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 19
  • 20. La figure ci-dessous (Figure 1) illustre les différentes branches du cycle de développement en Y : Figure 1 : Cycle de développement en Y L'objectif de la branche technique est de rassembler les besoins techniques (sécurité, intégration à l'existant,…) dans un dossier, élaborer une architecture logicielle et applicative qui répond aux contraintes présentées dans le dossier technique et identifier les besoins en frameworks techniques afin de palier aux manques de la technologie (formulaires de saisie interactifs, outils de mapping Objet / Relationnel, …). Quant à la branche fonctionnelle, elle a pour objectif de juger de la capacité des développeurs à intégrer l'architecture applicative à monter en compétences sur les frameworks techniques, à comprendre la conception et à suivre les règles de développement. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 20
  • 21. 2. Planning du projet Dés mon première réunion avec mon encadrant, il m’a proposé un planning prévisionnel (Table 2) que j’ai ajusté par la suite et au fur et à mesure de l’avancement du projet. Les tâches inscrites dans ce planning correspondent parfaitement aux phases du cycle du développement Y. Id Tâche Date de début Date de fin Durée 1 Autoformation / Formation : 16/03/2009 04/04/2009 20j Langage de programmation Python ; Framework d’OpenERP OpenObject ; Fonctionnement d’OpenERP. 2 Etude de l’existant 06/04/2009 20/04/2009 11j 3 Etude fonctionnelle 21/04/2009 28/04/2009 6j 4 Etude technique 29/04/2009 05/05/2009 5j 5 Conception de la solution 06/05/2009 18/05/2009 9j 6 Réalisation 19/05/2009 26/06/2009 28j 7 Validation et tests 29/06/2009 30/06/2009 2j 8 Finalisation du rapport 01/07/2009 02/07/2009 2j Total 83j Tableau 2 : Planning du projet Figure 2 : Diagramme de Gantt Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 21
  • 22. Dans sa globalité, le sujet consiste à concevoir et développer un module de gestion de transit à l’aide de l’ERP open source OpenERP pour les transitaires. Pour la bonne conduite du projet, le processus adopté est le processus 2TUP vu qu’il offre l’avantage d’effectuer en parallèle deux études technique et fonctionnelle avant d’attaquer la conception de la solution. La partie suivante sera consacrée à l’étude fonctionnelle et technique en plus d’une étude préliminaire. Dans cette partie, il était question de présenter le contexte général du projet permettant d’avoir une idée plus claire sur le cadre entourant mon projet, afin de découvrir les différentes parties qui suivent avec une vision plus claire. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 22
  • 23. fonctionnelle Etude fonctionnelle Partie et technique 2 La deuxième partie de ce rapport est consacrée à l’étude fonctionnelle et technique. Elle s’articule autour de trois chapitres : Le premier chapitre présente une étude préliminaire visant à donner une vue sur l’existant à SECORATRANS où j’ai fait l’étude de l’existant. Le deuxième chapitre présente l’étude fonctionnelle, à travers la capture des besoins fonctionnels, les cas d’utilisation UML et leurs descriptions textuelles. Le troisième chapitre définit l’architecture logicielle du système et le Framework utilisé. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 23
  • 24. Chapitre Etude préliminaire Dans ce chapitre je présente une étude préliminaire sur le projet en commençant par l’étude de l’existant, la problématique et enfin une synthèse. 1. Projet de la gestion de transit SECORA-TRANS, est une société générale de transit où j’ai fait l’étude de l’existant, opère au sein d’un secteur concurrentiel, à forte agressivité commerciale et en pleine évolution, la mise en place donc des procédures et d’une organisation de système d’information sort à l’évidence pour mieux répondre aux exigences d’un tel environnement. Les moyens mis en place pour exercer les formes de coordination au niveau de la direction tout en laissant au personnel leur autonomie, sont de trois sortes : Le contrôle de performance, d’où une gestion par objectif ; La supervision directe, d’où la standardisation et la formalisation de toutes les procédures de travail ; Le travail de groupe pour une polyvalence des collaborateurs et un système de résultat. Ces moyens réduisent la surface de contrôle du sommet stratégique. Les qualifications professionnelles requises et la formation continue y contribuent pour beaucoup. En outre toute cette organisation ne peut donner ces meilleurs fruits que si elle est accompagnée d’un système d’information bien rodé. Cela ne peut se faire qu’à l’aide d’un Progiciel de Gestion Intégré open source qui permettra : D’assurer une coordination entre tous les intervenants de l’équipe ; Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 24
  • 25. De suivre toutes les opérations effectuées par les intervenants en temps réel ; D’avoir des tableaux de pilotage retraçant toute l’activité ; D’avoir un archivage et accès aux documents et aux informations sécurisé et rapide. Pour faire face à l’évolution des structures et des technologies du commerce international, SECORA-TRANS a lancé d’une manière successive depuis 5 ans une série de logiciels afin de mieux répondre à ces problèmes de gestion interne, je peux citer à titre d’exemple : le logiciel « Gestion des dossiers » : qui sert seulement à l’archivage des dossiers validés non encore facturés. le logiciel « Gestion de Ventilation » : c’est un logiciel utilisé par le déclarant afin de répartir la valeur totale déclarée entre plusieurs articles d’une même facture soumis à un même régime douanier ; le logiciel « Gestion de la facturation » : c’est un logiciel utilisé par l’employé afin de l’aider à Facturer et suivre le paiement des clients. 2. Procédures et circuit d’un dossier de transit Le système actuel est basé sur les registres manuels, ainsi que des applications métiers ne communiquant pas entre elles en plus des états et des tableaux réalisés sur Excel ou word. Le processus du métier est décrit dans les lignes qui suivent : Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 25
  • 26. 2.1 Circuit simplifié d’un dossier import/export Secrétaire I Réception des documents Secrétaire II Ouverture et suivi des dossiers import/export Déclarant Déclaration de la marchandise Opératrice de saisie Saisie de la déclaration en détail Commis Dédouanement des produits Agent de facturation Etablissement de la facture clients : Comptable Contrôle et suivi des dépenses et factures clients Figure 3 : Circuit d’un dossier Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 26
  • 27. 2.2 Le circuit d’un dossier 2.1.1 Réception des documents «la secrétaire I » Réception par fax, par courrier de l’ordre de transit et des documents qui l’accompagnent (avis d’arrivée + factures fournisseur,…) afin de permettre au transitaire de prendre les dispositions nécessaires à la déclaration (la date de réception ainsi que les documents reçus). Parfois le client se présente directement au bureau de la société muni des documents nécessaires (factures fournisseur, liste de colisage, titre d’importation, certificat d’origine, titre de transport, …). Dans ce cas, «la secrétaire I» lui délivre un accusé de réception sur lequel est mentionné le jour de réception, ainsi que les documents reçus, et garde une copie. 2.1.2 Ouverture d’un dossier «la secrétaire II» Tout d’abord, elle vérifie les documents reçus et s’assure de leur caractère original, relève les documents manquants au dossier, qui peuvent être source de blocage. Elle procède par la suite à leur enregistrement sur un registre contenant les indications suivantes : le numéro de dossier (numéro de classement+l’année) ; le nom de l’importateur ; le bureau de dédouanement (ex casa port, casa extérieur...) ; la désignation de la marchandise ; la valeur de la marchandise en dirham et en devise ; le fournisseur. Sur ce registre sont mentionnés par la suite, le poids de la marchandise ainsi que la nature des colis. Le régime douanier attribué à la marchandise ainsi que le numéro de la DUM doivent également être enregistrés sur ce registre (après la validation du dossier). Elle ouvre enfin un dossier sous un numéro et le remplit en fonction des documents reçus, Elle doit mentionner (sur le dossier) les indications suivantes : la date de réception des documents ; le nom et l’adresse du destinataire des marchandises ; Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 27
  • 28. le nom et l’adresse de l’expéditeur des marchandises ; la désignation de la marchandise ; les documents manquants. Après la réception du bon à délivrer, elle complète les énonciations manquantes à savoir : Date d’arrivée ; Les marques, numéros, espèces et nombre des colis ; La nature et le poids brut des marchandises ; Le numéro du titre de transport ; Le dernier port ou aéroport (la provenance). Le numéro du titre d’importation doit également figurer sur le dossier après sa domiciliation. 2.1.3 Déclaration de la marchandise « le déclarant » Il s’agit pour le déclarant de procéder à : Exploitation de dossier par «les secrétaires» ; Identification de tous les éléments lui permettant d’établir la déclaration en détail et de choisir le régime douanier, en fonction de l’usage que l'opérateur économique souhaite réserver à sa marchandise ; Désignation des nomenclatures : recherche de la nomenclature (numéro et libellé) correspondante à chaque produit figurant sur la facture ; Calcul de la contre valeur en monnaie nationale : par l’application du cours de change du jour de la déclaration ; Calcul du poids net total et poids brut total ; Calcul du montant à imputer sur le titre d’importation. La valeur totale à déclarer Prix FOB en devise * cours de change en DHS + montant du fret en devise * cours de change + Frais d’assurance (0.3% du montant coût et frêt en dirhams + Frais d’aconage (23.4 dhs la tonne du poids brut sauf si le montant de l’aconage est indiqué sur la facture de la compagnie de transport) Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 28
  • 29. 2.1.4 La déclaration en détail (DUM) «L’OPÉRATRICE DE SAISIE» Le logiciel SADOC permet la saisie, la modification et la consultation des éléments de la déclaration, il permet également la consultation des déclarations sommaires. Avant de commencer la saisie du dossier, elle lui donne un numéro de répertoire. Une fois les énonciations de la DUM saisies, l’opératrice a deux possibilités. Soit mettre la déclaration en «ATTENTE» dans ce cas le système procède à son enregistrement provisoire et les données saisies sont gardées en mémoire pour une durée limité avant qu’elles soient automatiquement effacées. Soit de valider définitivement la déclaration ce qui vaut signature et enregistrement définitif par le système. Une déclaration signée et enregistrée définitivement ne peut être ni supprimée ni modifiée par l’opératrice. Mais elle peut être consultée. 2.1.5 La facturation : « Agent de facturation » Une fois le processus de dédouanement achevé, le dossier est transmis à l’agent chargé de la facturation. La facture reprend tous les frais engagés qui sont à la charge de client. Une fois établie une copie est adressée au client avec toutes les pièces justificatives (facture d’échange, facture magasinage, récépissé d’envoi des lettres de réserve,…) en plus d’une copie de l’exemplaire redevable de la DUM et l’engagement d’importation imputé. Et l’autre copie est transmise au service comptabilité. La facture client comprend plusieurs frais dont on peut citer à titre d’exemple : frais d’ouverture de dossier ; manipulation ; frais de transport local ou national ; frais d’échange ; aconage ODEP ; les lettres de réserves ; droit de douane ; frais de surestarie ; frais de magasinage (en cas de dépotage) ; honoraires. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 29
  • 30. 3. Problématique Le système actuel de la société SECORATRANS est basé sur les registres manuels ainsi que des applications métiers ne communiquant pas entre elles en plus des états et des tableaux réalisés sur Excel ou word. Les outils existant aujourd’hui sur le marché proposent des fonctionnalités nettement plus avancées et mieux adaptées aux besoins de SECORATRANS, en terme de pilotage, d’intégration de données, de partage d’information en temps réel... Ils permettent également de répondre aux exigences des clients et partenaires de l’entreprise. Dans un tel contexte, l’entreprise avait plus que jamais besoin d’un nouveau système qui correspond le plus à ses exigences. Car, les premiers diagnostics qui ont été effectués ont fait ressortir que les applications informatiques actuelles, qui malgré leur contribution effective à la gestion de l’entreprise, restent marqués par des insuffisances techniques, stratégiques et organisationnelles. Les principales faiblesses diagnostiquées sont : L’existence de diverses applications informatiques isolées ; un recours à l’informatique insuffisamment développé (exemple : opération du contrôle et du suivi des dossiers non informatisée…) ; Coexistence de procédures manuelles avec les applications informatiques; Les systèmes informatiques n’intègrent pas toutes les demandes fonctionnelles exprimées par l’entreprise ; Une large utilisation de documents non informatisés (les chemises import/export (vert et jaune), fiches de dépense, chèque, bulletin de réception…) ; Manque de traçabilité ; Insuffisance du contrôle et du suivi des dossiers ; l’absence de procédure automatisée de recoupement d'information utilisant un identifiant unique; Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 30
  • 31. 4. Synthèse Pour remédier aux problèmes cités ci-dessus, et pour améliorer le système de suivi des dossiers pour les transitaires, SECORATRANS cherche à mettre en place un ERP open source OpenERP qui assure la gestion de l'ensemble des services de l’entreprise depuis la réception des documents jusqu’au recouvrement : réception des documents, suivi et contrôle des dossiers. Cette étude préliminaire m’a permis de bien cerner le sujet et de dégager les principales fonctionnalités utiles pour la mise en place de mon projet. J’entamerai dans le chapitre suivant l’étude fonctionnelle. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 31
  • 32. Chapitre Etude fonctionnelle Ce chapitre présente l’étude fonctionnelle du projet qui comprend la capture des besoins fonctionnels et la formalisation de ces besoins en cas d’utilisation UML. 1. Objectifs du projet La solution recherchée va couvrir l’ensemble des activités de l’entreprise : suivi des dossiers, la ventilation de la valeur déclarée, la déclaration de la marchandise et l’archivage des dossiers facturés, suivi et contrôle des dossiers, et devra permettre la dématérialisation de l’ensemble des opérations de l’entreprise. En effet, ce projet doit aussi avoir pour objectif : la réalisation d'une application informatique unique pour la gestion de l'ensemble des services de l’entreprise depuis la réception des documents jusqu’au recouvrement : réception des documents, suivi et contrôle des dossiers. mettre en place un système commun et partagé répondant aux attentes de l’ensemble des utilisateurs de l’entreprise l’introduction d’un mot de passe pour chaque utilisateur, choisi par lui-même. Et qui une fois attribué, il n’engage que la personne titulaire de dit mot de passe. mettre en place une solution complète de serveur d'entreprise comprenant des fonctions de messagerie et de collaboration un stockage de données protégé et centralisé. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 32
  • 33. 2. Capture des besoins fonctionnels Après avoir cerner les besoins de la société dans le chapitre précédent (étude préliminaire), je vais formaliser ces besoins en cas d’utilisation en définissant les acteurs interagissant avec le système. 2.1 Définition des acteurs du système À ce stade je vais déterminer les six acteurs principaux interagissant avec le système Utilisateur Cet acteur accède de manière sécurisée au système, et consulte les contenus. Secrétaire de réception des dossiers Cet acteur accède de manière sécurisée au système, recevoir les contenus, et c’est celui qui valide ou pas les dossiers des clients. Déclarant Cet acteur accède de manière sécurisée au système, ventile les dossiers, et c’est celui qui fait la déclaration des marchandises. Opérateur de saisie Cet acteur accède d’une manière sécurisée, obtient le numéro de la D.U.M de la marchandise. Agent de facturation Cet acteur accède d’une manière sécurisée, établit la facture des ventes des dossiers clients. Administrateur Cet acteur attribue les droits d'accès aux utilisateurs, gère les utilisateurs (ajout, modification, suppression d'un utilisateur), ainsi que le contenu et l’arborescence de l’OpenERP. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 33
  • 34. Remarque : L’opérateur de saisie n’est pas un acteur système car il n’interagie qu’avec le système SADOC de la douane. Figure 4 : Les acteurs principaux du système 2.2 Cas d’utilisation du système Le diagramme des cas d’utilisation permet de structurer les besoins des utilisateurs et les objectifs d’un système. En effet, il identifie les acteurs et leurs interactions avec le système. Afin de mieux comprendre tous les volets du système, je l’ai décomposé en huit cas d’utilisations. Par la suite, je vais détailler les principaux cas d’utilisation. La figure ci-dessous (Figure 5) représente le diagramme des cas d’utilisation : Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 34
  • 35. Figure 5 : Diagramme de cas d’utilisation Cycle de vie d’un dossier client Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 35
  • 36. 2.3 Description des cas d’utilisation 2.3.1 Cas d’utilisation Authentification Le tableau ci-dessous (Tableau 3), représente la description de ce cas d’utilisation: Code CU_Authentification Nom Authentification Acteurs système Tous les acteurs Objectif/Résultat Accès aux fonctionnalités attribuées. Description Ce scénario permet à tout acteur de s’identifier auprès du système et d’accéder aux fonctionnalités qui lui sont attribuées. Pré condition Existence à dans la base de données du système Scénario Action de l’acteur Action du système authentification 1 Se connecter au système. 2 Vérifier login et mot de passe, valider et autoriser l’accès selon les droits. Exceptions 1 Se connecter au système 2 Le système ne répond pas 1 Se connecter au système 2 Vérifier les informations de l’utilisateur. Retour à 1 (login ou password incorrect) Fréquence A la demande. Tableau 3 : Scénario d’authentification 2.3.2 Cas d’utilisation Gérer Dossier Ce cas d’utilisation concerne la gestion des dossiers, opération effectuée par l’Administrateur qui peut ajouter, modifier et supprimer un dossier, ainsi que la validation d’un dossier. Le tableau ci-dessous (Tableau 4), représente la description de ce cas d’utilisation: Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 36
  • 37. Code CU_Gerer_Dossier Nom Gérer Dossier Acteurs système Administrateur Objectif/Résultat Suivre et contrôler les dossiers clients. Description Ce scénario permet de faire les opérations d’ajout, de modification et de suppression d’un dossier client dans la base de données du système, ansi que la validation et la clôture d’un dossier client. Pré condition Authentification au système avec le compte Administrateur. Scénario Gérer_Dossier Action de l’acteur Action du système 1 Saisir les informations de dossier à ajouter. 2 Rechercher le numéro de dossier à modifier. 3 Rechercher le numéro de dossier à supprimer. 4 Enregistrer les informations dans la base de données du système. 5 Valider dossier 6 Etat dossier ouvert Exceptions 1 Saisir les informations de dossier à ajouter. 2 Le système ne répond pas. 1 Saisir les informations de dossier à ajouter. 2 Données insuffisantes. 1 Rechercher le numéro de dossier à modifier, à supprimer et valider. 2 Le système ne répond pas. 1 Rechercher le numéro de dossier à modifier, à supprimer et à valider. 2 Erreur. Fréquence A la demande. Tableau 4 : Scénario de gérer dossier Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 37
  • 38. 2.3.3 Cas d’utilisation Gérer Ventilation Ce cas d’utilisation consiste à saisir les détails des différents articles de la marchandise (nomenclature, quantité, poids, valeur). Le tableau ci-dessous (Tableau 5), représente la description de ce cas d’utilisation: Code CU_Gerer_Ventilation Nom Ventilation de la marchandise. Acteurs système Déclarant. Objectif/Résultat Saisie des détails des différents articles de la marchandise. Description Ce scénario permet de faire la saisie des articles qui seront utiles pour la déclaration de la marchandise. Pré condition Authentification au système avec le compte Déclarant. Scénario Gerer_Ventilation Action de l’acteur Action du système 1 Lister dossiers ouverts 2 Afficher liste dossiers ouverts. 3 Choisir numéro dossier 4 Afficher dossier choisi 5 Ajouter ventilation 6 Enregistrer les informations dans la base de données du système Exceptions 1 Lister dossiers ouverts 2 Choisir numéro dossier 3 Ajouter ventilation 4 Le système ne répond pas 5 Données insuffisantes pour la ventilation Fréquence A la demande Tableau 5 : Scénario de gérer ventilation Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 38
  • 39. 2.3.4 Cas d’utilisation Gérer Déclaration Ce cas d’utilisation consiste à calculer la contre valeur, le poids net total, poids brut total et le montant à imputer sur le titre d’importation brut. Le tableau ci-dessous (Tableau 6), représente la description de ce cas d’utilisation: Code CU_Gerer_Declaration Nom Déclaration de la marchandise Acteurs système Déclarant Objectif/Résultat Calcul des différents indicateurs de la marchandise Description Ce scénario permet de faire le calcul de la contre valeur, le poids net total, poids brut total et le montant à imputer sur le titre d’importation brut. qui seront utiles pour la déclaration chez le système de la douane (SADOC). Pré condition Authentification au système avec le compte Déclarant Scénario Gerer_Declaration Action de l’acteur Action du système 1 Lister dossiers à déclarer 2 Afficher liste dossier à déclarer 3 Choisir numéro dossier 4 Afficher dossier choisi 5 Déclarer dossier 6 Calculer paramètres 7 Etat dossier déclaré Exceptions 1 Choisir numéro dossier 2 Déclarer dossier 3 Le système ne répond pas 4 Données insuffisantes pour le calcul Calcul impossible dossier (déjà déclaré) Fréquence A la demande Tableau 6 : Scénario de gérer déclaration Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 39
  • 40. 2.3.5 Cas d’utilisation Gérer Facturation Ce cas d’utilisation reprend tous les frais engagés qui sont à la charge de client. Une fois établie une copie est adressée au client avec toutes les pièces justificatives. Le tableau ci-dessous (Tableau 7), représente la description de ce cas d’utilisation: Code CU_Gerer_Facturation Nom Facture des ventes Acteurs système Agent Facturation Objectif/Résultat Calcul des frais de dossier Description Ce scénario permet de faire le calcul tous les frais engagés qui sont à la charge de client Pré condition Authentification au système avec le compte Agent Facturation Scénario Gerer_Facturation Action de l’acteur Action du système 1 Lister dossiers déclarés 2 Afficher liste dossiers déclarés 3 Choisir numéro dossier 4 Afficher dossier choisi 5 Facturer dossier 6 Calculer montant total 7 Etat dossier facturé Exceptions 1 Choisir numéro dossier 2 Facturer dossier 3 Le système ne répond pas 4 Données insuffisantes pour la facturation Fréquence A la demande Tableau 7 : Scénario de gérer facturation Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 40
  • 41. 2.3.6 Cas d’utilisation Paramétrage Ce cas d’utilisation concerne le paramétrage de l’application (la gestion des accès et la gestion de contenu). Le tableau ci-dessous (Tableau 8), représente la description de ce cas d’utilisation: Code CU_PARAM_APPLICATION Nom Définition des paramètres de l’application Acteurs système Administrateur. Objectif/Résultat Paramétrer l’application Description Ce scénario permet de paramétrer l’application, la gestion des accès, la gestion de contenus... Pré condition Connexion avec le compte Administrateur Scénario Action de l’acteur Action du système Paramétrage du 1 Choisir l’option Paramétrage du système Système. 2 Afficher la liste des paramètres. 3 Définir les paramètres. 4 Valider 5 Sauvegarder Exceptions 1 Définir les paramètres 2 Le système ne répond pas 1 Définir les paramètres 2 Paramètres désactivés Fréquence A la demande. Tableau 8 : Scénario de paramétrage Au terme de ce chapitre, j’ai achevé les différentes phases de la branche fonctionnelle du processus Y. L’objet du chapitre suivant est l’étude technique du projet qui a pour but de faire apparaître le choix de l’architecture du système et les frameworks techniques qui seront utilisés. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 41
  • 42. Chapitre Etude technique Ce chaplitre détaille la branche technique du processus Y. Je présente d’abord, la technologie utilisée, puis l’architecure logicielle du système pour enfin le Framework et techniques utilisés 1. Les ERP : Entreprise Resource Planning Les ERPs (Enterprise Resource Planning), aussi appelés Progiciels de Gestion Intégrés (PGI), sont des applications dont le but est de coordonner l'ensemble des activités d'une entreprise autour d'un même système d'information. Les Progiciels de Gestion Intégrés proposent généralement des outils de Groupware et de Workflow afin d'assurer la transversalité et la circulation de l'information entre les différents services de l'entreprise. Plus qu'un simple logiciel, un ERP est un véritable projet demandant une intégration totale d'un outil logiciel au sein d'une organisation et d'une structure spécifique, et donc des coûts importants d'ingénierie. D'autre part sa mise en place dans l'entreprise entraîne des modifications importantes des habitudes de travail d'une grande partie des employés. Ainsi on considère que le coût de l'outil logiciel représente moins de 20% du coût total de mise en place d'un tel système. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 42
  • 43. 1.1 Architecture technique Figure 6 : Architecture technique d’un ERP L'ERP est donc sur serveur. La majorité des ERP sont couplés à une base de données ORACLE. De plus, les ERP sont compatibles packs Office, en particulier pour PowerPoint et Excel. En effet, le premier étant utile pour personnaliser les bureaux ERP en fonction de l'entreprise et le second pour effectuer les imports/exports de données. Enfin, les ERP sont aussi compatibles avec des outils de reporting (CrystalReport en général). Le reporting étant utilisé en particulier pour le module de gestion relation client, que nous verrons par la suite. 1.2 Architecture modulaire Un ERP est un ensemble dont toutes les parties fonctionnent les unes avec les autres d'où l'ergonomie et l'unicité des informations et donc la cohérence du SI. Un ERP est modulaire dans le sens où il est possible de n'avoir qu'une ou plusieurs applications en même temps, ou peu à peu. Les applications modulaires telles que les ERP permettent d'être sûr de la compatibilité des modules entre eux, ils s'imbriquent comme des Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 43
  • 44. blocs de Lego et fonctionnent ensemble (pas de vérification de compatibilité à effectuer).Voici un exemple d'architecture modulaire qui tend à représenter tous les ERP: Figure 7 : Architecture modulaire d’un ERP L'architecture modulaire schématisée ci-dessus intègre plusieurs modules retouchant aux grandes fonctions d'une entreprise : le module finance, logistique et e-commerce… 1.3 Les fonctionnalités de base La figure ci-dessous (Figure x) représente les fonctionnalités de base d’un ERP : Figure 8 : Fonctionnalités de base d’un ERP Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 44
  • 45. 2. Solution de gestion intégrée OpenERP Open ERP est un progiciel de gestion intégré en licence libre, dont la grande souplesse est idéale aussi bien pour les indépendants que pour les PME. Il couvre pratiquement tous les secteurs d’activité : industrie, commerce, prestations de services, e-Commerce, négoce, etc. Comme la plupart des logiciels libres, l'accessibilité, la flexibilité et la simplicité sont les maîtres mots du développement. 2.1 Environnement de développement Un MVC est une architecture de modèle utilisée en génie logiciel. Dans des applications complexes qui présentent des lots de données aux utilisateurs, on souhaite souvent séparer les données (modèle) et l'interface utilisateur (vue), de sorte que les changements à l'interface utilisateur n'affectent pas le traitement des données, et que les données peuvent être réorganisées sans changer l'interface utilisateur. Le MVC résout ce genre de problème en découplant l'accès des données et la logique des applications de la présentation des données et de l'interaction utilisateur, en introduisant un composant intermédiaire : « le contrôleur ». Dans open ERP, on peut appliquer cette sémantique de Model-View-Controller avec : Model : les modèles sont les objets déclarés dans OpenERP. Ils sont également des tables PostgreSQL ; View : les vues sont définies en fichiers XML dans OPENERP ; Controller : le contrôleur est Python qui contrôle OPENERP. Figure 9 : les relations structurelles entre les trois objets Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 45
  • 46. 2.2 Environnement d'exécution Pour exécuter le code, l'OpenERP serveur doit être installée dans un serveur exécutant MVC Framework Foundation et un groupe d'applications de tierce-partie que nous appelons l'environnement d'exploitation. Les utilisateurs n'ont besoin de rien de plus qu'un OpenERP web client ou OpenERP GTK client pour accéder aux différents modules de l’ERP. 2.3 Environnement d'exploitation OpenERP a besoin d'un groupe bien connu d'applications tierces telles web services, OpenERP web client ou OpenERP GTK client, et quelques autres utilitaires. Base de données PostgreSQL est également nécessaire. Le modèle est basé sur le standard SQL, et toutes ces applications peuvent être installées aussi bien sur Linux ou Windows. Figure 10 : Environnement d’exploitation de l’ERP open source OpenERP Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 46
  • 47. 2.4 Framework OpenObject OpenObject est le Framework d'OpenERP, ou programme permettant la génération d'OpenERP. Il est très souple et complet, et permet la création des applications de gestion, quelles qu'elles soient. Figure 11 : Framework OpenObject d’OpenERP 2.4.1 Rapidité de développement Développer des applications de gestion avec OpenObject, bien plus qu'avec n'importe quel autre outil de ce type. On crée un fichier Python contenant la description des champs et les règles de gestion, un fichier XML décrivant les écrans, et le tour est joué. Bien sûr, il n'y a aucune limitation aux codes, ceci étant écrit en Python, langage très riche. Si on a besoin d'aller plus loin, OpenObject permet la création de Wizards (sous- programmes), l'automatisation des tâches et leur planification, l'intégration de données. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 47
  • 48. 2.4.2 Génération de rapports Les rapports sont très simplement définis et intégrés, ce sous 2 formes : Rapports imprimables Ils sont générés par le biais de reportlab. Les fichiers de génération de ces rapports peuvent être transformés dans OpenOffice, puis importés rapidement. Ecrans On peut définir tout type de tableau de bord, contenu des données, des listes, des graphiques. 2.4.3 Gestion des workflows Toutes les règles de gestion peuvent être définies. Le moteur de Workflows d'OpenObject est très puissant, et permet des imbrications de règles complexes (ou simples), qui peuvent être ensuite modifiées par le biais de l'application elle-même. 2.4.4 Communication avec des applications tierces Toutes les communications entre OpenObject et les interfaces (même vers le client GTK officiel) sont effectuées en XMLRPC. Les types d'objets, les écrans, les données sont transmises par ce protocole. On a besoin d'intégrer les applications OpenObject à un portail ou à une autre application. Des connecteurs existent entre OpenObject et LDAP, ainsi qu'avec de nombreuses autres applications Open Source (ezPublish, Asterisk, ...). 2.4.5 Business Intelligence OpenObject est, dans sa version 5, entièrement doté des fonctionnalités pour effectuer simplement le stockage des données dans des bases de données tierces (OLAP). Les rapports sont donc le vrai reflet des activités, non de simples statistiques internes. Ce chapitre a permis de détailler les différents choix techniques, à savoir la technologie adoptée, l’architecture logicielle et le Framework utilisé. La partie suivante détaillera la branche réalisation du processus Y. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 48
  • 49. Mise en Œuvre du Partie projet 3 Le contenu de cette partie s’articule sur deux chapitres : Le premier est consacré à l’analyse et la conception du module métier du système, en présentant le diagramme de classes, d’activité et d’état, quelques diagrammes de séquences et la structure du système. Le deuxième est consacré à la réalisation du système, en présentant quelques prises d’écran. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 49
  • 50. Chapitre Conception de la solution Ce chaplitre détaille la phase conception de la branche réalisation du processus Y. Je présente d’abord la conception des classes métiers puis la structure du système. 1. Conception des classes métiers 1.1 Diagrammes de séquences Le diagramme de séquences permet de mettre en relief les différents messages échangés entre les objets et acteurs du système, et ce selon un point de vue temporelle. En effet, l'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical (axe temporel) du diagramme ; le temps s'écoule indépendamment des événements, "de haut en bas" de l’axe vertical. Je vais dans la suite présenter quelques diagrammes de séquences. 1.1.1 Scénario Authentification Ce scénario permet à l’utilisateur de se connecter au système en saisissant son login et mot de passe. Le système vérifie ces informations qui sont stockées dans la base de données et affiche la page d’accueil suivant les privilèges et le rôle de l’utilisateur. La figure ci-dessous (Figure 12) représente le diagramme de séquences du scénario d’authentification Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 50
  • 51. Figure 12 : Diagramme de séquences du scénario Authentification 1.1.2 Scénario Paramétrage Ce scénario est déclenché par l’administrateur du système, il consiste à faire la gestion du contenu, et la gestion des comptes utilisateurs et les droits d’accès attribués à ces derniers. La figure suivante (Figure 13), présente le diagramme de séquences du cas Paramétrage. Figure 13 : Diagramme de séquences du scénario Paramétrage Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 51
  • 52. 1.1.3 Scénario Gestion des Dossiers : Ce scénario est déclenché par l’administrateur du système, il consiste à faire la gestion des dossiers, et le suivi et le contrôle de ces dossiers (Figure 14). Figure 14 : Diagramme de séquences du scénario Gestion des dossiers 1.1.4 Scénario Ventilation : La ventilation consiste à saisir les détails des différents articles (nomenclature, quantité, poids, valeur) Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 52
  • 53. Figure 15 : Diagramme de séquences du scénario Ventilation 1.1.5 Scénario Déclaration La déclaration de la marchandise consiste à effectuer les opérations suivantes : Calcul de la contre valeur en monnaie nationale : par l’application du cours de change du jour de la déclaration ; Calcul du poids net total et poids brut total ; Calcul du montant à imputer sur le titre d’importation. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 53
  • 54. Figure 16 : Diagramme de séquences du scénario Déclaration Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 54
  • 55. 1.1.6 Scénario Gestion de la facturation La facture reprend tous les frais engagés qui sont à la charge de client. Une fois établie une copie est adressée au client avec toutes les pièces justificatives (facture d’échange, facture magasinage, récépissé d’envoi des lettres de réserve,…). Pour créer un avoir, agent de facturation utilise le numéro de la facture correspondant à la commande client. Figure 17 : Diagramme de séquences du scénario Gestion de la facturation Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 55
  • 56. 1.2 Digramme de classes Le diagramme de classes exprime, de manière générale, la structure statique d’un système, en termes de classes et de relations entre elles. Une classe permet de décrire un ensemble d’objets (attributs et comportements), tandis qu’une relation ou association permet de faire apparaître des liens entre ces objets. Le schéma ci-dessous (Figure 18) représente le diagramme de classe que j’ai établi pour la conception du système: Figure 18 : Diagramme de classes Le schéma ci-dessous (Figure 19) représente le diagramme d’activité que j’ai établi pour la conception du système: Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 56
  • 57. Figure 19 : Diagramme d’activité Cycle de vie d’un dossier Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 57
  • 58. Le schéma ci-dessous (Figure 20) représente le diagramme d’état que j’ai établi pour la conception du système: Figure 20 : Diagramme de classes Ce chapitre avait pour objectif la présentation de la conception détaillée de la solution à travers le diagramme de classes, d’activité, d’état, et quelques diagrammes de séquences. Dans le chapitre suivant je exposerai les outils utilisés, et quelques exemples d’illustration. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 58
  • 59. Chapitre Réalisation de la solution Ce chaplitre détaille la phase réalisation de mon projet. Je présente d’abord, les outils utilisés et quelques prises d’écran du système. 1. Outils utilisés Pour le développement du système je me suis basés sur l’ERP OpenERP et les différentes technologies et Framework qu’il utilise, pour ajouter le système comme module au sein de cet ERP j’ai eu recours à plusieurs outils comme l’IDE Eclipse et le SGBD PostgreSQL, ainsi que la langage de programmation Python et la langage à balises extensible XML, dont la présentation est détaillée dans les paragraphes suivants. 1.1 IDE Eclipse 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 ; Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 59
  • 60. La cohabitation entre plusieurs versions d'un même plug-in sur une même plate- forme ; Le support de plusieurs langages grâce à des plug-ins dédiés : Python, Java, Cobol, C, PHP, C#, ... ; Le support de plusieurs plates-formes d'exécution : Linux, Windows,… La rapidité d'exécution grâce à l'utilisation de la bibliothèque SWT ; 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… 1.2 SGBD PostgreSQL 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. Nous avons utilisé PostgreSQL sous Linux, et nous avons utilisé l’utilitaire pgAdmin pour l’utiliser à distance à partir d’un client Windows. 1.3 Langage Python Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans l'imposer) une approche modulaire et orientée objet de la programmation. Python est développé depuis 1989 par Guido van Rossum et de nombreux contributeurs bénévoles. Détaillons un peu les principales caractéristiques du langage Python: Portable : Il est supporté par les différents systèmes d’exploitation ; Gratuit ; Simple : Il possède une syntaxe très simple tout en combinant des types de données évolués (listes, dictionnaires…) ; Absence des pointeurs ; Il est orienté objet et supporte l’héritage multiple et la surcharge des opérateurs ; Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 60
  • 61. Dynamique : cette fonctionnalité est probablement la plus intéressante de Python ; Extensible : on peut facilement l’interfacer avec des bibliothèques C existantes ; Python : gère ses ressources (mémoire, descripteurs de fichiers...) sans intervention du programmeur, par un mécanisme de comptage de références ; Python : possède actuellement deux implémentations. L'une, interprétée, dans laquelle les programmes Python sont compilés en instructions portables, puis exécutés par une machine virtuelle (comme pour Java, avec une différence importante: Java étant statiquement typé, il est beaucoup plus facile d'accélérer l'exécution d'un programme Java que d'un programme Python).L'autre génère directement du bytecode Java ; Dynamiquement typé ; Soutenu par la communauté d’utilisateurs qui tentent à l’évoluer. 1.4 Langage XML XML (eXtensible Markup Language et en Français Langage à balises étendu, ou Langage à balises extensible) était lancé en 1997 par la communauté SGML (Standard Generalized Markup Language). XML est un langage simple et puissant de description et d’échange de documents structurés de n’importe quel domaine de données grâce à son extensibilité, il décrit cette structure à l’aide d’un système de balises. Quelques points remarquables d’XML : Il apparaît comme un format d’échange de données universel ; Il a la possibilité de créer des nouvelles balises contrairement à HTML qui définit un nombre limité ; Il garantit à ses utilisateurs l’indépendance de leurs documents de toute technologie propriétaire ; Il unifie le monde du traitement de document et celui du Web. Master Spécialisé : Qualité du Logiciel Rapport de Stage 2008/2009 61