La business Intelligence Agile

1 452 vues

Publié le

C'est un rapport

Publié dans : Ingénierie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 452
Sur SlideShare
0
Issues des intégrations
0
Intégrations
184
Actions
Partages
0
Téléchargements
63
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

La business Intelligence Agile

  1. 1. Mémoire de Master –Partie Etude Bibliographique- Pour l’obtention du diplôme Master de recherche en Informatique Option : Systèmes d’Information et Technologies Thème Réalisé par : Encadré par : Mlle. BEKKOUCHE Salma Mme. KHOURI Selma Mlle. LANASRI Dihia Mr. BOUZIANI Lotfi Promotion: 2014/2015 Étude de la conception des projets BI selon les principes Agiles République Algérienne Démocratique et Populaire ‫الشــعبية‬ ‫الديمــقراطيــة‬ ‫الجــزائريــة‬ ‫الجـمهوريــــة‬ Ministère de l’Enseignement Supérieur et de la Recherche Scientifique ‫وزارة‬‫العلـــم‬ ‫البــحث‬ ‫و‬ ‫العــالي‬ ‫التـعليـم‬‫ي‬ ‫المدر‬‫س‬‫اآللي‬ ‫لإلعالم‬ ‫العليا‬ ‫الوطنية‬ ‫ة‬ ) ‫سابقا‬ ‫اآللي‬ ‫اإلعالم‬ ‫في‬ ‫للتكوين‬ ‫الوطني‬ ‫المعهد‬ ( Ecole nationale Supérieure d’Informatique Ex.INI (Instituts National de formation en Informatique)
  2. 2. II Sommaire Liste des figures .............................................................................................................................................IV Liste des tableaux..........................................................................................................................................IV Liste des abréviations..............................................................................Erreur ! Signet non défini. 1. Qu’est-ce que l’informatique décisionnelle? ................................................................................6 2. Historique de l’informatique décisionnelle..................................................................................6 3. Objectifs de l’informatique décisionnelle dans une organisation........................................7 4. L’architecture d’un système décisionnel.......................................................................................8 4.1. Sources de données............................................................................................................................8 4.2. ETL (Extraction, Transformation and Loading) .....................................................................8 4.3. Entrepôt de données .........................................................................................................................9 4.3.1. Entrepôt de données (Data Warehouse)...........................................................................9 4.3.2. Magasin de données (Data Mart)..........................................................................................9 4.4. Outil de restitution et d’analyse de données...........................................................................9 4.4.1. Tableau de bord........................................................................................................................10 4.4.2. Reporting ....................................................................................................................................10 4.4.3. Analyse multidimensionnelle (OLAP)..............................................................................10 4.4.4. Recherche corrélative............................................................................................................11 5. Modélisation dimensionnelle..........................................................................................................12 5.1. Les composantes d’un schéma dimensionnel..................................................................12 5.1.1. Table de Faits.......................................................................................................................12 5.1.2. Table de Dimension : ........................................................................................................12 5.2. Les types de schéma dimensionnel......................................................................................12 5.2.1. Schéma en étoile.................................................................................................................12 5.2.2. Schéma en flocon de neige..............................................................................................13 5.2.3. Modèle en constellation...................................................................................................13 6. Méthodes classiques de développement d’un projet décisionnel ....................................14 6.1. La méthode de Kimball.............................................................................................................14 6.2. La méthode d’Inmon ......................................................................................................................15 7. Comparaison entre les deux méthodes.......................................................................................16 Conclusion.......................................................................................................................................................17 1. Définition de Méthodologie de développement agile............................................................19
  3. 3. III 2. Manifeste agile..........................................................................................................................................19 3. Principes de développement Agile................................................................................................20 4. Caractéristiques des méthodes Agiles.........................................................................................20 5. Méthodes Agiles ...................................................................................................................................21 5.1. Scrum...............................................................................................................................................21 5.2. Extreme Programming (XP)........................................................................................................22 5.3. Dynamic System Development Method (DSDM)............................................................22 5.4. Feature-Driven Development (FDD)...................................................................................23 5.5. Lean Development (LD)..............................................................................................................24 5.6. Adaptive Software Development (ASD).............................................................................24 Conclusion.......................................................................................................................................................25 Références Bibliographiques et webographiques...........................................................................26 Thèses...........................................................................................................................................................26 Articles .........................................................................................................................................................27 Livres ............................................................................................................................................................28 Références Webographiques...............................................................................................................28
  4. 4. IV Liste des figures Figure 1: L’infocentre [CORBILLE et al, 2006]....................................................................................6 Figure 2: Le Système Décisionnel [CORBILLE et al, 2006].............................................................7 Figure 3: Architecture d’un système décisionnel [TOURNIER 2007] .........................................8 Figure 4: Modèle de pilotage d’un système : utilisation d’une boucle de rétroaction pour modéliser le pilotage d’un système [FERNANDEZ 2013]...........................................................10 Figure 5: Analyse des ventes d’une chaine de magasin informatique (vision cubique) [TOURNIER 2007].......................................................................................................................................11 Figure 6: Exemple d'un schéma en étoile [KHOURI 2008].........................................................13 Figure 7: Exemple d'un schéma en flocon de neige [KHOURI 2008] ......................................13 Figure 8: Le cycle de vie d’un projet décisionnel [KIMBALL et al, 2013] ...............................14 Figure 9: Le cycle de vie d’un projet décisionnel selon la méthode Inmon [INMON 2002] .............................................................................................................................................................................16 Figure 10: Le schéma global de Scrum (Reproduit) [DASGUPTA et al, 2007].....................22 Figure 11: Cycle de vie de la méthode DSDM [GORAKAVI et al, 2009] ...................................23 Figure 12: Cycle de vie de la méthode FDD [PALMER et al, 2002]............................................24 Liste des tableaux Tableau 1: Comparaison entre les approches Kimball et Inmon [BRESLIN 2004].............17
  5. 5. 5 Chapitre 1 L’informatique décisionnelle L’information est devenue une ressource stratégique pour les entreprises, c’est pourquoi ces dernières s’intéressent au management de leur capital informationnel. Les entreprises manipulent une masse colossale de données issues de différentes sources, afin de pouvoir analyser ces données, se doter d’un système décisionnel est considéré comme un moyen primordial. La réalisation d’un système décisionnel passe par un cycle de vie spécifique en cascade qui peut reposer sur une des deux méthodes : Kimball ou Inmon. Dans ce qui suit, nous allons aborder les principes généraux de l’informatique décisionnelle, suivis d’une comparaison entre les deux méthodes classiques de développement BI.
  6. 6. Chapitre 1 :L’informatique décisionnelle 6 1. Qu’est-ce que l’informatique décisionnelle? La Business Intelligence (BI) en Anglais ou le système décisionnel, l’informatique décisionnelle sont des appellations différentes pour un même concept. L’informatique décisionnelle est : « l’ensemble des outils informatiques (matériels et logiciels) qui permettent l’analyse des données opérationnelles issues du système d’information des entreprises. Ces données sont transformées en une vision orientée décideur puis analysées au moyen de manipulations et de restitutions adaptées». [TOURNIER 2007] 2. Historique de l’informatique décisionnelle Selon [GAM El GOLLI 2008], les systèmes décisionnels ont connu une certaine évolution, les grandes entreprises ont été les premières à utiliser ces systèmes pour manipuler la quantité énorme de données opérationnelles. Dans ce qui suit, nous présentons un petit aperçu sur l’évolution de l’informatique décisionnelle: Années 70-80 ‘L’infocentre’: l’infocentre1 nait pour répondre au besoin de stockage de données. Pour faire des analyses, les informaticiens suivent un processus qui consiste à se poser des questions sur une situation, et la réponse à cette question induit à une autre jusqu’à obtenir un rapport d’analyse de cette situation. Figure 1: L’infocentre [CORBILLE et al, 2006] 1 Infocentre : concept lancé par IBM en 1980, il permet aux utilisateurs d’accéder à leurs données dans leurs propres termes [ROUX 1991]
  7. 7. Chapitre 1 :L’informatique décisionnelle 7 Années 90 ‘EIS’ : EIS2 (Executive Information System) proposent les premiers tableaux de bord mais malgré ça, les systèmes se retrouvent surchargés et ne satisfont pas les besoins des décideurs en matière d'informations pertinentes. Fin des années 90 : le Système Décisionnel est devenu basé sur l’utilisation: 1. Des entrepôts de données. 2. Des bases de données multidimensionnelles OLAP. Figure 2: Le Système Décisionnel [CORBILLE et al, 2006] 3. Objectifs de l’informatique décisionnelle dans une organisation Les raisons pour lesquelles les entreprises recourent à un système décisionnel sont communes malgré la variété de leurs domaines d’activités. Selon [KIMBALL et al, 2013] les objectifs d’un système décisionnel sont :  Accessibilité facile et rapide aux informations.  Cohérence des informations : les données du système sont crédibles et de qualité.  Adaptation aux changements : les données existantes doivent généralement rester inchangées. Lorsque la technologie ou les besoins changent, les données doivent être changées en tenant au courant tous les utilisateurs du système.  Présentation des informations à temps : les informations doivent être disponibles au bon moment afin de réagir rapidement.  Protection et sécurisation des informations: le système doit permettre le contrôle d’accès à ces informations confidentielles. 2 EIS : est un système d’information qui permet aux décideurs de récupérer, de façon autonome, les informations nécessaires à la prise de décisions. [KANICLIDES et al, 1994]
  8. 8. Chapitre 1 :L’informatique décisionnelle 8  Conversion de la masse de données en une valeur métier : le système, à travers les outils d’analyse, permet de dégager une valeur qui aide dans la prise de décision. 4. L’architecture d’un système décisionnel Un système décisionnel comprend quatre composantes principales : Figure 3: Architecture d’un système décisionnel [TOURNIER 2007] 4.1. Sources de données Elles sont nombreuses, variées, distribuées et autonomes. Elles peuvent être internes (bases de données de production, ERP (Enterprise Resource Planning), Archives, Feuilles de calcul …) ou externes (Internet, bases des partenaires) à l'entreprise. [TESTE 2000] 4.2. ETL (Extraction, Transformation and Loading) Selon Kimball, les ETL correspondent à une surface de travail, et ils représentent l’intermédiaire entre le système opérationnel et l’interface du système décisionnel. Ils permettent l’extraction des données à partir des sources de données. Ces données subissent une transformation qui peut être un nettoyage, formatage ou standardisation afin de les charger dans l’entrepôt de données.
  9. 9. Chapitre 1 :L’informatique décisionnelle 9 4.3. Entrepôt de données 4.3.1. Entrepôt de données (Data Warehouse) Inmon considère l’entrepôt de données comme « une collection de données orientées sujet, intégrées, non volatiles et évolutives dans le temps, organisées pour le support d'un processus d'aide à la décision. » [INMON 2002] D’après cette définition, on constate que les caractéristiques d’un Data Warehouse sont:  Orienté sujet : les données sont obligatoirement liées au métier de l’entreprise et organisées par fonctions. Exemple : Assurances, Banques, Commerce  Intégré: les données manipulées au niveau d’un Data Warehouse doivent être centralisées pour éviter les anomalies. Le Data Waterhouse intégrera ces éléments pour former une vision unique de l'activité de l'entreprise.  Non volatile : une fois les données sont stockées au niveau d’un Data Waterhouse, les opérations de mise à jour ou de suppression ne sont plus autorisées. L’accès est autorisé uniquement en mode lecture.  Evolutif dans le temps : c’est le fait de garder l’historique des transactions et de pouvoir visualiser leurs évolutions dans le temps. 4.3.2. Magasin de données (Data Mart) Le magasin de donnée qui est un extrait d’un Data Warehouse. Les données extraites sont adaptées à une classe de décideurs ou à un usage particulier [TESTE 2000]. En d’autre termes un Data Mart se focalise sur les données d’un seul département au sein de l’entreprise tel que : Marketing, Vente. 4.4. Outil de restitution et d’analyse de données Pour faciliter l’accès à l’information pour tous les utilisateurs selon leurs profils métiers et afin d’extraire les éléments de décision pour dynamiser la réactivité globale dans l’entreprise, certains outils ont été mis à la disposition des décideurs, on cite :
  10. 10. Chapitre 1 :L’informatique décisionnelle 10 4.4.1. Tableau de bord [MALO 1995] définit le Tableau de bord comme « un outil pour le top-management d'une entreprise qui permet d'avoir une vue globale et synthétique sur l'état des opérations en cours et sur son environnement. » Le décideur dans une entreprise essaye d’atteindre plusieurs objectifs selon le poste qu’il occupe. Selon le schéma présenté ci-dessous, Un objectif correspond à la consigne de fonctionnement du système. Le décideur, a en charge d’adapter la commande de fonctionnement du système selon cette consigne de fonctionnement et les mesures effectuées en fin de boucle. Cette boucle de rétroaction permet de minimiser les écarts entre les mesures réelles et les objectifs à atteindre. [JUGLARET 2012] Figure 4: Modèle de pilotage d’un système : utilisation d’une boucle de rétroaction pour modéliser le pilotage d’un système [FERNANDEZ 2013] 4.4.2. Reporting Le Reporting est : « l’ensemble des comptes rendus permettant à une entreprise de suivre son activité et lui permet de s’évaluer grâce à la création périodique de rapports et de bilans analytiques de son activité. Ces rapports sont souvent destinés au manager ou au corps exécutif. » [POLETTO 2012] Le but de ces rapports et bilans réguliers est de faire un point ponctuel sur la stratégie de l’entreprise et ainsi permettre d’évaluer les moyens mis en œuvre [POLETTO 2012]. Mais ils fournissent également une aide à la décision pour les choix stratégiques et économiques de l’entreprise. 4.4.3. Analyse multidimensionnelle (OLAP) Pour assurer une analyse efficace des données se trouvant dans les entrepôts, ces derniers sont modélisés sous forme multidimensionnelle. Cette modélisation présente les données sous formes de points dans un espace à plusieurs dimensions (appelé cube
  11. 11. Chapitre 1 :L’informatique décisionnelle 11 ou hypercube de données). Cette modélisation permet l’expression d’analyse en ligne (OLAP) multidimensionnelles. [TOURNIER 2007] Exemple : La Figure 5 montre un cube d’analyse des activités d’une chaîne de revendeurs informatiques. Les indicateurs d’analyse liés au métier de vente de cette chaîne sont : « la quantité » et « le montant de vente ». On peut analyser ces indicateurs selon trois dimensions: les magasins de ventes, les Dates de ventes et les Produits vendus. Chaque dimensions est constitué de plusieurs niveaux de détails ce qui assure une analyse détaillée de l’activité. Figure 5: Analyse des ventes d’une chaine de magasin informatique (vision cubique) [TOURNIER 2007] 4.4.4. Recherche corrélative La recherche corrélative ou le Data mining est : « le processus qui permet la découverte de la connaissance. Les outils utilisés dans ce processus partent à la recherche d’hypothétiques associations en explorant un grand volume de données. Quand les associations sont vérifiées, l’outil du data mining les remonte à l’utilisateur.» [FRANCO et al, 2001] Le data mining répond à deux objectifs qui sont :
  12. 12. Chapitre 1 :L’informatique décisionnelle 12  Exploiter autant que possible le capital d’informations disponible et faire sortir les informations cachées.  Constituer des modèles pour découvrir des tendances ou pour anticiper l’avenir en répondant à des questions de type « Que se passerait-il si ? » et « Comment cela évoluera-t-il dans l’avenir ». 5. Modélisation dimensionnelle La conception de l’entrepôt de données est basée sur une modélisation dimensionnelle qui est une technique d’organisation des données dans des bases de données, dans un schéma simple et compréhensible [CHOUDER 2007]. 5.1. Les composantes d’un schéma dimensionnel 5.1.1. Table de Faits Représente le sujet d’analyse. Elle est composée d’un ensemble de mesures qui représentent les différentes valeurs de l’activité analysée. [ENCINAS 2005] Chaque table de faits contient au moins deux clés étrangères qui la connectent aux dimensions. Chaque ligne dans la table des faits correspond à un événement mesurable, ce qui représente le grain (niveau de granularité). [KIMBALL et al, 2013] 5.1.2. Table de Dimension : Se compose de paramètres (ou attributs) qui servent à enregistrer les descriptions textuelles. Ces paramètres sont utilisés pour l’analyse. [ENCINAS 2005] Une hiérarchie de dimension : est le résultat de la décomposition d’une ou plusieurs dimensions en plusieurs niveaux. [KHOURI 2008] 5.2. Les types de schéma dimensionnel 5.2.1. Schéma en étoile Dans ce schéma, chaque dimension est représentée par une table de dimension et les mesures par une table de faits qui référencie les tables de dimension en utilisant une clé étrangère pour chacune d’elles. [BELLATRECHE 2000] Dans ce schéma, les informations associées à une hiérarchie de dimension, sont représentées dans une seule table. [KHOURI 2008]
  13. 13. Chapitre 1 :L’informatique décisionnelle 13 Figure 6: Exemple d'un schéma en étoile [KHOURI 2008] 5.2.2. Schéma en flocon de neige Le schéma en étoile peut s’étendre à un schéma en flocon de neige. Cela est vérifié grâce à l’application d’une hiérarchie sur une ou plusieurs dimensions. Ce schéma peut réduire les performances de l’entrepôt au moment de son utilisation. Il présente un temps de réponse élevé causé par plusieurs jointures dans une seule requête. [KHOURI 2008] Figure 7: Exemple d'un schéma en flocon de neige [KHOURI 2008] 5.2.3. Modèle en constellation C’est l’utilisation partagée des mêmes tables de dimensions par plusieurs tables de faits. [KHOURI 2008]
  14. 14. Chapitre 1 :L’informatique décisionnelle 14 6. Méthodes classiques de développement d’un projet décisionnel Généralement, le développement d’un système décisionnel se fait en suivant l’une de ces deux méthodes : celle de Kimball ou celle d’Inmon [GOEDE et al, 2010]. 6.1. La méthode de Kimball La méthode de Kimball [KIMBALL et al, 2013] est caractérisée par :  La modélisation de l’entrepôt de données est basée sur le modèle en étoile et ses variantes (flocon de neige et constellation).  L’architecture en bus, qui consiste à créer un ensemble de magasins de données liés à chaque département de l’entreprise, ces magasins, lorsque assemblés, créent l’entrepôt de données. Cette approche est possible lorsque les dimensions sont conformes, c’est-à-dire qu’elles représentent exactement la même chose d’un magasin à l’autre. [RIVARD 2012]  La méthodologie de Kimball est menée par les besoins des clients [RIVARD 2012] et les exigences métiers. Présentation de la méthode Le cycle de vie d’un projet décisionnel suivant la méthode Kimball est donné par le schéma suivant : Figure 8: Le cycle de vie d’un projet décisionnel [KIMBALL et al, 2013]
  15. 15. Chapitre 1 :L’informatique décisionnelle 15 La méthode de Kimball encourage l’approche itérative en impliquant le client, le plus possible. Cette méthode débute par les besoins du client. Par la suite, la création de l’entrepôt de données, tels que trois chemins sont empruntés en parallèles, car ils ne visent pas les mêmes éléments de l’environnement [RIVARD 2012] :  La conception de l’architecture technique : dans cette étape, on doit choisir l’architecture technique et les outils matériels et logiciels nécessaires pour la mise en place de l’entrepôt de données.  La modélisation dimensionnelle : dans ce chemin, on définit la modélisation dimensionnelle de l’entrepôt et des magasins de données, et on définit les outils ETL que nous allons utiliser.  Conception des applications BI : c’est un chemin dédié pour le développement des applications décisionnelles tels que : les rapports, les tableaux de bord… Ces trois chemins sont intégrés en fin du projet au moment du déploiement. Le processus complet est répété pour chaque nouveau magasin de données demandé par les utilisateurs finaux. [RIVARD 2012] tout en assurant l’évolution et la maintenabilité du système. 6.2. La méthode d’Inmon La méthode d’Inmon [INMON 2002] est basée sur les points suivants [RIVARD 2012]:  La création de l’entrepôt de données, ce dernier permettra d’alimenter les autres magasins de données des différents départements ce qui garantit la cohérence de données.  Une connaissance approfondie du domaine métier de l’entreprise.  La modélisation de données repose sur le modèle Entité/Association et la normalisation en 3ème forme normale.  Inmon divise la base de données de l’entreprise en quatre niveaux : 1. Opérationnel : contient les BDD du système opérationnel ; 2. Entrepôt de données atomique ; 3. Départemental ; 4. Individuel. Les trois derniers niveaux constituent l’entrepôt de données. Les données sont transformées entre le premier et le deuxième niveau en utilisant un processus ETL.
  16. 16. Chapitre 1 :L’informatique décisionnelle 16 Présentation de la méthode Le schéma ci-dessous, montre le cycle de vie d’un projet décisionnel basé sur l’approche spirale d’Inmon. Cette méthode est une approche menée par les données. Figure 9: Le cycle de vie d’un projet décisionnel selon la méthode Inmon [INMON 2002] Selon le schéma ci-dessus, la création de l’entrepôt est la première étape du projet, et selon les résultats de la conception retenus à la fin du cycle, les besoins définis par le client seront bien compris par l’équipe projet ce qui permet de reprendre le cycle du projet pour permettre l’évolution de l’entrepôt de données et non pas sa révolution. 7. Comparaison entre les deux méthodes Les méthodes d’Inmon et Kimball sont différentes dans leur globalité, mais elles ont les mêmes caractéristiques et suivent le même type de cycle. Le tableau ci-dessous, synthétise les différences majeures entre les deux méthodes, en se basant sur les travaux de recherche de [BRESLIN 2004]: Inmon Kimball Méthode et Architecture Approche Top-Down Bottom-Up Structure architecturale Le Data Warehouse alimente les Data Marts Les Data Marts modélisent un processus métier, le schéma de l’entreprise est donné par le bus de données et les dimensions conformes.
  17. 17. Chapitre 1 :L’informatique décisionnelle 17 Complexité de la méthode Complexe Simple Processus Dérive de la méthode spirale Processus à quatre étapes, débute par un SGBD relationnel Architecture physique Complexe Simple Modélisation de données Outils Traditionnels Modélisation dimensionnelle Accessibilité de l’utilisateur Faible Forte Philosophie Audience primaire Les professionnels IT Les utilisateurs finaux Tableau 1: Comparaison entre les approches Kimball et Inmon [BRESLIN 2004] Conclusion Les systèmes décisionnels sont devenus parmi les premières occupations des entreprises afin de disposer des informations précises et assurer son pilotage efficace. Le développement d’un système décisionnel nécessite une étude détaillée des sources de données d’une organisation ainsi que les besoins des décideurs, c’est pourquoi la collaboration des parties prenantes est un facteur important. Le choix d’une méthode classique ou agile de développement d’un projet décisionnel revient à l’équipe projet, selon les spécificités du projet qu’elle développe, chaque méthode a des caractéristiques qui s’adaptent avec un cas et pas avec un autre. Le chapitre suivant permettra de présenter les méthodes agiles les plus utilisées dans le domaine du développement logiciel.
  18. 18. 18 Chapitre 2 Les méthodes de développement agiles Un processus de développement logiciel comprend plusieurs activités : l’analyse des besoins, la conception, l’implémentation et les tests. Selon certaines approches classiques, ces activités sont séquentielles i.e. on ne peut pas commencer une activité avant que la précédente ne soit finie. Afin de rendre le processus de développement plus souple et flexible, les approches agiles sont apparues. Dans ce qui suit, nous allons expliquer les méthodes de développement agiles.
  19. 19. Chapitre 2 : Les méthodes de développement agiles 19 1. Définition de Méthodologie de développement agile Dans le contexte du développement logiciel, on utilise le terme agile pour qualifier une méthodologie de développement. D’après [OXFORD] une méthode de développement agile désigne une méthode de gestion de projet, utilisée en particulier pour le développement du logiciel. Elle est caractérisée par la répartition des tâches sur de courtes phases de travail avec une réévaluation fréquente du travail fait et une adaptation des plans. 2. Manifeste agile Pour faire face aux défis rencontrés lors du développement logiciel, un groupe de dix- sept fondateurs ont formé une alliance de développement logiciel Agile en Février 2001. Cette alliance est connue sous le nom de « Agile Alliance ». Ce groupe a défini un manifeste pour valoriser les meilleures pratiques de ce type de développement [JEFFRIES 2002]:  Les individus et leurs interactions mieux que les processus et les outils. Cette valeur se focalise sur l’importance de la communication et de l’interaction entre les membres d’une même équipe (chef de projet, concepteur, développeur, testeur) qui ont un impact plus important que celui des processus et outils.  Un logiciel opérationnel mieux qu’une documentation exhaustive. Sachant qu’une documentation performante est un guide précieux pour permettre à un utilisateur de bien comprendre le fonctionnement de son logiciel. Mais celui-ci préfère généralement avoir accès à un prototype tangible mieux que sa documentation.  La collaboration avec les clients mieux que la négociation contractuelle. Avoir un contrat qui définit les droits et les responsabilités entre le client et le prestataire de service est important. Mais cela ne peut pas remplacer le rôle crucial joué par la communication. Cette dernière aide le client à interagir d’une manière directe avec les développeurs.
  20. 20. Chapitre 2 : Les méthodes de développement agiles 20 Grâce à la communication, les développeurs livrent un logiciel qui répond aux besoins ce qui augmente la satisfaction chez leurs clients.  L’adaptation aux changements mieux que le suivi d’un plan Un plan est un élément clé pour suivre l’état d’avancement d’un projet. Toutefois, un plan de projet doit être flexible pour réagir face aux besoins évolutifs des clients. 3. Principes de développement Agile En plus du manifeste agile, [JEFFRIES 2002] a défini douze principes pour le développement de logiciels agiles : 1. Satisfaire le client à travers des livraisons continues des parties fonctionnelles du logiciel. 2. Accueillir les besoins évolutifs y compris les tardifs. 3. Fournir fréquemment un logiciel fonctionnel. 4. Les clients et les développeurs doivent collaborer ensemble durant le projet. 5. Réaliser le projet autour des équipes motivées en leurs mobilisant un environnement du travail adéquat. 6. La communication directe est la méthode la plus efficace afin d’échanger des informations entre les membres du groupe. 7. Un logiciel fonctionnel est la principale mesure du progrès. 8. Le développement doit être durable suivant un rythme constant. 9. La bonne conception et l’excellence technique améliorent l’agilité. 10. Simplifier au maximum. 11. L’auto-organisation est la clé de succès d’une architecture ou d’une conception. 12. L’amélioration de l’équipe d’une manière autonome et régulière. 4. Caractéristiques des méthodes Agiles En général, un développement agile est caractérisé selon [ABRAHAMSSON et al, 2003] par les attributs suivants: Adaptatif, Itératif, Coopératif et Simple.
  21. 21. Chapitre 2 : Les méthodes de développement agiles 21  Adaptatif : veut dire malléable, en d’autres termes c’est la capacité de s’assouplir aisément.  Itératif : se base sur des incréments courts pour avoir la rétroaction de l’utilisateur.  Coopératif : encourage la communication entre le client et le développeur de façon directe.  Simple : la méthode elle-même est facile à apprendre et à appliquer. 5. Méthodes Agiles Nous présentons ci-dessous les principales méthodes agiles proposées. Pour chacune des méthodes, nous présentons ses fondateurs, l'année de son apparition et son principe de développement. 5.1. Scrum Fondateurs: Ken Schwaber, Jeff Sutherland et Mike Beedle Année : 2001 Principe de la méthode [DEVARAPALLI 2013]: La méthode Scrum est une méthode basée sur des Sprints (itérations) de durée de 30 jours. Un sprint commence par une planification qui consiste à choisir un ensemble de spécifications à partir d’un carnet de produit 3(backlog de produit). Les spécifications retenues sont les plus prioritaires à inclure dans un carnet de sprint 4(backlog du sprint) puis un plan détaillé de tâches est établi. On entame chaque jour de Sprint par un « Scrum quotidien ». C’est une réunion quotidienne qui se déroule dans un même lieu et heure. Pendant cette réunion, chaque membre de l’équipe présente son état d’avancement et discute ses problèmes rencontrés. 3 Carnet de produit : Une liste ordonnée des spécifications requises d’un produit. 4 Carnet de sprint : Les spécifications choisies à partir d’un carnet de produit pour être développé dans un sprint.
  22. 22. Chapitre 2 : Les méthodes de développement agiles 22 Une fois la durée de sprint est finie, l’équipe se réunit pour faire une démonstration au client en lui présentant les fonctionnalités développées. Figure 10: Le schéma global de Scrum (Reproduit) [DASGUPTA et al, 2007] 5.2. Extreme Programming (XP) Fondateurs: Kent Beck & Ward Cunningham Année: 1995 Principe de la méthode [ABRAHAMSSON et al, 2003] : Extreme Programming (XP) est un ensemble de pratiques du génie logiciel qui sont : itérations courtes, livraison rapide, présence du client sur le champ, communication et coordination, intégration continue, refactoring et tests, propriété collective du code et programmation par paires. La méthode XP est destinée aux logiciels caractérisés par des exigences vagues et évolutives. 5.3. Dynamic System Development Method (DSDM) Origine: Rayaume-Uni Année: 1994 Principe de la méthode: C’est une extension des pratiques de développement rapide d'applications5 ou Rapid Application Development (RAD) [DEVARAPALLI 2013]. Ce dernier permet au programmeur de créer des prototypes d’interfaces utilisateurs pour avoir une rétroaction du client, et ainsi combler ses besoins [RIVARD 2012]. 5 Développement rapide d'applications : l’implémentation dans des courts délais pour permettre au client de suivre l’évolution de son produit.
  23. 23. Chapitre 2 : Les méthodes de développement agiles 23 La figure 11 illustre les étapes d’un projet DSDM. D’abord, on commence par une étude de faisabilité dans laquelle on décide si DSDM est applicable sur le projet ou pas. Ensuite, on fait une étude de besoins de haut niveau. Puis, on développe un modèle fonctionnel itératif qui détaille les spécifications à développer. Cette étape est suivie d’une conception. On finit par une implémentation et test de logiciel développé. Excluant l’étude de faisabilité, les phases de DSDM sont itératives. [GORAKAVI et al, 2009] Figure 11: Cycle de vie de la méthode DSDM [GORAKAVI et al, 2009] 5.4. Feature-Driven Development (FDD) Fondateurs: Jeff De Luca et Peter Coad Année : 1997 Principe de la méthode [PALMER et al, 2002]: FDD est un processus composé de cinq étapes principales. La première étant le développement d’un modèle global, Dans cette étape le client et l’équipe de développement définissent le contexte du système à développer puis une liste de fonctionnalités est établie. Les fonctionnalités sont ordonnées par priorité selon les besoins du client. Chaque fonctionnalité est planifiée durant un cycle de deux semaines de conception et d’implémentation. Ces deux dernières étapes sont itératives.
  24. 24. Chapitre 2 : Les méthodes de développement agiles 24 Figure 12: Cycle de vie de la méthode FDD [PALMER et al, 2002] 5.5. Lean Development (LD) C’est une méthode inspirée de la production industrielle en particulier celle des automobiles durant les années 1980 [DEVARAPALLI 2013]. Cette méthode adopte un certain nombre de principes qui sont selon [POPPENDIECK et al, 2006]:  Eliminer le gaspillage : ne pas produire ce qui n’est pas demandé par le client.  Développer la qualité interne: veiller sur la bonne qualité du code pour détecter facilement les erreurs.  Créer le savoir : en acquérant la rétroaction du client. De plus la livraison rapide, le respect mutuel entre les membres de l’équipe et surtout l’optimisation des ressources (coût et délai). 5.6. Adaptive Software Development (ASD). Fondateur : James A. Highsmith Année : 2000 Principe de la méthode [CHOWDHURY et al, 2011]: Le processus commence par la phase d’initiation du projet où les objectifs et les calendriers du cycle de développement sont fixés. Plusieurs composants sont développés simultanément en phase de collaboration. Ces composants sont affinés d’une façon continue, c’est pourquoi la planification du cycle de développement est une partie du processus itératif. Au stade final, l’équipe projet apprend les pratiques qui vont lui permettre d’aboutir à un logiciel de qualité du point de vue client.
  25. 25. Chapitre 2 : Les méthodes de développement agiles 25 Conclusion Les méthodes agiles sont des procédés itératifs et incrémentaux qui nécessitent une contribution importante du client. A travers ce chapitre nous avons donné un aperçu sur les méthodes les plus connues dans le domaine de génie logiciel. Dans le chapitre suivant nous montrerons l’application des pratiques agiles dans le cadre de la BI (Business Intelligence).
  26. 26. Références Bibliographiques et Webographiques 26 Références Bibliographiques et webographiques Thèses [BELLATRECHE 2000] BELLATRECHE L. Utilisation des Vues Matérialisées, des Index et de la Fragmentation dans la conception logique et physique d’un Entrepôt de Donnée. Thèse doctorat en informatique. France : Université de Clermont-Ferrand II, 2000 [CHOUDER 2007] CHOUDER L. Entrepôt Distribué de Données. Thèse de Magistère en informatique. Alger : Institut National de Formation en Informatique (I.N.I), 2007 [DEVARAPALLI 2013] DEVARAPALLI S. Agile BI Development core practices, Thèse de Master en informatique. Suède : Université de BORAS, 2013 [ENCINAS 2005] ENCINAS SERNA M.T. Entrepôts de données pour l’aide à la décision médicale : Conception et expérimentation. Thèse de doctorat en informatique. France: l’Université Joseph Fourier, 2005 [GAM EL GOLLI 2008] GAM EL GOLLI I. Ingénierie des Exigences pour les Systèmes d’Information Décisionnels: Concepts, Modèles et Processus La méthode CADWE. Thèse de doctorat en informatique. PARIS I : UNIVERSITÉ PARIS I – PANTHÉON – SORBONNE, 2008. [JUGLARET 2012] JUGLARET F. Indicateurs et Tableaux de Bord pour la prévention des risques en Santé-Sécurité au Travail. Thèse doctorat en Sciences et Génie des Activités à Risques. Paris : École nationale supérieure des mines de Paris, 2012 [KHOURI 2008] KHOURI S. Modélisation conceptuelle à base ontologique d’un entrepôt de données. Thèse de Magistère en informatique. Alger : Institut National de Formation en Informatique (I.N.I), 2008 [POLETTO 2012] POLETTO M .L’informatique décisionnelle. Thèse professionnelle en Informatique. France : Ecole Supérieure d’Informatique CESI EXIA, 2012 [RIVARD 2012] RIVARD E. Proposition d’une méthodologie agile en intelligence d’affaires pour réduire les risques d’échecs. Essai pour l’obtention du grade de maître en technologies de l’information. Québec : Université DE SHERBROOKE, 2012. [TESTE 2000] TESTE O. Modélisation et manipulation d'entrepôts de données complexes et historisées. Thèse doctorat en informatique. Toulouse : Université Paul Sabatier de Toulouse (sciences) ,2000 [TOURNIER 2007] TOURNIER R. Analyse en ligne (OLAP) de documents. Thèse
  27. 27. Références Bibliographiques et Webographiques 27 de doctorat en informatique. Toulouse : Université Toulouse III – Paul Sabatier. 2007. Articles [ABRAHAMSSON et al, 2003] ABRAHAMSSON P., WARSTA J., SIPONEN M.T., RONKAINEN J. New Directions on Agile Methods: A Comparative Analysis. Proceeding of International Conference on Software Engineering, IEEE, USA, 2003 [BRESLIN 2004] BRESLIN M. Data Warehousing Battle of the Giants: Comparing the Basics of the Kimball and Inmon Models. BUSINESS INTELLIGENCE JOURNAL, 2004 [BUNIO 2012] BUNIO T S. Agile Data Warehouse – The Final Frontier: How a Data Warehouse redevelopment is being done in an Agile and pragmatic way. 2012 Agile Conference, IEEE, 2012, pp. 156-164 [CHOWDHURY et al, 2011] CHOWDHURY A.F., NAZMUL Huda M. Comparison between Adaptive Software Development and Feature Driven Development. International Conference on Computer Science and Network Technology, IEEE, 2011 [DASGUPTA et al, 2007] DASGUPTA S., VANKAYALA V.K. Developing realtime business intelligence systems the agile way.1st Annual IEEE Systems Conference. Waikiki Beach, Honolulu, Hawaii, USAApril9-12, 2007 [ECKERSON 2007] ECKERSON W. Predictive Analytics. Extending the Value of Your Data Warehousing Investment: TDWI Best Practices Report, 2007 [GEODE et al, 2010] GOEDE R., HUISMAN M. The Suitability of Agile Systems Development Methodologies for Data Warehouse Development. The Proceeding of the International Conference on Information Management and Evaluation: North west University, South- Africa, 2010, pp. 99-106 [GHARAIBEH et al, 2009] GHARAIBEH N., ABU-SOUD S.M., BDOUR W., GHARAIBEH I. Agile Development Methodologies: Are they suitable for developing Decision Support Systems. IEEE, 2009 [GOLFARELLI et al, 2011] GOLFARELLI M., RIZZI S, TURRICCHIA E. Modern Software Engineering Methodologies Meet Data Warehouse Design: 4WD, Springer-Verlag, 2011, LNCS 6862, pp.66-79 [GOLFARELLI et al, 2012] GOLFARELLI M., RIZZI S., TURRICCHIA E. Sprint Planning Optimization in Agile Data Warehouse Design, Springer-Verlag, 2012, LNCS 7448, pp. 30-41 [GORAKAVI et al, 2009] GORAKAVI P K. Build Your Project Using Dynamic System Development Method, 2009 [KANICLIDES et al, 1994] KANICLIDES T., KIMBLE C. Executive Information Systems: A framework for their development and use. UNIVERSITY OF YORK - DEPARTMENT OF COMPUTER SCIENCE, Heslington, York, Y01 500, England, 1994 [MUNTEAN et al, 2013] MUNTEAN M., SURCEL T. Agile BI–The Future of BI. Informatica Economică, 2013. Vol 17, no 3, pp. 114-124. issn14531305
  28. 28. Références Bibliographiques et Webographiques 28 Livres [CORBILLE et al, 2006] CORBILLE A., DUMAS V. Business Intelligence et Portails, France : Dunod, 2006 [FERNANDEZ 2013] FERNANDEZ A. L’essentiel du tableau de bord. 4ème édition, France: Eyrolles, 2013 [FRANCO et al, 2001] FRANCO J., DE LINGNROLLES S. Piloter l’entreprise grâce au data warehouse. 2ème edition, France: Eyrolles, 2001 [INMON 2002] INMON W.H. Building the Data Warehouse. 3rd Edition, United States of America: John Wiley & Sons, 2002. [JEFFRIES 2002] JEFFRIES R. Agile Modeling Effective Practices for Extreme Programming and the Unified Process. Scott W.Ambler, 2002 [KIMBALL et al, 2013] KIMBALL R, MARGY R. The Data warehouse toolkit: The Definitive Guide to Dimensional Modeling. 3rd Edition, United States of America: John Wiley & Sons, 2013 [MALO 1995] MALO J.L. Les tableaux de bord comme signe d’une gestion et d’une comptabilité à la française. Foucher. 1995 [PALMER et al, 2002] PALMER S. R., FELSING J. M. A Practical Guide to Feature Driven Development. Upper Saddle River: Prentice Hall, 2002 [POPPENDIECK et al, 2006] POPPENDIECK M., POPPENDIECK T. Implementing Lean Software Developpement: From Concept To Cash, 1ère édition, USA, 2006. [ROUX 1991] ROUX F.J. Infocentre pourquoi ? Comment?. France : Eyrolles, 1991 Références Webographiques [OXFORD] OXFORD Dictionaries. Definition of agile [En ligne]. Disponible sur : <http://www.oxforddictionaries.com/definition/english/agile> (Consulté le 23.01.2015).

×