Elaboration d’une Solution Décisionnelle pour l’ATB

Institut Supérieur de Gestion de Tunis
1/90
100%
Rendu du PDF...
Page 1 sur 90Lecteur de document UniversityLib

Elaboration d’une Solution Décisionnelle pour l’ATB

Institut Supérieur de Gestion de Tunis · Business Intelligence and Decision Support Systems · textbook

Voir tous les documents en intelligence artificielle et données

Minist re de lEnseignement Sup rieur Et de la

Recherche Scientifique

Universit de Tunis

Institut Sup rieur de Gestion de Tunis

Projet de fin d tudes pour lobtention

dune licence appliqu e en Informatique D cisionnelle

ELABORATION DUNE SOLUTION DECISIONNELLE

POUR LATB

Entreprise daccueil

Arab Tunisian Bank (ATB)

Elabor par

Kdous Mohamed Amine

Sammouda Chirine

Encadrant p dagogique

Encadrant professionnel

Mme. Rejeb Lilia

Mr. Sahraoui Aymen

Ann e universitaire

2017 2018

Remerciements

D dicace

Kdous Mohamed Amine

D dicace

Sammouda Chirine

Table des mati res

Chapitre I : Contexte g n ral ................................................................................................... 11

1.

Introduction ....................................................................................................................... 11

2. Cadre du projet .................................................................................................................. 11

3. Pr sentation de lorganisme daccueil .............................................................................. 11

3.1 Historique .................................................................................................................. 11

3.2

Fiche didentit de lATB .......................................................................................... 12

3.3 Organigramme du si ge ............................................................................................. 13

3.4 Direction du Stage ..................................................................................................... 13

3.4.1

Pr sentation de la DCSI ..................................................................................... 14

3.4.2

Pr sentation de la direction des tudes et des projets ......................................... 15

4. Pr sentation du projet ....................................................................................................... 15

4.1 Contexte du projet ..................................................................................................... 15

4.2 Analyse de lexistant ................................................................................................. 16

4.3 Critique de lexistant ................................................................................................. 16

4.4 Description de la solution .......................................................................................... 17

5. Conclusion ........................................................................................................................ 18

Chapitre II : M thodes de conception et outils d cisionnels .................................................... 19

1.

Introduction ....................................................................................................................... 19

2. M thode de conception ........................................................................................................ 19

2.1

Etudes des m thodes pr dictives classiques .............................................................. 19

2.2 M thodes AGILES .................................................................................................... 20

2.3 M thodes AGILES Vs M thodes pr dictives classiques .......................................... 21

2.4 M thodologie adopt e ............................................................................................... 22

2.5

Pr sentation de la m thodologie SCRUM ................................................................. 23

2.6

Les intervenants dans Scrum ..................................................................................... 23

2.7

Les art facts du Scrum [11] ....................................................................................... 24

2.8

Lapproche SCRUM appliqu un projet BI ............................................................ 25

3. Approche de conception de lentrep t de donn es ........................................................... 26

3.1 Mod les conceptuels .................................................................................................. 26

3.2 Approches pour la cr ation du Datawarehouse (ROLAP, MOLAP, HOLAP) ......... 26

4. Comparaison des outils d cisionnels ................................................................................ 27

4.1 Outils pour la cr ation de DataWarehouse ................................................................ 27

4.2 Outils pour Extract Transform Load (ETL) .............................................................. 29

4.3 Outils de Reporting .................................................................................................... 31

5. Environnement de d veloppement retenu ......................................................................... 32

5.1 Outil de conception ................................................................................................ 33

5.2 Outil de d veloppement ......................................................................................... 33

6. Conclusion ........................................................................................................................ 34

Chapitre III : Phase de pr paration ........................................................................................... 35

1.

Introduction ....................................................................................................................... 35

2. Analyse des besoins .......................................................................................................... 35

2.1

Identification des acteurs du syst me ........................................................................ 35

2.3

Sp cification des besoins non fonctionnels ............................................................... 36

3. Backlog produit ................................................................................................................. 37

4. Planification du projet ....................................................................................................... 39

4.1

Pilotage du projet avec la m thodologie SCRUM ..................................................... 39

4.2 D coupage de la solution en Sprints : ....................................................................... 39

4.3 Diagramme de Gant ................................................................................................... 40

5. Etude des donn es sources ................................................................................................ 40

