Accueil pdf

[3 Janvier 2010] NOUVEAU SITE WEB
      Cliquer sur l'image ci-dessous pour y accéder ...


Nouveau Site Web


 

 

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

 

PARIS

 

 

 

 

MĖMOIRE

 

Présenté en vue d’obtenir le

 

DIPLÔME D’INGĖNIEUR C.N.A.M

 

en

 

INFORMATIQUE

 

par

 

Laurent DONGĖ

 

 

 

 

Réalisation d’un projet de merchandising

 

Soutenu le jeudi 6 décembre 2007

 

 

 

 

Jury

 

 

Présidente :      Isabelle COMYN-WATTIAU, Professeur

 

Membres :       Tatiana AUBONNET, Maître de conférence

 

Jacky AKOKA, Professeur

 

Pierre AUDOIN, Chef de service

 

            Pierre ESTIVALET, Merchandiser Senior

 

 

 

 


Résumé :

 

            Aujourd’hui, afin d’être plus compétitifs, les groupes de distribution ont besoin de se doter d’outils d’optimisation de la présentation des produits sur leurs surfaces de vente. C’est ce que permet l’application Merchandising. On gagne en productivité en automatisant les tâches manuelles et en simplifiant les outils.

            Pour rester souple par rapport à l’utilisation d’une solution propriétaire, nous avons fait le choix de gérer les notions « métier » propres à l’entreprise dans une solution spécifique.

            Cette application a dû être intégrée dans un Système d’Information d’entreprise très hétérogène. L’utilisation d’un ETL permet de réduire la complexité du système en définissant un cadre de développement précis et en masquant les différentes implémentations techniques.

            Plus on en élargit l’emploi, plus la complexité du système diminue. Il nécessite cependant certains outils annexes pour répondre complètement aux besoins.

            D’autre part, nous avons utilisé J2EE pour implémenter les interfaces WEB. C’est une architecture qui répond à nos besoins d’IHM. Elle permet de concevoir des applications structurées, maintenables, mais avec l’inconvénient d’engendrer des coûts de développement importants.

            L’architecture WEB utilisée n’est pas propriétaire mais basée sur des produits Open Source. Elle présente un avantage financier certain du fait de l’absence de dépenses liées aux licences.

            Enfin, des séries de tests de montée en charge ont permis de valider la qualité de services rendus aux utilisateurs.

            La mise en œuvre de l’application répond aux objectifs essentiels. Il est cependant nécessaire de mieux répondre aux besoins de supervision, de reporting et de gestion de la qualité des données.

 

Mots-clés :

 

ETL, conception d’application J2EE, architecture, Open Source, tests

 

Summary :

 

Today, in order to be more competitive, distribution groups need tools to optimize product presentation in their stores. The Merchandising application allows this. With the automatisation of manual tasks and the use of simple tools, productivity has been increased.

To remain flexible compared to the use of an owner solution, we made the choice to manage the concepts with a solution specific to the company.

This application has been integrated into a heterogeneous information system with an ETL. The ETL reduces the system complexity, as it defines a precise development framework and it hides the various technical implementations.

The more the ETL is used, the more the system complexity decreases. However, ETL requires additional tools to satisfy all our needs.

            In addition, we use J2EE to implement the WEB interfaces. It is an architecture which meets our HMI needs. It allows the development of structured applications, easy to support, but the development costs generated are very high.

            The WEB architecture used is based on Open Source products. There is a financial advantage in using these products as there is no licence to pay.

            Stress Tests have allowed the validation of the quality of services given to the users.

            The implementation of the application has satisfied the essential needs. However, some evolutions are needed in order to have tools capable of answering requests of supervision, reporting and management of data quality.

 

Keywords :

 

ETL, J2EE application design,  architecture, Open Source, tests


REMERCIEMENTS

 

 

            J’ai effectué mon « stage » au sein du service Reporting et Pilotage du département administratif de la Direction de l’informatique du Groupe MONOPRIX, sous la responsabilité de Jean-François Lemaire, chef de service et en collaboration avec Pierre Audoin, responsable du Merchandising PGC. Ce « stage » a débuté en septembre 2004.

            Suite à la réorganisation de la Direction de l’informatique, en début 2007, le projet Merchandising est désormais rattaché au service référentiel du département Marchandise dont la responsable est Isabelle Renoncet.

            A ma demande, j’ai été transféré dans l’équipe d’Isabelle Renoncet à partir du premier avril 2007 pour continuer à piloter le projet.

            Ce mémoire n’aurait pu voir le jour sans le soutien de mes professeurs du CNAM, de mes collègues, de mes amis et de ma famille.

            Parmi toutes ces personnes, je tiens à exprimer mes remerciements à Monsieur Jacky Akoka à qui je dois d’avoir pu présenter ce mémoire après neuf années de cours du soir.

            Je remercie tout particulièrement Monsieur Pierre Audoin pour son aide précieuse et son soutien sans faille tout au long du projet, ainsi que les ingénieurs d’étude qui ont travaillé sur le projet.

            Je remercie également Madame Isabelle Renoncet pour la compréhension dont elle a fait preuve dès mon arrivée dans son service.

            Un travail de si longue haleine suppose le soutien des proches. Je remercie mon épouse Xiao ping pour le soutien qu’elle m’a toujours apporté et sa patience. Merci également à Léona et Roland pour leur encouragement.

 


 

 

 

Introduction. 6

1.     Le projet 8

1.1.      Le merchandising. 11

1.2.      Pourquoi ce projet ?. 15

1.3.      Les contraintes. 19

1.4.      Les étapes importantes du projet 20

2.     Présentation des méthodologies, technologies et concepts utilisés. 24

2.1.      Gestion et management de projet 24

2.2.      Les modèles et les méthodes. 26

2.3.      Management des ressources humaines. 53

2.4.      ETL et EAI : généralités. 64

2.5.      Organiser une application J2EE. 77

2.6.      Ruby on Rails. 94

2.7.      L’architecture Web. 100

2.8.      Les stress tests. 117

3.     Mise en œuvre  de l’application merchandising. 133

3.1.      Présentation de l’application merchandising. 133

3.2.      Gestion du projet merchandising. 143

3.3.      Illustration de la démarche. 153

3.4.      Intégration dans le Système d’Information existant. 190

3.5.      Mise en œuvre de l’architecture J2EE. 207

3.6.      Réalisation des tests de montée en charge. 210

4.     Bilan. 225

4.1.      Bilan ETL. 225

4.2.      Bilan J2EE. 230

4.3.      Bilan Architecture Web J2EE. 236

4.4.      Bilan Test de Charge. 241

4.5.      Bilan Rails. 244

4.6.      Bilan Gestion du projet 245

Conclusion. 247

Glossaire. 286

Bibliographie. 295

Annexes. 298

Annexe A : Exemples de développement ETL GENIO.. 300

Annexe B : Exemple de développement VBIS. 310

Annexe C : Exemple de développement J2EE. 320

Annexe D : Résultats des tests de montée en charge. 350

Annexe E : Publications dans Monop Infos, magazine interne, entre octobre 2005 et avril 2007. . 356

Annexe F : MLD de GDP. 363

Annexe G : Versions des logiciels. 366

Annexe H : Exemples de dossier de préconisations. 367

Annexe I : Illustration correspondant à un plan magasin. 374

Annexe J : Cartographie de l’application merchandising. 375

Annexe K : Liste des tables des bases de données de l’application spécifique. 378

Annexe L : Scoring correspondant au choix du logiciel 385

Annexe M : Cartographie macroscopique du Système d’Information de Monoprix. 389

Annexe N : Présentation des fonctionnalités principales du progiciel de KLEE. 392

Annexe O : Présentation des écrans de l’application spécifique. 417

Annexe P : MPD.. 449

Annexe Q : RAILS - contrôleur RO et CRUD CLASSIQUE. 467

Annexe R : Processus du projet – diagrammes d’activité. 499

 

 

 

 

 

 

 

 

 

 

 


 

 

Introduction

 

Aujourd’hui, de nombreuses entreprises choisissent les meilleurs outils informatiques pour répondre à leurs besoins afin d’être le plus compétitif possible. Elles se dotent ainsi d’ERP ( Entreprise Resource Planning ) ou de suites logicielles spécialisées. En suivant cette démarche, leurs systèmes d’information  gagnent en complexité. Choisir la meilleure solution pour répondre à chacun de ses besoins multiplie le nombre de technologies et de standards utilisés au sein de l’entreprise.

 

Nous allons nous intéresser aux problématiques liées à cette démarche d’entreprise, à travers la mise en œuvre de la suite logicielle SMART Office au sein du groupe de distribution de proximité MONOPRIX. Cette suite permet d’élaborer des dossiers de merchandising fournissant des préconisations de mise en rayon des produits à l’attention des magasins.

 

Dans un premier temps seront présentés le projet,  les grands principes du domaine fonctionnel lié au merchandising, les raisons de l’origine du projet, ses contraintes, ainsi que les étapes importantes du projet, l’étape pour arrêter un choix sur une offre logicielle particulière.

 

Une présentation des méthodologies, technologies et concepts utilisés sera suivie par l’exposé de la mise en œuvre de l’application merchandising. La démarche pour mener à bien le projet sera précisée.

 

Après avoir choisi la suite logicielle qui semble correspondre le mieux à nos besoins, il reste à l’intégrer dans le Système d’Information existant. Il faut alors récolter l’information nécessaire au bon fonctionnement de la suite logicielle, puis fournir les éléments permettant de diffuser les dossiers de préconisations de mise en rayon aux magasins. Après une présentation du Système d’Information existant, nous nous attacherons aux moyens d’intégrer différentes applications d’entreprise, en particulier  à l’aide d’ETL ( Extract Transform and Load) et d’EAI (Entreprise Application Integration), dont le point fort est de faire cohabiter des systèmes hétérogènes.

 

Mais ces produits ne suffisent pas à eux seuls à fournir une solution applicative complète, il faut également se doter d’interfaces, afin de pouvoir administrer l’intégration des informations récoltées, de diffuser les documents de préconisations réalisés et de suivre l’élaboration des dossiers de préconisations. Il est alors nécessaire d’organiser son application [JOU05a] et de choisir des outils de développement. Nous avions une volonté forte d’utiliser des outils permettant de rendre le code plus lisible et ainsi de simplifier la maintenance de ce dernier afin de ne pas se retrouver avec des développements de type « spaghetti ».

 

Se pose ensuite la question de l’architecture à mettre en place, dans laquelle nous allons déployer les développements réalisés. En fonction du nombre d’utilisateurs que nous souhaitons supporter, de la lourdeur des développements, du temps de réponse attendu, du niveau de sécurité désiré et de la tolérance de panne exigée, quelle architecture devons-nous mettre en œuvre ? Nous présenterons alors la solution Open Source basée sur Apache et Tomcat.

 

Enfin, comment pouvons-nous savoir que les développements réalisés et déployés dans l’architecture, ainsi que cette dernière, vont vraiment offrir la qualité de service attendu ? La réalisation de stress tests permettra de répondre à cette question. Nous présenterons alors ce que sont des stress tests, leur utilité, des offres du marché permettant de les réaliser, la démarche utilisée et leurs limites.


 

1.    Le projet

 

Objectif

 

Le projet a pour but de renouveler l’application de merchandising PGC (Produit Grande Consommation). Cette application est utilisée au sein de l’enseigne de distribution de proximité MONOPRIX par une cellule merchandising de 10 personnes.

            Elle permet d’élaborer des dossiers de préconisations de mise en rayon à destination des 250 magasins du groupe.

            En se dotant d’un outil plus perfectionné, l’entreprise souhaite réduire les coûts associés aux processus « métier » liés à l’élaboration des dossiers de préconisations. Elle compte ainsi augmenter la productivité en limitant les interactions humaines et en raccourcissant la durée de ces processus.

 

Les acteurs

           

L’élaboration des dossiers de préconisations implique de nombreux acteurs. Elle est faite par la cellule merchandising en collaboration avec les bureaux d’achat, le marketing, les fournisseurs et la direction des ventes.

            En amont, l’achat élabore les collections. Le marketing fournit une stratégie. Les fournisseurs font des propositions dans leurs spécialités.

            En aval, la cellule merchandising organise la mise en scène des produits et la vente exploite les dossiers de préconisations.

            Enfin, les merchandisers travaillent étroitement avec les fournisseurs qui procurent les visuels et les caractéristiques de leurs produits.

 

Contexte

 

Le schéma ci-dessous positionne l’application de merchandising par rapport aux principaux acteurs, applications et systèmes centraux auxquels elle se rapporte.

 

 

 

Figure 1 : Vision Globale Acteurs, Applications, Systèmes centraux

 

Sujet du mémoire

 

Le sujet de ce mémoire est la « réalisation d’un projet de merchandising ». Le merchandising n’est pas le sujet principal de ce mémoire. Nous allons nous intéresser plutôt aux aspects techniques qu’aux aspects fonctionnels et à la démarche qui a été suivie pour mener à bien ce projet.

 

Les problématiques auxquelles nous allons nous attacher sont :

 

·        La gestion et le management de projet

 

·        La façon d’intégrer une suite logicielle au sein d’un Système d’Information hétérogène existant.

 

·        Le choix de technologies WEB et d’outils de développement. Ainsi que les raisons de ce choix.

 

·        Le choix d’une architecture WEB et la validation de cette architecture.

 

Le projet merchandising va permettre d’illustrer ces quatre problématiques. L’objectif n’est pas d’exposer dans ses moindres détails les problématiques liées à ce projet mais plutôt de se servir de ce cas concret pour apporter des réponses à ces problématiques.

Le but de ce mémoire n’est pas non plus de traiter de ces sujets de façon exhaustive, mais de se concentrer sur les points réellement abordés lors du projet et qui ont permis de le mener à bien et de répondre de façon satisfaisante aux besoins des utilisateurs. Compte tenu des délais et des impératifs du projet, il est difficilement possible de maîtriser pleinement l’ensemble des technologies et des logiciels qui vont être utilisés lors de ce projet.

L’important est de saisir l’essentiel de ce qu’apporte chacun des outils utilisés et de s’en servir le plus simplement possible afin que le projet reste évolutif et facilement maintenable.

 


 

1.1.         Le merchandising

 

Présentation

 

Le merchandising correspond à l’ensemble des techniques visant à optimiser la répartition et la présentation des produits en magasin afin d’optimiser la rentabilité et le trafic et de contribuer à l’expression de l’image de l’enseigne.

 

Cette définition paraît très simple, mais derrière cette simplicité se cache un certain niveau de complexité.

 

En effet, pour arriver à élaborer des dossiers de préconisations de mise en rayons à destination des magasins, le merchandiser a besoin de nombreuses informations relatives :

 

  • aux produits : prix, dimensions, nomenclature, caractéristiques, images des produits

 

  • aux points de ventes : mobilier, capacité des linéaires, assortiments des produits correspondant au point de vente, historiques de vente du produit, colisage de livraison, périodicité de livraison

 

  • à la politique de l’entreprise, l’état du marché national et son évolution

 

  • d’un modèle de vente : écoulement des ventes sur la semaine

 

Le travail du merchandiser consiste, à partir de ces informations et en partenariat avec les bureaux d’achat de l’entreprise et la direction des ventes, à proposer une répartition des produits en magasin afin de répondre pleinement aux ventes et à ne pas avoir de rupture de produit en rayon. Il va faire des préconisations sur le nombre de facings à accorder à un produit dans le linéaire du magasin et sur son emplacement. Ces préconisations se font à partir de données quantitatives dont nous avons fait une liste non exhaustive ci dessus et qui vont être extraites du Système d’Information de l’entreprise mais également de notions qualitatives telles que les couleurs des visuels correspondant aux différents produits. Le merchandiser va par exemple chercher à obtenir le meilleur rendu visuel afin de rendre la répartition des produits la plus agréable possible pour le consommateur. L’aspect visuel est donc une composante importante de l’élaboration des dossiers de préconisations.    

 

Dossiers de préconisations

 

Les dossiers de préconisations à destination des magasins présentent toujours le même type de structure :

  • une page de garde (Figure 2)
  • un argumentaire (Figure 3)
  • une présentation du marché national et de l’enseigne, l’évolution du marché
  • des plans de masse (Figure 4)
  • les planogrammes en couleurs avec les visuels des produits (Figure 5). Il existe plusieurs planogrammes en fonction du linéaire du magasin. Un planogramme correspond à une représentation graphique des mobiliers en magasin sur lesquels on a positionné des produits. Les produits sont facilement identifiables à l’aide de photos les représentant.
  • Liste des produits du planogramme (Figure 6): numéro de produit sur le planogramme, ean du produit, désignation, nombre total de facing, colisage de réassortiment du produit

(correspond à la quantité minimale que l’on peut livrer au magasin).

 

Le magasin, à l’aide de ces dossiers, optimise de manière rapide la rentabilité de son point de vente sans avoir à faire des analyses complexes et fastidieuses. En effet, ces dossiers sont le fruit d’une analyse conjointe du merchandising, des bureaux d’achats et de la direction des ventes qui tient compte de la capacité des linéaires, de la rotation des stocks et des nouveaux assortiments des produits. Ces dossiers facilitent donc le travail des magasins mais permettent également d’avoir une offre homogène sur l’ensemble des points de vente de l’enseigne. Ils facilitent donc la mise en place de la politique de marketing de l’entreprise.

 

Figure 2 : Page de garde

 

Figure 3 : Le marché

 

 

Figure 4 : Plan de masse

 

Figure 5 : Exemple de planogramme

Figure 6 : Liste des produits du planogramme

 

            D’autres exemples de dossiers sont présents dans l’Annexe H.

 


 

