la business intelligence agile

28
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)

Upload: dihiaselma

Post on 08-Aug-2015

226 views

Category:

Engineering


10 download

TRANSCRIPT

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)

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

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

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

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.

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]

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]

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.

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 :

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

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 :

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]

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]

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]

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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).

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

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

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).