CycleDeVieProjetBI 3ppvvv

1/16/17
MTI820 − Entrepôts de données et intelligence d’affaires
Le cycle de vie d'un projet en intelligence d'affaires
Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Des ros iers 1
Question
• Quels sont les facteurs les plus déterminants pour la
réussite d’un projet de BI?
Besoins prioritaires en TI
1
1/16/17
Le succès d'un projet de BI

• Taux de réussite:
Critères de prédisposition
• Les 5 critères de succès (selon R. Kimball):
Critère Contribution
Le parrainage de la haute direction* 60 %
La motivation et la légitimité du changement* 15 %
La faisabilité* 15 %
Le partenariat entre les intervenants d’affaires et des TI 5 %
La culture analytique 5 %
*: critères indispensables
• Parrainage de la haute direction:
– Facteur critique au succès du projet;
– Caractéristiques d’un sponsor idéal:
• Conviction de l’impact potentiel de la solution de BI;
• Influence importante au sein de l’entreprise;
• Exigeant mais réaliste;
• Connaissance des concepts de base du BI est un atout;
• Vision axée sur le succès à long-terme du projet.
– Important d’avoir plusieurs sponsors dans le projet.
2
1/16/17
• Motivation et la légitimité du changement:
– Besoin urgent d’améliorer l’accès à de l’information de
qualité (ex: concurrence, nouvelle réglementation, etc.);
– Les projets de BI alignés avec des besoins d’affaires réels
ont de meilleures chances de réussir;
– Le projet est plus facilement justifiable lorsqu’il existe de
telles motivations.
• Faisabilité:
– Concerne principalement la disponibilité de données de
qualité:
• Niveau de détail (granularité) suffisamment fin;
• Effort raisonnable pour nettoyer et consolider.
– Se détermine à l’aide du profilage de données (profiling).
Question
• Quelle est la meilleure approche pour développer une
solution de BI ?
Approche top-down vs bottom-up

Caractéris tique Top-down (B. Inmon) Bottom-up (R. Kimball)
Objectifs Livrer une s olution Livrer une s olution permettant aux

technologiquement s aine bas ée s ur us ager d’obtenir facilement et
des méthodes et technologies rapidement des répons es à leurs
éprouvées des bas es de données requêtes d’analys e
Complexité de la méthode Plutôt complexe Plutôt s imple
Importance de la conception Importante Peu importante

phys ique
Orientation du modèle Orienté données Orienté proces s us d’affaires
Acces s ibilité des utilis ateurs Faible Forte

finaux
Outils de conception Traditionnels (diagrammes entité- Modélis ation dimens ionnelle
relation et flot de données ) (s chéma en étoile)
Auditoire principal Profes s ionnels en TI U tilis ateurs finaux
Source: E. Turban, R. Sharda, D. Delen et D. King (2010). « Bus ines s intelligence: A manegerial approach », Pears on.
Département de génie logiciel et des TI MTI820 Hiver 2011 – C. Des ros iers 9
3
1/16/17
Projet vs programme de BI
• Projet:
– Une seule itération dans le cycle de vie d’un projet de BI;
– A une date de début et de fin;
– Plus facile à planifier.
• Programme:
– Coordination de ressources, infrastructures et
communications sur plusieurs projets;
– Définition continuelle de nouveaux projets (pas de fin
abrupte);
– Plus difficile à planifier.
Le cycle de vie d’une solution BI

• Diagramme de flux de travail (DW Lifecycle, Kimball):
C o n ce p tio n d e Sé le ctio n e t
l’arch ite ctu re in stallatio n d e s C ro issan ce
te ch n iq u e p ro d u its
Dé fin itio n
P lan ificatio n C o n ce p tio n e t
d e s M o d é lisatio n C o n ce p tio n
d e p ro je t / d é ve lo p p e me n t Dé p lo ie me n t
b e so in s d e s d o n n é e s p h ysiq u e
p ro gramme d u systè me ETL
d ’affaire s
C o n ce p tio n d e s Dé ve lo p p e me n t
ap p licatio n d e d e s ap p licatio n s M ain te n an ce
BI de BI
Ge stio n d e p ro je t / p ro gramme
• Note: dépendance horizontale et verticale entre les activités;
Planification
– Fait interactivement avec la définition des besoins;
– Comprend:
• Définition de la portée;
• Recrutement;
• Identification, estimation et affectation
des tâches.
Dé fin itio n
P lan ificatio n
d e s
d e p ro je t /
b e so in s
p ro gramme
d ’affaire s
4
1/16/17
Question
• Comment détermine-t-on la portée d’un projet de BI?
La portée préliminaire du projet