1.2.         Pourquoi ce projet ?

 

La solution existante.

 

            L’outil existant utilisé par les marchandisers est une vieille version de l’outil SPACEMAN de la société Nielsen qui se compose d’une application autonome installée sur chacun des postes utilisateurs.

            Les merchandisers alimentent cette application à l’aide de fichiers au format EXCEL ou TXT (texte).

 

            Le processus « métier » d’élaboration utilisé pour élaborer les dossiers de préconisations à l’attention des magasins est le suivant (Figure 7) :

 

(1)   Les informations relatives aux produits et aux ventes sont obtenues à l’aide de BI Query anciennement nommé GQL qui est un requêteur du marché. Les données sont extraites sous la forme de fichier EXCEL.

(2)   Les classements des magasins par chiffre d’affaire par périmètre de produits sont extraits à partir du produit Arthur Décision de Comshare. Cette solution repose sur une base Oracle. Elle permet entre autres  d’avoir une vision multidimensionnelle des ventes selon les axes produits, magasins, temps et manifestations (les campagnes promotionnelles telles que Noël, Halloween sont des manifestations). Ces classements sont utilisés pour constituer des groupes de magasins qui représentent au mieux le parc de points de vente. Il est en effet impossible de faire l’ensemble des dossiers de préconisations pour chacun des magasins. Il faudrait 2 merchandisers par magasin pour mettre à jour ces dossiers une fois par an, ce qui n’est pas envisageable (la cellule merchandising ne comporte que 10 personnes et il y a 250 magasins). Le merchandiser doit  effectuer de nombreuses manipulations sur les classements des magasins et les ventes correspondant aux produits afin de pouvoir utiliser ces informations dans l’application et réaliser les planogrammes.

(3)   Un référentiel des différents périmètres de planogrammes et des linéaires associés est géré à l’aide de fichiers au format EXCEL.

(4)   Le merchandiser a également besoin des visuels correspondant à son périmètre de produit. S’il lui manque des visuels, il doit lui-même prendre les photos manquantes des produits. Les photos sont enregistrées sur chacun des postes des merchandisers et ne concernent que leur périmètre.

(5)   Le merchandiser peut alors se consacrer à l’élaboration des planogrammes et des dossiers en collaboration avec les bureaux d’achat et la direction des ventes.

(6)   Le dossier une fois terminé est envoyé à la reprographie qui va en tirer un exemplaire papier pour chacun des magasins. Un exemplaire de chaque dossier est livré en magasin sans tenir compte du fait que le magasin est concerné par tout ou partie du dossier de préconisations : on envoie tout à tout le monde.

 

 

 

 

 

Figure 7 : L’outil d’élaboration existant

 

 

 

 

Les axes d’optimisation 

 

            Au vu de ce processus « métier », il est possible d’identifier un certain nombre d’axes d’optimisation.

            On peut réduire les coûts liés à ce processus d’élaboration des dossiers de préconisations, en minimisant les interventions manuelles effectuées par les merchandisers. Cela passe par l’automatisation systématique des procédures manuelles qui peuvent l’être.

            La centralisation de l’information relative aux planogrammes dans une base de données, la mise en place d’un référentiel image unique et pas de déploiement sur les postes clients de l’application ou un déploiement minimaliste permettent de simplifier et de minimiser les tâches d’administration.

            Le choix d’une solution logicielle possédant une interface simple et conviviale diminue la durée de montée en compétence des merchandisers.

Si, de plus, cette solution répond à de nouveaux besoins non couverts par la solution actuelle tels que l’élaboration de dossiers de préconisations pour les surgelés qui sont présentés dans des meubles spécifiques, il est alors possible d’élargir les périmètres concernés par les dossiers de préconisations.

Le fait de souscrire un  abonnement images auprès d’une société extérieure pour les périmètres nouvellement traités évite aux merchandisers de prendre eux-même en photo les produits pour lesquels on ne possède pas de visuel.

L’abandon de l’impression papier pour la diffusion des dossiers planogrammes au profit d’une diffusion au format PDF permet de ne plus imprimer et livrer des dossiers aux magasins qui ne sont pas concernés.

 

 

La solution cible

 

Dans la solution cible, rien ne doit être installé sur le poste client. L’utilisateur accède à un serveur distant à partir de son poste de travail. Il s’identifie sur ce serveur et accède à l’application merchandising qui permet d’élaborer les dossiers planogrammes.

Le processus d’élaboration cible est le suivant (Figure 8) :

 

(1,2) Les informations correspondant aux produits et aux ventes sont directement disponibles dans l’outil d’élaboration.  Le classement des magasins est géré de façon transparente, le merchandiser n’a plus à s’en soucier. Il n’a plus à faire de manipulation fastidieuse pour obtenir de l’information utilisable.

 

(3) Les informations anciennement gérées dans des fichiers autonomes seront gérées dans une base de donnée au travers d’une interface WEB.

 

(4) Les visuels correspondant aux produits sont livrés par un prestataire extérieur auprès duquel on souscrit un abonnement. Chaque mois, on lui envoie la liste des produits. En retour, les images manquantes sont envoyées puis intégrées dans la base image.

 

(5) Le merchandiser peut alors se consacrer à l’élaboration des planogrammes et des dossiers de préconisations en collaboration avec les bureaux d’achat et la direction des ventes.

 

(6) Une fois qu’un merchandiser a achevé un dossier de préconisations, un administrateur fonctionnel met à disposition le dossier dans l’application de diffusion au travers d’une interface d’administration WEB. Le magasin peut alors récupérer le dossier à l’aide d’un navigateur WEB et l’imprimer au besoin. Les dossiers ne sont plus envoyés au service de reprographie, ni livrés sous format papier à l’ensemble des magasins.

 

 

 

 

 

Figure 8 : L’outil d’élaboration cible

 

 

Les gains

 

L’automatisation d’un certain nombre de traitements permet d’éliminer de nombreuses interventions humaines et ainsi de réduire la durée du processus.

La gestion centralisée évite d’avoir un éclatement de l’information sur l’ensemble des postes utilisateurs. Cette gestion centralisée facilite les tâches d’administration.

La souscription d’un abonnement image et la mise à jour automatique de la base image libèrent les merchandisers de la gestion des images.

            La mise en place d’une diffusion numérique des dossiers de préconisations permet aux magasins de les avoir plus rapidement. Il n’y a plus de livraison au magasin. Le magasin n’a plus qu’à choisir ce dont il a besoin via l’Intranet. Il peut alors imprimer les dossiers directement en magasin. De plus, il existe des gains financiers puisque cette diffusion entraîne une consommation de papier moins importante et permet de faire des économies en ne sollicitant plus le service de reprographie et le service courrier.

            Ce nouveau processus « métier » va donc permettre de gagner du temps et de supprimer des tâches inutiles. On améliore ainsi la productivité du service merchandising. Le nombre de dossiers de préconisations de mise en rayon pourra être plus important en conservant le même effectif dans la cellule merchandising.

 

 

1.3.         Les contraintes 

 

Les contraintes pour mener à bien ce projet sont nombreuses et de natures diverses. Ces contraintes sont essentiellement techniques, politiques et financières.

 

            Le  Système d’Information est hétérogène. Toutes les informations nécessaires ne sont pas gérées dans ce dernier. De nombreuses informations relatives au merchandising sont dispersées dans des fichiers EXCEL sur chacun des postes des merchandisers. Il n’existe pas de référentiel centralisé contenant ces informations.

            Les dossiers planogrammes nécessitent l’existence d’un référentiel image. Or, ce référentiel devrait se composer d’environ 46 000 images occupant plus de 10 Go d’espace disque. Ce qui exclut le fait de dupliquer ce référentiel sur chacun des postes, la taille de ce référentiel étant trop volumineuse.

La qualité visuelle de ces images est très importante, il est nécessaire que l’applicatif puisse au moins afficher 65 000 couleurs pour obtenir un rendu visuel acceptable.

Outre ces contraintes techniques, la DSI (Direction des Systèmes d’Information) préconise fortement l’utilisation d’un certain nombre de solutions et de standards. Le choix d’ORACLE est préconisé pour les bases de données relationnelles, ainsi que de J2EE pour les développements Web. Ces préconisations ont pour but de limiter l’hétérogénéité du système.

La DSI a également adopté une politique de déploiement minimaliste des différentes applications à mettre en place sur les postes utilisateurs.  C’est pourquoi les solutions Web sont préférées aux applications Clients – Serveur.

Enfin, malgré l’importance du projet, les moyens mis à notre disposition pour mener à bien ce projet sont très limités. Et la pression sur les délais à respecter est très grande. 

 


 

1.4.         Les étapes importantes du projet

 

Choix de la suite logicielle

 

La première étape de ce projet a consisté à choisir la suite logicielle qui répondait au mieux aux besoins identifiés des utilisateurs ou qui pouvait facilement être adaptée aux spécificités propres de leur métier.

Nous tenions à ce que le logiciel présente une interface intuitive, simple, conviviale, ceci pour diminuer la durée d’appropriation de l’application, dans le but de raccourcir la courbe de montée en compétence des merchandisers. Ils seront plus vite opérationnels si on met à leur disposition un outil simple, plutôt qu’un outil complexe et peu ergonomique.

Nous avons donc comparé les offres des principaux acteurs du marché : Prospace de JDA, SMART Office de KLEE Commerce, Apollo d’IRI et Spaceman de Nielsen. Les offres ne reposant pas sur des bases de données relationnelles et ne permettant pas de gérer un référentiel centralisé ont immédiatement été écartées.

Les deux offres qui sont alors restées en liste étaient Prospace de JDA et SMART Office de KLEE commerce. Elles ont été analysées de manière plus approfondie. Nous avons identifié l’ensemble des points fonctionnels et techniques auxquels devait répondre la suite logicielle. Des pondérations ont été attribuées à chacun de ces points en fonction de leur niveau d’importance. L’attribution de notes nous a alors permis d’effectuer un scoring des deux solutions et de choisir, en fonction des résultats, la suite qui correspondait le mieux à nos attentes. Le scoring utilisé est fourni dans l’Annexe L.

            Notre choix s’est porté sur l’offre SMART Office de KLEE Commerce. C’est cette suite qui semblait répondre le mieux aux contraintes que nous avions et qui permettait d’améliorer au mieux le processus d’élaboration des planogrammes, selon les axes d’optimisation identifiés préalablement.

            Cependant, cette suite ne permettait pas d’éviter les interventions sur les postes clients. En effet, on doit installer un applicatif client sur chacun des postes des utilisateurs. Ce problème a été contourné par l’utilisation de la technologie TSE de Microsoft. Cette technologie permet d’accéder à partir de n’importe quel poste Windows 2000, 2003 ou XP à des bureaux distants gérés par un serveur distant. Nous avons donc pu être en conformité avec les attentes de la DSI qui ne souhaitait pas d’intervention sur les postes clients.

            D’autres critères plus subjectifs ont également joué un rôle dans le choix du produit, tels que la disponibilité et la réactivité de l’éditeur, et aussi le fait que l’éditeur puisse fournir des prestations complémentaires comme un abonnement image. L’éditeur livre chaque mois les visuels des produits sous forme numérique correspondant à un certain périmètre.

            L’offre de KLEE repose sur un référentiel composé d’une base image, d’une base relationnelle de type ORACLE et d’un ensemble de modules. Les modules vont permettre d’administrer la base image, d’élaborer les dossiers planogrammes, de gérer la base de données et d’extraire de l’information de façon automatique.

 

 

 

 

 

 

 

 

Figure 9 : Architecture de la suite logicielle SMART Office    

 

 

 

 

 

Intégration de cette suite dans le système

 

La seconde étape consiste à intégrer cette suite logicielle dans le Système d’Information existant. Il est possible d’alimenter les bases de données à l’aide de fichiers « texte » en paramétrant des fichiers XML, ce qui permet d’être assez souple au niveau de l’alimentation des données. Il ne reste donc plus qu’à collecter l’information nécessaire à l’élaboration des planogrammes.

Nous avons donc identifié les traitements à mettre en place pour alimenter le référentiel et précisé la fréquence à laquelle ils devaient être exécutés.

Les grands groupes de traitements sont les suivants :

·        alimentation des informations relatives aux produits

·        récupération des classements des magasins en terme de ventes par ensemble de produits

·        récupération des ventes par produit correspondant à chacun des magasins

·        envoi de la liste des produits présents dans le référentiel à l’éditeur afin de recevoir les visuels des produits correspondant à l’abonnement image souscrit.

 

Hormis l’alimentation des informations relatives aux produits qui est exécutée chaque jour de la semaine, les autres traitements sont mensuels.

 

            Etant donné que l’information présente dans le Système d’Information n’est pas directement exploitable, nous avons, avant de créer les fichiers qui serviront à alimenter le référentiel de l’offre de KLEE Commerce, mis en place un Datamart.

 

 

 

 

 

 

 

Figure 10 : Mise en place d’un Datamart

 

 

 

 

 

 C’est une base de données qui contient toutes les informations relatives au merchandising et à l’historique des ventes sur une période d’un an permettant l’élaboration des planogrammes. Ce Datamart était initialement prévu pour fournir le bon niveau d’agrégation de l’information nécessaire à la suite SMART Office. Mais, la prise en compte d’évolutions fonctionnelles telles que la gestion de regroupements particuliers de produits en univers ont eu pour conséquence d’élargir son utilisation à la gestion de notions propres au merchandising qui n’étaient pas gérées dans le Système d’Information existant.

            La gestion des univers, qui sont des regroupements de produits propres au merchandising, permet de gérer des périmètres de produits correspondant exactement aux dossiers planogrammes envoyés aux magasins. Ce qui n’était pas le cas jusqu’alors, les périmètres des dossiers correspondaient à des regroupements de sous-ensembles de nomenclature produit utilisés dans l’entreprise. Ces regroupements étaient difficilement gérables par les merchandisers.

            On veut également gérer, dans cette base, la liste des dossiers planogrammes et leurs caractéristiques telles que leurs fréquences de mise à jour ou la personne en charge du planogramme. Jusqu’à présent, cette gestion était faite à l’aide de fichiers EXCEL.

            Le fait de vouloir diffuser les planogrammes sous forme de fichiers PDF via l’intranet oblige également à gérer un ensemble de notions : une arborescence de diffusion, une identification des magasins pour pouvoir ensuite filtrer la liste des dossiers proposés en fonction de leurs caractéristiques.

            La gestion de ces notions ne pouvait pas se faire dans l’offre SMART Office de KLEE Commerce car elles revêtent un caractère « métier » qui n’a pas lieu d’être géré dans un tel outil. Il est important que cet outil reste indépendant des données propres de l’entreprise.

 

Mise en œuvre d’interfaces Web

 

            Le fait de gérer ces notions au niveau du Datamart oblige à se doter d’interfaces qui vont permettre de les administrer et de suivre la bonne exécution des différents traitements.

            Pour cela, il est nécessaire de choisir des normes et des outils de développement, de mettre en place une architecture et de valider cette architecture à l’aide d’un outil de stress test que nous aurons préalablement sélectionné. Cette validation servira à s’assurer que l’application offre la qualité de service attendu pour éviter de se retrouver avec un système indisponible le jour de sa mise en production parce qu’il n’aura pas tenu la charge générée par les utilisateurs. 

              

 

 

 

 

 

 

 

 


2.    Présentation des méthodologies, technologies et concepts utilisés

 

2.1.         Gestion et management de projet

 

La gestion de projet informatique est fondée sur des travaux de modélisation et de collaboration. Un client demande à un fournisseur, qu’il soit interne ou externe à l’entreprise, de mettre en place une solution à sa problématique au travers d’un modèle. Les deux parties prenantes doivent alors collaborer en bonne intelligence afin d’atteindre un objectif commun.

 

L’Informatique est une discipline jeune en comparaison des domaines millénaires du bâtiment et des systèmes de collaborations militaires. La réalisation d’un projet informatique traditionnel suppose en général la maîtrise des techniques de planification, des connaissances en ISO 9001 et d’UML. Il existe de nombreuses normes et méthodes utilisables dans la réalisation d’un projet informatique. On constate cependant que ces normes et ces méthodes convergent aujourd’hui vers certaines méthodes et techniques telles que  les Design patterns, UML ou Java. Par le respect de règles et méthodes, on cherche à produire des solutions de qualité documentées afin de répondre aux problématiques rencontrées par les entreprises. La documentation est perçue comme un facteur permettant de contribuer à l’obtention d’une solution de qualité mais elle représente parfois un coût important.

 

La qualité de la collaboration et le maintien du dialogue entre le client et les fournisseurs d’un projet sont des conditions indispensables au bon déroulement du projet. La bonne réussite d’un projet informatique repose sur cette collaboration. Si le client est satisfait, il sera confiant et, en général, permettra au fournisseur d’être plus libre dans sa gestion de projet. Pour remplir pleinement son rôle le fournisseur doit se mettre à la place de son client. Il pourra ainsi effectuer une analyse pertinente de la problématique à laquelle il est confronté et répondre pleinement aux contraintes fonctionnelles et techniques. Le fournisseur doit avant tout préciser avec le client le contexte du projet et en définir le contenu. Il est nécessaire de bien définir l’alignement stratégique du projet et de dégager les différents processus « métier »  cibles, ainsi que les règles « métier » associées.

 

