La business Intelligence Agile

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]

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
 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
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
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
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
 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
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
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
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
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
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.

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
 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
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
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
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
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

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

La business Intelligence Agile

Contenu connexe

Tendances

Similaire à La business Intelligence Agile

Plus de dihiaselma

La business Intelligence Agile