• Dépend de:
– Le nombre de sujets d’analyse visés (ex: fonctions d’affaires,
régions, etc.)
– Le nombre et le type de sources de données brutes;
– L’approche employée pour charger les données des sources
dans l’entrepôt de données;
– Les règles d’affaires appliquées aux données sources lors de la
validation;
– Le contenu, le niveau de détail, et l’historique des données
sources;
– Les outils frontaux (front-end) d’intelligence d’affaires
employées pour l’analyse;
– La complexité architecturelle de l’environnement.
La portée préliminaire du projet

• Directives pour déterminer la portée:
– Définie en fonction de besoins spécifiques;
– Doit apporter une valeur d’affaires suffisante à l’entreprise,
tout en restant faisable;
– Doit être fait conjointement avec les représentants
d’affaires et ceux des TI.
• Document de portée du projet:

– Information de base sur le projet;
– Les inclusions et exclusions de la portée;
– Les critères de succès;
– Les risques et stratégies de gestion de risque.
5
1/16/17
Exemple de document de portée

Nom du projet
Information de bas e
BigCo dés ire maximis e r les r evenus p rov enan t de s es acti vités de pr omo tio n. P rés en tem ent , elle dé pens e
enviro n $4 0 milli on an nuell eme nt e n pu blicité . L’objecti f es t d e ré dui re les dé pens es r eliées aux ac tivit és
promotionnelle de 25% d’ici trois ans .
La pr ochain e p has e d u p roj et de BI p or te ra s u r l’in fo rma tio n p ro mo tion nelle, com plé men tan t le pr oje t
précé den t cons acré aux do nné es de vente. Les équi pes de vent e et de ma rketi ng aur on t accès à la fois aux
donn ées de ven te e t de p ro mo tion, per me tta nt ai ns i le dévelo ppe me nt de s t ra tégie p ro mo tion nelles pl us
efficaces .
Portée du projet:
• Trois années de données his toriques s ur les activités internes de promotion;
• Maximum de 25 utilis ateurs initialement, avec le plan d’augmenter la capacité à 150 utilis ateurs ;
• L’architecture technique s era bas ée s ur…
Exclus ions :
• Données externes , telles que les information s ur les ventes et promotions des principaux compétiteurs ;
• Support pour des programmes promotionnels non-domes tiques ;
• …
Critères de s uccès :
• U ne s eule s ource d’information employée pour les analys es reliées aux activités de promotion;
• Réduction du temps requis pour effectuer une analys e reliées aux activités de promotion;
• …
Ris ques et s tratégies de ges tion des ris ques :
• …
Question
• Comment justifie-t-on un projet de TI à la direction et aux
investisseurs de l’entreprise?
• Comment peut-on démontrer la valeur du projet à ceux-
ci?
Justification du projet
• Retour sur l’investissement (ROI):
ROI = Bénéfices − Dépenses.
• Investissements et coûts:
– Achat/mise à niveau de composantes matérielles:
• Ex: serveurs, réseau, HD, etc.
– Achat/mise à niveau de composantes logicielles:
• Ex: ETL, DBMS, analyse multidimensionnelle, etc.
– Embauches internes:
• Ex: analyste de données, DBA, directeur de projet, etc.
– Ressources externes:
• Ex: consultants, support technique de produits achetés, etc.
– Coûts de maintenance:
• Ex: frais de maintenance, support et croissance.
6
1/16/17
Justification du projet
• Bénéfices ($):
– Augmentation des revenus de vente;
– Meilleur taux de réponse aux envois publicitaires;
– Élimination des produits à faible marge de profit;
– Réduction des dépenses en marketing;
– Diminution du taux d’attrition;
– Réduction des cas de fraude;
– etc.
• Coûts et bénéfices estimés au stade de planification.
Exemple de ROI
• Qui:
– Compagnie IBM, complexe de production de semi-
conducteurs dans l'état de New-York;
• Défis:
– Satisfaire les besoins en rapports (reporting) des équipes
de production et d'ingénierie;
• Solution:
– SAS Business Intelligence;
– 600 utilisateurs;
– 100 sources;
– 100 Gb;
source: Nucleus Research Inc., 2007
Exemple de ROI
• Coûts et bénéfices:
• Bénéfices principaux:
– Réduction du temps de création de rapports;
– Amélioration de la qualité et la visibilité des données;
– Embauche d'employé en TI évitée;
• ROI: 386% (après 3 ans)