6. Conception de la base de donn es .................................................................................... 42

7. Alimentation de la base de donn es .................................................................................. 42

8. Conclusion ........................................................................................................................ 44

Chapitre IV ............................................................................................................................... 45

Sprint 1 : Mise en place dun Data Warehouse des Suivis ....................................................... 45

1.

Introduction ....................................................................................................................... 45

2. Sprint Backlog .................................................................................................................. 45

3. Conception du DataWarehouse ......................................................................................... 47

3.1 Choix des mesures ..................................................................................................... 47

3.2 Choix des dimensions ................................................................................................ 47

3.3

Table de faits ............................................................................................................. 48

4. Mod lisation du DataWarehouse ...................................................................................... 49

5.

Int gration des donn es du DataWarehouse (ETL) .......................................................... 49

5.1 Extraction des donn es ................................................................................................... 51

5.2 Transformation des donn es ........................................................................................... 53

5.3 Chargement des donn es ................................................................................................ 57

6. La restitution des donn es ................................................................................................. 59

Chapitre V : Suivi et valuation de la classification des actifs et des risques clients. ............. 67

1.

Introduction ....................................................................................................................... 67

2. Sprint Backlog .................................................................................................................. 67

3. La classification des Actifs ............................................................................................... 68

3.1 Actifs courants (Classe 0) .......................................................................................... 68

3.2 Actifs n cessitant un suivi particulier (Classe 1) ....................................................... 68

3.3 Actifs incertains (Classe 2) ........................................................................................ 69

3.4 Actifs pr occupants (Classe 3) .................................................................................. 69

3.5 Actifs compromis (Classe 4) ..................................................................................... 69

4. Formules pour le calcul des risques .................................................................................. 70

Publicité

4.1

Formule de calcul du STRATE ........................................................................... 70

4.2

Formule de calcul de la Variation des engagements ................................................. 70

4.3

Formule de calcul de la Garantie plafonn lengagement ...................................... 70

5. Conception du Datamart Risque ................................................................................. 71

5.1 Choix des mesures .......................................................................................................... 71

5.2 Choix des dimensions ................................................................................................ 71

5.3 Mod lisation du Datamart .............................................................................................. 72

6.

Int gration des donn es du Datamart RISQUE (ETL) ............................................... 72

6.1

Extraction des donn es .............................................................................................. 72

6.2

Transformation des donn es ...................................................................................... 73

6.3 Chargement des donn es ........................................................................................... 76

Annexe A : Le Projet D cisionnel ............................................................................................ 77

ANNEXE B : Dictionnaire des donn es sources ..................................................................... 82

Bibliographie ............................................................................................................................ 87

Table des figures

Liste des tableaux

Introduction g n rale

Chapitre I : Contexte g n ral

1. Introduction

Dans le pr sent chapitre, nous allons voquer bri vement lhistorique de lorganisme daccueil,

ses missions et son organisation. Par la suite, nous allons introduire le contexte du projet et faire

une tude de lexistant. Enfin, nous nous int ressons la pr sentation de la solution propos e

et la justification du choix de la m thodologie adopt e.

2. Cadre du projet

Ce projet sinscrit dans le cadre de la pr paration dun projet de fin d tudes afin dobtenir le

Dipl me de Licence Appliqu e en Informatique D cisionnelle lInstitut Sup rieur de Gestion

(ISG). Ce projet dont la dur e est de trois mois, est r alis au sein de lATB (Arab Tunisian

Bank).

Son objectif principal est le d veloppement dune application int gr e d di e laide la

d cision.

3. Pr sentation de lorganisme daccueil

3.1 Historique

En 1930, lArab Bank a t fond e dans le but de construire une institution au service du monde

arabe. Elle a d marr avec sept actionnaires et un capital qui ne d passait pas les 15 000 livres

palestiniennes. 52 ans plus tard, Arab Bank a d cid dint grer lagence de Tunisie et fondre

une banque commerciale tunisienne lATB.

LATB sest donn e pour mission doffrir des services diversifi s et de qualit aux particuliers

ainsi quaux professionnels et de contribuer au d veloppement conomique et financier du pays.

Elle est class e parmi les meilleures banques en termes de r sultats, importance des fonds

propres et de ses actifs.

L'ATB dispose aujourd'hui d'un r seau de 131 agences et emploie plus de 1300 personnes. Cette