Suite à cette phase de pré étude, les dirigeants d’une entreprise décident ou non de lancer le projet.

           

            Dans le cas d’une décision favorable, il faut conduire le projet. Il est alors nécessaire de mettre en place une organisation et une méthodologie de gestion de projet. Les grandes lignes de cette méthodologie consistent à analyser les besoins, évaluer les charges, définir et suivre les différents incréments à mettre en place, identifier et gérer les risques, définir l’architecture technique et applicative, gérer au mieux la réutilisation, et maîtriser les ressources humaines ainsi que les ressources logicielles. 

 

Il existe plusieurs types de projet : les projets de développement, les projets d’intégration et les projets de déploiement. Certains projets peuvent appartenir à plusieurs de ces types.

 

C’est entre autres le cas du projet merchandising. Dans ce projet, il a été nécessaire de mettre en place une solution spécifique au travers de développement, d’intégrer un progiciel dans le Système d’Information de l’entreprise et de déployer ces solutions au sein de l’entreprise.

 

Il est crucial que le projet ait un objectif clairement défini, limité et unique. En général, un projet est caractérisé par un niveau de complexité important. On peut caractériser cette complexité en identifiant les charges globales, les savoir-faire requis et les risques encourus.

 

Les limites du projet doivent être définies de manière précise en terme de délais, de moyens financiers, de ressources et de personnels.

 

La gestion d’un projet Informatique commence par la précision du contexte, des acteurs, de leurs interactions et l’identification des processus « métier ». On s’intéresse tout d’abord  à définir la démarche projet.  Le projet suit un cycle de vie. Des modèles et méthodes sont utilisés pour décrire son contenu.

 

Le cycle de vie comporte plusieurs étapes :

 

·        Pré étude

·        Evaluation des besoins et des charges

Décomposition en tâches et détermination de lots.

 

·        Budgétisation

Associer des coûts aux tâches. Déterminer des rubriques budgétaires globales et des réserves.

·        Rédaction de l’offre et du contrat

·        Kick Off

Démarrage officiel du projet pour canaliser l’énergie des différents acteurs.

·        Planification

Détermination d’un échéancier et du calendrier.

·        Conception

·        Implémentation et tests

·        Recette

·        Mise en production

·        Achèvement

·        Maintenance

 

On peut différencier les cycles de vie correspondant à des développements spécifiques ou à des développements de progiciel.

 

Ces deux types de développements se différencient essentiellement sur la phase de développement. Les phases de définition, d’exploitation, d’utilisation, de maintenance et d’évolution sont gérées de manière identique. Dans le premier cas, il s’agit de mener une étude préalable, suivie d’une étude détaillée, d’une étude technique de mise en œuvre et de la mise en œuvre à proprement parler. Dans le second cas, il s’agit de choisir un progiciel, d’effectuer le paramétrage afin de répondre au besoin, de tester les adaptations effectuées.   

 

D’autre part, dans le cas du développement d’un logiciel spécifique au sein d’une entreprise, la phase de « rédaction de l’offre et du contrat » est moins formelle.

 

 

2.2.         Les modèles et les méthodes

 

Il existe plusieurs modèles de déroulements type de projet . Le déroulement d’un projet dépend de sa nature et de son contexte. Il n’y a pas de méthode universelle qui puisse être appliquée à tous les projets. On peut différencier deux types de méthodes de gestion de projets. Les méthodes traditionnelles suivent des cycles séquentiels et sont basées sur des contrats. Les méthodes plus modernes positionnent l’utilisateur comme un acteur clef du projet et préfèrent satisfaire ce dernier plutôt qu’honorer les clauses d’un contrat.

 

Ci-dessous, un diagramme illustrant le déroulement type d’un projet traditionnel [MAN06].

Figure 11 : Déroulement type d’un projet traditionnel


 

Cycles de projet

 

Lors de la réalisation d’un logiciel, plusieurs types de cycles de développement sont possibles. Les grandes familles sont les cycles en cascade, les cycles en V et les cycles itératifs.

Cascade

 

Figure 12 : Cycle de vie en cascade

Ce cycle de vie en cascade (Figure 12) est hérité du bâtiment. Les phases traditionnelles de développement sont effectuées les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle. Chacune des phases produit des livrables définis au préalable et se termine à une date précise. Une étape de validation et de vérification des livrables permet de terminer une phase.


 

V

 

Figure 13 : Cycle de vie en V

Depuis les années 1980, le cycle en V (Figure 13) est devenu un standard de l'industrie du développement de logiciel et de la gestion de projet.

Ce cycle limite les retours aux étapes précédentes afin de pallier le problème de réactivité du modèle en cascade. Les phases de la partie montante, renvoient de l'information sur les phases en vis-à-vis. Les livrables des étapes montantes sont préparés dans les étapes descendantes. Par exemple, les livrables des tests de validation sont définis lors des spécifications.


 

Itératif

 

Figure 14 : Cycle de vie itératif

Le produit issu d'une activité est appelé un artéfact. On distingue les activités des artéfacts. Un cycle de type roue de Deming est appliqué sur la production des livrables : documentation, code, test.

Dans le cas d’une gestion de projet, on étudie la faisabilité d’un nouveau besoin. On élabore une solution. Une phase de fabrication permet ensuite de construire cette solution. La livraison au client correspond à la transition.

Dans un cycle itératif (Figure 14 ci dessus), les phases de faisabilité, d’élaboration, de fabrication et de transition correspondent respectivement aux phases de spécifications, de détermination de l’architecture, de développement et de tests. L'objectif est d’effectuer au plus tôt les livraisons au client afin qu’il puisse effectuer une recette.

Une itération est plus courte et régulière qu'une roue de Deming (PDCA) qui,  appliquée à une organisation importante, peut prendre plusieurs années.

Comparaison

Le cycle en V a pour origine l'industrie lourde. Les phases de validation sont importantes car les phases successives du projet sont de plus en plus lourdes. Dans le cas de gros projets réunissant un nombre important de personnes, les décisions de la direction ou des architectes ont tellement d’impact en terme de charge et de durée qu'il est important de s'assurer de la validité de chacune des étapes.

Dans le cas d'un projet logiciel impliquant peu de personnes sur des durées courtes de l’ordre d’une à deux années, on dispose d'une plus grande réactivité du fait de la proximité géographique et d’une communication facilitée compte tenu de la taille de l’équipe. De plus, les coûts sont plus limités entre chaque étape. Dans ce contexte, il est possible d’utiliser des méthodes de développement dites agiles en diminuant le formalisme et en multipliant le nombre de cycles.

 

Tests et validation des logiciels

 

Les tests sont une activité centrale. Ils permettent d’améliorer la qualité des logiciels. Le maître d’œuvre d’un projet peut mettre une stratégie de test en place qui se compose de tests unitaires, tests d’intégration, de vérification et de validation.

 

La validation met en évidence les défauts d’un logiciel et sa conformité par rapport à ses spécifications. Cette étape permet de gérer les anomalies, d’évaluer la conformité fonctionnelle et la fiabilité du logiciel.

 

Il existe deux grandes familles de tests. Les tests fonctionnels qui permettent d’évaluer l’ergonomique, la robustesse, la réponse au stress ou le niveau de performance d’un logiciel et les tests structurels qui permettent des analyses de la couverture du code, des analyses statistiques ou des analyses de complexités. Ces différents tests peuvent être automatisés. Des outils permettent l’automatisation de tests, la capture et le rejeu (Opensta, Selenium), ou encore l’analyse de couverture (RCOV pour ruby).

 

D’autre part, des techniques de vérification telles que les revues peuvent être effectuées par le client. A l’aide de ces revues, les dérapages sont limités, voire évités. Les coûts sont réduits par la correction des problèmes des résultats intermédiaires. Le résultat obtenu correspond d’avantage au résultat attendu. De plus, ces revues permettent de partager les responsabilités du projet entre le client et le fournisseur.  

 

            La réalisation de test permet de détecter les erreurs. Mais cette détection doit être réalisée au plus tôt. Plus une erreur est détectée tôt moins elle est coûteuse à corriger. Le coût de la correction d’une erreur au niveau de l’analyse est beaucoup moins important que le coût de la correction d’une erreur au niveau de la conception. Si la correction de cette erreur s’effectue dans les phases d’implémentation ou d’exploitation, les coûts de correction peuvent être 1000 fois plus importants.

 

 

 

Méthode Agile : panorama des principales méthodes 

 

Une méthode agile est une méthode de développement informatique [BEN05]. Le client est impliqué un maximum dans le projet. La réactivité aux demandes est donc très bonne. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. On cherche à satisfaire un client plutôt que les clauses d’un contrat.

            La méthode recherche la production d’un code de qualité. Les développements sont guidés par les tests.

 

            L’objectif de ces méthodes est de permettre de mieux maîtriser les délais, les coûts et la production des projets informatiques.

 

Les développements sont effectués de façon itérative et incrémentale.

 

La méthode RAD est à l’origine des méthodes agiles. Les méthodes agiles sont le résultat de la recherche d’approches plus adaptées aux nouvelles technologies dans lesquels des cycles courts sont favorisés.

 

Les méthodes agiles prônent 4 valeurs fondamentales qui sont présentées dans le manifeste agile:

·        L'équipe : « Personnes et interaction plutôt que processus et outils »

·        L'application : «  Logiciel fonctionnel plutôt que documentation complète » 

·        La collaboration : « Collaboration avec le client plutôt que négociation de contrat » 

·        L'acceptation du changement : « Réagir au changement plutôt que suivre un plan » 

Les  4 valeurs se déclinent en 12 principes :

·        « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles ».

·        « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ».

·        « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ».

·        « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ».

·        « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail ».

·        « La méthode la plus efficace de transmettre l'information est une conversation en face à face ».

·        « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ».

·        « Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ».

·        « Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité ».

·        « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle ».

·        « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto organisent ».

·        « À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accordé et ajuste son comportement dans ce sens ».

Un panorama des principales méthodes : RAD, Crystal Clear, Scrum, DSDM, XP, UP, RUP est présenté ci-dessous.

 

RAD

RAD est l’acronyme de Rapid Application Development. C’est une méthode de développement de logiciels dont le cycle de développement est très court. Elle a été développée par James Martin dans les années 1980.

La réalisation et les tests de l’application sont effectués par morceau à intervalles réguliers. Dans cette méthode, des environnements graphiques sont utilisés afin d'obtenir rapidement des prototypes.

 

Crystal clear

Crystal clear est une méthode de gestion de projet crée par Alistair Cockburn. Cette méthode est adaptable aux spécificités des projets. Elle repose sur un certain nombre de  principes auquel doit adhérer l'ensemble de l'équipe :

  • La communication a une place importante dans le projet afin de faire collaborer les différents acteurs du projet de manière efficace.
  • Le nombre des membres d'une équipe est limité à six personnes pour améliorer la solidarité.
  • l'équipe travaille dans une même pièce pour que la proximité facilite la communication.
  • Les schémas de modélisation sont effectués en groupe sur tableau blanc pour une meilleure communication et une meilleure collaboration.
  • La collaboration avec le client est très importante. Les discussions entre les utilisateurs et les développeurs sont nombreuses.
  • Des parties exécutables de l'application sont livrées fréquemment. Le client peut ainsi se rendre compte de l’avancement du projet et faire des retours sur les livraisons.

La méthode Crystal clear reste très souple au niveau des procédures à suivre et des normes à utiliser. La procédure est découpée en différentes étapes :

  • Les utilisateurs sont observés dans leur travail afin de mieux comprendre leurs besoins et leur contexte. Les fonctionnalités sont classées par ordre de priorité en collaboration avec les utilisateurs. Les fonctionnalités avec la plus haute priorité sont développées en premier.
  • Au début du projet, une ébauche de conception et une ébauche d’architecture sont réalisées.
  • On planifie les dates des itérations. Des livrables fonctionnelles sont définies à la fin de chacune d’elles.
  • La réalisation proprement dite de l'application se fait durant les itérations.

La méthode Crystal clear présente tous les avantages des méthodes agiles : flexibilité par rapport au changement, rapidité, livraisons fréquentes. Elle convient aux petites structures.  Elle est très efficace dans les projets de petite taille mais n’est pas adéquate pour des projets importants.

Scrum

Scrum est une méthode agile pour la gestion de projets. Elle a été conçue pour améliorer la productivité en évitant de paralyser les équipes par l’emploi de méthodologies trop lourdes.

Ken Schwaber et Jeff Sutherland ont mis au point les grands principes de Scrum au début des années 1990.

Le terme Scrum est emprunté au rugby et signifie mêlée. L’utilisation de ce terme est une analogie au rugby du fait que le processus s'articule autour d'une équipe soudée, qui cherche à atteindre un but.

Dans cette méthode, on focalise l'équipe de façon itérative sur un ensemble de fonctionnalités. L’équipe doit réaliser ces fonctionnalités durant des itérations de l’ordre de 30 jours appelées Sprints.

Un but à atteindre est défini dans chaque Sprint. On détermine un ensemble de fonctionnalités à implémenter. Le sprint aboutit à la livraison d'un produit proposant les nouvelles fonctionnalités.

Un ScrumMaster a pour rôle de réduire les perturbations extérieures et de résoudre les problématiques non techniques de l'équipe.

Le client participe de façon active. Il priorise la réalisation des fonctionnalités du logiciel.  Il a la possibilité de changer la liste des fonctionnalités désirées à condition qu’elles ne soient pas en cours de réalisation.

Dynamic Systems Development Method

Dynamic Systems Development Method (DSDM) est une méthode de gestion de projet de la catégorie des méthodes agiles. Cette méthode a été développée en Grande-Bretagne à partir de 1994

La méthode DSDM s'appuie sur 9 principes de base :

·        Implication des utilisateurs durant tout le cycle de développement. Ils font partie de l'équipe projet.

·        Autonomie. L'évolution des besoins peut être influencée par l’équipe projet.

·        Visibilité du résultat. Un feed-back rapide est possible par des livraisons fréquentes.

·        Adéquation. On cherche à livrer une application en adéquation avec le besoin « métier » du client.

·        Développement itératif et incrémental. L'évolution du développement est basée sur le feed-back des utilisateurs.

·        Réversibilité. Toute modification effectuée durant le développement doit être réversible.

·        Synthèse. Un schéma directeur définit le périmètre et les grandes lignes du projet.

·        Tests. Les tests sont effectués en continu, en parallèle du développement.

·        Coopération. Il est nécessaire d’être souple par rapport aux modifications des fonctionnalités demandées.

 

Extreme programming

L'Extreme Programming (XP) est une méthode agile de gestion de projet informatique [BEN05]. Elle est adaptée aux équipes de petite taille qui sont confrontées à des besoins changeants. Des principes simples sont poussés à l'extrême.

L'Extreme Programming a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries pendant un projet "C3" de calcul des rémunérations chez Chrysler entre 1996 et 1999.

Le but principal est de réduire les coûts liés au changement. Dans les méthodes traditionnelles, les besoins sont définis et fixés, au départ du projet. Les coûts ultérieurs de modifications s’en trouvent accrus. Cette méthode fait en sorte de rendre le projet plus flexible et ouvert au changement. Elle introduit des valeurs de base et des principes. Elle repose sur un certain nombre de pratiques.

Elle utilise des principes qui ne sont pas nouveaux mais elle les pousse à l'extrême :

·       la revue de code est permanente et effectuée par binôme

·       les tests sont systématiques et effectués avant chaque implémentation 

·       la conception se fait tout au long du projet (refactoring) 

·       on choisit toujours la solution la plus simple

·       l’emploi de métaphores permet d’améliorer la compréhension

·       l'intégration des modifications s’effectue plusieurs fois par jour 

·       pour s’adapter au changement, les cycles de développement sont très rapides.

Les cycles de développement rapides impliquent des itérations très courtes qui peuvent durer moins d’une semaine. Une itération se compose d’un ensemble d’étapes qui permettent de :

·        déterminer les scénarios clients de l’itération 

·        transformer les scénarios en tâches à réaliser et de déterminer les tests fonctionnels correspondants

·        réaliser les tâches en binôme

·        valider et livrer les fonctionnalités développées au client

Tant que le client fournit des scénarios, le cycle se répète. La première livraison est en générale la plus longue à réaliser mais peut aboutir après quelques itérations. Après avoir mis en production, les itérations peuvent être encore plus fréquentes.

 

UP

Processus Unifié (PU) ou en anglais Unified Process (UP) est une méthode de prise en charge du cycle de vie des logiciels orientés objets. Elle est générique, itérative et incrémentale, contrairement à Merise ou SADT qui sont des méthodes séquentielles.

RUP, proposé par la société Rational, est l’une des plus célèbres implémentations de la méthode PU. C’est une solution livrée clés en main qui permet d’avoir un cadre de développement logiciel. Cette méthode est guidée par les besoins des utilisateurs et centrée sur l’architecture logicielle.

Les processus unifiés utilisent UML. UML est un langage de modélisation. Mais UML ne prend pas en charge le cycle de vie du logiciel, le processus de création et de conception des modèles. La prise en compte de la diversité des projets, des problématiques, des équipes et des cultures d’entreprise dans une seule et unique méthode n’étant pas aisée, PU tente de couvrir cette lacune. PU est générique et possède de nombreux avatars afin de répondre à la diversité des situations :

·        RUP : Rational Unified Process, processus défini par la société Rational Software (IBM)

·        EUP : Enterprise Unified Process, processus intégrant les phases de post-implantation et décrivant le cycle de vie du logiciel

·        XUP : Extreme Unified Process, processus intégrant UP avec l’extreme programming.

·        AUP : Agile Unified Process, processus mettant l’accent sur l’agilité des développements. Il s’appuye plus  sur l’optimisation et l’efficience sur le terrain que sur la modélisation

·        2TUP : Two Tracks Unified Process, processus proposé par Valtech prenant en compte les aléas  et contraintes liés aux changements perpétuels et rapides des SI des entreprises.