source: Nucleus Research Inc., 2007
7
1/16/17
Équipe d’un projet de BI

• Analogie avec une équipe de hockey:
P ro p rié taire ,
Sp o n so rs
P ré sid e n t
Dire cte u r gé n é ral Dire cte u r d e p ro je t
En traîn e u r ch e f,
C h e f d e p ro je t
En traîn e u r ad jo in t
An alyste d ’affaire s,
Gard ie n d e b u t, Arch ite cte d e d o n n é e s,
C e n tre s, An alyste e n QA,
Ailie rs, Ad min istrate u r d e B D,
Dé fe n se u rs Arch ite cte /d é ve lo p p e u r ETL,
Arch ite cte /d é ve lo p p e u r d ’ap p licatio n s B I
Sp é cialiste te ch n iq u e ,
Sp é cialiste e n sé cu rité ,
Un ité s sp é ciale s Sp é cialiste e n fo rage d e d o n n é e s,
C h argé d e s te sts,
Éd u cate u r
P artisan s Utilisate u rs

• Sponsor:
– Membre de la haute direction;
– Approuve les budgets;
– Défend le projet en cas de besoin.
• Directeur de projet:
– Sert de liaison entre les sponsors et les autres membres de
l’équipe;
– Responsable du leadership et de la direction du projet;
– Influence les décisions stratégiques et architecturelles.

• Chef de projet:
– Gère le projet au jour le jour:
• Coordination des ressources et des activités;
• Planification des tâches et des budgets;
• Suivi de l’état et de l’avancement du projet.
– Doit pouvoir réagir rapidement aux problèmes rencontrés,
avant que ceux-ci s’intensifient.
• Analyste d’affaires:
– Gère la collecte et la définition des besoins;
– Assure la juste représentation des besoins dans les autres
étapes du projet;
– Doit très bien connaître les processus d’affaires de
l’entreprise.
8
1/16/17

• Analyste en QA / intendant des données:
– Responsable d’établir une vue consolidée des définitions
et règles des données, à l’échelle de l’entreprise;
– S’assure que les données insérées dans l’entrepôt sont
valides et complètes;
– Peut également être responsable de vérifier l’intégrité des
applications de BI.
• Architecte de données:
– En charge de définir une architecture facilitant la
réutilisabilité, l’intégration et l’optimisation des données;
– Conçoit et développe le modèle dimensionnel des
données;
– Participe parfois à la collecte des besoins.

• Administrateur de BD (DBA):
– Responsable de convertir le modèle des données en
structures physiques de l’entrepôt (tables, colonnes, etc.);
– Choisit des paramètres physiques maximisant la
performance de l’entrepôt (ex: disposition des disques,
partitionnement, indexes, etc.)
– Gère l’intégrité, la disponibilité et la performance de
l’entrepôt au quotidien.
• Architecte/développeur ETL:
– Responsable de la conception et développement du
système ETL;
– Architecte est souvent impliqué dans la collecte des
besoins;

• Architecte/développeur d’application de BI:
– En charge de concevoir la couche d’interaction aux
données;
– Conçoit et développe les applications de BI, souvent à
l’aide de produits commerciaux;
– Configure la couche sémantique des outils de BI.
• Note:
– Un projet de BI comporte normalement tous ces rôles;
– Grand projets: plusieurs personnes peuvent avoir le même
rôle;
– Petits projets: une personne peut jouer plusieurs rôles.
9
1/16/17
Définition des besoins

• Étape critique à la réussite du projet;
• Se concentre sur les utilisateurs, et non les données;
• Identifie les besoins les plus prioritaires;
• Comprend:
– Entrevue des utilisateurs;
– Identification des processus d’affaires; C o n ce p tio n d e
– Préparation du document de description l’arch ite ctu re