banque sest investie dans le d veloppement dune strat gie de filialisation. On parle

aujourdhui dune cr ation des soci t s sp cialis es. En vue de consolider sa position sur le

march Tunisien et daccro tre ses champs daction, lATB sint resse particuli rement aux

axes suivants [1] :

" Une orientation plus soutenue vers le march des particuliers sans toutefois

n gliger sa cible privil gi e constitu e des petites et moyennes entreprises, et les

grandes entreprises.

" Une synergie entre la banque et ses filiales.

3.2 Fiche didentit de lATB

Comme tout tablissement, lATB poss de une fiche signal tique qui est d crite par la table 1

[2] :

D nomination

Date de cr ation

Fondateur

Si ge social

Forme juridique

Activit

Direction

Nombre dagences

Nombre demploy es

Nombre de filiales

Capitalisation

Bilan comptable

T l phone

E-mail

Site web

LArab Tunisian Bank

30 juin 1982

Hatem Kchouk

9 Rue Hedi Nouira, 1001 Tunis

Soci t anonyme

Banque

Mohamed Ferid Ben Tanfous

131

1300

9

100 millions TND en 2015

2 696 000 USD en 2014

71351155

[email protected]

http://www.atb.tn/

Table 1. Fiche d'identit de l'ATB

3.3 Organigramme du si ge

Lorganisation de lATB est mod lis e par lorganigramme pr sent dans la figure 1 :

Directeur

g n ral

Direction

centrale de

financement

Dircetion

centrale de

l'inspection et de

l'audit

Adjoint au

directeur

g n ral

Direction des

affaires

juridiques

Direction central

du d partement

comptable

Direction des

moyens de

paiement

Direction des

ressources

humaines

Direction

d'organisation

Direction de

syst mes

Publicité

d'infomation

Division

administration

des syst mes

Division de

coordination

Division de

production

Division tudes

et

d veloppement

Service

maintenance

hard

Service

exploitation

Service

maintenance

application soft

Service

maintenance

application hard

centrale

help desk

Figure 1. Organigramme du si ge [3]

3.4 Direction du Stage

Notre stage d tude se d roulera au sein de la direction des syst mes dinformation, plus

pr cis ment dans la division administration des syst mes en collaboration avec la direction des

Etudes et des projets. Nous allons expliquer dans ce qui suit, les activit s de chacune de ces

directions.

3.4.1

Pr sentation de la DCSI

La direction centrale des syst mes dinformation de lATB (DCSI) est compos e

principalement de trois d partements :

Le d partement infrastructure et syst mes qui est subdivis en :

" Unit r seau de communication

" Cellule dadministration syst mes et base de donn es

" Unit de gestion de mat riel informatique

Le d partement exploitation et maintenance constitu de :

" La division assistance utilisateur

" La cellule de sauvegarde et restauration

" La division exploitation

Le d partement application et maintenance qui est compos de :

" La cellule core system

" Lunit des canaux de distribution lectronique

" La division d veloppement et maintenance syst me

"

Nous nous int ressons, non seulement la cellule dadministration syst mes et base de donn es

qui fait partie du d partement infrastructure et syst mes, mais aussi la direction des tudes et

des projets qui pilote tous les projets de la banque.

3.4.2 Pr sentation de la direction des tudes et des projets

La Direction des tudes et des projets a pour mission la planification strat gique et

op rationnelle des actions de d veloppement de la banque.

A ce titre, elle est charg e notamment :

" De r aliser des tudes n cessaires latteinte des objectifs de la banque.

" Dassurer le pilotage de plusieurs projets en termes de co t, d lai, qualit et risque.

" Dassurer le suivi et l valuation de la performance des projets.

" De coordonner l laboration des plans et des strat gies

" De produire les rapports dactivit

4. Pr sentation du projet

4.1 Contexte du projet

Ce projet consiste laborer une solution d cisionnelle pour lanalyse des engagements, des

produits et des garanties de la banque tout en se r f rant de la classification et le calcul de risque

des clients afin de faciliter la prise de d cision.

La banque dispose des sources de donn es regroupant des informations sur les clients cr anciers

telles que :

Les engagements : Le client peut tre li diff rents types dengagements envers

la banque. Principalement, on peut citer :

" Les cr dits moyen terme

" Les cr dits long terme

" Les engagements par signature

" Laval