·        EssUP : Essential Unified Process, par Ivar Jacobson, à l’initiative d'UML et RUP. Ce processus unifié intègre certains concepts des méthodes Agile.

 

 

RUP

 

RUP repose sur 6 principes :

 

·        développement itératif

·        traitement et formalisation des exigences

·        architecture à base de composant

·        modélisation visuelle

·        vérification de la qualité du logiciel

·        gestion du changement

 

RUP est caractérisé par un découpage temporel en phases et itérations, l’utilisation d’un support entièrement informatique et un aspect générique et paramétrable.


 

UML

 

UML signifie Langage de Modélisation Unifié (Unified Modeling Language) [ROQ00] [ROQ07]. C’est un langage graphique de modélisation. Il représente une formalisation très aboutie et non propriétaire de la modélisation objet utilisée en génie logiciel. UML n'est pas une méthode.

UML est issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson. Il est né de la fusion des langages de modélisation objet Booch, OMT, OOSE. UML est un standard défini par l'OMG (Object Management Group).

Le modèle UML 2 est composé de 13 types de diagrammes alors que UML 1.3 n’en comportait que 9.

UML se décompose en plusieurs sous-ensembles : les vues, les diagrammes et les modèles d’éléments.

Les vues décrivent le système d'un point de vue donné (organisationnel, dynamique, temporel, architectural, géographique, logique …). Les vues sont des notions abstraites. La combinaison de ces vues définit le système complet.

Les diagrammes décrivent le contenu des vues à l’aide d’éléments graphiques. Les diagrammes peuvent faire partie de plusieurs vues.

Les modèles d'éléments tels que les cas d'utilisation, les classes ou les associations permettent d’élaborer les diagrammes UML.

Une façon de mettre en oeuvre UML est de considérer différentes vues superposables pour collaborer à la définition du système : vue d’implémentation, vue logique, vue des cas d’utilisation, vue de déploiement et vue des processus (Voir Figure 15).

Figure 15 : Les différentes vues dans UML

·        Vue des cas d'utilisation :

Elle représente le point de vue des acteurs du système et correspond aux besoins.

·        Vue logique :

On définit le système de l’intérieur. Elle explique la manière de satisfaire les besoins utilisateurs.

·        Vue d'implémentation :

Elle permet de définir les dépendances entre les modules.

·        Vue des processus :

Elle met en œuvre les notions de tâches concurrentes, stimuli, contrôles et synchronisations. Elle couvre des aspects temporels et techniques.

·        Vue de déploiement :

Elle décrit la position géographique et l'architecture physique de chacun des éléments du système.

            Ces différents points de vues permettent de répondre aux questions suivantes : Quoi ? Qui ? Comment ? Où ? Seul le pourquoi n’est pas défini à l’aide d’UML.

Les 13 diagrammes UML sont dépendants hiérarchiquement et se complètent (voir Figure 16 et Tableau 1). Ci-dessous est présentée la hiérarchie des diagrammes UML 2.0 sous forme d'un diagramme de classes.

 

 

Figure 16 : La hiérarchie des diagrammes UML 2.0

 


 

Tableau 1 : Diagrammes UML 2.0

Nom du diagramme

Description

Diagrammes Structurels ou Diagrammes statiques (Structure Diagram)

Diagramme de classes

Class diagram

Il représente les classes intervenant dans le système.

Diagramme d'objets

Object diagram

Il sert à représenter les objets utilisés dans le système.

Diagramme de composants

Component diagram

Il décrit le point de vue physique des composants du système. Il présente, en particulier, leur mise en œuvre (fichiers, bibliothèques, bases de données...)

Diagramme de déploiement

Deployment diagram

Il représente les éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage...), la répartition des composants du système sur ces éléments matériels et la façon dont ils interagissent.

Diagramme des paquetages

Package Diagram

Il permet de représenter les dépendances entre regroupement d’éléments, ainsi qu’entre packages.

Diagramme de structure composite

Composite Structure Diagram

Les relations entre composants d'une classe sont décrites sous forme de boîtes blanches.

Diagrammes Comportementaux ou Diagrammes dynamiques (Behavior Diagram)

Diagramme des cas d'utilisation

Use case diagram

Il identifie les possibilités d'interaction entre le système et les acteurs.  Les fonctionnalités que doit fournir le système sont alors précisées.

Diagramme états transitions

State Machine Diagram

Le comportement du système ou de ses composants est décrit sous forme de machine à états finis.

Diagramme d'activité

Activity Diagram

Le comportement du système ou de ses composants est décrit sous forme de flux ou d'enchaînements d'activités.

Diagramme d'interactions (Interaction Diagram)

Diagramme de séquence

Sequence Diagram

Le déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs est représenté de manière séquentielle.

Diagramme de communication

Communication Diagram

C’est un diagramme de séquence simplifié qui se concentre sur les échanges de messages entre les objets.

Diagramme global d'interaction

Interaction Overview Diagram

Ce diagramme décrit les enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes de séquences. Un diagramme de séquence est une variante du diagramme d’activité.

Diagramme de temps

Timing Diagram

Il décrit les variations d'une donnée au cours du temps.

 


 

            Ci-dessous un tableau récapitulant les différents diagrammes utilisés en fonction des vues.

 

Tableau 2 : Diagrammes en fonction des vues

Vues

diagrammes

Vue logique

Diagramme de classes et d’objets

Vue d’implémentation

Diagramme de composants

Vue cas d’utilisation

Diagramme de cas d’utilisation

Vue processus

Diagramme d’activité, séquence, collaboration

Vue déploiement

Diagramme de déploiement

 

Le langage UML 2.0 a été lancé en 2003 [BOR04]. Il présente une avancée très intéressante du support de communication.  On peut utiliser UML 2 comme on utilisait UML 1.3.

UML 2 est très influencé par les processus MDA (Model Driven Architecture) et MDD (Model Driven Development). L'un des objectifs d’UML 2 est de parvenir à une automatisation du développement afin de passer directement du modèle au code source et donc de fournir un programme compilé, prêt à être lancé. C’est pourquoi les sémantiques des modèles UML ont été précisées afin d'éviter des problèmes d'interprétation. Selon le niveau d'abstraction, sans pour autant devoir programmer, les modèles se rapprochent des programmes eux-mêmes. Un autre objectif serait de générer également de façon automatique les tests cases qui accompagnent le programme.

Le niveau d'abstraction du langage est donc plus élevé que dans la version précédente. UML 2 bénéficie d’un langage enrichi qui a été modularisé en différents sous langages qui peuvent être combinés.

La nouvelle version d’UML ajoute 4 autres diagrammes : le diagramme des paquetages (package diagram), le diagramme de structure composite (composite structure diagram), le diagramme global d'interaction (interaction overview) et le diagramme de temps (timing diagram).

D’autre part, le diagramme de collaboration d'UML 1.4 est devenu diagramme de communication dans UML 2.0 et la plupart des diagrammes ont été revus pour répondre aux nouveaux besoins d’abstraction et d’automatisation...

Processus 2TUP 

 

2TUP signifie 2 Track Unified Process [ROQ00]  [ROQ07]. C’est un processus de développement logiciel qui implémente le Processus Unifié.

Le 2TUP repose sur un cycle de développement en Y (Figure 17) permettant de dissocier les aspects techniques des aspects fonctionnels. Il commence par une étude préliminaire. Cette étude préliminaire permet d’identifier les acteurs qui vont interagir avec le système à construire, d’identifier les messages qu'échangent les acteurs et le système, de produire le cahier des charges et de modéliser le contexte. Ensuite, le processus s'articule autour de 3 phases essentielles : une phase technique (branche de droite), une phase fonctionnelle (branche de gauche) et une phase de réalisation.

 

           

Figure 17 : Schéma en Y

 

 

            Le processus 2TUP repose sur une démarche itérative et incrémentale pour diminuer les risques et organiser la production des livrables. Il sépare les préoccupations fonctionnelles et techniques.

 

Le processus 2TUP permet le développement de progiciels objet. C’est pour cette raison que l’analyse est très centrée sur la détermination de classes et que la modélisation objet est très présente dans chacune des étapes du processus (Tableau 3).

 

Tableau 3 : Description des différentes étapes du processus

Phase

Description

Etude préliminaire

Capture initiale des besoins

Effectuer un recueil initial des besoins fonctionnels et techniques

Préciser le contexte, les acteurs, les interactions

Capture des besoins fonctionnels

Compléter le recueil des besoins

Rechercher les classes candidates

Produire un modèle des besoins

Qualifier les risques de non réponse aux besoins

Capture des besoins techniques

Déterminer les contraintes et les choix dimensionnant le système

Prendre en compte des contraintes d’intégration

Prendre en compte des contraintes techniques et logicielles

Déterminer la configuration matérielle

Sélectionner les outils et les matériels

Définir le style d’architecture en tiers

Etablir la spécification logicielle (gestion des erreurs, sécurité, distribution, intégrité, utilisation de l’aide)

Définir les couches logicielles (modèle en 5 couches et couche de synchronisation avec le SI)

Analyse

Etudier les spécifications fonctionnelles

Veiller à ce que le résultat de l’analyse ne dépende d’aucune technologie

Définir le modèle structurel d’analyse :

Découper les classes en catégories (cohérence, indépendance)

Définir le modèle statique d’analyse :

Détailler, compléter, optimiser les diagrammes de classes

Définir le modèle dynamique :

Déterminer la collaboration entre objets (diagramme interaction et diagramme d’état)

Itérer sur les deux derniers modèles

Conception générique

Définir des composants nécessaires à l’architecture technique

Uniformiser et réutiliser les mêmes mécanismes pour tout le système

Construire le squelette

Ecarter les risques

Déterminer les Frameworks  et les Design patterns

Organiser l’architecture technique et les composants

Veiller à répondre à des objectifs de réutilisation, de fabrication et de déploiement

Déterminer les couches, le modèle logique et le modèle d’exploitation

Valider avec un prototype

Conception préliminaire

Intégration de l’analyse et de la conception générique

Cartographie des composants

Déploiement du poste et des composants d’exploitation (composants distribués, applications, base de données)

Interface EAI, intégration de progiciels

IHM : vision précise des couches présentation et application

Compléter la configuration logicielle

Déterminer les modules

Conception détaillée

Etudier comment réaliser chaque composant

Concevoir et documenter le code qui va être produit

Processus de construction itératif qui s’applique successivement aux couches logicielles

Codage

Produire les composants

Tests

Tester les unités de code

Effectuer des tests d’intégration pour tester les IHM

Recette

Effectuer des tests de recette pour valider les fonctions du système développé

Documentation

Réaliser la documentation à destination des différents acteurs : utilisateurs, administrateurs et personnes en charge du suivi d’exploitation…

 

Diagramme UML dans 2TUP

 

UML est utilisé pour modéliser le système. Ci-dessous, les diagrammes utilisés durant les différentes phases du processus.

 

Tableau 4 : Les diagrammes utilisés durant les différentes phases du processus.

        Phases

 

 

Diagrammes

Capture initiale des besoins

Capture des besoins techniques

Capture des besoins fonctionnels

Analyse

Conception

générique

Conception

préliminaire

Conception

détaillée

Classes

 

X

X

X

X

X

X

Package

 

X

X

 

X

X

X

Objets

 

 

 

 

 

X

X

Structure composite

 

 

 

 

 

X

X

Cas d’utilisation

 

X

X

X

X

 

 

Séquence

 

X

X

X

 

X

X

Collaboration

X

X

X

 

 

X

X

Etats

 

 

 

X

 

X

X

De temps

 

 

 

 

 

X

X

D’activité

 

X

X

 

 

X

X

Global d’interaction

 

X

X

X

 

X

X

De composants

 

X

 

 

X

 

X

De déploiement

 

X

 

 

X

 

 

 

XP 

                                  

L’eXtreme Programming est une alternative à des méthodes plus lourdes dans le cas de projets de taille moyenne [BEN05]. Elle regroupe des bonnes pratiques de développement qui visent à améliorer la qualité des logiciels. Elle repose sur un processus projet en continu. Les phases de conception, de validation et d’intégration sont effectuées en continu. Des itérations sont effectuées au niveau du développement et des livraisons. Le code est sans cesse amélioré par la réécriture. Elle repose sur une rétroaction constante, le pilotage par les tests, une planification par les scénarios clients et l’intégration du client. Elle recherche une conception simple, s’appuie sur des conventions d’écriture et le code produit est une copropriété des membres de l’équipe. Les tests fonctionnels expriment les besoins et permettent d’effectuer la recette de l’application. Cette méthode recherche une meilleure maîtrise de l’environnement en s’inspirant du concept de cible mouvante (moving target).

 

L’eXtreme Programming repose sur un ensemble de pratiques permettant de réaliser un logiciel, de la programmation à la planification. Cette méthode permet d’organiser l’équipe et de gérer les relations avec le client.

Elle est basée sur des principes qui ne sont pas nouveaux : livraisons fréquentes, relecture de code, tests automatiques.

Mais dans cette méthode, ces pratiques sont poussées à l’extrême.

L’équipe se focalise sur la réalisation et ne perd pas son temps dans des activités imposées consommatrices de temps et de ressources comme la production de documents non exploités.

Le contact humain est positionné au premier rang, dans l’équipe et avec le client.

Il n’existe que très peu de projets pour lesquels les spécifications sont complètes et ne changent pas. Dans cette méthode, on n’attend pas d’avoir l’exhaustivité des spécifications pour commencer à réaliser l’application.

Les modifications des spécifications du client sont acceptées et prises en compte tout au long du projet afin de répondre à ses besoins.

XP définit 13 pratiques classées en 3 catégories :

 

·        les pratiques de programmation

o       conception simple (simple design)

o       remaniement (refactoring)

o       développement piloté par les tests unitaires (unit tests)

o       tests de recette (customer tests)

·        les pratiques de  collaboration

o       programmation en binômes (pair programming)

o       responsabilité collective du code (collective code)

o       règles de codage (coding standards, ownership)

o       métaphore (metaphor)

o       intégration continue (continuous integration)

·        les pratiques de gestion de projet

o       livraisons fréquentes (frequent releases)

o       planification itérative (planning game : planification effectuée par le client et l’équipe au cours de séances tout au long du projet)

o       client sur site (on-site customer, whole team)

o       rythme durable (sustainable pace)

 

 

Ces pratiques, plutôt d’ordre technique, sont destinées à mettre en place un environnement de travail basé sur les valeurs suivantes :

 

·        la communication pour une meilleure visibilité

la communication directe est favorisée par rapport à l’écrit car elle permet un échange d’informations très important en un minimum de temps.

La documentation n’est cependant pas supprimée, elle est gérée comme un besoin comme un autre. Les différents problèmes rencontrés sont résolus par l’ensemble de l’équipe client et fournisseur.

·        la simplicité comme garantie de productivité 

·        le feedback comme outil de réduction des risques

L’objectif est d’améliorer continuellement le pilotage du projet.

·        le courage de prendre de bonnes décisions

 

Une équipe XP doit remettre sans cesse en question ses méthodes de travail plutôt que de suivre des instructions à la lettre. Les pratiques XP doivent permettre l’amélioration de l’efficacité de l’équipe dans le respect des 4 valeurs d’XP.

 

            Compromis coût, délais, qualité, contenu.

 

            Un projet dépend de 4 variables interdépendantes : coût, délais, qualité, contenu [BEN05].

 

·        Coût

 

Le fait de changer l’équipe ou l’environnement de travail peut à court terme ralentir l’équipe. La plupart du temps le coût d’un projet est fixé préalablement au lancement du projet, lors de la demande des budgets. Si le coût fixé est sous dimensionné, il y a de fortes chances que la qualité du logiciel en pâtisse. Les coûts de maintenance et d’indisponibilité, quant à eux, risquent d’exploser.

Dans la plupart des cas, la sous estimation du coût d’un projet peut conduire à une dérive conséquente des coûts. La détermination de coûts plus élevés dès le départ permet de limiter l’ampleur des dérapages.

A l’opposé, si le coût du projet est sur dimensionné, on peut être amené à mettre en place une équipe trop importante qui sera difficile à coordonner. Et contrairement à ce que l’on espérait, la qualité de services sera dégradée et la durée du projet allongée.

 

·        Délais

 

Le fait de repousser les dates de livraison peut induire des coûts de synchronisation et la confiance du client et de l’équipe peut s’en trouver diminuée.

D’autre part, imposer des délais trop courts a pour conséquence de mettre la pression à l’équipe. Le risque est alors un manque de recul des membres de l’équipe et une baisse de leur niveau d’exigence.

 

·        Qualité

 

Une diminution du niveau de la qualité peut provoquer une démotivation de l’équipe ou une perte de la confiance du client qui finira par s’apercevoir de la dégradation du niveau de qualité. La démotivation de l’équipe peut avoir pour conséquence une augmentation du turn-over.

 

·        Contenu

 

Cette dernière variable permet d’être très flexible. Il est possible d’adapter le contenu d’un projet en jouant sur le périmètre fonctionnel. La réduction du périmètre fonctionnel permet de conduire à une réduction des coûts, de la durée tout en préservant un niveau de qualité acceptable. C’est sur cette dernière variable que joue la méthode XP.

 

Equilibre client et fournisseur

 

            Un équilibre doit s’instaurer entre les développeurs et le client.

 

Le client ne doit pas avoir tous les pouvoirs sinon on tombe dans un projet « marche à mort » (deathmarch projet).

 