te ch n iq u e
des besoins.
Dé fin itio n
P lan ificatio n
d e s M o d é lisatio n
d e p ro je t /
b e so in s d e s d o n n é e s
p ro gramme
d ’affaire s
C o n ce p tio n d e s
ap p licatio n d e
BI
Définition des besoins

• Processus d’analyse (Kimball):
Analys e
niveau programme
BP: processus d’affaires (business process)
Bes oins d’affaires

regroupés par BP
Sélection du BP
(matrice en bus ,
diagramme de
prioris ation)
Bes oins
BP Analys e fonctionnels , Développement
prioritaire niveau projet non fonctionnels , datamart
techniques
Modélisation des données

• Se base sur le document de description des besoins;
• Processus hautement itératif et dynamique;
• Vise la simplicité et l’efficacité;
• Comprend:
– Identification des faits et leur granularité;
– Identification des dimensions et leur hiérarchie;
– Stratégies: dénormalisation, gestion des changements, etc.
Dé fin itio n
M o d é lisatio n C o n ce p tio n
d e s b e so in s
d ’affaire s d e s d o n n é e s p h ysiq u e
10
1/16/17
Modélisation des données

d 'u tilisation
Ap pel service
R e p résentant
Matrice en bus
Lign e té l.
C an al d e
d e ve n te
P ro d u it
Emp lo yé
C lie n t
P ro ce ssu s / ve n te de données
R e lai
P lan
Date
Dime n sio n
Factu ratio n client X X X X X X
Ge stio n du trafic X X X X X X X
d ' ap p e ls
In ve n taire X X X
Se rvice à la X X X X X X X
clie n tè le
Schéma en étoile
(magasin de données)
Conception physique des données

• Utilise le modèle de données;
• Comprend:
– Détail du schéma relationnel (ex: clés, types, contraintes, etc.);
– Optimisation de la performance (ex: indexes, partitionnement,
agrégation, etc.);
– Gestion de la sécurité.
C o n ce p tio n e t
M o d é lisatio n C o n ce p tio n
d é ve lo p p e me n t
d e s d o n n é e s p h ysiq u e
d u systè me ETL
Conception physique des données

Requête analytique
SELECT SUM(Inve nt a i re . qu a nt i té )
FROM Inventa ir e , Produit , Fourniss eu r
WHERE Inventai r e. i d Pr o du i t = Produit. id AND
Inventar e .i d F ou r ni s se u r = Fourniss eu r .i d AND
Produit. c at é g or i e= ' mo t eu r _m a zd a ' AND
Fourniss e ur . p ro v in c e= ' QC '
Stratégie d’optimisation
(index jointure étoile)
CREATE BITMAP INDEX indexJoi nt u re ON
Inventai r e( F ou r ni s s eu r .p r ov i nc e , Produit .c a té g or i e)
FROM Inventa ir e , Fournis s eu r , Produit
WHERE Inventai r e. i d Pr o du i t = Produit. id AND
Inventar e .i d F ou r ni s se u r = Fourniss eu r .i d
11
1/16/17
Conception de l’architecture technique

• Définit la vision d’ensemble de la solution et l’intégration des
technologies du projet;
• Se concentre sur les besoins, pas les aspects techniques;
• Doit considérer:
– Environnement technique actuel;
– Directions stratégiques prévues.
• Comprend:
– Identification des besoins techniques;
– Création du plan d’architecture.
Dé fin itio n d e s C o n ce p tio n d e Sé le ctio n e t
b e so in s l’arch ite ctu re in stallatio n d e s
d ’affaire s te ch n iq u e p ro d u its
Conception de l’architecture technique
Sélection de
produits
Modèle architecturel
Conception et développement du système ETL

• Représente environ 70% des efforts et risques du projet;
• Doit considérer:
– Nombre et type des sources de données;
– Outils disponibles.
• Comprend:
– Identification et analyse des sources de données;
– Développement des méthodes d’extraction, de nettoyage et de
consolidation des données (code maison ou outils
commerciaux);
– Développement des méthodes d’insertion de données (ex:
scripts, outils complexes);
– Validation de la qualité des données. C o n ce p tio n
C o n ce p tio n e t
d é ve lo p p e me n t
p h ysiq u e
d u systè me ETL
12
1/16/17
Conception et développement du système ETL

Matrice de transformation
Cha m ps Ta ble Cha m ps Ta ble Rè gle de
c ible c ible s ourc e s ourc e tra ns form a tion
Flot de traitements / données (SSIS)
Conception et développement des applications BI