Les produits : Le client sengage fournir les produits bancaires tels que les

diff rents types de commissions, dint r t et les agios&

Les garanties : La banque exige une garantie bancaire qui permet dassurer un

remboursement dans le cas o le client n'arriverait pas honorer le contrat.

Les classes : La classification des clients peut tre consid r e comme une tape

essentielle la prise de d cision et se fait selon :

  • Le gel des comptes bancaires
  • La consolidation des cr dits
  • La classification des impay s

Chaque classe peut avoir une valeur entre 0 et 5. Plus la note est proche de 5 plus le client est

mal class .

4.2 Analyse de lexistant

Les donn es de lATB sont g n ralement sauvegard es dans un syst me Oracle, mais il existe

aussi une grande partie qui a t migr e vers un nouveau syst me intitul Equation

sp cifique lArabe banque. La migration totale des donn es est encore inachev e donc une

partie des donn es concernant les engagements clients r side toujours dans lancien syst me.

Pour suivre les engagements, les produits et les garanties, la solution utilis e actuellement est

une application .NET classique qui permet la consultation et lexportation des donn es sous

forme Excel et peut tre consid r e comme tant basique et traditionnelle. Elle est d finie sur

une base de donn es Oracle 11g en utilisant des liens de bases de donn es DBLINK permettant

lacc s distance (oracle 11g, AS 400).

4.3 Critique de lexistant

La solution utilis e traite chaque module part. Dailleurs les informations concernant les

engagements, les clients, les produits et les garanties se trouvent dans diff rentes bases de

donn es.

Cette solution tait ad quate et r pondait aux besoins des d cideurs pour le suivi des

engagements clients, la consultation et le calcul. Cependant, depuis quelques ann es, la banque

a not une augmentation consid rable du nombre de client le, do une l vation du volume

des donn es traiter et lenrichissement du syst me dinformation de la banque. Ceci a men

alors, linefficacit de cette solution face ces changements, on parle d :

  • un mauvais partage de linformation
  • un manque de souplesse
  • un temps de traitement tr s lent qui peut durer jusqu 4 jours en consid rant le volume

important des donn es analyser.

Les bases de donn es relationnelles utilis es dans cette solution sont d finies comme tant un

r pertoire d' l ments de donn es dot s d'une relation pr d finie entre eux. Ce r pertoire peut

contenir des informations erron es et manquantes, et ne r pondent pas aux attentes des

d cideurs qui ont besoin dinformations pertinentes et fiables sur lesquelles ils peuvent

sappuyer pour une prise de d cision avis e. Il est indispensable alors dopter pour une structure

de donn es mieux adapt e afin de faciliter lanalyse des donn es pour des fins d cisionnelles.

Les d cideurs sont confront s des probl mes qui r sident dans :

  • La complexit de la structure de la base cause de nombre assez important des tables

et des jointures mises en Suvre.

  • La difficult dacc s distance aux informations.
  • La difficult de la repr sentation des donn es historiques
  • La g ne de lexploitation optimale des donn es et la classification selon un th me

bien d termin .

Publicité

4.4 Description de la solution

Apr s avoir tudi le processus de la prise de d cision de lATB, il sest av r quil est

n cessaire de mettre en place un syst me d cisionnel qui va permettre de :

  • Homog n iser les ressources de donn es h t rog nes.
  • Suivre les engagements clients via une interface utilisateur en visualisant

principalement les impay s et les cr dits.

  • Consulter les produits de la banque (les int r ts et les commissions).
  • Consulter les garanties.
  • Classifier les clients et calculer les risques dinsolvabilit (classification des actifs,

les agios, les provisions).

  • Analyser les donn es et g n rer des rapports selon le besoin du d cideur.
  • Diffuser les informations n cessaires tous les acteurs d cisionnels.
  • Faciliter lanalyse et la prise de d cision au niveau des hauts et moyens secteurs de

la banque.

Cest pour cette raison que nous avons opt pour une solution d cisionnelle ayant pour but de

collecter et r cup rer les donn es de diff rentes sources disponibles, les traiter et les charger

dans un entrep t de donn es puis fournir une interface web dynamique qui permettra aux

d cideurs de suivre les engagements, les produits et les garanties bancaires, de consulter la

classification des clients tout en se r f rant du risque calcul , et enfin avoir lacc s aux