L’équipe ne doit pas avoir trop de pouvoir sinon le projet risque de ne pas répondre aux besoins du client en cherchant à utiliser à tout prix les dernières technologies à la mode.

 

Dans une organisation XP, les responsabilités sont clairement séparées :

·        le client définit les fonctionnalités et leur ordre d’implémentation

·        les développeurs estiment les coûts et prennent en charge la réalisation

 

La mise en œuvre de la méthode XP peut être de chercher à résoudre les problèmes les plus sérieux de manière itérative et de traiter les problèmes restants jusqu’à parvenir à une situation stable.

 

Influence de la culture d’entreprise

 

La culture générale de l’entreprise est un facteur important de la réussite d’un projet XP.

 

Il est difficile de tirer les bénéfices de la méthode XP dans le cas :

·        où le mérite se mesure aux heures supplémentaires et où on considère qu’une équipe ne fonctionne à plein rendement que sous forte pression

·        d’une culture centrée sur le jeu politique, où les relations de type gagnant / gagnant ne sont pas de mise

·        d’une culture attachée aux démarches linéaires où la qualité du logiciel s’exprime en nombre de documents produits.

 


 

XP et le cycle en V

 

Un comparatif simple entre le cycle en V et XP est effectué dans le tableau ci-dessous (Tableau 5).

 

Tableau 5 : Comparatif simple entre V et XP 

Points

V

XP

Traitement du problème

De front

En tranche

Spécification

Complète

Partielle. Ajustement des spécifications à partir du feedback du client.

Début de réalisation

A la fin de la conception

Tranche par tranche avec prise en compte du changement

Résultat de la conception

Document

Code

Fabrication du logiciel

Codage

Compilation

Organisation

Spécialisation des individus (spécification, conception, codage et tests)

Polyvalence des individus. Chaque membre de l’équipe est responsable de l’ensemble de l’activité.

Moyen de communication privilégié

Documentation

Communication directe

 

XP et RUP

 

Un comparatif simple entre RUP et XP est effectué dans le tableau ci-dessous (Tableau 6).

 

 

Tableau 6 : Comparatif simple entre XP et RUP

La méthode

XP

RUP

Est basé sur

Des valeurs et principes

Des best practices

Met en avant

Les personnes

Un outil

Repose sur un cycle itératif

Itération sur des livraisons d’un logiciel incomplet

Itération sur des processus linéaires

Produit

Du code

Un modèle en faisant l’abstraction du code

 

Compléments de conception

 

            Lors de la réalisation du projet, un certain nombre de compléments de conception peuvent être employés. On peut citer par exemple : les modèles de données Merise, les mappings ORM, la conception des écrans d’IHM, l’emploi de Design Patterns, l’utilisation de frameworks et la réutilisation de ce qui a déjà été mis en place.


 

Merise

 

Merise est une méthode d'analyse, de conception et de gestion de projet. Son principal atout est d’être une méthode complètement intégrée. Elle fournit un cadre méthodologique et un langage. Elle est née dans les années 1970, à la demande du ministère de l'industrie. C’est une méthode spécifiquement française.

 

            Elle préconise une analyse séparée des données et des traitements à plusieurs niveaux : conceptuel, logique et physique. Elle impose de vérifier la cohérence entre les deux analyses avant la validation et le passage au niveau suivant.

Elle est articulée simultanément selon 3 axes.

Le projet suit :

·        un cycle de vie composé de phases de conception, de réalisation et de maintenance. Ensuite, un nouveau cycle de projet commence.

·        un cycle de décision comportant des choix : GO et NO GO.

·        Un cycle d'abstraction en trois parties : conceptuel, logique et physique. On prend d'abord les grandes décisions « métier » avant d’entrer dans les aspects techniques.

Dans cette méthode, on effectue une analyse critique de l'existant (démarche bottom-up), puis on décline la solution retenue (démarche top-down).

Ce recensement de l'existant allonge considérablement la durée du projet. Dans d’autres démarches reposant sur des méthodes itératives de type RAD ou sur l'adoption systématique des best practices observées dans d'autres entreprises, cette analyse préalable n’est pas effectuée.

            Au niveau conceptuel, on s'attache aux invariants de l'entreprise. On veut décrire, après l’abstraction, le modèle de l'entreprise ou de l'organisme.

On utilise alors deux types de schéma. Des schémas représentant la structure du Système d’Information du point de vue des données, les Modèles Conceptuels des Données (MCD) et des schémas représentant les traitements, les Modèles Conceptuels des Traitements (MCT).

Le MCD repose sur les notions d'entités et d'associations et sur les notions de relations. L'entité est définie comme un objet de gestion. L'association ou relation est un lien sémantique entre une ou plusieurs entités.

 

Le MCT repose sur les notions d'événements, d'opérations et de processus. L'événement est assimilable à un message. Un événement peut déclencher une opération ou être le résultat d'une opération. L'opération se déclenche sur un ou plusieurs évènements  synchronisés. Elle est constituée d'un ensemble d'actions. Le processus correspond à un enchaînement d'opérations.

Au niveau organisationnel, on précise comment on organise les données de l'entreprise  et les tâches ou procédures.

On construit :

·       le Modèle Logique des Données (MLD) qui reprend le contenu du MCD mais précise la volumétrie, la structure et l'organisation des données. A ce stade, il est par exemple possible de connaître la liste exhaustive des tables de la base de données relationnelle.

·       un Modèle Logique des Traitements (MLT) qui précise les acteurs et les moyens qui seront mis en œuvre. Les traitements sont découpés en procédures fonctionnelles.

Au niveau physique, on établit la manière concrète de mettre le système en place au travers de deux modèles :

·        le Modèle Physique des Données (MPD) permet de préciser les systèmes de stockage employés. On implémente le MLD dans le SGBD retenu.

·        le Modèle Opérationnel des Traitements (MOT) spécifie les fonctions telles qu'elles seront réalisées.

 

SADT

 

SADT est l’acronyme de Structured Analysis and Design Technique. Cette méthode est également appelée IDEF0 (Integration DEFinition for transitions modeling). Elle est d'origine américaine. Elle a été développée par Doug Ross en 1977 pour la société Softech et était répandue dans la fin des années 1980. C’était l'un des standards de description graphique d'un système complexe par analyse fonctionnelle descendante. Dans cette méthode, l'analyse chemine du général vers le particulier et le détaillé. SADT est une démarche systémique de modélisation d'un système complexe ou d'un processus opératoire. Le principal avantage est de proposer une structure hiérarchisée par niveau permettant une clarification et une décomposition analytique de la complexité d'un système. Le principal inconvénient est l’absence de représentation séquentielle.


 

Classification des méthodologies

 

            Ci-dessous, une classification des méthodologies par rapport à leurs niveaux de formalisme et les natures des cycles suivis.

Figure 18 : Classification des méthodologies

 

CMM

 

CMM signifie Capability Maturity Model [LAB00]. C’est un système qualité qui vise à améliorer le processus de développement logiciel apparu en 1987. On peut ainsi évaluer la capacité de développement logiciel d’une organisation et la faire évoluer par pallier. Ce modèle se base sur une grille de maturité hiérarchisée. Une organisation d'évolution de processus logiciel en "échafaudage" a été inventée à partir des travaux de Watts Humphrey. Les améliorations réalisées à chaque étage fournissent la fondation de l’étape suivante. Cinq niveaux évolutifs ont été définis. Cette méthode permet d'atteindre des objectifs de coûts, de délais et de qualité. Contrairement à la norme ISO 9000, CMM a été conçu spécifiquement pour le développement logiciel. Ce modèle offre à une organisation bien définie proposant une structure d'évaluation de son niveau de maturité, un ensemble de procédures documentées pour améliorer son niveau de maturité et un ensemble de processus de contrôle pour valider les étapes de cette progression.


 

Cette méthode commence par la détermination du niveau de maturité actuel de l’organisation. Ensuite l’organisation dispose d'une liste détaillée des actions à entreprendre afin d’atteindre le niveau de maturité recherché. Les niveaux de maturité sont :

·        initial

L’organisation n’est pas dans un environnement stable pour l'évaluation, le développement et la maintenance de logiciels.

·        reproductible

La gestion de nouveaux projets est basée sur l'expérience d'anciens projets similaires. C'est l'engagement permanent des ressources humaines qui garantit une pérennité du savoir-faire.

·        défini

Les directives de gestion de projet sont établies. Le processus standard de développement et d'évolution du logiciel a été documenté.

·        maîtrisé

Des objectifs qualitatifs et quantitatifs sont fixés. La productivité et la qualité sont mesurées.

·        optimisé

L'organisation toute entière est centrée sur l'amélioration continue des processus.

L’emploi de la méthode CMM ne garantit pas la réussite d'un projet. Des aspects tels que la motivation des équipes, la diminution du turn-over ne sont pas couverts par cette méthode.


 

                       

2.3.         Management des ressources humaines

 

Le management permet au chef de projet de diriger l’équipe projet afin d’atteindre les objectifs du projet.

           

Organisation

 

Les acteurs du projet se répartissent en deux ensembles la       MOA et la MOE.

 

MOA 

 

MOA désigne le Maître d'OuvrAge ou la Maîtrise d'OuvrAge. La maîtrise d’ouvrage est responsable de l’efficacité de l'organisation et des méthodes de travail autour des systèmes d’information. Elle fait appel à un Maître d’OEuvre (MOE) pour obtenir les produits (matériels, logiciels, services et solutions) nécessaires à la réalisation de sa mission. Dans un projet, le maître d'ouvrage décrit les besoins, le cahier des charges, établit le financement et le planning général des projets, fournit au MOE les spécifications fonctionnelles et valide la recette fonctionnelle des produits, assure la responsabilité de pilotage du projet dans ses grandes lignes et adapte le périmètre fonctionnel en cas de retard dans les travaux afin de respecter  la date de la livraison finale.

La MOA a également des fonctions d’organisation (conduite du changement, formation des utilisateurs, organisation et modification des processus ou procédures) et doit s’assurer de la bonne adéquation entre la stratégie « métier » de l'entreprise ou de l'organisation (les objectifs, les enjeux...) et le Système d’Information.

 

 

MOE

 

MOE désigne le maître d'œuvre ou l'organisation qui assure la maîtrise d'œuvre garante de la bonne réalisation technique des solutions. Il a un devoir de conseil auprès de la maîtrise d’ouvrage. C’est à la MOE de faire en sorte que le Système d’Information tire le meilleur parti des possibilités techniques et de garantir la qualité technique de la solution.

 

Equipe projet

 

Tout projet nécessite la mise en place d’une équipe. Dans une équipe chaque membre de l’équipe a un rôle à tenir et donc la responsabilité d’un certain nombre de tâches à effectuer.

 

Le chef de projet Informatique a pour responsabilité de planifier les ressources, de former, de développer et de diriger l’équipe projet.

 

Dans le cas d’une gestion de projet XP, l’équipe comprend 6 membres dont les responsabilités sont indiquées sur la figure ci-dessous [BEN05].

 

Figure 19 : Organisation d’une équipe XP

 

 

Planification et suivi

 

            Le chef de projet doit organiser le suivi du projet et des individus composant l’équipe projet.

 

            Afin de suivre les différentes étapes du projet, il dispose de techniques de planification telles que les réseaux Pert afin de représenter les contraintes d’ordonnancement des tâches du projet, ainsi que les diagrammes de Gantt qui permettent de représenter les contraintes associées aux ressources.

 

 

De plus, le chef de projet peut réaliser un tableau de bord afin de rendre compte de l’activité, de l’avancement des lots et de l’évolution des charges restantes.

 

            Il doit diffuser ses rapports d’avancement à sa hiérarchie mais également à l’équipe. La diffusion de l’information au sein de l’équipe est un point crucial. Il est nécessaire de communiquer de façon régulière avec les différents acteurs du projet. La communication humaine est un facteur déterminant pour la bonne réussite d’un projet. 

 

Pour bien conduire le projet, il est nécessaire de contrôler et de réguler le traitement des étapes en fonction des difficultés rencontrées et des modifications des besoins fonctionnels.

 

            Le pilotage d’un projet est cadré par un certain nombre de réunions : comité de direction, comité de pilotage et comité de suivi. Dans les comités de direction, la direction valide les choix stratégiques ou les grandes orientations du projet. Lors des comités de pilotage, les points bloquants sont levés et les décisions importantes sur les orientations de l’application sont prises. Le comité de suivi, quant à lui, permet de suivre la bonne marche du projet. 

 

            Les réunions sont nécessaires pour mener à bien un projet mais il est toutefois important de limiter leur coût. Cela peut être fait en ne sollicitant que les personnes concernées. Avant une réunion, on peut également envoyer l’ordre du jour afin que les différents intervenants juge de l’intérêt d’assister ou non à la réunion. Après chaque réunion, un compte rendu doit être fait afin de garder une trace. Avant de diffuser le compte rendu, on peut demander une validation de ce dernier par les différents participants de la réunion.

 

            Il est essentiel que les réunions soient efficaces. Pour qu’elles débouchent sur des résultats, il est nécessaire que les tâches levées lors de ces réunions soient réalisables.

 

            On peut employer des méthodes telles que la méthode Item Action qui consiste à identifier les différents points levés lors de la réunion à des tâches, des décisions à prendre, des recommandations ou des constatations.

 

Des phrases complètes et compréhensibles par tous doivent être utilisées lors du compte rendu de la réunion. En face d’une action à effectuer sont indiquées son origine, les personnes qui doivent la prendre en charge et les dates d’exécution. Le quoi, le pourquoi, par qui et comment sont ainsi spécifiés. Il ne doit pas y avoir d’ambiguïté lors de la lecture du compte rendu.

 

L’ensemble des comptes rendus ainsi que la documentation du projet et les livrables doivent être classés de manière ordonnée dans une arborescence de fichiers centralisée.

 

Gestion du conflit

           

Toute collaboration humaine débouche sur des points de vue divergents ou des désirs incompatibles. Il est alors nécessaire de gérer les différentes positions et points de vue des parties prenantes tout particulièrement lorsque des conflits apparaissent.

 

           


 

Maîtriser le déroulement

 

Gestion des délais

                       

Afin d’estimer les délais, il est avant tout nécessaire d’évaluer les charges. La méthode la plus couramment utilisée est de faire une estimation par analogie aux projets que l’on a déjà effectués.

Une fois cette estimation faite, on peut élaborer un échéancier et déterminer le chemin critique du projet.

Il est préférable de conserver quelques marges de manœuvre au niveau de chacune des étapes. On peut alors  estimer une durée probable du projet et de chacune des tâches qui le composent. On détermine ainsi une date de livraison et une date de mise en production probable.

 

Gestion des coûts 

                       

            Le coût d’un projet peut être décomposé comme suit :

Coûts directs

 

  • Coûts conception / réalisation
    • Coût de main d’œuvre client
    • Coût de main d’œuvre projet
  • Coûts logiciels
  • Coûts infrastructure
  • Coûts de déploiement
    • Coût de main d’œuvre
  • Coûts de formation
  • Coûts de maintenance évolutive et corrective
    • Coût de main d’oeuvre

 

Coûts indirects

 

  • Coûts de débordement
    • Coût de main d’œuvre
    • Coût de business du au débordement
  • Coûts d’inadéquation aux besoins réels
    • Coût de business dû à l’inadéquation des besoins
  • Coûts de changement
    • Coût de main d’œuvre
  • Coûts de défaut de qualité
    • Coût de main d’œuvre
    • Coût de business associé à un incident
  • Coûts de turn-over
    • Coût de main d’œuvre

 

Les coûts ont plus ou moins d’importance. Les coûts les plus forts correspondent à la main d’oeuvre informatique. Les coûts logiciel et d’infrastructure peuvent également être très importants.

 

Les coûts engendrés par l’inactivité des utilisateurs, liés à la non disponibilité de l’application ou à l’inadéquation avec les besoins réels des utilisateurs ne sont pas simples à évaluer. 

 

Des différences de coût peuvent apparaître entre la méthode XP et une méthode basée sur un processus unifié reposant sur l’implémentation d’un modèle. Il n’est pas possible de dire quelle est la méthode la moins coûteuse, cela dépend beaucoup du projet et de son contexte. On peut néanmoins envisager des possibilités de coûts supplémentaires ou des diminutions des coûts sur certains des centres de coûts identifiés précédemment :

 

  • Coûts supplémentaires

 

La présence du client sur site au sein de l’équipe génère un coût de main d’œuvre client plus important.

 

Le recourt à la programmation en binôme augmente le coût de la main d’œuvre projet.

 

Sur les phases de déploiement et de maintenance, l’absence de documentation peut engendrer des surcoûts surtout dans le cas de renouvellement de l’équipe.

 

La formation continue de l’équipe tout au long du projet génère des coûts de formation conséquents.

 

  • Diminution des coûts

 

La présence du client sur site au sein de l’équipe permet de minimiser les temps d’attente et les écarts entre les besoins réels et le logiciel obtenu.

 

Le recours aux outils les plus simples possibles diminue les coûts de licences.

 

L’intégration continue permet d’anticiper les problèmes de déploiement.

 

Le client est un membre de l’équipe. Ses besoins de formation sont moins importants que s’il découvre le logiciel lors de sa livraison.

 

L’utilisation de solutions simples et l’automatisation des tests permettent dans une moindre mesure de diminuer les coûts liés à la maintenance du logiciel.

 

La méthode XP permet de prévenir les débordements grâce à ses techniques de planification par fonctionnalités.

 

L’écart entre les fonctionnalités proposées par le logiciel et les besoins du client est minimisé du fait de la forte implication de ce dernier tout au long du projet. Les coûts indirects engendrés par l’inadéquation aux besoins des utilisateurs sont donc fortement diminués.

 