• Se fait en parallèle avec la modélisation des données et la
conception du plan d’architecture;
• Nécessite une interaction importante avec les utilisateurs;
• Comprend:
– Modélisation des tableaux de bord, rapports, indices de
performances (KPI) adaptés aux utilisateurs;
– Définition des modèles de prédiction, classification et clustering;
– Configuration des outils et des métadonnées;
– Implémentation du portail de navigation;
– Validation des applications.
Dé fin itio n d e s C o n ce p tio n d e s Dé ve lo p p e me n t d e s

b e so in s d ’affaire s ap p licatio n B I ap p licatio n s B I
Conception et développement des applications BI
Requêtes à accès
Bes oins analytiques direct, reporting,
et techniques data mining
Rapports s tandards
Portail de BI
Modèle phys ique

Applications
analytiques
Architecture Tableaux de bords

et s corecards
BI opérationnel
13
1/16/17
Gestion du projet
• Assure la coordination des activités du projet;
• Comprend:
– Suivi de l’avancement et de l’état du projet;
– Suivi des problèmes;
– Contrôle des changements (ex: portée du projet);
– Développement du plan de communication (affaires et TI).
Plan de projet
• Définit pour chaque activité:
– Ressources responsables;
– Les dates de début et de fin estimées (ne doivent pas être
modifiées);
– L’état courant (ex: future, en cours ou complétée);
– Les dates de début et de fin mises à jour;
– Le nombre de jours de retard;
– Le % complété;
– Les dépendances (autres tâches).
Plan de projet
14
1/16/17
Déploiement
• Point de convergence des activités de développement;
• Ne doit pas être fait avant d’avoir:
– Matériel de formation des utilisateurs;
– Mécanismes de gestion et de suivi d’erreurs;
– Documentation complète;
– Validation des données et outils;
– Processus efficace de communication.
Maintenance et croissance
• Assure le fonctionnement optimal du système et prévoit
l’ajout de nouvelles fonctionnalités;
• Comprend:
– Suivi de l’utilisation et réglages de performance (tuning);
– Sauvegarde et récupération des données;
– Support aux utilisateurs;
– Préparation de nouveaux cycles de développement.
Questions
• Quels les risques potentiels d’un projet de BI?
15
1/16/17
Risques selon Kimball

• Ne pas pouvoir recruter un sponsor influent et visionnaire
provenant de la haute direction;
• En faire trop en même temps, au lieu d’employer une
approche de développement itérative centrée sur un sujet à la
fois;
• Être séduit par la technologie, au lieu de se concentrer sur les
objectifs et les besoins de l’entreprise;
• Supposer qu’il est possible de développer le projet sans
l’apport des membres d’affaires;
Risques selon Kimball (suite)

• Aller de l’avant avec le projet, même si les données source
sont de piètre qualité ou n’ont pas été validées;
• Faire la conception d’un entrepôt de données comme s’il
s’agissait d’une BD transactionnelle (ex: normalisation);
• Sous-estimer la quantité de travail reliée au nettoyage et la
consolidation des données;
• Accorder trop d’importance au système ETL, au détriment de
la performance et la qualité des applications de BI (et vice-
versa).
Questions
• À quoi correspond le développement Agile?
• Quels sont les avantages/inconvénients de ce mode de
développement?
16
1/16/17
Le développement en mode agile [1/2]

• Philosophie Agile:
« Si un projet doit se solder par un échec, mieux vaut le
savoir après 1 seul mois, qu’après 15 mois »
– Jeffries, Anderson et Hendrickson (2000). Extreme Programming Installed.
• Principes de base des méthodes agile:

– Se concentrer sur les besoins prioritaires;
– Développer en itérations/prototype;
– Petites équipes;
– Collaboration soutenue entre l’équipe de développement
et les clients;
– La livraison est plus importante que le processus;
– Documentation : seulement le nécessaire.
Le développement en mode agile [2/2]

• Agile vs Développement en cascade:
Les entrepôts de données en mode agile [1/3]

• Exemple d’itérations de développement agile
ITÉRATION 1: ITÉRATION 2: ITÉRATION 3: ITÉRATION 4:
D éfinition des bes oins D éfinition de la portée D évelopement de la Intégration de la
s olution s olution
D urée 1-2 mois 1-2 mois 4-8 mois 1-2 mois
Livrable Prototype Solution BI Solution complète Solution complète livrée