diff rents tableaux de bord et des rapports interactifs pour des fins d cisionnelles.

5. Conclusion

A travers ce chapitre, nous avons pu acqu rir une connaissance assez importante concernant

lactivit de lATB, en faisant l tude de lexistant et en soulignant ses limites. Ensuite, nous

avons propos une solution qui r pond aux besoins de la banque. Quant au chapitre qui suit,

nous allons num rer les diff rentes m thodes de conception qui existent pour enfin, adopter

une et Idem pour les outils informatiques d cisionnels.

Chapitre II : M thodes de conception et outils

d cisionnels

1. Introduction

Afin dassurer une bonne gestion du projet, une tude comparative des m thodes de conception

simpose ce stade. De m me pour le choix des outils informatiques que nous allons utiliser et

les approches que nous allons adopter. Ce chapitre sera alors, d di la justification de nos

choix en faisant recours une comparaison bien d taill e.

2. M thode de conception

2.1 Etudes des m thodes pr dictives classiques

Les m thodes de d veloppement utilis s jusqu 1990 comme Cycle en V , Cleanroom ,

Waterfall et la Spiral de Boehm nassuraient plus la bonne ma trise et la gestion des

co ts, budgets, et des d lais dun projet dont le p rim tre fonctionnel est assez d velopp .

Les tudes du Standish Group ont d montr travers le Chaos Report [4] que le taux de

r ussite des projets labor s avec Waterfall, par exemple, na pas d pass 32% en 2009, et

beaucoup moins en 2012 avec un taux de 14%. Alors quon consid re quun projet r ussi, sil

arrive respecter le p rim tre fonctionnel, le budget et les d lais pr vus pr alablement. Cest

pourquoi les recherches se sont orient es vers lexploration de nouvelles approches adopter

notamment les m thodes agiles.

Successful

Challenged

Failed

Figure 2. The Chaos Manifesto

2.2 M thodes AGILES

Une m thode agile est une approche it rative et incr mentale, qui est men e dans un esprit

collaboratif avec juste ce quil faut de formalisme. Elle g n re un produit de haute qualit tout

en prenant en compte l volution des besoins des clients. [5]

Cette approche forme un ensemble de m thodes permettant en effet de g rer essentiellement

les projets informatiques.

Elles se basent sur des cycles de d veloppement adaptifs en fonction des besoins fonctionnels

du projet. En outre, limplication des collaborateurs dans le d veloppement du projet est

assur e.

Ces m thodes r pondent aux attentes du client en un temps r duit et impliquent les

collaborateurs en comp tences.

Les m thodes de d veloppement Agile peuvent tre num r es comme suit :

" Scrum

" Adaptive Software Development (ASD)

" Extreme Programming

" Dynamic System Development Method (DSDM)

" XP

" Kanban

Etc...

La figure 3 illustre la r partition de diff rentes m thodologies Agiles adopt es en 2016 [6].

Scrum occupe la plus grande partie. Dailleurs il est g n ralement adopt pour son paradigme

innovateur de conduite de projet ainsi que ses pratiques ding nierie logicielle.

Figure 3. R partition des M thodologies agiles adopt es en 2016

2.3 M thodes AGILES Vs M thodes pr dictives classiques

Apr s avoir tudi chaque m thode, nous proposons ce tableau comparatif qui r capitule les

principales diff rences entre les deux m thodes. [7]

Axe de comparaison M thodes AGILES

M thodes classiques

Planification

Cycle de vie

Adaptive

Pr dictive

It ratif et incr mental

En cascade ou en V

Documentation

Tr s r duite au strict n cessaire au

Livr e en quantit

profit des fonctionnalit s

importante sous forme dun

op rationnelles afin de recevoir les

Support de communication

feedbacks des clients.

et de validation.

Equipe

Une quipe soutenue par un chef

Une quipe compos e de

de projet o la communication et

ressources sp cialis es

linitiative sont les piliers du

dirig e par un chef de projet.

travail.

Livraison de la

G n ralement rapide et

G n ralement tardive.

solution

incr mentale.

Intervention du client Tr s fr quente lors de la mise en

Pratiquement inexistante, le

Suvre de la solution avec

client value le produit vers

proposition de changement si

la fin du projet.

souhait .

Mesure de succ s

Respect des engagements initiaux

Satisfaction du client

en termes de d lais, budgets, co ts

et qualit .