De part la prise en compte permanente du changement tout au long du projet, il n’y a pas ou peu de coûts indirects liés au changement.

 

Le recours aux tests automatisés réduit les défauts de qualité.

 

Les coûts du turn-over sont réduits du fait de l’intérêt porté à chacun dans l’équipe. La dimension humaine a une place importante dans cette méthode. La motivation de chacun des membres est recherchée et favorisée.

 

Le travail collaboratif diminue l’impact d’un départ.

 

Gestion des risques 

 

            Il n’est pas toujours évident d’identifier les risques. Pourtant, on peut envisager que des tâches reposant sur des domaines fonctionnels ou techniques méconnus représentent des risques. Le fait de travailler pour la première fois avec une personne représente un risque. On peut donc dire que la nouveauté est associée à un risque majeur alors que ce que l’on a l’habitude de faire correspond à un risque moindre.

 

            L’estimation des risques ne peut se faire que sur la base d’une analyse qualitative. On cherche à imaginer les probabilités de risques, leurs impacts et à identifier les facteurs de risques.

 

            L’expérience de la conduite de projet permet de minimiser les risques mais ne les élimine pas pour autant. Les risques ne sont pas toujours prévisibles et peuvent être de nature très diverse telles que la démission d’un membre de l’équipe ou les pannes matérielles.

 

Gestion de la qualité

La gestion de la qualité est l'ensemble des activités qui permettent d’obtenir de la qualité dans un cadre de production de biens ou de services.

On parle de la qualité totale lorsque l’on cherche à satisfaire les différentes parties prenantes : les fournisseurs, les clients, les actionnaires, les employés et l'État.

La qualité optimale correspond à un équilibre au niveau des besoins de l'ensemble des parties prenantes. Le niveau de qualité optimal ne doit pas produire de coûts inadéquats. On parle alors de sur-qualité. La qualité est censée réduire le coût de la non-qualité. Une entreprise est performante lorsque les ressources qu'elle met en œuvre, sont justifiées et efficaces, et lui permettent de se positionner avantageusement sur un marché avec une marge d'avance sur la concurrence.

 

Les normes qualité

Les normes internationales de la qualité se sont orientées vers la qualité totale (TQM : Total Quality Management), qui articule stratégie, système, performance, dimension humaine et sociale. En France, le déploiement de la démarche qualité a été tardif : vers 1990. Une version simplifiée de la démarche qualité a alors été élaborée et diffusée sous le nom d'Assurance Qualité, définie dans les normes ISO 9001.

Assurance Qualité

Assurance Qualité ou Quality Assurance (QA) couvre toutes les activités de production depuis la conception, le développement, la production, l'installation, les services et la documentation. L’objectif étant de bien faire les choses dès la première fois et d’aller droit au but.

            De nombreuses méthodes sont utilisées pour améliorer la qualité. Parmi elles on peut citer la roue de Deming, le diagramme de Gantt, l’outil PERT et le brainstorming.

Roue de Deming

La roue de Deming permet de cadrer le pilotage d’une démarche qualité. Elle précise les étapes de mise en place de la maîtrise de la qualité. Elle est aussi désignée par PDCA (Plan - Do - Check - Act : concevoir, mettre en œuvre, contrôler, agir) ou encore par la "roue de la qualité". Cette méthode a été lancée par les qualiticiens JURAN et SHEWART de la société Bell Telephon en 1925.

Diagramme de Gantt

Le diagramme de Gantt permet d’optimiser et de sécuriser un processus. Le diagramme de Gantt est un outil permettant de modéliser la planification de tâches nécessaires à la réalisation d'un projet.

Le diagramme de Gantt a été développé par Henry L. Gantt, ingénieur américain, vers 1910. Il est utilisé en ordonnancement et en gestion de projet. Il permet de visualiser dans le temps les tâches d’un projet. L’avancement du projet est alors représenté graphiquement. Son emploi permet de répondre à des objectifs de planification optimale, de communication sur le planning établi et de justification de choix.

Un diagramme de Gantt permet de déterminer les dates de réalisation d'un projet, d'identifier les marges existantes, de visualiser le retard ou l'avancement des travaux.

De nombreux logiciels de gestion de projet utilisent ces diagrammes. On peut citer par exemple l’offre propriétaire Microsoft Projet ou la solution gratuite GANTT Projet.

Réseau PERT

L'outil PERT est utilisé pour analyser un fonctionnement. C’est une méthode de gestion de projet permettant de définir les tâches et le délai d’un projet et d’en assurer le suivi. Elle a été créée en 1957 par l’US Navy.

PERT signifie Program Evaluation and Review Technique. Il permet de visualiser la dépendance des tâches et de les ordonnancer. Il repose sur un graphe de dépendances. On indique une date de début et de fin au plus tôt et au plus tard de chacune des tâches. On peut en particulier, à l’aide de ce diagramme, déterminer le chemin critique conditionnant la durée minimale du projet. Des tâches critiques sont alors identifiées. Elles correspondent aux tâches qui ne doivent pas subir de retard sinon l’ensemble du projet sera retardé. Cet outil fournit donc une méthode permettant d'optimiser et de planifier l’ordonnancement des tâches du projet.

Le brainstorming

 

Le brainstorming ou remue-méninges est une méthode de créativité.

 

ISO 9001

La norme ISO 9001 fait partie des normes ISO 9000 relatives aux systèmes qualité. Elle donne les exigences organisationnelles qui sont requises pour l'existence d'un système de management de la qualité.

Dans la norme ISO 9001 version 2000, les exigences sont relatives à quatre grands domaines :

·        Responsabilité de la direction : exigences d'actes de la part de la direction.

·        Système qualité : exigences administratives permettant la sauvegarde des acquis. Exigence de prise en compte de la notion de système.

·        Processus : identification et gestion des processus contribuant à la satisfaction des parties intéressées.

·        Amélioration continue : mesure et enregistrement de la performance, engagement d'actions de progrès efficaces.

La mise en œuvre d’un système de management de la qualité selon les exigences de la norme ISO 9001-Version 2000 consiste à :

  • Démontrer l'aptitude à fournir régulièrement un produit conforme aux exigences du client et aux exigences réglementaires applicables.
  • Chercher à accroître la satisfaction des clients par l'application efficace du système, et en particulier, mettre en œuvre un processus d'amélioration continue.

Le texte de la norme ISO 9001 aborde les 4 processus principaux :

  • La responsabilité de la direction 
  • Le management des ressources 
  • La réalisation du produit 
  • Les processus de mesure, d'analyse et d'amélioration continue

Elle est basée sur 8 principes de management :

  • L'écoute client 
  • Leadership
  • L'implication du personnel 
  • L'approche processus 
  • Le management par approche système 
  • L'amélioration continue 
  • L'approche factuelle pour la prise de décision 
  • La relation avec les fournisseurs

La version 2000 de la norme ISO 9001 se différencie sur deux points par rapport aux versions précédentes.

Dans les versions précédentes, on définit par écrit ce que l'on doit faire et on fait ce que l'on a écrit. Alors que dans la version 2000, on définit le niveau de qualification (ou de compétence) nécessaire pour tenir un poste et on s'assure que les personnes tenant ce poste ont la qualification voulue et, si nécessaire, on met en œuvre des formations. On définit un niveau de qualification plutôt que de spécifier un mode opératoire à suivre.

Contrairement aux versions précédentes la satisfaction réelle de l'utilisateur final est plus importante et le client est positionné au sommet de la pyramide.


 

Les normes ISO 9000 et XP

 

On peut faire un parallèle entre les principes des normes ISO 9000 avec les principes et valeurs de la méthode XP. Même si la méthode XP ne respecte pas dans les règles de l’art les principes des normes ISO, elle s’en inspire tout de même.

 

Tableau 7 : Positionnement de XP par rapport aux principes ISO 9000

Principes ISO9000

Positionnement de la méthode XP

Orientation client

 

La méthode XP est orientée client. Le client fait partie de l’équipe. La méthode cherche à comprendre le client et à répondre à son besoin

Leadership

 

Le bénéfice attendu du leadership est l’établissement de la confiance et l’élimination de la peur, ce qui rappelle les qualités de communication et de courage prônées par XP.

Implication du personnel

 

La méthode considère que les individus sont plus importants que les technologies et les processus. Cette méthode cherche à mettre en valeur les individus.

Approche processus

 

XP peut être vu comme un processus avec un formalisme minimal.

Management par approche système

 

XP s’inspire d’une approche systémique.

Amélioration continue

De fait de l’utilisation d’itérations dans les développements et de la recherche continue de l’amélioration des compétences, XP respecte tout à fait ce principe.

Approche factuelle pour la prise de décision

La méthode XP se veut pragmatique par rapport aux observables.

Relation mutuelle bénéfique pour les fournisseurs

 

XP est basé sur des relations de type gagnant – gagnant plutôt que sur le respect de clauses d’un contrat initial.

 

Qualité des données

La qualité des données se réfère à la conformité des données aux usages prévus, dans les modes opératoires, les processus, les prises de décision, et la planification.

La qualité livrée

Pour ce qui est de la qualité, la qualité livrée du logiciel peut être mesurée de différentes manières. En interne, le niveau de qualité est mesuré par le responsable qualité ou les équipes, alors qu’en externe, c’est le client qui mesure le niveau de qualité.


Amélioration de la qualité 

 

Un certain nombre de mesures permettent de contrôler la qualité : la mesure de la conformité, de la satisfaction ou les enquêtes de satisfaction.

 

La qualité interne peut être améliorée en gérant la qualité de l’architecture et du code par : des lectures croisées, des inspections, des revues de code et d’analyse ou du refactoring.

A force d’implémenter de nouvelles fonctionnalités dans une application, le code source tend à devenir de plus en plus complexe, d’autant plus que l’on emploie des techniques modernes de développement itératif et incrémental.

La refactorisation (refactoring) est une opération de maintenance du code informatique. Elle consiste à retravailler le code source pour améliorer sa lisibilité, simplifier sa maintenance sans pour autant ajouter de nouvelles fonctionnalités.

 

La qualité interne est également améliorée par l’établissement d’outils tels que les normes de codage, les guides de conception des composants ou les designs patterns.

 

La qualité externe, quant à elle, peut être améliorée en s’efforçant d’offrir le meilleur service possible à son client.

 

La qualité est obtenue au travers de

 

·        méthodes structurées

il est important de déterminer les aspects à traiter, de les ordonner et de gérer le changement par la mise en place de versions de documents et de code.

·        la mise en œuvre de moyens et d’outils adaptés

CVS peut être utilisé pour gérer les différentes versions du code et des documents. Microsoft Office permet d’élaborer de nombreux documents du projet.

·        la formation

le recourt à la formation est un facteur d’amélioration de la qualité et de la productivité du fait de la montée en compétence des acteurs du projet.

 

L’amélioration de la qualité peut passer par l’utilisation d’UML pour modéliser le système en simplifiant et uniformisant la modélisation, en améliorant la relation entre les différents acteurs et en s’appuyant sur des normes et méthodes.

 

De plus, il est important d’entretenir une culture de la qualité.

 

 

Atteindre des Objectifs 

 

Rentabilité

 

            Tout projet commence en général par l’estimation du ROI (retour sur investissement). C’est un élément important de la prise de décision des dirigeants. Les gains financiers correspondant au projet sont estimés. On évalue également la date de retour sur investissement qui correspond à la date à partir de laquelle le projet permet des gains financiers.

 

            Réutilisation

                       

            Il est important de réaliser une phase appelée « mémoire du projet » afin de préciser les aspects réutilisables de la démarche sur des problématiques similaires.

            Cette étape permet de tirer parti de ce qui a été fait en évitant de reproduire les mêmes erreurs et en cherchant à réutiliser les points positifs de la démarche projet.

            C’est en quelque sorte un bilan du projet. 

           

 

 

 

2.4.         ETL et EAI : généralités

 

ETL GENIO

 

Présentation

 

ETL signifie Extract Transform and Load. Un ETL permet de construire de façon simple des processus qui permettent d’extraire des données de systèmes hétérogènes, de les transformer, puis de les charger dans un système cible.

 

A l’aide d’un ETL, il est possible de connecter diverses sources de données à de multiples systèmes cibles à travers toute l’entreprise, afin d’alimenter un data warehouse, de gérer des méta-données ou d’intégrer des applications d’entreprise.

 

 On peut exploiter de manière plus efficace les données et donc optimiser les processus « métier ». Il est possible de consolider les données afin d’en tirer une information fiable, cohérente et actualisée ou de les échanger entre applications, en ayant au préalable effectué des transformations et nettoyé ou enrichi les données.

 

 

Architecture

 

L’ETL que nous utilisons dans le projet est la version 4 de Genio d’hummingbird.

 

Son architecture est de type client / serveur, construite sur un modèle Hub and Spoke. Le Hub se compose d’un moteur centralisé et d’un référentiel de données et méta-données. Les sources de données et les cibles entre lesquelles le Hub échange des données correspondent aux Spoke.

 

Figure 20 : Architecture de GENIO

 

 

GENIO se compose de différents éléments qui permettent de concevoir, de déployer et de maintenir les transformations de données et les processus d’échanges.

 

Ces composants sont : designer, administration manager, repository, engine, scheduler, metalink et datalink. Nous allons plus nous attacher dans ce qui suit au designer et au scheduler car ce sont les composants que nous utilisons le plus lorsque nous développons. 

 

 

Engine

 

L’engine est un moteur de transformation multithread de type broker. Il permet d’exécuter les processus.

 

Repository

 

 Le repository est un référentiel objet pouvant être hébergé sur les principaux SGBDR du marché. Dans notre cas, nous l’avons hébergé sur une base ORACLE 8. Dans ce référentiel sont stockés et gérés tous les aspects des transformations, les méta-données des processus d’échange, les objets créés au travers du designer, ainsi que les informations relatives aux exécutions des processus.

 

 

Administration manager (Console d’administration)

 

L’interface d’administration permet d’initialiser l’environnement, le repository et de gérer l’administration des utilisateurs et leurs droits.

 

Scheduler

 

Le scheduler permet

 

·        la planification temporelle et événementielle. Il est possible de programmer, déclencher et contrôler les processus dont l’exécution peut être planifiée par des événements externes tels que la modification de fichier, le transfert de fichier, à une heure donnée, à partir d’un calendrier, de façon périodique (journalière, hebdomadaire ou mensuelle) ou à la création d’un fichier. Il est un point d’entrée unique pour l’ensemble des planifications de l’architecture.

·        le contrôle et la surveillance des exécutions en temps réel au niveau du moteur de  l’ETL.

·        la visualisation des comptes rendus d’exécution. On peut trier les exécutions par date, par nom de processus, par nombre d’erreurs.

·        l’accès à un historique complet

 

 

Metalink

 

Metalink permet de récupérer et de transformer des données et métadonnées provenant d’applications ou de divers ERP.

 

Datalink

 

Datalink propose une bibliothèque de liens aux SGBD relationnels ou multidimensionnels et aux systèmes de gestion de fichiers plats.

 

Designer 

 

Le Designer permet de concevoir les processus exécutables dans le moteur de l’ETL au sein de projets. Il est possible de créer de nombreux objets qui vont permettre de concevoir les différents processus.

 

 

Ses caractéristiques

 

Gain de productivité

 

Le Designer est une interface graphique qui simplifie les opérations de mapping des données sources avec les structures cibles. Le temps d’apprentissage et les ressources nécessaires afin d’être opérationnel sont minimes par rapport à l’apprentissage d’un langage de programmation tel que Java. C’est un environnement multi utilisateurs qui permet d’élaborer des transformations de données, ainsi que des processus d’échange.

           

Développement simple

 

Le designer permet de manipuler de nombreux objets simples qui vont permettre de concevoir les différents processus. Voici une liste non exhaustive d’objets les plus couramment utilisés :

 

o       Connexion

C’est un lien vers une base de donnée ou un fichier

 

o       Table

Elles sont liées à une connexion et sont le reflet des tables d’une base de donnée ou de la structure d’un fichier.

 

o       DataSet

C’est un ensemble de tables d’une connexion avec la possibilité de faire des jointures. Dans le cas des bases de données, on peut utiliser des fonctions telles que somme, max, min … Les fonctions proposées restent très basiques. On peut néanmoins faire des jointures, des agrégations, des distinctions, des filtres ou des tris.

 

o       Module

Il accepte une table ou un dataset en entrée et plusieurs sources de données en sortie. Il permet la lecture d’informations présentes dans une base de données ou un fichier, de transformer ces informations ou de les mapper et de les écrire dans un ou plusieurs autres systèmes cibles (bases de données ou fichiers).

C’est au niveau du module qu’est offerte la possibilité d’utiliser un langage simple. On dispose ainsi de fonctions analogues aux langages de programmation : fonctions mathématiques, de manipulation de chaîne ou de conversion.

 

o       Processus

Un processus se compose de modules, de déclenchement d’exécutables, d’envois d’email ou d’événements …

Les exécutables peuvent être des batch s externes ou des scripts Shell dans le cas où l’on aurait des besoins de transformations spécifiques.

 Les notions de transaction, de commit et de rollback à l’intérieur de ces programmes sont prises en charge.

 

 

 

Possibilité de mise en œuvre de transformation complexe

 