75% Bes oins 25% Bes oins 5% Bes oins 5% Bes oins
25% Conception 50% Conception 10% Conception 10% Conception
Proces s us
0% Développement 15% Développement 50% Développement 50% Développement
0% Tes t 10% Tes t 35% Tes t 35% Tes t
50% U tilis ateur 50% U tilis ateur 25% U tilis ateur 100% U tilis ateur
100% Architect 100% Architecte 100% Architecte 100% Architecte
25% Lead technique 100% Lead technique 100% Lead technique 100% Lead technique
0% Sp. modélis ation 50% Sp. modélis ation 100% Sp. modélis ation 50% Sp. modélis ation
Res s ources
0% Développeur ETL 0% Développeur ETL 100% Développeur ETL 50% Développeur ETL
0% Développeur BI 50% Développeur BI 100% Développeur BI 50% Développeur BI
100% Sp. tes ts 100% Sp. tes ts
100% Chef livrais on
Accès utilis ateurs Accès utilis ateurs
Accès utilis ateurs Données d’analys e Données d’analys e
Technologie Accès utilis ateurs Données d’analys e
N ettoyage et trans fert N ettoyage et trans fert
Données s ource Données s ource Données s ource
17
1/16/17

• Avantages vs inconvénients:
Avantages Inconvénients
• Livraison plus rapide de la • Peut développer des silos de
solution; données;
• Réduction des coûts; • Potentiel de réduire:
• Évite d’avoir des besoins o Qualité de données;
obsolètes. o Stabilité du système;
o Partage d’information.

• Solution: Integrated Sandboxing*:
– Créer un environnement de prototype (Sand box);
– Administration de données flexible et allégée;
– Copie de production / fédération des données;
– Ramener les données rapidement sans trop de
formalisme;
– Gouvernance;
– Déploiement en production;
*: S. Brobst, M. McIntire et E. Rado (2008). Agile Data Warehousing with Integrated Sandboxing,
Business Intelligence Journal, vol. 13, no. 1.
18

CycleDeVieProjetBI 3ppvvv

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CycleDeVieProjetBI 3ppvvv

Transféré par

Droits d'auteur :

Formats disponibles

1/16/17

MTI820 − Entrepôts de données et intelligence d’affaires

Le cycle de vie d'un projet en intelligence d'affaires

Le succès d'un projet de BI

Approche top-down vs bottom-up

Objectifs Livrer une s olution Livrer une s olution permettant aux

Importance de la conception Importante Peu importante

Acces s ibilité des utilis ateurs Faible Forte

Le cycle de vie d’une solution BI

• Note: dépendance horizontale et verticale entre les activités;

La portée préliminaire du projet

La portée préliminaire du projet

• Document de portée du projet:

Exemple de document de portée

• ROI: 386% (après 3 ans)

Équipe d’un projet de BI

Dire cte u r gé n é ral Dire cte u r d e p ro je t

Équipe d’un projet de BI

Équipe d’un projet de BI

Équipe d’un projet de BI

Équipe d’un projet de BI

Équipe d’un projet de BI

Définition des besoins

– Préparation du document de description l’arch ite ctu re

Définition des besoins

Bes oins d’affaires

Modélisation des données

Modélisation des données

Conception physique des données

Conception physique des données

Conception de l’architecture technique

Conception de l’architecture technique

Conception et développement du système ETL

Conception et développement du système ETL

Flot de traitements / données (SSIS)

Conception et développement des applications BI

Dé fin itio n d e s C o n ce p tio n d e s Dé ve lo p p e me n t d e s

Conception et développement des applications BI

Modèle phys ique

Architecture Tableaux de bords

Risques selon Kimball

Risques selon Kimball (suite)

Le développement en mode agile [1/2]

• Principes de base des méthodes agile:

Le développement en mode agile [2/2]

Les entrepôts de données en mode agile [1/3]

D urée 1-2 mois 1-2 mois 4-8 mois 1-2 mois

Livrable Prototype Solution BI Solution complète Solution complète livrée

Les entrepôts de données en mode agile [2/3]

Les entrepôts de données en mode agile [3/3]

Vous aimerez peut-être aussi