Table 2. M thodes AGILES Vs m thodes classiques

2.4 M thodologie adopt e

Apr s cette tude comparative, nous avons d cid dadopter la m thode Agile pour r aliser

Publicité

notre projet. Cette m thode est parfaitement coh rente avec les concepts de base du cycle de

vie dun Datawarehouse, un concept publi par le Ralph Kimball, qui se r sume en trois points

[8] :

" Ajouter une valeur m tier lentreprise.

" Stocker les donn es dans des dimensions.

" Concevoir une solution daspect it rative.

Les m thodes agiles sont de nature it rative et participative, on commence par d velopper des

petits morceaux dapplication qui apportent de la valeur ajout e, quon valide par le client puis

on passe aux suivants. Cest le client qui pilote au fur et mesure le d veloppement de la

solution travers le choix des fonctionnalit s quil souhaite voir d velopper.

La nature de ce processus est la cl de notre d cision. Appliquer lagilit sur un projet

d cisionnel permettra dimpliquer davantage lutilisateur et dassurer la valeur m tier pour

lorganisation.

Apr s avoir fix une m thode suivre pour la r alisation du projet, il est temps de choisir une

des m thodes de d veloppement Agile parmi celles cit es pr c demment.

2.5 Pr sentation de la m thodologie SCRUM

La m thodologie SCRUM est inspir e des valeurs et de lesprit du jeu Rugby. Cette approche

est issue des travaux des signataires du Manifeste Agile : Sutherland et Schwaben, et fait partie

de la famille des m thodologies incr mentales et it ratives.

Cette m thodologie est d finie dans un milieu de travail assurant la r alisation des projets

consid r s complexes. Cette m thode est apte principalement pour la mise ex cution des

projets software n anmoins, elle peut tre galement appliqu e tout autre type de projet, du

plus simple au plus innovant.

En utilisant les m thodologies classiques et unifi es, le client ne pouvait ni suivre l volution

du travail ni tre impliqu dans lex cution de son projet

En effet, en Scrum, le client est plus impliqu dans le suivi de lavancement du projet et

lapprobation de plusieurs livrables. Il peut donc suivre r guli rement l volution des travaux

dans le cas dune demande de modification dun l ment ou dinsatisfaction a sera plus facile

de le modifier pour satisfaire ses besoins.

La m thodologie SCRUM assure loptimisation de la pr visibilit dun projet et le contr le des

risques. [9]

2.6 Les intervenants dans Scrum

En comparant un projet s quentiel avec un projet agile, on note une diff rence aux niveaux des

missions et des responsabilit s des intervenants car une importance particuli re est accord e

sur lappropriation de tous les l ments sprint du projet par les membres de l quipe.

La m thodologie Scrum d finit trois r les [10] :

" Le Porduct Owner (PO)

Cest le porte-parole des clients charg de d finir soigneusement le backlog qui permet de

recueillir les besoins du client, les sp cifications du produit ainsi que toutes les fonctionnalit s

du projet r aliser. Le propri taire du produit est galement responsable de classer les l ments

du backlog par priorit et indiquer lordre de leur r alisation.

" Le Scrum Master

Cest la personne qui joue le r le dun animateur de l quipe. Il nest pas consid r comme un

chef de projet ou un donneur dordres mais plut t comme un coordinateur facilitateur qui assure

le bon d roulement du projet et veille r soudre les probl mes et les obstacles qui emp chent

lavancement du travail de son quipe.

" Le Scrum Team

Cest l quipe de d veloppement qui est responsable de d livrer les l ments de chaque sprint

selon leurs ordres de priorit s. Le groupe est constitu darchitectes, d veloppeurs

administrateur base de donn es etc.

2.7 Les art facts du Scrum [11]

" Product Backlog :

Le carnet des produits est d fini comme tant une liste ordonn e contenant les exigences et les

besoins du client et toutes les sp cifications relatives au produit. Le Porduct Owner est charg

du Product Backlog en termes de contenu, disponibilit et ordonnancement.

" Sprint Backlog :

Le sprint Backlog est un l ment indispensable pour la compr hension de la progression du

travail de l quipe de d veloppement. Chaque sprint doit r pondre aux attentes du Product

Owner et assure latteinte des objectifs pr alablement d finis au d but du Sprint. Il sagit dun

plan bien d taill de taches effectu es