Des possibilités de scripting disponibles au niveau des modules permettent de mettre en œuvre des processus de transformation complexe de données. Ce langage simple permet d’utiliser des boucles, des tests, des variables et des instructions. On peut définir des variables ou utiliser des instructions logiques telles que for ou if. Un ensemble complet de fonctions de transformation permet de créer des programmes de transformation au même titre qu’un langage de programmation. Il offre de nombreuses fonctions  utilisées pour construire des expressions avec des sources de données et des variables. Ces fonctions couvrent le spectre complet de la manipulation des chaînes, dates, nombres, et booléens. Des clauses complexes telles que des IF, THEN, ELSE et CASE peuvent également être utilisées dans les expressions. Les utilisateurs peuvent ainsi créer leurs propres macros afin de décrire leurs règles « métier ». Les objets créés sont stockés dans le repository afin d’être réutilisés.

 

Analyse d’impact

 

Une analyse d’impact des modifications effectuées sur les objets et les objets associés est réalisée par le designer. Si un changement touche l’intégrité d’un objet, l’objet devient invalide. Les modifications faites au niveau des structures de données sources et cibles sont également détectées. Ceci permet d’éliminer les risques de corruption de données ou d’échec pendant les processus de transformations.

 

 

Transparence des implémentations techniques

 

GENIO utilise les mêmes fonctions lorsqu’il manipule des fichiers ou des sources de données. Il ne fait pas de distinction sur le fait que la source ou la cible soient des fichiers « texte »  ou des tables d’une base de données. L’utilisateur n’a pas à se soucier des implémentations techniques des fonctions qu’il utilise. C’est le moteur qui gère cet aspect et qui va utiliser la grammaire SQL native correspondant à une base de données précise afin d’exploiter les possibilités propres de la base de données pour accéder aux seules données que l’on souhaite transformer. Cette approche présente l’avantage de minimiser le trafic réseau.

 

 

Gestion des erreurs

 

Il est possible de lever des exceptions et de gérer des erreurs. Un module peut retourner un code erreur permettant, au sein d’un processus, de conditionner l’exécution des modules qui le suivent.

 

A l’aide de la commande write, utilisable dans les modules, il est possible d’écrire des messages dans le compte rendu d’exécution. De plus, le compte rendu d’exécution propose par défaut la visualisation de nombreuses autres informations qui facilitent la détection des erreurs : l’ensemble des ordres SQL effectués sur les différentes bases de données, des compteurs correspondant aux enregistrements lus, écrits, mis à jour …

 

 

 

Implémentations possibles

 

Il existe différents types d’implémentation. Soit l’essentiel des manipulations de données se fait au sein du module, soit on déporte une partie des transformations au niveau des bases de données sources ou cibles. Ou encore, on exécute des ordres SQL. Dans ce dernier cas, c’est le moteur de base de données qui fait tout le travail, et il n’y a pas de transfert d’information sur le réseau.

 

 

 

 


 

EAI / VBIS 

 

Présentation

 

L’EAI (Entreprise Application Intégration) désigne des processus et des progiciels permettant d’automatiser les échanges entre différentes applications d’une même entreprise ou entre les systèmes d’information d’entreprises différentes. Les applications et les entreprises peuvent ainsi s’échanger des données, des messages et collaborer à l’aide de processus communs.

 

Une plate-forme EAI relie les applications hétérogènes du Système d’Information autour d’un bus logiciel commun, chargé du transport des données.

 

Deux facteurs principaux poussent au développement de la mise en place de l’EAI dans les entreprises :

Le premier est lié à la composition très diversifiée du Système d’Information de l’entreprise. L’EAI permet d’exploiter les données et le potentiel de ces différents systèmes, et également de faciliter la maintenance des passerelles existant entre ces systèmes.

Le second facteur de développement de l’EAI est lié aux événements ou aux changements structurels qui poussent les entreprises à augmenter la flexibilité et la réactivité de leur Système d’Information, d’où la généralisation des besoins d’intégration entre les applications de production (ERP), de logistique (SCM), de relation client (CRM)… La chaîne de valeur se conçoit dans sa globalité.

 

Deux grandes Familles        

 

On distingue deux grandes familles de technologies EAI : les EAI tactiques et les EAI d’infrastructure.

 

L’EAI tactique intervient dans un périmètre limité, généralement comme une brique d’un projet fonctionnel de l’entreprise. C’est un outil, un composant qui va permettre d’automatiser un ensemble de traitements localisés, sans impact sur le Système d’Information global de l’entreprise.

 

L’EAI d’infrastructure implique une prise en compte et une évolution éventuelle du système global de l’entreprise et de ses processus. On parle alors de Business Process Management. Ce sont des solutions qui se justifient dans des environnements applicatifs complexes ou des environnements critiques, de grandes entreprises. L’EAI devient alors l’un des piliers de l’architecture du Système d’Information.

 

 

 

VBIS

           

            Nous allons présenter dans cette partie une solution logicielle de la société Vignette qui permet d’automatiser un ensemble de traitements localisés. Si on va sur le site de l’éditeur, ce logiciel est présenté comme étant un ETL. Mais comme nous le verrons dans la suite de part ses caractéristiques il s’assimile davantage à un EAI tactique. La frontière entre les ETL et les EAI n’est pas très nette et nombre d’ETL et d’EAI présentent les mêmes fonctionnalités. Une chose est sûre  : il est préférable, pour des raisons marketing, de mettre en avant les fonctionnalités ETL de ces produits, les ETL ayant la réputation d’être beaucoup plus stables que les EAI.

           

Cet outil se compose d’un environnement de développement VBIS (Vignette Business Intégration Studio). 

Il permet d’intégrer des applications d’entreprise, des procédures et de l’information de façon rapide. Il offre des possibilités d’intégration et d’unification des systèmes d’information d’entreprise.

Il est possible d’intégrer de l’information à partir - ou vers - des applications, des entrepôts de données ou d’autres sources de données présentes à l’intérieur ou à l’extérieur de l’entreprise.

 

Caractéristiques

 

A l’aide d’une interface graphique simple, il permet de réduire les temps de développement, de recette et de déploiement et donc de réduire les coûts liés à la mise en œuvre et à la maintenance des applications.

 

L’environnement graphique permet le développement de programmes à l’aide d’adaptateurs sans la moindre ligne de code.

Les adaptateurs sont associés aux diagrammes de flux. Les diagrammes de flux qui forment les processus d’adaptation sont exécutés comme une séquence d’étapes. Il existe donc un ordre d’exécution entre eux. Les adaptateurs correspondent aux étapes, et la direction des connexions entre les adaptateurs détermine de quelle façon les étapes sont exécutées. L’exécution des diagrammes de flux est contrôlée à l’aide de ports de contrôle tels que l’exécution port qui prend la valeur true ou false. Si une valeur false est levée, les adaptateurs qui suivent ne sont pas exécutés.

Un diagramme de flux particulier est associé à l’exécutable pour indiquer  le premier diagramme de flux  à exécuter. L’ensemble des diagrammes de flux est regroupé au sein d’un projet.

 

L’environnement se compose :

  • d’une fenêtre des librairies d’adaptateur
  • de fenêtres permettant l’édition des diagrammes de flux
  • d’une fenêtre projet

 

Ces adaptateurs peuvent être testés à l’aide de VBIS. Le débuggeur permet de gérer des points d’arrêt, de suivre pas à pas les opérations, les valeurs, de visualiser et de se déplacer entre différents niveaux des diagrammes de flux. 

 

 

Librairies des Adaptateurs

 

Les adaptateurs se présentent sous forme de modules. Ils permettent de se connecter à des applications d’entreprise spécifiques et à diverses sources d’information. Il existe des adaptateurs pour de nombreuses applications et plateformes. Ils permettent d’intégrer diverses applications d’entreprise (ERP, CRM, système back office), applications gros système, bases de données et autres entrepôts de données internes ou externes à l’entreprise. Il existe également des adaptateurs spécialisés pour de nombreux standards : COM, EDI, EJB, FTP, Flat Files, HTTP, CORBA (Iona Orbix), JavaBean, JDBC, JMS, LDAP, ODBC, SNMP et XML (Figure 21).

 

 

 

Un ensemble d’adaptateurs est disponible afin de contrôler les flux et la logique, de surveiller et de gérer les erreurs des processus d’intégration et des applications. Ce qui permet  d’implémenter la logique « métier » de façon graphique.

Il est possible de réutiliser les processus d’intégration en tant qu’adaptateurs à l’intérieur d’autres processus d’intégration. On peut ainsi imbriquer les procédures « métier ».

 

 

            Figure 21 : Différentes librairies d’adaptateurs existants 

 

Ces adaptateurs permettent de connecter un large panel de composants, de systèmes et d’applications. Il est donc possible de gérer des flux de données et de les contrôler au travers d’applications et de sources de données.

Les Processus

 

            Les processus sont élaborés à l’aide de diagrammes de flux. Les diagrammes de flux sont des programmes composés d’éléments visuels (adaptateurs et autres diagrammes de flux) connectés les uns aux autres pour tenir compte de flux de données et de contrôles au travers des applications et des sources de données. Les diagrammes de flux fournissent une méthode simple et rapide d’accéder à l’information existante et de la transformer. VBIS se compose d’un ensemble d’éléments visuels qui correspondent à des données, des applications et des opérations.

Les éléments fournissent des informations sur la façon dont ils sont exécutés. Il est possible de surveiller les adaptateurs, de déterminer si un adaptateur s’exécute, de jauger la progression par rapport à un but connu, de détecter les erreurs, de mesurer la performance, de récolter des statistiques et d’effectuer des audits.

Ils permettent également de visualiser la façon dont se propage l’information entre les applications.

            Les adaptateurs sont les éléments fondamentaux des diagrammes de flux, on peut sélectionner des méthodes sur ces adaptateurs afin d’effectuer des opérations spécifiques. Les adaptateurs peuvent avoir plusieurs méthodes mais on ne peut en sélectionner qu’une seule à la fois.

            Les adaptateurs sont connectés à l’aide de ports. Un port peut recevoir des entrées d’un autre adaptateur et envoyer des sorties vers d’autres ports. Dans le cas de l’adaptateur d’accès aux bases de données via ODBC, les ports correspondent aux colonnes d’une table relationnelle.

            Un port peut être obligatoire ou optionnel, recevoir ou envoyer une ou plusieurs valeurs à la fois. Les connexions entre les ports sont représentées par des flèches.

 

 

Flexibilité de déploiement

 

Le déploiement des projets, une fois réalisés, est très souple. Il est possible de déployer les processus d’intégration de contenu sous la forme de programmes Java standards (EJB, JavaBean,.jar), ou de programmes Windows (COM,.exe), ou de services Web, sur des systèmes d’exploitation variés, sans écrire de code. Un même diagramme de processus d’intégration peut être déployé sous de multiples formes dans de multiples environnements d’exploitation, sans changement. Il n’est pas nécessaire de gérer la complexité de l’implémentation.

 


 

Comparatif ETL /EAI

 

ETL et/ou EAI

 

Il existe aujourd’hui plusieurs types d’outils sur le marché de l’intégration de données. Les deux principales catégories qui sont utilisées pour implémenter les échanges de données sont les outils ETL et EAI. Les architectures des ETL et des EAI partagent de nombreux concepts communs. Cependant, ils correspondent à des besoins « métier » différents et offrent des fonctionnalités spécifiques. En général, les ETL sont des solutions de traitement automatique d’échange de données axées sur des données techniques et travaillant principalement avec des RDBMS (Relational DataBase Management System).

 

D’un autre côté, les outils d’EAI sont considérés comme des solutions d’échange de données en temps réel, axées  sur des données « métier » et qui travaillent principalement avec des MOM (Message Oriented Middleware).

 

Cependant, les deux catégories de produits ont souvent affaire aux mêmes données et implémentent les mêmes règles « métier ».

 

GENIO est un ETL qui offre un certain nombre d’extensions provenant des EAI en proposant un certain nombre d’adaptateurs à diverses applications d’entreprises. Il permet d’éviter dans une certaine mesure de se doter d’une solution ETL et d’une solution EAI distinctes.

 

Plusieurs cas de figures peuvent faire en sorte que l’on ait recours à un EAI tactique en complément d’un ETL tel que GENIO.

En effet, la bibliothèque d’adaptateurs proposée permet de se connecter à diverses solutions du marché mais est moins riche que celle des EAI. On peut donc être obligé de se doter d’une solution EAI, en plus de cet ETL, afin de bénéficier d’adaptateurs correspondant à des applications qui ne sont pas proposées par l’ETL.

 D’autre part, GENIO peut ne pas permettre de gérer pleinement les besoins d’intégration d’applications dans le cas où l’on souhaiterait mettre en œuvre des programmes, sous forme d’exécutables, manipulant des données sans vouloir utiliser de langage de programmation.

 

 

ETL

 

Traditionnellement, les ETL permettaient d’extraire, de transformer et de charger des données en mode batch, afin d’alimenter des entrepôts de données utilisés par des applications décisionnelles.

            Par contre, la nécessité d’augmenter les fréquences de rafraîchissement de l’information qui se rapprochent de plus en plus du temps réel, fait que les ETL répondent désormais à des problématiques plus larges d’intégration de données, à la fois batch et en temps réel. Ils se rapprochent ainsi des problématiques traitées par les EAI.

           

 

 

Les ETL sont utilisés pour les mouvements de données en mode batch, principalement pour :

    • le chargement des Datawarehouse

 

    • les opérations de réplication et de migration entre bases de données

 

    • la mise à disposition de données auprès de systèmes décisionnels

 

    • l’intégration de données hétérogènes plutôt en mode batch mais parfois en temps réel

 

    • l’analyse préalable des données afin d’obtenir des statistiques sur la fiabilité des données. On peut vouloir déterminer le type des données ou les index utilisés pour y accéder. On caractérise alors les données par un profil.

 

    • gérer la qualité des données. On peut rediriger des erreurs dans des tables d’anomalies en vue de les retraiter.

 

 

Même si les ETL et EAI ont tendance à converger sur certains aspects, il existe cependant des différences importantes entre ces deux catégories de produit.

 

 

EAI

 

Les EAI permettent de résoudre l’hétérogénéité du Système d’Information en intégrant et en faisant collaborer les différentes applications ou progiciels.

 

Il est possible d’intégrer des données en temps réel. La mise en correspondance des formats d’entrée et de sortie se fait à l’aide de graphiques.

 

 Avec un EAI on peut gérer des données de référence de façon cohérente et unifiée, et inclure dans les processus « métier » des validations d’utilisateurs par le biais de workflow.

 

Certaines solutions EAI permettent également de gérer des cadres d’échange pour chaque type de partenaire de l’entreprise afin de répondre aux besoins d’intégration inter entreprise.


            Les EAI proposent trois grandes couches de services :

 

    • le transport et la connectivité :  ils proposent une large bibliothèque de connecteurs permettant de relier la plupart des grands progiciels ERP et CRM du marché.

 

    • le routage et la transformation : transformer un format de donnée d’une application source en un format compréhensible par l’application cible.

 

    • BPM (Business Process Management) : permet de se détacher de la technique et de voir les processus sous un angle « métier ».

 

 

 

Tableau comparatif

 

Les deux familles de produit que sont les EAI et les ETL tentent toutes deux de répondre aux problématiques d’intégration des données hétérogènes en temps réel et aux problématiques de gestion des données de références MDM ( Master Data Manager). Ce sont les deux problématiques sur lesquelles ces produits se recouvrent.

           

L’ETL, initialement mis en œuvre pour extraire des données de production, les transformer et les charger dans un Dataware house en mode batch, peut aujourd’hui récupérer en instantané les données dans les systèmes de production (ERP, CRM) ou être utilisé dans des problématiques de migration d’applications, d’urbanisation ou d’homogénéisation du Système d’Information.

           

De plus, les Datawarehouse deviennent une application du Système d’Information comme une autre à partir de laquelle on peut répercuter des changements dans le système de production et ainsi modifier les données de départ.

 

Les EAI, quant à eux, évoluent pour devenir la plate forme constitutive de nouvelles architectures orientée service (SOA) auprès des annuaires de services, avec l’intégration dans un portail et via l’orchestration des services grâce aux couches de BPM.  

 


 

Tableau 8 : Comparatif des caractéristiques EAI/ETL d’un point de vue général

Caractéristiques

EAI

ETL

Orientation

Orienté Processus

Orienté Données

Principe

Basé sur la mise en œuvre de règles « métier »

Basé sur la mise en correspondance de schémas de données différentes

Volumétrie gérée à l’aide de l’outil

Volumétrie faible de l’ordre de 100 000 enregistrements dans le cas de VBIS afin d’obtenir des temps d’exécution raisonnables

Capable de gérer des volumétries importantes de données. De l’ordre de plusieurs millions d’enregistrements dans le cas de GENIO.

Possibilité d’analyse des données

les EAI étant basés sur une approche orientée « métier », ils ne permettent pas d’analyser les types des données et les index utilisés

Reposant sur la mise en correspondance de schémas de données, des possibilités d’analyse des données sont offertes par les ETL.

Gestion de la qualité des données 

Certaines possibilités existent mais sont très limitées

Il est possible de nettoyer les données et de mettre en place des mécanismes de gestion des erreurs.

Possibilité de transformation des données

Il existe des fonctions simples permettant de transformer de l’information. Les possibilités d’agrégation des données sont limitées

Les fonctions de transformation et d’agrégation des données sont plus nombreuses et plus élaborées.

Possibilité d’utilisation de format PIVOT

Possible

Possible

Gestion des Méta-données

Possible

Possible

Gestion des données de références

Pas encore couvert

Pas encore couvert

Connecteurs progiciels

Il existe de nombreux connecteurs

Quelques connecteurs mais moins nombreux que dans le cas des EAI

Bus d’échange et de transformation

Possibilité

Possibilité

Gestion des processus « Métier »

BPM