" Sprint Burn-Down Chart :

Le graphique d'avancement est une repr sentation qui donne une vue globale sur l' volution de

quantit de travail restante par rapport au travail engag . Sur laxe vertical se situe le travail

restant. Laxe horizontal pr sente le temps. Ce type de graphique permet de pr voir l tat

davancement du travail pendant un laps de temps afin de suivre le d roulement de lactivit .

Figure 4. Vue globale du Scrum [12]

2.8 Lapproche SCRUM appliqu un projet BI

Le projet d cisionnel est un projet de type particulier. Il est non seulement complexe, mais aussi

il doit aussi r pondre parfaitement aux besoins volutifs des utilisateurs engag s de prendre des

d cisions cruciales dans un univers instable et changeant. Cela nest autre que la finalit de

Business Intelligence. Dailleurs, toute d cision est obligatoirement une prise de risque,

dautant plus critique calculer dans un environnement incertain. De ce fait, il est indispensable

dint grer et inclure au plus les utilisateurs lors de d veloppement de la solution. Pour cette

raison, la solution SCRUM agile est appel e lors de l laboration dun projet BI. Elle propose

en effet, plusieurs approches appliquer sur ce type de projet [13], Nous citons : [14]

" Lapproche de Kimball Bottom-Up

Dans cette approche, Le Data Warehouse est consid r comme tant lunion des datamarts

coh rents entre eux. Le Datawarehouse physique nexiste pas.

" Lapproche dInmon Top-Down

Dans cette approche, le Data Warehouse est un r f rentiel centralise stockant les donn es

relatives lentreprise au niveau le plus d taille. Par la suite, des Datamarts sont mod lis s et

cr es a partir de ce Data Warehouse.

Quant notre solution, nous avons adopt lapproche de conception top-down permettant

de mettre en place un r f rentiel centralis , le DW, puis charger de mani re coh rente les

datamarts. Cette approche est simple et r sistante lors de chargements des dimensions, ainsi

que lors de cr ations des magasins de donn es. En outre, elle est insensible et flexible aux

besoins des clients qui voluent au cours des phases de mise en Suvre.

3. Approche de conception de lentrep t de donn es

3.1 Mod les conceptuels

Dans cette section, nous allons choisir un sch ma de mod lisation de notre Datawarehouse.

Commen ons tout dabord par d finir les deux mod les quils existent [15] :

" Un sch ma en toile (Star Schema) est une structure dimensionnelle qui repr sente, au

centre, une seule table de faits dont les colonnes sont les mesures. La table de faits est

entour e par cercle de dimensions pr sentant les axes danalyse. Toute dimension

niveaux multiples est aplatie en une seule dimension. Le sch ma en toile est con u

pour r pondre des requ tes inh rentes la structure dimension-fait.

" Le principe du sch ma en flocon de neige est quils peuvent exister des hi rarchies de

dimensions, contrairement au sch ma en toile.

Pour notre solution, nous avons opt pour le mod le en flocon de neige qui permet de formaliser

une hi rarchie de dimensions, ce qui facilite lanalyse et r duit le volume des donn es.

3.2 Approches pour la cr ation du Datawarehouse (ROLAP, MOLAP,

HOLAP)

Il existe 3 possibilit s pour cr er un DW [16] :

" Relationnel OLAP (ROLAP) : Les donn es sont stock es dans un SGBD relationnel et

un moteur OLAP permet de stimuler le comportement du SGBD.

" Multidimensionnel OLAP (MOLAP) : Les donn es sont stock es dans un Cube qui

nest autre quune base de donn es multidimensionnelle qui permet la restitution des

donn es de fa on instantan e.

" Hybride OLAP (HOLAP) : LHOLAP est un m lange du ROLAP et du MOLAP, les

cubes HOLAP sont donc Hybrides.

Pour notre solution, nous avons opt pour HOLAP. Lid e consiste avoir la possibilit

dacc der aux donn es agr g es travers MOLAP, ou acc der aux d tails si souhait s travers

ROLAP. Cela pourra nous aider lors de la phase de restitution. Nous pourrons avoir un rapport

dont les donn es sont issues dune base multidimensionnelle, ainsi quun autre beaucoup plus

d taill dont les donn es sont issues, cette fois-ci, dune table relationnelle. [17]

4. Comparaison des outils d cisionnels

Nous allons pr senter dans c...