Possible dans certains EAI mais pas dans le cas de VBIS

Non significatif

Intégration inter entreprise

Possible

Non significatif

Rafraîchissement

Temps réel asynchrone

Essentiellement batch

 

 

 


 

2.5.         Organiser une application J2EE 

 

Comment organiser une application WEB ?

 

J2EE

 

J2EE est une plateforme, c’est à dire une base générique qui fournit un ensemble de fonctionnalités utilisables dans une majorité d’applications. Les développeurs ont à leur disposition un ensemble d’outils qu’ils n’ont pas besoin de concevoir eux même.

 

J2EE,  qui signifie Java 2 Enterprise Edition, est une norme proposée par la société Sun. Elle a été adoptée par de grands groupes mondiaux tels que : IBM, Oracle, BEA …


            Existant depuis 1998, elle est stable et fiable. Elle évolue constamment. Sun a mis en place un système de spécifications permettant d’être à l’écoute des besoins, des propositions ou critiques des développeurs.

 

L’utilisation de Java permet de rendre les applications totalement indépendantes de la plateforme système utilisée.  Une même application peut aussi bien tourner sous Windows que sous Unix.

 

De plus, les développements ont l’avantage d’être plus facilement maintenables que d’autres langages tels que le C par exemple.

 

J2EE comprend les spécifications du serveur d'application [JOU05b] (son environnement d'exécution).

 

Services

 

La plateforme propose des services offrant un certain nombre de fonctionnalités au travers d’API. Les API présentent l’avantage d’être faciles à prendre en main. Elles permettent de cacher la complexité d’accès aux ressources et donc de gagner considérablement du temps. Les développeurs peuvent ainsi consacrer plus de temps aux aspects « métier ».

 

Il existe deux types de services : des services d’infrastructure et des services de communication. Les deux tableaux suivants décrivent les différentes API de chacun de ces types. 

 


 

Services d’infrastructure

 

Tableau 9 : Services d’infrastructure

Nom de l’API

Description

JDBC - Java Database Connectivity

API d’accès aux bases de données. Son utilisation diminue le nombre de lignes de code à écrire. De plus, les accès peuvent être optimisés à l’aide des pools de connexions fournis par les serveurs d’application.

JNDI

API d'accès aux services de nommage et aux annuaires d'entreprises (DNS, NIS, LDAP, …).

JTA / JTS - Java Transaction Api / Java Transaction Services

API définissant des interfaces standards avec un gestionnaire de transactions.

JCA (J2EE Connector Architecture)

API de connexion au Système d'Information de l'entreprise (ERP…).

JMX (Java Management eXtension)

API permettant de développer des applications WEB de supervision d'applications.

 

Services de communication

 

Tableau 10 : Services de communication

Nom de l’API

Description

JAAS (Java Authentification and Authorization Service)

API de gestion de l'authentification et des droits d'accès.

RMI (Remote Method Invocation)

API permettant la communication synchrone entre objets.

Web Services

permettent de « partager » un ensemble de méthodes qui pourront être appelées à distance. Cette technologie utilise XML, ce qui permet de l’employer avec n’importe quel langage et n’importe quelle plateforme.

JMS (Java Message Service)

API fournit des fonctionnalités de communication asynchrone (appelées MOM pour Middleware Object Message) entre applications.

JavaMail

API permettant l'envoi de courrier électronique.

 

Composants

 

J2EE repose sur des composants. Ce qui permet :

    • d'étendre l'architecture de façon simple
    • d’obtenir une bonne qualité de service par la mise en place de mécanismes de haute disponibilité
    • de faciliter la maintenance des applications

 

 

 

On  peut distinguer 2 catégories de composants : les composants Web et les composants « métier ».

 

Composants Web

 

Les composants Web correspondent à la partie présentation d’une application. Ils permettent d’implémenter des Interfaces Homme Machine (IHM) et les traitements qui leur correspondent.

 

Pour permettre d’avoir un code performant, robuste et maintenable, différentes technologies sont utilisées telles que les JSP et les servlets.

 

            JSP signifie Java Server Page. Ces pages servent à générer le code HTML de l’IHM. On peut utiliser dans ces pages des scriplets Java ou des balises personnalisées.

 

            Les Servlets sont des classes Java qui permettent le traitement des requêtes utilisateurs.

 

Composants Métier

 

Ils sont chargés des traitements des données propres à un secteur d'activité. Ils doivent également assurer l'interfaçage avec les bases de données. Les EJB (Entreprise JavaBean) sont un exemple de composant « métier ».

 

Les composants standards que nous venons de voir peuvent parfois être assez lourds à utiliser. Ils sont conçus pour de grandes architectures et peuvent être mal adaptés aux applications moins importantes.

 

On peut alors utiliser des frameworks servant à simplifier l’utilisation des technologies standards. Ils sont souvent plus limités, mais leur utilisation est plus simple.

 

 

 

 

 


 

Architecture basique d’une application

 

Figure 22 : Exemple d’architecture basique d’application

 

 

Cette architecture permet de décomposer le système en sous-systèmes. Elle se compose de 5 couches :

 

  • Client

 

C’est l’interface utilisateur (HTML, WML, PDA…). Du fait qu’elle ne gère pas les règles fonctionnelles, on peut la faire évoluer facilement.

 

  • Application

 

Elle permet de traiter le fonctionnel de l’application. Elle utilise les services de la couche Entreprise. La couche Application permet de gérer le fonctionnel spécifique à partir de vues d’objets « métier ». Elle peut être implémentée à l’aide de Servlets ou de Web Services.

 

 

 

 

  • Entreprise

 

Elle correspond aux objets structurants de l’entreprise. Ces objets sont transversaux à toute l’entreprise. Elle propose des services d’accès aux objets au travers de méthodes de création, de modification, de suppression et de recherche. On peut utiliser des classes DAO ou EJB.

 

  • Mapping

 

Cette couche est liée à la structure des données. Dans le cas d’un SGBDR, on utilise un outil de mapping relationnel objet tel que Hibernate.

 

  • Physique

 

Cette couche correspond à la structure physique des données : SGBD tel que ORACLE, CICS, LDAP

 

            Le schéma ci-dessus (Figure 22) est un exemple d’architecture d’application basique. Cette architecture n’est pas générique. Elle est adaptable en fonction du projet que l’on a à mener. Les noms utilisés pour les différentes « couches » peuvent varier suivant les personnes. On peut trouver le terme de couche de Présentation pour désigner la couche gérant l’interface homme / machine. La couche « métier » est également appelée « couche  de Domaine ».

L’architecture que nous utiliserons (Figure 23)  est simplifiée par rapport à cette version basique.

Elle comporte :

·        une couche Présentation

·        une couche DAO

·        une couche Physique

Figure 23 : Architecture utilisée

Dans les sections suivantes, nous allons détailler la couche Application & Présentation et la couche « métier ».

Couche Application & Présentation

 

Cette couche est très liée au type de client utilisé.

 

Lorsque l’application n’a pas besoin d’utiliser des composants très spécifiques, on met en place des applications WEB avec un client léger pour les utilisateurs. Il est en effet très simple de générer les interfaces de façon rapide à l’aide d’HTML.

 

L’inconvénient de l’utilisation de client léger peut être que, dans certains cas, les flux réseaux sont beaucoup plus importants qu’avec une solution basée sur un client riche. Il est alors nécessaire de palier à cet inconvénient en recourant à un réseau possédant des débits plus importants.

 

La couche Application ne constitue pas toujours une couche indépendante. Elle sert à assurer la communication entre la couche Présentation et la couche « métier ». Elle permet également de contrôler l’enchaînement des différentes tâches. Elle a la charge de connaître l’état des sessions des clients. Dans notre cas nous parlerons uniquement de couche Présentation pour désigner la couche prenant en charge les interfaces utilisateurs.

 

            Pour mettre en œuvre cette couche, il existe deux possibilités :

 

·        Utiliser les Servlets et les JSP

 

Ceux sont des composants de bas niveau qui n’offrent que des fonctionnalités de base. Les Servlets serviront de « Contrôleur ». Ils devront exécuter les traitements liés aux requêtes utilisateurs, ainsi que les appels aux modèles « métier ».

Les JSP permettront de gérer la partie présentation en générant du HTML à envoyer au client. Elles ne devront avoir qu’un minimum de code Java afin d’être optimales.

 

·        Utiliser un framework

 

On peut par exemple utiliser le framework Struts qui repose sur une architecture MVC (Model View Controller) [FEL06]. Ce framework est basé sur les Servlet / JSP. A l’aide de cette architecture MVC, le travail du développeur est simplifié.

 

Couche Métier

 

Dans le cas d’applications importantes et si l’on doit utiliser un ensemble de clients très différents tels que des clients WEB, clients riches ou des clients programmés avec des langages divers et variés,  l’utilisation des Entreprise JavaBean (EJB) peut être utile.

Cependant, si l’application WEB n’a besoin que d’un seul type de client, on pourra alors utiliser des solutions plus légères telles que Hibernate.

 

 

 

 

Design Patterns

 

Les patterns - ou modèles de conception - permettent de répondre à un problème particulier [FRE06]. Le principal intérêt des patterns est de permettre la manipulation d’artefacts plus élaborés que les objets et les classes. Ils augmentent la force d’expression des langages de modélisation.

Le concepteur d’un pattern propose une solution générique pour un problème donné, qui est souvent rencontré dans divers développements. Cette solution est présentée sous une forme indépendante d’un langage de programmation particulier, ce qui oblige de l’implémenter pour une application donnée.

 Il existe un nombre important de patterns. Ils apportent  généralement des solutions aux problèmes critiques. Mais une bonne compréhension de ces derniers est nécessaire afin de ne pas les utiliser dans de mauvaises conditions.

Ils sont généralement représentés sous forme de diagramme UML [ROQ06].

 

Lors de la mise en place d’une application, on est amené à utiliser un certain nombre de patterns. Nous allons maintenant voir les patterns qui ont été employés dans le cadre de la mise en place de l’application merchandising :

 

  • MVC 2
  • DAO
  • Abstract factory
  • Singleton



MVC 2

 

MVC est l'abréviation de Model View Controller. Le modèle MVC est  plutôt un Architectural Pattern qu’un Design Pattern. Il concerne l'architecture globale d'une application et non pas une de ses fonctionnalités.

 

MVC organise une application interactive en trois modules séparés. Un premier module permet de gérer le modèle de l’application, la représentation des données et la logique du métier. Un second module permet de gérer les vues qui présentent les données à l’utilisateur et recueillent ses saisies. Le dernier module est un contrôleur qui achemine les requêtes et les flux de contrôle.

 

En utilisant dans nos développements le Framework Struts, nous nous intéresserons à la version 2 de ce modèle (Figure 24) qui a été proposée pour la première fois par Sun Microsystem : MVC 2. La différence entre les deux versions est essentiellement due au fait que dans la seconde version le contrôleur est unique, alors que dans la première il existait une multitude de contrôleurs.

 

Dans l’approche MVC 2, 

Le Modèle correspond à des JavaBean

Les Vues sont des pages JSP 

Le Contrôleur est un servlet unique

 

 

 

 

 

Figure 24 : MVC version 2 adapté au développement Web

  1. L'utilisateur envoie une requête à l'application à l’aide de son navigateur. Il déclenche une action.
  2. Le Contrôleur reçoit la requête, l'analyse et effectue l'opération sur le Modèle.
  3. Il fournit ce Modèle à la Vue.
  4. La Vue se met à jour en utilisant le Modèle.
  5. La Vue est envoyée à l'utilisateur en réponse à sa demande initiale.

 

DAO ( Data Access Object)

 

Le pattern DAO permet de regrouper les différents modes d’accès aux données persistantes : stockées en base de données, dans des fichiers, dans des annuaires … Ces modes d’accès sont gérés dans des endroits bien distincts de l'architecture et non pas dispersés dans toute l’application.

 

De cette manière, le changement du mode de stockage ne remet pas en cause le reste de l'architecture. Mais cette souplesse a pour inconvénient de rendre la mise en oeuvre des appels plus complexe.


Le schéma suivant présente le pattern (Figure 25).

 

 

 

 

 

 

 

 

 

 


Figure 25 : Design pattern DAO (Data Access Object)

 

 

Abstract Factory (Fabrique Abstraite)

 

            Le pattern Fabrique Abstraite fournit une interface pour créer des familles d’objets apparentés ou dépendants sans avoir à spécifier leurs classes concrètes (Figure 26).

            Le client est découplé de tous les détails des produits concrets.

            Les fabriques concrètes implémentent les différentes familles de produits.

Pour créer un produit, le client utilise l’une de ces fabriques.

Il n’a donc jamais besoin d’instancier un objet produit.

Les méthodes de la fabrique permettant de récupérer un produit doivent renvoyer le type d’interface et pas le type de la classe d’implémentation.


 

Figure 26 : Design Pattern fabrique abstraite



 

Singleton

 

            Le singleton est une classe pour laquelle on ne souhaite créer qu’une seule et unique instance pendant toute la durée de l’exécution de l’application. Pour cela, on limite les accès au constructeur qui est déclaré comme privé (private). On implémente une méthode static nommée par convention getInstance() pour obtenir une instance de la classe.

 

 

Frameworks

 

            Un framework est une ossature générale pour le développement d’une application dans un domaine particulier.

            Les frameworks facilitent le travail du développement en fournissant un squelette d’application qu’il suffit de remplir pour l’adapter à ses besoins. Un framework est une surcouche de tous les besoins génériques. On est obligé de supporter un grand nombre de choses même si l’utilisation que l’on en fait est réduite.  De plus, du fait de l’ajout de cette surcouche, le temps pris par le développeur pour monter en compétence sur l’environnement sera plus important. 

 

 


 

 

Struts

 

Struts est un projet Open Source très populaire. De nombreuses entreprises l’utilisent. Il existe énormément de livres, articles, tutoriaux traitants de Struts. Les développeurs l’utilisant bénéficient donc d’une base d’information importante.

Struts peut être assimilé à une surcouche de Servlet/JSP. Il comble une bonne partie des lacunes du modèle Servlet/JSP.

Il s'appuie sur MVC version 2. Il met à disposition un ensemble d’outils destinés à organiser de façon simple le modèle MVC au sein d’une application WEB. Il permet de centraliser la navigation du site à un seul endroit. Le comportement de la totalité de l’application WEB est donc configuré dans un seul fichier. Ce fichier, nommé struts-config.xml, est au format XML et est placé dans le répertoire WEB-INF de l'application.


Ce fichier manipule 3 types d'éléments:

 

  • Les ActionForms :

 

Elles étendent la classe org.apache.struts.action.ActionForm. Elles servent essentiellement de contenant et sont utilisées par le Contrôleur et les Vues. On peut les considérer comme étant des "JavaBeans" spécialisés.

 

  • Les Actions :

 

Elles étendent la classe org.apache.struts.action.Action. Elles héritent d'une méthode execute(...) dans laquelle est placé le code à exécuter. Il existe des actions pré-définies pour effectuer des traitements courants tels que les uploads de fichier.

 

·         Les Forwards :

 

Ils étendent la classe org.apache.struts.action.ActionForward. Lorsque l'action a terminé ses traitements, ils permettent de déterminer la page vers laquelle l'utilisateur doit être redirigé.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Cycle requête /réponse

 


Figure 27 : Cycle requête/réponse classique

 

Nous allons maintenant voir un cycle requête/réponse classique avec Struts (Figure 27):

  1. L’utilisateur envoie une requête HTTP à l’aide de son navigateur. Le contrôleur unique, qui est en fait un servlet, intercepte la requête HTTP.
  2. Le contrôleur sélectionne un ActionForm. Les données de la requête HTTP permettent alors de renseigner l’ActionForm.
  3. Le contrôleur sélectionne une action à exécuter et lui fournit l'ActionForm.
  4. L'action utilise l'ActionForm pour mettre à jour le modèle.
  5. En fonction du résultat, l'action sélectionne la page JSP à retourner. Elle fournit ensuite l'ActionForm correspondant à la page JSP.
  6. La page JSP se génère en utilisant l'ActionForm.
  7. L'utilisateur reçoit le résultat de sa demande.

 

 

Les Tiles

 

 

Dans une application Web, l’ensemble des pages possède en général un élément central variable entouré d’éléments plus ou moins statiques : barre de navigation, en-tête, colonnes à gauche …

La bibliothèque Tiles est un plug-in intégrable à Struts. Elle permet de créer des modèles de page réutilisables pour l’ensemble de l’application à l’aide d’un document XML central.
Cette bibliothèque peut également être utilisée indépendamment de Struts.

 

Hibernate

 

Hibernate est un framework Open Source permettant de gérer la couche d’accès aux données [BAU05] [PAT05] [ARN05]. Il est complémentaire au framework Struts qui lui gère l’Interface Homme Machine.

 




Figure 28 :  Schéma simplifié du fonctionnement d'Hibernate

 

 

 

Il facilite le travail entre les deux univers que sont l'orienté objet et la base de données relationnelle (Figure 28). Il joint ces deux univers, à travers le mapping objet/relationnel. Le mapping objet/relationnel ou ORM sert à faire le lien entre la représentation objet des données et sa représentation relationnelle.

 
Hibernate
 s'occupe du transfert des classes Java dans les tables de la base de données. Il permet également de mettre en correspondance des types de données Java avec les types de données de la base de données relationnelle. De plus, il propose des moyens de requêter et de récupérer les données.

 
Hibernate
 est assimilable à une surcouche de JDBC qui permet d’ajouter une dimension objet.

 

 



 

 

 

 

 

 


 

Outils de développement

 

Eclipse