Monografia FDWS

UNIVERSIDADE FEDERAL DA BAHIA
INSTITUTO DE MATEMTICA
DEPARTAMENTO DE CINCIA DA COMPUTAO
Mauricio Cesar Santos da Purificao
FDWS: Uma Metodologia para Gerncia e

Desenvolvimento de Projetos geis de Business
Intelligence
Salvador - Bahia
2010-2
Mauricio Cesar Santos da Purificao
FDWS: Uma Metodologia para Gerncia e

Desenvolvimento de Projetos geis de
Business Intelligence
Monografia apresentada ao curso de

bacharelado em Cincia da Computao do
Departamento de Cincia da Computao
da Universidade Federal da Bahia, como
requisito para obteno do grau de Bacharel
em Cincia da Computao.
Orientadora: Profa . Vaninha Vieira dos Santos
Salvador - Bahia
2010-2
AGRADECIMENTOS
Agradeo em primeiro lugar a Deus, pois sem ele nada do que foi feito poderia ter sido
realizado. Finalizar esta monografia foi uma tarefa rdua e se no houvesse f e a certeza da
ajuda divina no seria possvel conclu-la.
Como est escrito em: (Provrbios 21.31) "O cavalo prepara-se para o dia da batalha, mas
do SENHOR vem a vitria." A Ele eu dedico a concluso dessa monografia e toda a honra,
como s ele digno de receber. Amm !
Agradeo tambm a meus pais: Rosenaide Vitria Santos da Purificao e Paulo Cesar
Pereira da Purificao, por me possibilitarem acreditar que heris existem. Sim, posso dizer,
vocs so meus heris e depois de Deus devo tudo o que tenho e sou a vocs. Minhas vitrias
so fruto da luta e do suor de vocs tambm. Sei bem as dificuldades e os sacrifcios que os dois
enfrentaram para me educar e garantir que eu possa ter um futuro abenoado. No posso deixar
de incluir minhas Tias Dilma e Neide por todas as horas de jejum e orao e a minha famlia
em geral pela fora, apoio e carinho.
A Professora Dra. Vaninha Vieira dos Santos, orientadora desta monografia, pelo apoio,
dedicao, broncas, muitos puxes de orelha, cobranas, sempre de forma gentil e adequada
para o desenvolvimento deste trabalho. Posso dizer que o profissional que sou hoje muito
diferente daquele quando eu lhe conheci e isto fruto do trabalho que tivemos em conjunto e
de toda a nossa interao. Te agradecer por tudo muito pouco. Valeu pelo aprendizado, pelo
amadurecimento, pela amizade e pela parceria. Professora Dra. Christina von Flach Garcia
Chave e a Me. Karla Carvalho de Aleluia por terem aceitado participar da banca de defesa desta
monografia e por todas as contribuies dadas a este trabalho.
Chris, um agradecimento especial, pelo tempo que fui teu monitor em Engenharia de Software, nem tenho palavras para dizer o quanto foi bom trabalhar contigo e o quanto lhe admiro
pela figura humana que tu s. Obrigado por tudo !
Fao um agradecimento em especial a equipe do SIAC, que muito mais do que uma equipe,
tornou-se uma famlia pra mim. Vivaldo, Andr, Helder, Mrio, Fernando... vocs foram fundamentais na execuo deste trabalho. Agradeo muito a ajuda, a fora, a pacincia de cada um
de vocs. No posso deixar de citar aqui, o grande mestre Antnio, exemplo de ser humano,
chefe e profissional, muito obrigado pelo exemplo de vida.

Falando de SIAC e CPD, tenho de citar muitas pessoas aqui, Aninha, Heraldo, Juliana,
Marcel (muito obrigado com o Abstract dessa monografia), Andr Andrade, Rosinha, o pessoal
que assistiu minha defesa (Alan, Carlinha...) (Como bom ter amigos !!!) entre outros. Cada
um de vocs contribuiu tanto para este trabalho, como para minha formao.
Agradeo tambm aos alunos da disciplina Tpicos em Banco de Dados dos semestres de
2009-2 e 2010-2, a Gustavo pela amizade, parceria e companherismo na monitoria da disciplina,
a equipe do Projeto Permanecer, Hugo e Marcondes... como foi bom trabalhar com vocs e aos
membros do DW-UFBA (Joo e Elane).
Agradeo de um modo geral a todos os que passaram em minha vida, amigos, colegas,
conhecidos... (Caso eu tenha esquecido de citar nomes, me perdoem...) Como diria Charles
Chaplin: "Cada pessoa que passa em nossa vida, passa sozinha, porque cada pessoa nica
e nenhuma substitui a outra. Cada pessoa que passa em nossa vida passa sozinha, e no
nos deixa s, porque deixa um pouco de si e leva um poquinho de ns. Essa a mais bela
responsabilidade da vida e a prova de que as pessoas no se encontram por acaso."
RESUMO
Solues de Business Intelligence (BI) so de grande importncia para os gestores das empresas e dos seus responsveis de TI devido aos benefcios advindos de sua implementao e
uso, referentes a melhoria do processo decisrio das organizaes, como por exemplo, companhias privadas e instituies de ensino como a Universidade Federal da Bahia (UFBA). Porm,
a implementao de solues de BI uma misso difcil por causa dos ambientes de Tecnologia
da Informao (TI) altamente complexos e grandes volumes de dados no-integrados oriundos de bases distintas sejam estas externas ou internas. Alm disso, as abordagens tradicionais
de desenvolvimento de solues de BI como Kimball (KIMBALL, 2002) no possibilitam que
os gestores das empresas experimentem os benefcios destas solues a curto prazo e muitas
vezes os projetos encerram-se sem ter havido nenhum resultado visvel aos gestores da organizao. Nesse contexto surgem os conceitos de Agile BI e Agile Data Warehousing, que nada
mais so do que a aplicao de prticas advindas das metodologias geis no universo do desenvolvimento de solues de BI. O conceito de Agile BI ultrapassa a fronteira da metodologia
e interfere em vrios outros aspectos do desenvolvimento das solues como, por exemplo, a
arquitetura da soluo e o prprio comportamento das ferramentas usadas durante o processo.
Este trabalho apresenta a especificao de uma metodologia para gerncia e desenvolvimento
de projetos geis de BI usando prticas combinadas das metodologias Extreme Programming
(XP), SCRUM e Feature Driven Development (FDD) de modo a atender ao requisito metodologia e processo de desenvolvimento sob o conceito de Agile BI. O uso dessa metodologia foi
avaliado em dois projetos realizados na disciplina "Tpicos em Banco de Dados"do Departamento de Cincia da Computao da Universidade Federal da Bahia (DCC-UFBA) e no projeto
Permanecer DW-UFBA. Os resultados de sua aplicao so explicitados e analisados.
Palavras-chave: Business Intelligence, Data Warehouse, Mtodologias geis, SCRUM,
FDD, XP, Agile Data Warehousing, Agile BI.
ABSTRACT
Business Intelligence(BI) solutions is a great importance for business managers and their IT
managers due to the arising benefits from their implementation and use, regarding the improvement of making decisions for organizations, for example, private companies and institutions
of education such as Federal University of Bahia (UFBA). However, the implementation of BI
solutions is a difficult task because of the environments of Information Technology (IT) highly
complex and large volumes of non-integrated data coming from these different external or internal bases. Moreover, traditional approaches to development of BI solutions such as Kimball
(KIMBALL, 2002) do not enable business managers to experience the benefits of these short-term
solutions and often the projects are close without having been visible results to managers of the
organization. In this context the concepts of Agile BI and Agile Data Warehousing, which are
nothing more than the application of practices from the world of agile development of BI solutions. The concept of Agile BI surpass the border of the methodology and interfere other aspects
of the development of solutions, for example, the architecture solution and the actual behavior
of the tools used during the process. This paper presents the specification of a methodology
for management and development of agile BI projects using combined practical methodologies
of Extreme Programming (XP), Scrum and Feature Driven Development (FDD) to meet the
requirement of the methodology and process of development under the Agile BI concept. The
use of this methodology was evaluated in two projects in the course "Topics in Database"of the
Department of Computer Science of the Federal University of Bahia (DCC-UFBA) and into the
project Permanecer DW-UFBA. The results of its application are described and analyzed.
Keywords: Business Intelligence, Data Warehouse, Agile Methodologies, SCRUM, FDD,
XP, Agile Data Warehousing, Agile BI.
LISTA DE FIGURAS
1
Arquitetura de BI - Viso Simplificada. Adaptado de (COSTA; ANCIES, 2001).
22
Viso Geral de um Data Mart (COSTA; ANCIES, 2001). . . . . . . . . . . . . .
22
Exemplo de Arquitetura de Povoamento e Descrio das Atividades de ETL

(COSTA; ANCIES, 2001). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Exemplo de Modelo Estrela (CRAMER, 2006). . . . . . . . . . . . . . . . . . .
26
Exemplo de Modelo Floco De Neve (CRAMER, 2006). . . . . . . . . . . . . . .
27
Exemplo de Cubo Multidimensional (CRAMER, 2006). . . . . . . . . . . . . .
28
Etapas comuns aos Mtodos. Adaptado de (S, 2009). . . . . . . . . . . . . .
31
Mtodo Kimball (CARVALHO, 2009). . . . . . . . . . . . . . . . . . . . . . . .
32
Viso Geral do Processo SCRUM (MARAL, 2009). . . . . . . . . . . . . . . .
37
10
Exemplo de Product Burndown exibindo o consumo de story points de cada

sprint (CAVALCANTI, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
39
Exemplo de Sprint Burndown exibindo o consumo de horas das tarefas durante

a sprint (CAVALCANTI, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
12
Ciclo de vida de um projeto com o FDD (HEPTAGON, 2010). . . . . . . . . . .
41
13
Ciclo Semanal em XP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
14
Ciclo de Desenvolvimento Agile Data Warehousing. Adaptado de (HUGHES,

2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
48
Exemplo de trs ciclos de desenvolvimento curtos, ou "semanais"(CARVALHO,

2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
16
Ciclo Tradicional de Desenvolvimento na Plataforma Pentaho . . . . . . . . .
53
17
FDWS - Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
18
FDWS - Ciclo de Vida - Viso Geral . . . . . . . . . . . . . . . . . . . . . . .
65
19
FBS Verso Original (VERSION-ONE, 2010). . . . . . . . . . . . . . . . . . . .
67
20
FBS Adaptada ao FDWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
21
FDWS - Planejamento do Projeto - Processo . . . . . . . . . . . . . . . . . . .
68
22
FDWS - Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . .
74
23
Matriz de Necessidades (OLIVEIRA, 2010). . . . . . . . . . . . . . . . . . . . .
75
24
FDWS - Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
25
FDWS - Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
26
Atividades da etapa de Percepo. Adaptado de (S, 2009). . . . . . . . . . . . 109
27
Atividades da etapa de Concepo. Adaptado de (S, 2009). . . . . . . . . . . 111
28
Atividades da etapa de Entrega. Adaptado de (S, 2009). . . . . . . . . . . . . 112
29
Atividades da etapa de Operao. Adaptado de (S, 2009). . . . . . . . . . . . 113
30
Atividades da etapa de Ajustes/Melhorias. Adaptado de (S, 2009). . . . . . . 113
31
Avaliadores por sexo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
32
Avaliadores por escolaridade . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
33
Avaliadores por tempo de experincia em BI e DW . . . . . . . . . . . . . . . 127
34
Avaliadores por nvel de conhecimento em Prticas geis . . . . . . . . . . . . 127
35
Avaliadores por nvel de conhecimento na Metodologia SCRUM . . . . . . . . 127
36
Avaliadores por nvel de conhecimento na Metodologia XP . . . . . . . . . . . 128
37
Avaliadores por nvel de conhecimento na Metodologia FDD . . . . . . . . . . 128
38
FDWS - Planejamento do Projeto - Mapeamento das Etapas e Metodologias de

Origem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
39
FDWS - Planejamento da Release - Mapeamento das Etapas e Metodologias de

Origem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
40
FDWS - Iterao - Mapeamento das Etapas e Metodologias de Origem . . . . . 132
41
FDWS - Ps-Iterao - Mapeamento das Etapas e Metodologias de Origem . . 132
42
Objetos de Fluxo Bsicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . 134
43
Objetos de Conexo da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . 134
44
Artefatos Bsicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . . 135
45
Elementos de Raia da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . 135
46
Representao de Uma Atividade em Diferentes Nveis de Granularidade (TESSARI,
2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
47
Tipos de Eventos BPMN de Incio para um BPD (TESSARI, 2008). . . . . . . . 136
48
Tipos de Eventos BPMN Intermedirios para um BPD (TESSARI, 2008). . . . . 137
49
Exemplo de Evento Intermedirio Anexado a uma Atividade (TESSARI, 2008). . 137
50
Tipos de Evento BPMN para o Trmino de um Processo (TESSARI, 2008). . . . 138
51
Tipos de Elementos do Tipo Gateway na BPMN (TESSARI, 2008). . . . . . . . 138
52
FDWS - Planejamento do Projeto: Anlise Organizacional . . . . . . . . . . . 140
53
FDWS - Planejamento do Projeto: Criar/Priorizar FBS do Projeto . . . . . . . 141
54
FDWS - Planejamento do Projeto: Projeto de Arquitetura Tcnica . . . . . . . 142
55
FDWS - Planejamento do Projeto: Projeto de Arquitetura Tcnica - Anlise de

Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
56
FDWS - Planejamento do Projeto: Plano de Projeto . . . . . . . . . . . . . . . 144
57
FDWS - Planejamento do Projeto: Montagem da Equipe . . . . . . . . . . . . 145
58
FDWS - Planejamento da Release: Levantar Requisitos da Release . . . . . . . 146
59
FDWS - Planejamento da Release: Desenvolver Modelo Abrangente da Release 147
60
FDWS - Planejamento da Release: Criar/Priorizar Release Backlog . . . . . . . 148
61
FWDS - Planejamento da Release: Criar Plano de Sprints . . . . . . . . . . . . 149
62
FDWS - Iterao: Detalhar Funcionalidade . . . . . . . . . . . . . . . . . . . 150
63
FDWS - Iterao: Projeto Fsico . . . . . . . . . . . . . . . . . . . . . . . . . 151
64
FDWS - Iterao: Projeto de Metadados . . . . . . . . . . . . . . . . . . . . . 152
65
FDWS - Iterao: Projeto de ETL . . . . . . . . . . . . . . . . . . . . . . . . 153
66
FDWS - Iterao: Projeto da Aplicao de BI . . . . . . . . . . . . . . . . . . 154
67
FDWS - Iterao: Validao e Verificao . . . . . . . . . . . . . . . . . . . . 155
LISTA DE TABELAS
2
Descrio das Etapas do Planejamento do Projeto Executadas no Projeto Permanecer DW-UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Descrio das Etapas do Planejamento da Release Executadas no Projeto Permanecer DW-UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Descrio das Etapas da Iterao Executadas no Projeto Permanecer DW-UFBA 117
Descrio das Etapas da Ps-Iterao Executadas no Projeto Permanecer DWUFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Descrio das Etapas do Planejamento do Projeto Executadas na Disciplina

Tpicos em Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Descrio das Etapas do Planejamento da Release Executadas na Disciplina

Tpicos em Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Descrio das Etapas da Iterao Executadas na Disciplina Tpicos em Banco

de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Descrio das Etapas da Ps-Iterao Executadas na Disciplina Tpicos em

Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
LISTA DE ABREVIATURAS E SIGLAS
BI
Business Intelligence (Inteligncia de Negcios),

17
BPD
Business Process Diagrams (Diagramas de Processos de Negcio), 133
BPMI
The Business Process Management Initiative,

133
BPMN
Business Process Modeling Notation (Notao

para Modelagem de Processos de Negcio), 133
CIOs
Chief Information Officers (Diretores de Tecnologia da Informao), 17
CLF
Construir a Lista de Funcionalidades, 41
CPD-UFBA
Centro de Processamento de Dados da UFBA, 89
CPF
Construir por Funcionalidade, 42
DCC-UFBA
Departamento de Cincia da Computao da

Universidade Federal da Bahia, 89
DM
Data Mart, 24
DMA
Desenvolver um Modelo Abrangente, 40
DMs
Data Marts, 21
DPF
Detalhar por Funcionalidade, 41
DW
Data Warehouse, 17
ETC
Extrao, Transformao e Carga, 21
ETL
Extract, Transform and Load, 21
FBS
Feature Breackdown Structure, 66
FDD
Feature Driven Development, 18
OLAP
On-Line Analytical Processing (Processamento

Analtico Online), 24
PPF
Planejar por Funcionalidade, 41
TI
Tecnologia da Informao, 17
WBS
Work Breakdown Structure, 50
XP
Extreme Programing, 18
SUMRIO
Introduo
17
1.1
Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.2
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.3
Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
Conceitos
20
2.1
Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.2
Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.2.1
Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.2.2
ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.2.3
Modelagem Multidimensional . . . . . . . . . . . . . . . . . . . . . .
25
2.2.4
OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.3
2.4
Metodologias para Gerncia e Desenvolvimento de Projetos de Data Warehousing 28

2.3.1
Abordagens para Implementao de um DW . . . . . . . . . . . . . .
30
2.3.2
Modelo Geral de Processo para Data Warehousing . . . . . . . . . . .
31
2.3.3
Mtodo Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
Metodologias geis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.4.1
SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.4.1.1
Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.4.1.2
Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.4.1.3
Papis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.4.1.4
Medio de Progresso . . . . . . . . . . . . . . . . . . . . .
39
2.4.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
2.4.2.1
Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . .
40
2.4.2.2
Papis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
2.4.3.1
Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.4.3.2
Papis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
2.4.3
2.5
3
FDD
Avaliao de Trabalhos Relacionados
48
3.1
Agile Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.2
Extreme Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.2.1
Planejamento do Processo . . . . . . . . . . . . . . . . . . . . . . . .
50
3.3
Aplicao de Prticas geis na Criao de Data Warehouse Evolutivo . . . . .
51
3.4
Agile BI - Pentaho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.5
Aplicao de Prticas geis em Projetos de BI . . . . . . . . . . . . . . . . . .
53
3.6
Anlise dos Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . .
56
3.7
Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Metodologia FDWS
59
4.1
Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.2
Papis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.2.1
Gerncia de Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.2.2
Gerncia de Negcio . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.2.3
Ncleo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . .
62
Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.3.1
Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.3.1.1
69
4.3
Anlise Organizacional . . . . . . . . . . . . . . . . . . . .
4.3.2
4.3.3
Criar/Priorizar FBS do Projeto . . . . . . . . . . . . . . . .
70
4.3.1.3
Projeto de Arquitetura Tcnica . . . . . . . . . . . . . . . .
71
4.3.1.4
Plano de Projeto . . . . . . . . . . . . . . . . . . . . . . . .
72
4.3.1.5
Montagem dos Times . . . . . . . . . . . . . . . . . . . . .
72
Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.3.2.1
Levantar Requisitos da Release . . . . . . . . . . . . . . . .
75
4.3.2.2
Desenvolver Modelo Abrangente da Release . . . . . . . . .
76
4.3.2.3
Criar/Priorizar Lista de Funcionalidades da Release . . . . .
77
4.3.2.4
Criar Plano de Iteraes . . . . . . . . . . . . . . . . . . . .
77
4.3.2.5
Revisar Arquitetura Tecnolgica/Ferramentas . . . . . . . .
78
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.3.3.1
Configurao do Ambiente de Testes, Produo e Homologao 78
4.3.3.2
Configurao de Ferramentas . . . . . . . . . . . . . . . . .
78
4.3.3.3
Criar Verso de Teste, Produo e Homologao . . . . . . .
78
4.3.3.4
Detalhar Funcionalidades . . . . . . . . . . . . . . . . . . .
80
4.3.3.5
Projeto Fsico . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.3.3.6
Projeto de Metadados . . . . . . . . . . . . . . . . . . . . .
81
4.3.3.7
Projeto de ETL . . . . . . . . . . . . . . . . . . . . . . . .
81
4.3.3.8
Projeto da Aplicao de BI . . . . . . . . . . . . . . . . . .
82
4.3.3.9
Validao e Verificao (Testes Integrados) . . . . . . . . . .
82
4.3.3.10 Implantao no Ambiente de Homologao . . . . . . . . .
83
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Anlise da Metodologia FDWS . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.4.1
Papis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.4.2
Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
4.4.3
FDWS e os Trabalhos Relacionados . . . . . . . . . . . . . . . . . . .
88
4.3.4
4.4
4.3.1.2
Estudo de Caso
89
5.1
Projeto Permanecer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.1.1
89
5.1.2
90
5.1.3
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.1.4
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
Tpicos em Banco de Dados - Semestre 2010-2 . . . . . . . . . . . . . . . . .
93
5.2.1
93
5.2.2
94
5.2.3
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.2.4
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.3.1
Execuo da Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.3.2
Anlise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.2
5.3
Concluso
99
6.1
Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2
Dificuldades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.3
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Referncias
103
Apndice A -- Modelo Geral de Processo para Data Warehousing
107
A.1 Percepo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

A.2 Concepo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.3 Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.4 Operao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
A.5 Ajustes/Melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Apndice B -- Anlise dos Estudo de Caso
114
B.1 Aplicao da Metodologia FDWS no Projeto Permanecer DW-UFBA . . . . . 114

B.1.1
Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.1.2
Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.1.3
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.1.4
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.2 Aplicao da Metodologia FDWS na Disciplina Tpicos em Banco de Dados . 118

B.2.1
Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.2
Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.3
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.4
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Apndice C -- Questionrio de Avaliao da Metodologia FDWS
123
C.1 Informaes Pessoais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

C.2 Questionrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Apndice D -- Perfil dos Avaliadores
126
Apndice E -- Especificao e Modelagem da Metodologia FDWS
129
E.1 Mapeamento dos Subprocessos e Atividades da Metodologia FDWS de Acordo

com as Metodologias de Origem . . . . . . . . . . . . . . . . . . . . . . . . . 129
E.2 Modelagem da Metodologia FDWS . . . . . . . . . . . . . . . . . . . . . . . 133
E.2.1
E.2.2
Descrio da Notao BPMN . . . . . . . . . . . . . . . . . . . . . . 133

E.2.1.1
Elementos Bsicos da Notao . . . . . . . . . . . . . . . . 133
E.2.1.2
Refinamento dos Elementos . . . . . . . . . . . . . . . . . . 135
Diagramas de Processo da Metodologia FDWS . . . . . . . . . . . . . 138
17
INTRODUO
Este captulo apresenta a motivao para este trabalho, discute seus objetivos e os resultados
que se pretende alcanar com sua realizao e descreve a estrutura deste documento.
1.1
MOTIVAO
Solues de Inteligncia de Negcios (BI, do ingls Business Intelligence) possibilitam uma

melhora significativa no processo decisrio das organizaes ao oferecer informaes teis, de
modo rpido e facilitado, a partir dos prprios dados existentes nelas. Por isso, continuam a ser
de grande prioridade para os gestores das empresas e dos seus responsveis de Tecnologia da
Informao (TI) (NBREGA, 2010).
Porm, segundo (FAYYAD, 2003 apud FERNNDEZ; MAYOL; PASTOR, 2008, p. 1) a grande
maioria destes projetos tm falhado em conseguir seus objetivos. Este fato no estranho
tratando-se de sistemas de suporte a deciso e da imaturidade da disciplina de BI com uma
diversidade de enfoques metodolgicos diferentes (PRESTON, 2003).
De acordo com (NBREGA, 2010) no relatrio da Forrester Research intitulado "Agile BI
Out of the Box", realizado a partir de um estudo com empresas dos Estados Unidos, os utilizadores empresariais de aplicaes de BI esto largamente insatisfeitos com a falta de agilidade e flexibilidade das solues desenvolvidas. Segundo o relatrio, necessrio criar uma
nova forma de conceber e construir as aplicaes de BI, defendendo que o processo tradicional
de recuperao de informaes sobre todas as fontes de dados, documentao de todos os atributos, criao do Data Warehouse (DW) baseado nos dados recolhidos e a compilao de especificaes para aplicaes de BI nem sempre uma abordagem suficiente para enfrentar os
desafios colocados pelos complexos ambientes de TI dos dias de hoje e pelas necessidades dos
seus utilizadores.
Para muitos Diretores de Tecnologia da Informao (CIOs do ingls Chief Information Officers), apesar do desejo das corporaes, conseguir empregar aplicativos novos e inovadores de
18
BI ainda um desafio. Isso porque, atualmente, na rede das empresas existem grandes volumes
de dados inseridos em ambientes complexos de TI que no conversam entre si. Consequentemente, o departamento de tecnologia tem enfrentado obstculos para suprir as necessidades dos
usurios por solues intuitivas e aplicaes de fcil utilizao (WAILGUM, 2010).
Outro detalhe importante que os clientes esto cada vez mais impacientes para obter os
benefcios do BI, seja por causa do aumento da competitividade da economia global ou por que
j perceberam como o desenvolvimento de solues de BI pode ser um processo demorado.
A maioria dos clientes enxerga um grande risco nas abordagens tradicionais, onde os projetos
tendem a demorar meses e meses para mostrarem os primeiros resultados (HUGHES, 2007).
Devido a este cenrio, o relatrio da Forrester Research defende uma abordagem definida
como "Agile BI"para a construo de solues de BI. O conceito de "Agile BI"no difere muito
das metodologias geis de desenvolvimento de software, o que demanda a criao de solues
em pequena escala (WAILGUM, 2010), com uma maior proximidade dos clientes e resultados
efetivos mais rpidos.
O uso de metodologias geis tambm defendido por (HUGHES, 2007) no que pode ser
chamado de "Agile Data Warehousing", como forma de tornar as equipes de desenvolvimento de
DW: um dos componentes de solues de BI, mais rpidas e eficazes. Ainda segundo (HUGHES,
2007) o uso do "Agile Data Warehousing"influi diretamente nos prazos de entrega, na qualidade
da aplicao desenvolvida e na reduo dos custos de produo.
Apesar de alguns esforos j existentes, o alinhamento de prticas geis com o desenvolvimento de solues de BI um grande desafio. Os mtodos geis foram concebidos para gerncia
e desenvolvimento de projetos de software e no de projetos de integrao de dados, como so
os projetos de BI. Existe uma diversidade de metodologias que podem ser utilizadas de acordo
com as adaptaes necessrias para o suporte a projetos de integrao de dados.
1.2
OBJETIVOS
O objetivo geral deste trabalho especificar uma metodologia para gerncia e desenvolvimento de projetos geis de BI derivada do SCRUM, com a composio de prticas advindas das
metodologias geis Feature Driven Development (FDD) e Extreme Programming (XP) . Para
tanto tem-se os seguintes objetivos especficos:
Investigar os processos tradicionais de construo de solues de BI.
Investigar a utilizao de metodologias geis nos processos de construes de solues
19
de BI.
Investigar, analisar e selecionar as prticas das metodologias SCRUM, FDD e XP a serem
instaciadas no universo do processo de construo de solues de BI.
Especificar uma metodologia para gerncia e desenvolvimento de projetos geis de BI
derivado das metodologias SCRUM, FDD e XP.
Realizar estudos de caso a partir do uso da metodologia especificada e avaliar seu uso
a partir dos feedbacks das equipes de desenvolvimento e dos stakeholders dos projetos
desenvolvidos.
1.3
ESTRUTURA DO TRABALHO
Alm deste captulo introdutrio este documento est organizado nos seguintes captulos:
O Captulo 2 fornece uma viso geral dos principais conceitos relacionados a este trabalho: BI, DW, Metodologias geis e Metodologias para Data Warehousing;
No Captulo 3 realizada uma anlise dos trabalhos relacionados a esta monografia, a fim
de oferecer uma base de comparao com a metodologia proposta neste trabalho;
O Captulo 4 trata do detalhamento e especificao da metodologia FDWS;
No Captulo 5 so detalhados os estudos de casos realizados e a avaliao da aplicao
da metodologia proposta;
Por fim, o Captulo 6 apresenta a concluso deste trabalho, bem como destaca as suas
principais contribuies e definies para trabalhos futuros.
20
CONCEITOS
2.1
BUSINESS INTELLIGENCE
BI pode ser visto como um processo sistemtico de aquisio, tratamento e anlise de informaes em que os dados internos e externos da empresa so integrados para gerar informao
pertinente para o processo de tomada de deciso. O papel do BI criar um ambiente informacional com processos atravs dos quais os dados operacionais possam ser coletados, tanto dos
sistemas transacionais como de fontes externas, e analisados, revelando dimenses "estratgicas"do negcio (PETRINI; FREITAS; POZZEBON, 2006).
A necessidade do cruzamento e anlise de informaes para uma plena gesto organizacional uma realidade no apenas de nosso tempo, mas tambm de pocas passadas. O interesse
pelo tema BI iniciou-se no ano de 1996, devido ao avano tecnolgico que possibilitou a criao
de ferramentas para captao, extrao, armazenamento, filtragem, disponibilizao e personalizao de dados. O mesmo tem crescido na medida em que se descobre no BI uma soluo para
os problemas relacionados a tomada de deciso dentro das corporaes (INTEL, 2010). No geral
as empresas no dispem de uma informao acionvel e instrumentos analticos necessrios
para melhorar os lucros e desempenho, sendo portanto ricas em dados e probres em informao.
O BI surge ento como uma resposta para esta necessidade (WILLIAMS; WILLIAMS, 2007).
Considerando o termo BI, vale considerar em que sentido a palavra inteligncia relaciona-se
com o ambiente de negcios. De acordo com (PETRINI; FREITAS; POZZEBON, 2006), inteligncia o resultado de um processo que comea com a coleta de dados. A explicao sobre como
as organizaes adquirem "inteligncia"reside na transformao dado-informao-inteligncia.
Os dados referem-se a uma descrio elementar de coisas, eventos, atividades e transaes que
so registrados, classificados e armazenados, mas no so organizados para transmitir qualquer
significado. Por exemplo, em uma empresa de vendas podemos ter dados armazenados relativos ao cadastro de produtos, cadastro de clientes e vendas realizadas. A partir destes dados
contextualizados mediante sua transformao e consolidao podemos obter informaes a respeito das vendas dos clientes, produtos mais vendidos e comparativos de vendas por perodos.
21
Por fim, a inteligncia eleva a informao a um nvel mais alto, como resultado do completo
entendimento de aes, contextos e decises. As solues de BI, realizam o ciclo de transformao dado-informao-inteligncia, de modo a melhorar o processo de tomada de decises
dentro das organizaes, que com o BI deixam de ser apenas ricas em dados e tornam-se ricas
em "inteligncia".
Vrias iniciativas tm recebido o nome de BI, devido ao fato de o mesmo constituir-se por
uma vasta categoria de software e solues para coleta, consolidao, anlise e disseminao
de informaes visando melhorar o processo decisrio. No existe, portanto um modelo de
soluo fechado para BI. BI pode, ento, englobar um grande grupo de aplicaes ou solues
diferenciadas contanto que elas possibilitem a melhoria do processo de tomada de decises
por meio de processos realizados nos dados uniformizados da organizao (PETRINI; FREITAS;
POZZEBON,
2006).
Analisando a Figura 1, podemos visualizar uma arquitetura tradicional para solues de

BI. Segundo esta arquitetura, temos basicamente dois componentes representados pela Arquitetura Tcnica de Povoamento e pela Arquitetura de Acesso aos Dados. A Arquitera Tcnica de
Povoamento define como os dados oriundos dos sistemas operacionais (fontes de dados externas e internas) so carregadas no DW atravs do processo de Extrao, Transformao e Carga
(ETC) (do ingls Extract, Transform and Load (ETL)). No processo de ETL, os dados operacionais so uniformizados, selecionados, transformados, e carregados no DW da soluo de
BI.
A Arquitetura de Acesso aos Dados define como os dados armazenados no DW sero acessados pelos usurios. Por exemplo, pode-se construir Data Marts (DMs) (Figura 2), que so
como um DW armazenando dados a nveis departamentais ou vnculados a reas especficas do
negcio, de modo que caso o DW necessite de algum suporte ou manuteno os departamentos
continuem acessando seus dados nos respectivos DMs. Por conseguinte, um novo processo de
ETL ser realizado para que do DW possa se dar carga nos dados dos DMS. Alm desses dois
componentes, existe uma camada de metadados que engloba toda a soluo. Os metadados
devem possibilitar o registro de todas as informaes sobre os dados como suas origens e os
processos de transformao sofridos. So de extrema importncia dentro do ambiente de DW,
pois representam uma viso integrada das bases de dados que fazem parte deste ambiente. So
utilizados para construir, manter, gerenciar e utilizar o DW (COSTA; ANCIES, 2001).
A Figura 2 ilustra como a partir de um DW podem ser gerados diversos DMs de acordo
com os departamentos ou as res de negcio existentes. Enquanto o DW concentra os dados de
toda a organizao, cada DM serve a um departamento ou rea de negcio especfica.
22
Figura 1: Arquitetura de BI - Viso Simplificada. Adaptado de (COSTA; ANCIES, 2001).
Figura 2: Viso Geral de um Data Mart (COSTA; ANCIES, 2001).
23
2.2
DATA WAREHOUSE
Segundo (INMON, 1997) a definio de DW : "uma coleo de dados orientada por assuntos, integrada, variante no tempo, e no voltil, que tem por objetivo dar suporte aos processos
de tomada de deciso".
Orientado por assunto: Os dados no esto mais organizados de acordo com as regras de
negcios dos sistemas, mas sim de acordo com as reas de interesse da organizao. Por
exemplo: vendas de produtos a diferentes tipos de clientes, atendimentos e diagnsticos
de pacientes, rendimento de estudantes, produo cientfica de professores e grupos de
pesquisa, ndices de aprovao e reprovao.
Integrado: Diferentes nomenclaturas, formatos e estruturas das fontes de dados precisam
ser agrupados em um nico esquema para prover uma viso unificada e consistente da
informao. Por exemplo, um sistema pode tratar o gnero das pessoas como masculino
e feminino, outro como m e f. Ao serem passados para a base do DW estes dados devero
ser unificados para um nico esquema de apresentao.
Variante no tempo: Ao contrrio dos sistemas transacionais, os dados em um DW no
sofrem constantes atualizaes, eles so armazenados periodicamente o que permite que
os mesmos possam ser analisados historicamente.
No voltil: Os dados de um DW em geral no so modificados como em sistemas
transacionais (exceto para correes), mas somente carregados e acessados para leituras,
com atualizaes apenas peridicas.
Nos sistemas transacionais busca-se otimizar ao mximo a performance de acesso s transaes, j em um DW o que se prioriza a qualidade da informao que pode ser consultada
em tempo hbil pelos gestores, analistas e executivos. O DW torna-se ento o ponto central da
arquitetura proposta para uma soluo de suporte a tomada de decises na medida em que consolida as informaes necessrias para o processo de tomada de decises atravs de um alicerce
slido de integrao de dados corporativos e histricos para a realizao de anlises gerenciais (INMON; HACKATHORN, 1997). Para constru-lo necessrio combinar as necessidades de
informaes de uma comunidade de usurios com os dados que realmente esto disponveis
(KIMBALL, 2002).
24
2.2.1
DATA WAREHOUSING
Data Warehousing um conjunto de tecnologias de suporte a deciso destinadas a possibilitar que as pessoas que trabalhem a partir de informaes (gerentes, analistas, executivos)
possam tomar melhores decises mais rapidamente (DAYAL; CHAUDHURI, 1997). O Data Warehousing possibilita ento a integrao das fontes de dados transacionais na construo do DW
que pode ser usado ou no com o objetivo final de suportar analses gerenciais, o que amplia o
escopo do Data Warehousing chegando no nvel do conceito de BI.
Pode-se considerar o Data Warehousing como um processo fundamental na construo de
solues de BI pois oferece o suporte necessrio s ferramentas que sero utilizadas para a
anlise dos dados, como o Processamento Analtico Online (OLAP do ingls On-Line Analytical Processing) e a Minerao de Dados (do ingls Data Mining 1 ). Porm, para construir uma
soluo de BI no necessariamente necessita-se realizar o processo de Data Warehousing, isto
pode ser feito a partir de uma planilha eletrnica por exemplo, sem que tenha-se o trabalho de
realizar qualquer processo de integrao de dados.
O Data Warehousing um elemento que potencializa a construo de solues de BI pois
fornece s ferramentas de anlise dados uniformizados e integrados, diminuindo o risco da
realizao de anlises gerenciais a partir de dados incorretos e no contextualizados. Observase que os termos Data Warehousing e BI so tratados como sinnimos na literatura devido
a proximidade de seus conceitos. Desenvolver uma soluo de Data Warehousing tambm
desenvolver uma soluo de BI, caso esta soluo destine-se a servir para o processo de tomada
de decises a partir das anlises gerenciais realizadas. Na metodologia proposta neste trabalho o
termo BI utilizado neste sentido, pois a soluo de BI construda com sua aplicao baseada
em Data Warehousing para a melhoria do processo de tomada de decises gerenciais.
2.2.2
ETL
O ETL constitui-se como um elemento bsico para a construo de um DW. Os dados que
sero armazenados no DW provm de vrias bases que no esto integradas e, alm disso,
podem ter sido modeladas de maneiras extremamente diferentes. Para tanto crucial que tais
dados passem por um processo de ETL para enfim serem utilizados no projeto de DW.
As operaes relacionadas ao ETL referem-se inicialmente a extrao dos dados das bases
1 Data
Mining uma das etapas no Processo de Descoberta do Conhecimento que consiste na aplicao de
algoritmos de anlise de dados e descoberta de conhecimento a fim de encontrar padres e modelos sobre os dados
(FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996).
25
dos sistemas transacionais, em segunda instncia a transformao destes dados de modo a

integr-los e resolver problemas relacionados a modelagens diferentes como, por exemplo, um
sistema que defina o gnero de uma pessoa como masculino e feminino e outro sistema que defina o mesmo item como m ou f. No DW todos os dados advindos de sistemas diferentes devem
ser uniformizados e tal uniformizao s garantida no processo de transformao dos dados.
A ltima operao a ser realizada a carga dos dados depois de extrados e transformados no
DW ou no Data Mart (DM) do projeto.
Os conceitos relacionados ao ETL parecem simples, mas o xito do processo de design
e implementao do ETL de vital importncia para o sucesso do projeto de DW. Segundo
estatsticas, em um projeto de DW, o processo de ETL pode consumir at 70% do esforo de
todo o trabalho (DAYAL et al., 2009). A Figura 3 ilustra uma arquitetura bsica para ETL e as
principais atividades envolvidas: Extrao, Transformao e Carga.
Figura 3: Exemplo de Arquitetura de Povoamento e Descrio das Atividades de ETL (COSTA;

ANCIES, 2001).
2.2.3
MODELAGEM MULTIDIMENSIONAL
Os requisitos de uma modelagem para DW so diferentes das aplicaes do ambiente

transacional. Para um DW dever haver uma extensa flexibilidade nas anlises a serem su-
26
portadas. As medidas a serem realizadas necessitam ser vistas sob diferentes perspectivas (ou
seja, atravs de vrias dimenses) e o entendimento e a visualizao de problemas tpicos no
universo das organizaes devem ser facilitados.
O modelo multidimensional surge como uma tcnica que responde a estes requisitos e auxilia no processo de anlise de dados que descrevem aspectos comuns de negcios. Um modelo
multidimensional possui trs elementos bsicos: Fatos, dimenses e medidas. Um fato uma
coleo de itens de dados implementados sobre tabelas de fatos que representam um item de
negcio, sendo composto por dados de medida e de contexto. Uma dimenso constitui-se como
os elementos que fazem parte de um determinado fato. Por exemplo, para um dado fato vendas de um produto teramos as dimenses: tempo, local, clientes e vendedores. As medidas
constituem-se como os valores numricos que representam os fatos.
Considerando a modelagem multidimensional, podemos modelar nossos dados sob dois
esquemas bsicos: modelo estrela (star scheme) (Figura 4) e floco-de-neve (snow-flake scheme)
(Figura 5).
Figura 4: Exemplo de Modelo Estrela (CRAMER, 2006).

No modelo estrela temos uma entidade central denominada fato e entidades menores ao redor desta denominadas dimenses, no modelo floco-de-neve ao contrrio do modelo estrela as
tabelas de dimenses encontra-se todas normalizadas (DAYAL; CHAUDHURI, 1997). O modelo
floco-de-neve possibilita a diminuio da redundncia de dados que pode ser bastante alta no
modelo estrela, porm este modelo aumenta a complexidade do esquema e dificulta as implementaes por parte das ferramentas de anlises de dados e at mesmo a compreenso por parte
dos usurios. O modelo estrela contribui para o ganho de desempenho mesmo que este ganho
seja a custo de maior espao de armazenamento.
27
Figura 5: Exemplo de Modelo Floco De Neve (CRAMER, 2006).
2.2.4
OLAP
A tecnologia OLAP possibilita s organizaes um mtodo de acesso, visualizao, e

anlise de dados corporativos com alta flexibilidade e desempenho. Deste modo, as ferramentas
OLAP permitem a gerao de relatrios, anlise de um grande volume de dados e a obteno
de informaes estratgicas que podem facilitar a tomada de deciso (ARAJO; BATISTA; MAGALHES,
2007). O termo OLAP refere-se a um conjunto de ferramentas voltadas para acesso
e anlise ad-hoc de dados, com o objetivo final de transformar dados em informaes capazes
de dar suporte s decises gerenciais de forma amigvel, flexvel e em tempo hbil ao usurio
(ARAJO; BATISTA; MAGALHES, 2007).
Segundo (ANZANELLO, 2002), OLAP mais do que uma aplicao, uma soluo de ambiente, integrao e modelagem de dados. Os dados utilizados pela soluo OLAP so originrios
de um DW ou simplesmente de um DM. Para formular a topologia e o projeto de uma soluo
OLAP multidimensional as seguintes perguntas devem ser feitas: Quando?, O qu?, Onde? e
Quem ?. Essas perguntas formam a base de todos os arrays multidimensionais (estruturas de
dados que armazenam os valores em mais de uma dimenso). A obteno dos dados originrios
das respostas destinada aos DW e, da, possivelmente para um ou vrios Data Marts (DMs).
Podemos definir um cubo de dados como uma representao intuitiva do fato, por que todas
as dimenses coexistem para todo o ponto no cubo e so independentes entre si. Alm disso,
so nos cubos multidimensionais que so gravados os valores quantitativos e as medidas das
informaes armazenadas.
28
Figura 6: Exemplo de Cubo Multidimensional (CRAMER, 2006).
2.3
METODOLOGIAS PARA GERNCIA E DESENVOLVIMENTO DE PROJETOS DE DATA WAREHOUSING
Nesta seo sero discutidas algumas das abordagens tradicionais existentes na literatura
para a gerncia e desenvolvimento de projetos de BI que envolvem Data Warehousing (Na
literatura essas metodologias so descritas apenas como metodologias para Data Warehousing,
apesar da relao existente entre Data Warehousing e BI como sinnimos, por isto o termo Data
Warehousing foi mantido).
A aplicao de metodologias geis em BI tem sido motivada devido a alguns problemas
que tem sido observados com estas abordagens:
1. Envolvimento com os clientes, usurios e patrocinadores do projeto. Se em projetos de
desenvolvimento de software tal envolvimento importante, em BI, este envolvimento
uma dos grandes fatores que possibilitam o sucesso do projeto;
2. Escopo do projeto muitas vezes grande demais, resultando em projetos caros e difceis
de implementar. O ideal que se inicie o projeto com um pequeno prottipo do que ser
a soluo de BI;
3. Demora na entrega de funcionalidades aos clientes. Muitos projetos de BI so encerrados
sem que os gestores tenham tido resultados satisfatrios;
4. Avaliao inicial e foco estratgico do projeto. Muitos projetos de BI falham por no
ter sido feito um planejamento adequado de acordo com as necessidades emergentes do
29
negcio;
5. Mudanas organizacionais (cultura organizacional). Projetos de BI acabam transformando a cultural organizacional. Dependendo de como o processo feito, essa mudana
de cultura pode trazer um impacto muito grande na instituio. A soluo de BI deve
ser experimentada e utilizada aos poucos de modo que a cultura antes existente possa ser
moldada aos poucos;
6. Ferramentas de consulta. Os gestores e usurios finais, precisam de tempo para experimentar e avaliar as ferramentas de consulta e explorao das informaes. O conjunto de
ferramentas utilizado deve ser flexvel e atender s necessidades do negcio;
7. Extensibilidade e adaptao a mudanas. Mudanas de requisitos so frequentes, principalmente em projetos de BI. O processo de desenvolvimento deve responder bem a
quaisquer tipo de mudanas, seja esta feita em qualquer fase do projeto. Alm disso,
a soluo desenvolvida deve ser projetada de modo que possa estar sempre em espanso, pois novas consultas sempre sero solicitadas desde que os gestores e usurios finais
percebam os benefcios da soluo de BI;
8. ETL. O processo de ETL altamente custoso. Integrar muitas bases pode demorar um
longo tempo. O ideal reduzir o escopo, diminuindo assim a complexidade do processo;
9. Qualidade dos dados. Um dos itens mais importantes em projetos de BI a anlise da
qualidade dos dados. Para tanto, testes exaustivos devem ser realizados a cada passo de
desenvolvimento, assim como testes automatizados de todo o processo.
Uma metodologia para Data Warehousing define como o DW deve ser construdo e implementado, mapeando assim os resultados esperados das vrias atividades e tcnicas adotadas na
construo e projeto de Data Warehousing (S, 2009). No existe, por enquanto, um consenso
em termos de qual seja a melhor metodologia e em que cenrios uma ou outra mais adequada.
Existem, portanto, na literatura, vrias propostas metodolgicas e estudos de caso de aplicaes.
Em alguns casos a metodogia de Data Warehousing est ligada com uma proposta de arquitetura para o DW. De um modo geral podemos agrupar as metodologias de Data Warehousing
em dois grupos que tambm correspondem a abordagens de arquitetura: Abordagem top-down
e Abordagem bottom-up.
30
2.3.1
ABORDAGENS PARA IMPLEMENTAO DE UM DW
A abordagem Top-Down defendida por Inmon (INMON, 1997) e define basicamente duas
etapas para a implementao de DW. Na primeira etapa realizada a especificao do esquema
de todo o DW. Na segunda etapa, feita a construo de DMs de acordo com as caractersticas
e particularidades de cada rea do negcio/departamento (S, 2009).
Um dos maiores problemas dessa abordagem que realizar o levantamento de todos os
requisitos do DW em uma nica etapa extremamente difcil devido a dimenso do negcio
que est sendo trabalhada e a dificuldade em se extrair os requisitos de usurio.
O maior defensor da abordagem Bottom-Up Ralph Kimball (KIMBALL, 2002). Segundo
esta abordagem, o DW deve ser concebido iterativamente a partir da construo de DMs que
sero posteriormente integrados dando origem ao DW. Deve existir um cuidado intenso na
definio dos esquemas dos DMs, pois os mesmos devero ser integrados posteriormente. Deste
modo a concepo de cada modelo deve ser feita pensando-se nesta posterior integrao. Em
(S, 2009) so indicadas quatro abordagens que podem ser utilizadas para se determinar o
modelo de dados de um DW e por conseguinte seu contedo: abordagem orientada a dados,
orientada aos objetivos, orientada aos utilizadores e orientada aos processos:
Orientada a dados: Segundo esta abordagem o modelo de dados do DW deve ser
derivado diretamente dos modelos de dados transacionais. Isto por que os usurios do DW
so incapazes inicialmente de formular as necessidades informacionais antes de perceberem e experimentarem as capacidades do DW. Por isso, em um primeiro momento, os
requisitos de usurio so ignorados vindo a ser percebidos apenas aps o lanamento de
uma primeira verso do mesmo;
Orientada aos objetivos: Esta abordagem consiste, inicialmente, em recolher e identificar os objetivos organizacionais. Esses objetivos podem ser identificados a partir de
entrevistas com stakeholders nos processos organizacionais e que sero posteriormente
quantificados em indicadores que permitam avaliar o desempenho do processo;
Orientada aos utilizadores: Segundo esta abordagem devem ser coletados as necessidades e expectativas dos futuros utilizadores do DW. Os requisitos de usurio so, portanto, colhidos e documentados servindo de base para a construo do modelo de dados
do DW;
Orientada a processos: Segundo esta abordagem os processos essenciais da organizao devem ser identificados. A partir dos processos mapeados devem ser definidos os
31
indicadores de desempenho desejados.

Existem, ainda, na literatura propostas que fazem a juno dessas abordagens de modo a
melhorar o processo de definio do modelo de dados do DW.
2.3.2
MODELO GERAL DE PROCESSO PARA DATA WAREHOUSING
Em (S, 2009), o autor realiza uma anlise entre algumas metodologias de implementao
de DW: Mtodo Kimball (KIMBALL, 2002), NCR/Teradata (NCR-TERADATA, 2007), Microsoft
(CRAIG; VIVONA; BERKOVITCH, 1999), SAS (BROWN, 2000), Iterations, (PRISM-SOLUTIONS,
2002) e identifica algumas etapas metodolgicas comuns a estes mtodos que podem ser visualizadas na Figura 7. Essas etapas so detalhas no Apndice A.
Figura 7: Etapas comuns aos Mtodos. Adaptado de (S, 2009).
Percepo: a etapa de identificao e definio de requisitos, arquitetura, modelos,

aplicaes analticas, aplicaes e ferramentas de apoio bem como a ordem em que as
iteraes do processo devero ser realizadas;
Concepo: considerada a etapa mais tcnica, pois onde o DW construdo;
Entrega: Consiste em colocar o sistema de DW em produo, obrigando a montagem de
toda a estrutura de apoio ao funcionamento do sistema de DW, isso inclui a documentao
e a formao/suporte aos utilizadores;
Operao: Consiste em garantir que o Sistema de DW est a funcionar, cumprindo com
os requisitos para os quais foi implementado;
Ajustes/Melhorias: Esta etapa pode ser subdividida em duas atividades. A primeira
atividade consiste em monitorar o funcionamento do sistema de DW de forma a eliminar
anomalias e melhorar seu desempenho. A segunda atividade consiste em recuperar sugestes e reclamaes dos utilizadores, atravs dos canais de suporte montados na etapa
de Entrega, que podero ser transformados em novos requisitos.
32
A partir da definio destas etapas (S, 2009) define um modelo geral de processo para Data
Warehousing e uma recomendao de metodologia para que um processo de Data Warehousing
possa obter sucesso. O processo definido por (S, 2009) detalhado no Apndice A.
2.3.3
MTODO KIMBALL
O mtodo de Kimball um dos mtodos mais referenciados em termos acadmicos e profissionais, por isto foi incluido neste captulo. O modelo geral do processo est descrito na
Figura 8. Esse mtodo iterativo e defende que a construo do DW seja incremental a partir
da contnua construo/integrao de DMs. Suas etapas so:
Figura 8: Mtodo Kimball (CARVALHO, 2009).
1. Planejamento do Projeto: Esta etapa engloba o seguinte conjunto de atividades (CARVALHO,
2009): Anlise inicial do ambiente, definio do escopo e data de entrega, mon-
tagem da equipe, definio do cronograma de atividades da iterao, definio de um

plano de comunicao para a equipe. Durante esta etapa devem ser avaliados e identificados: o nvel de preparao da organizao para ter um sistema de DW, os riscos
associados, patrocinadores, motivao e cultura organizacionais (S, 2009).
2. Especificao de Requisitos de Negcio: Nesta etapa os requisitos funcionais e nofuncionais devem ser coletados a partir de entrevistas com analistas de negcio, gestores,
executivos e membros da rea de TI. A partir da coleta, anlise e especificao dos requisitos existem trs grupos de atividades que podem ser executados em paralelo. Estes
grupos correspondem exatamente trilha da tecnologia, trilha dos dados e trilha das aplicaes de BI.
33
3. Trilha da Tecnologia: Consiste na sequncia de passos necessrios a implantao da

infra-estrutura tcnica. Assim, o desenho tcnico do ambiente precisa ser projetado, ferramentas e utilitrios devem ser definidos e tudo precisa ser devidamente configurado e
testado (CARVALHO, 2009). Engloba as seguintes atividades:
Projeto da Arquitetura Tcnica: Todo o conjunto de tecnologias que sero necessrias
quando o DW estiver em produo e em uso devem ser definidas, incluindo, por
exemplo, as ferramentas, os utilitrios e as plataformas necessrias para que o fluxo
dos dados ocorra (CARVALHO, 2009).
Escolha e Configurao de Ferramentas: Subdivide-se em dois eixos principais:
A criao do plano de arquitetura, que tem como meta a efetiva implantao da
arquitetura de todo o ambiente e, a seleo de produtos, cujo objetivo selecionar as
ferramentas mais adequadas a cada necessidade identificada no plano de arquitetura
(CARVALHO, 2009).
4. Trilha dos Dados: Compreende as etapas de modelagem dimensional, projeto fsico e
extrao, transformao e carga no DW (ETL).
Modelagem Dimensional: Promove a definio do modelo de dados (modelagem
dimensional) do DW;
Projeto Fsico: Esta atividade executada aps a modelagem dimensional sendo realizada a partir dos seguintes passos: Definio de padres de desenvolvimento para
os diversos componentes do sistema de DW e BI, desenvolver o modelo fsico de
dados, instanciar a base relacional para a execuo dos testes de ETL, desenvolver o
modelo inicial de indexao dos dados, definio das politicas de segurana, auditoria e criao da rea de stagging2 , desenvolver a base OLAP, definio de agregaes
e criao da base fsica.
Projeto do ETL e Desenvolvimento: No trabalho de Kimball so descritos trinta e
quatro subsistemas que, juntos, definem as diversas frentes de trabalho em um ambiente de desenvolvimento de ETL. Estes subsistemas se dividem em quatro subcategorias, que so extrao de dados, limpeza e padronizao dos dados, entrega dos
dados para apresentao e gerenciamento do ambiente de ETL (CARVALHO, 2009).
2A
rea de stagging consiste numa rea de armazenamento temporrio dos dados antes que os mesmos sejam
carregados em um DM ou DW, servindo para a movimentao dos mesmos a partir de bases de dados diferentes
(COSTA; ANCIES, 2001).
34
5. Trilha das Aplicaes de BI: Podemos listar algumas categorias bsicas de aplicaes
de BI que vo desde acessos convencionais ad-hoc por consultas SQL at relatrios prdefinidos e dashboards3 , capazes de apresentar uma viso global de desempenho dos
processos de negcio em uma interface unificada (CARVALHO, 2009). O desenvolvimento
destas aplicaes so iniciadas logo aps a especificao de requisitos, primeiro com a
compreenso dos relatrios mais utilizados pelos usurios e, em seguida, pelo desenho
dos primeiros relatrios e aplicaes que sero desenvolvidos (CARVALHO, 2009). A
Trilha das Aplicaes de BI compreende as seguintes atividades:
Projeto de Aplicaes de BI: Com a ajuda do pessoal de negcio os desenvolvedores
devem listar os principais relatrios que possam ser fornecidos pela aplicao de BI
e que tragam valor ao negcio de modo que os modelos para estes relatrios possam
ser criados e documentados.
Desenvolvimento da Aplicao de BI: A partir da especificao dos relatrios, os
mesmos podem ser implementados pela equipe de desenvolvimento.
6. Integrao e Implantao: Na atividade de integrao todos os sistemas desenvolvidos
so colocados no mesmo ambiente para a execuo de testes globais. So realizados testes
de qualidade de dados, testes das operaes do processo, testes de desempenho, testes de
implantao, testes de acessibilidade de usurios. Aps a realizao da bateria de testes
pode se realizar a implantao do que foi desenvolvido na iterao.
7. Manuteno: Nesta etapa o sistema de DW monitorado de modo a garantir seu pleno
funcionamento, desde as atividades de back-end como as de front-end. Novas solicitaes
de desenvolvimento podem ser avaliadas e deve-se oferecer suporte especializado aos
utilizadores do sistema.
8. Crescimento: Aps a entrada em produo e a montagem da estrutura de manuteno e
suporte, a expanso do DW o primeiro grande desafio que o gerente do projeto enfrenta.
natural que a verso que acaba de entrar em produo contemple bem alguma rea,
que logo pedir novos relatrios, enquanto outras reas so menos atendidas e solicitam
novos desenvolvimentos (CARVALHO, 2009).
9. Gerenciamento do Projeto: Suas atividades esto relacionadas com todo o processo de
engenharia de DW. Dentre as atividades de gerenciamento durante o desenvolvimento do
projeto esto a conduo das reunies de equipes, o sincronismo entre todas as frentes
3 Painel
com um conjunto de indicadores grficos que, por estar num formato visual, facilita a compreenso e
assimilao das informaes. Geralmente estes indicadores grficos so integrados entre si (ALMEIDA, 2010).
35
de desenvolvimento e monitorao das atividades com frequente acompanhamento do

cronograma geral.
2.4
METODOLOGIAS GEIS
As metodologias geis surgem como uma resposta s crescentes presses por inovao
em prazos cada vez mais reduzidos, s necessidades de constantes mudanas de requisitos e
ao mau desempenho de grande parte dos projetos de desenvolvimento de software. Por conta
desses fatores, houve um movimento na comunidade de desenvolvimento de software, que deu
origem aos mtodos geis. Posteriormente, o conceito chave deste movimento evoluiu, de uma
abordagem tcnica para o mbito gerencial, criando um novo enfoque de gerenciamento de
projetos que pode ser denominado de Gerenciamento gil de Projetos (DIAS, 2005).
Os mtodos geis de desenvolvimento de software surgiram como uma reao aos mtodos
clssicos de desenvolvimento e do reconhecimento da necessidade preeminente de se criar uma
alternativa a estes "processos pesados", caracterizados pelo foco excessivo na criao de uma
documentao completa a respeito do produto a ser desenvolvido (BECK et al., 2001). No ano
de 2001, dezessete (17) especialistas em processos de desenvolvimento de software representando as metodologias SCRUM, XP e outras, estabeleceram princpios comuns compartilhados
por todos esses mtodos. Foi ento constitudo o "Manifesto gil". O termo "Metodologias
geis"torna-se ento popular atravs do estabelecimento do manifesto (BECK et al., 2001). Os
conceitos chave do "Manifesto gil"so:
Indivduos e interaes sobre processos e ferramentas;
Software executvel sobre documentao;
Colaborao do cliente sobre negociao de contratos;
Respostas rpidas a mudanas sobre seguir planos.
Traando um comparativo com os chamados mtodos clssicos de desenvolvimento de
software, podemos observar que os mtodos geis priorizam os itens situados a esquerda na
declarao deste manifesto. Isto no significa que os itens a direita sejam desprezados. A
grande diferena quanto ao foco e a importncia que estes itens recebem em contraposio
aos mtodos clssicos de desenvolvimento de software.
36
Muitos especialistas criaram mtodos prprios para se adaptar s constantes mudanas

exigidas pelo mercado e as indefinies de requisitos iniciais dos projetos. A famlia dos mtodos geis de desenvolvimento de software tem origem no agrupamento de todos estes mtodos,
como por exemplo o SCRUM, o XP e o FDD (DIAS, 2005). Os mtodos SCRUM, FDD e XP
sero detalhados nas subsees seguintes.
2.4.1
SCRUM
SCRUM um framework gil para gesto e planejamento de projetos de desenvolvimento

de software (SCHWABER, 2004). Foi desenvolvido por Ken Schwaber e Mike Beedle na dcada
de 1990, baseando-se em experincias no desenvolvimento de sistemas e processos, a partir do
reconhecimento de que o desenvolvimento de software muito complexo para ser planejado
corretamente desde o incio. Por ser um framework, SCRUM servir como um guia de boas
prticas para atingir o sucesso. Entretanto, as decises de quando e como us-lo, quais tticas
e estratgias seguir para obter produtividade e realizar as entregas ficam por conta de quem o
estiver aplicando. O conhecimento das suas prticas permite a aplicao destas de forma variada
e este um dos aspectos positivos do SCRUM, a adaptabilidade (PORTELA, 2009).
2.4.1.1
CICLO DE VIDA
O ciclo de vida do SCRUM baseado em trs fases principais, divididas em sub-fases:

pr-planejamento, desenvolvimento e ps-planejamento (SCWABER; BEEDLE, 2002).
Pr-Planejamento: Nesta fase definida a viso do produto e as expectativas dos stakeholders. Os requisitos dos clientes so coletados e priorizados para o planejamento dos
trabalhos. Devem ser garantidos o financiamento/oramento para a realizao do projeto
e os riscos associados ao projeto devem ser identificados;
Desenvolvimento: Nesta fase so executadas atividades de refinamento de requisitos,
anlise, projeto, desenvolvimento e testes, devendo resultar em um incremento funcional
do produto que est sendo desenvolvido.
Ps-Planejamento: O ciclo de desenvolvimento encerrado e avaliado. Realizada a
demonstrao e a liberao do incremento de produto ao cliente o time de trabalho deve
refletir sobre as prticas empregadas, os indicadores finais e o aprendizado geral da
equipe.
37
Figura 9: Viso Geral do Processo SCRUM (MARAL, 2009).

A Figura 9, mostra como funciona o ciclo completo do SCRUM.
Este ciclo tem o seu progresso baseado em uma srie de iteraes bem definidas, cada uma
com durao de 2 a 4 semanas, chamadas sprints. Antes de cada sprint, realiza-se uma reunio
de planejamento (sprint planning meeting) onde o time (equipe) de desenvolvedores entra em
contato com o representante do cliente (product owner) para priorizar o trabalho que precisa
ser feito (itens do product backlog), selecionar e estimar as tarefas que o time pode realizar
dentro da sprint construindo assim a lista de funcionalidades da sprint (sprint backlog). A
prxima fase a execuo da sprint onde o time controla o andamento do desenvolvimento
realizando reunies dirias (daily meeting), no mais que 15 minutos de durao onde todos
os participantes devem estar prioritariamente de p, e observando o seu progresso usando um
grfico chamado sprint burndown.
Ao final de cada sprint, feita uma reviso no produto entregue para verificar se tudo
realmente foi implementado. Realiza-se ento uma reunio de reviso (sprint review), onde o
time demonstra o produto gerado ao product owner e este valida se o objetivo foi atingido. Logo
em seguida, realiza-se a reunio de retrospectiva (sprint retrospective), uma reunio de lies
aprendidas, com a finalidade de melhorar o processo, ou o time e/ou produto para a prxima
sprint (PORTELA, 2009).
38
2.4.1.2
ARTEFATOS
Em (SCHWABER, 2004), os seguintes artefatos esto definidos para o SCRUM ao longo do

seu fluxo de desenvolvimento: Product Backlog, Sprint Backlog e incremento de funcionalidade
do produto (MARAL, 2009).
Product Backlog: Contm uma lista de itens priorizados que incluem os requisitos funcionais e no funcionais do sistema que est sendo desenvolvido no projeto. O product
backlog nunca est completo e evolui de acordo com a evoluo do produto e do ambiente
ao qual est inserido;
Sprint Backlog: Corresponde a lista de tarefas que o time do projeto define para implementar na sprint os requisitos selecionados do product backlog;
Incremento de Funcionalidade: No SCRUM o time dever entregar incrementos de
funcionalidade a cada sprint. Os incrementos de funcionalidade consistem de cdigos
testados, bem estruturados e bem escritos, que so executveis acompanhados da documentao necessria para a sua operao.
2.4.1.3
PAPIS
(SCHWABER, 2004) define que as atividades no framework SCRUM so realizadas por trs
ppeis: Product Owner, Scrum Master e Time (CAVALCANTI, 2009) (MARAL, 2009).
Product Owner: Define as funcionalidades do produto, os itens do product backlog, o
valor de negcio para cada item do backlog, prioriza tais itens, aceita ou rejeita o resultado
do trabalho. Pode ser o cliente, uma pessoa que represente o cliente, algum de marketing
e que deve estar disponvel durante todo o projeto;
Scrum Master: Assegura que as prticas do SCRUM esto sendo executadas, remove os
impedimentos levantados pelo time, protege o time de interferncias externas, garante a
colaborao entre os diversos papis e funes;
Time: Estima e desenvolve as funcionalidades do produto; define como transformar
o product backlog em incremento de funcionalidades numa iterao gerenciando seu
prprio trabalho, sendo responsveis coletivamente pelo sucesso da iterao e, conseqentemente, pelo projeto como um todo.
39
2.4.1.4
MEDIO DE PROGRESSO
No SCRUM, o monitoramento do progresso do projeto realizado por meio de dois grficos

principais: Consumo do Produto (Product Burndown) e Consumo da Sprint (Sprint Backlog).
Estes grficos mostram ao longo do tempo a correlao entre a quantidade de trabalho que falta
ser feita (em qualquer ponto) e o progresso do time do projeto em reduzir este trabalho (COHN,
2005) (CAVALCANTI, 2009).
Product Burndown: Representa o quanto de story points foram entregues do produto em
cada sprint. Ou seja, o grfico iniciado com o total de story points estimado para o
projeto e a cada sprint so exibidos a quantidade ainda existente de story points. Deste
modo ao compararmos as barras do grfico podemos saber o quanto de story points foram
consumidas a cada iterao e quanto ainda falta de story points a serem consumidas no
projeto. A story points pode ser considerada como uma unidade de tamanho relativo
utilizado na estimativa de requisitos como uma alternativa a unidade de tempo. Points
uma medida de complexidade a/ou tamanho de um requisito;
Figura 10: Exemplo de Product Burndown exibindo o consumo de story points de cada sprint
(CAVALCANTI, 2009).
Sprint Burndown: Representa a quantidade de horas restante da sprint, respectivamente,
na linha do tempo como um todo. O grfico inicia com o total de horas estimado para a
sprint. A cada dia de trabalho deve ser marcado no grfico a quantidade de horas ainda
restante. Deste modo, fazendo a comparao entre dois dias no grfico pode se saber a
quantidade de horas consumidas.
2.4.2
FDD
FDD se baseia em processos bem definidos que podem ser repetidos. Alm disso, sua
abordagem concentrada nas fases de projeto e construo tendo uma alta nfase na modelagem
40
Figura 11: Exemplo de Sprint Burndown exibindo o consumo de horas das tarefas durante a
sprint (CAVALCANTI, 2009).
do sistema em um ciclo de vida iterativo com algumas atividades de gerenciamento de projetos
(UDO; KOPPENSTEINER, 2003).
Um dos conceitos bsicos utilizados o conceito de features (funcionalidades). Segundo
(PALMER; FELSING, 2002) o termo feature em FDD muito especfico correspondendo a uma
funo de tamanho pequeno que represente algum tipo de valor para o cliente. Podem ser
representadas a partir do seguinte template: <ao><resultado><objeto> com o uso de uma
preposio apropriada entre a ao, o resultado e o objeto (Por exemplo: <calcular>o<total>de
uma<venda> e <calcular>o<total de compras>de um<cliente> (JUNIOR, 2008)). O tamanho de
uma feature no pode ultrapassar o tamanho definido para as iteraes que de duas semanas.
2.4.2.1
CICLO DE VIDA
Como pode ser visualizado na Figura 12 o processo de desenvolvimento de software baseado

no FDD possui duas fases (Concepo/Planejamento e Construo) que podem ser divididas em
cinco processos (Desenvolver um Modelo Abrangente, Construir a Lista de Funcionalidades,
Planejar por Funcionalidade, Detalhar por Funcionalidade e Construir por Funcionalidade.
1. Concepo e Planejamento: Os processos realizados na fase de Concepo e Planejamento abrangem todo o projeto e so realizados apenas uma vez.
Desenvolver um Modelo Abrangente (DMA) - Anlise Orientada por Objetos:
realizado um estudo dirigido sobre o escopo do sistema e seu contexto, alm de
estudos detalhados sobre o domnio de negcio para cada rea a ser modelada. O
objetivo geral a elaborao de um modelo abrangente do sistema. Isto realizado
por sesses de modelagem de parte do domnio em grupos. O modelo abrangente
41
Figura 12: Ciclo de vida de um projeto com o FDD (HEPTAGON, 2010).

construdo e tem seu contedo atualizado iterativamente pela integrao dos modelos criados pelos grupos de modelagem;
Construir a Lista de Funcionalidades (CLF) - Decomposio Funcional: Devero ser identificadas as funcionalidades que satisfaam os requisitos. O domnio
decomposto funcionalmente em reas de negcio, atividades de negcio dentro das
reas mapeadas e funcionalidades dentro das atividades de negcio mapeadas. Esse
mapeamento permite estabelecer a lista categorizada de funcionalidades;
Planejar por Funcionalidade (PPF) - Planejamento Incremental: Tem o objetivo
de produzir o plano de desenvolvimento do projeto. definido a ordem na qual
as funcionalidades sero implementadas, baseada nas dependncias entre elas, na
carga de trabalho da equipe de desenvolvimento e tambm na complexidade das
funcionalidades a serem implementadas.
2. Construo: Os processos realizados na fase de Construo so realizados uma vez para
cada funcionalidade existente.
Detalhar por Funcionalidade (DPF) - Desenho (Projeto) Orientado por Objeto:
Um conjunto de funcionalidades so agendadas para o desenvolvimento ao serem
atribudas a um programador lder. O programador-lder pode ento formar uma
equipe de funcionalidades identificando quais sero os proprietrios das classes (desenvolvedores). Esta equipe dever produzir os diagramas de sequncia para a(s)
funcionalidade(s) atribuda(s). De posse desses diagramas o programador-lider re-
42
aliza o refinamento do modelo de objetos. Os programadores ento escrevem os

prefcios das classes e mtodos e realiza-se uma inspeo no projeto (design);
Construir por Funcionalidade (CPF) - Programao e Teste Orientados por
Objetos: Seu objetivo produzir uma funo com valor para o cliente (funcionalidade). Iniciando com o pacote de projeto (design), os proprietrios de classes
implementam os itens necessrios para que suas classes suportem o projeto para esta
funcionalidade. O cdigo desenvolvido passa pelo teste de unidade e pela inspeo
em uma ordem determinada pelo programador-lder. Aps passar pela inspeo, o
cdigo promovido a verso atual (build).
2.4.2.2
PAPIS
FDD admite os seguintes principais ppeis dentro de um projeto:

Gerente do projeto: Responsvel por todos os assuntos administrativos ligados ao projeto. Sua principal funo oferecer subsdios para que nenhum fator externo interfira na
produtividade da equipe;
Especialista do negcio: Deve usar o conhecimento a respeito do negcio para apresentar
a equipe de projeto as necessidades para que o software possa ter real valor para o cliente.
um membro fixo da equipe e deve fornecer o feedback sobre as entregas a todos os
envolvidos. Alm disso, est disponvel para o detalhamento das funcionalidades a todo
o momento;
Arquiteto: Atua como um consultor da equipe em termos da arquitetura do sistema;
Gerente de desenvolvimento: Responsvel por liderar o dia a dia do desenvolvimento
do produto. Todos os conflitos tcnicos entre os programadores-chefes esto sob sua
responsabilidade;
Programador-chefe: Responsvel por liderar pequenos grupos de desenvolvedores durante a construo das funcionalidades. Pode atuar como desenvolvedor sendo o responsvel pelas classes mais complexas do sistema. Possui papel fundamental nas atividades
de absoro do conhecimento do negcio e no planejamento das atividades;
Programador (Class Owner): Compem as equipes de funcionalidades e realizam atividades de programao, criao de diagramas, testes e documentao de funcionalidades.
43
Para projetos maiores ou complexos, FDD fornece um conjunto maior de papis, como por
exemplo: Gerente de release, testadores, escritores tcnicos, guru da linguagem, administrador
de sistemas, implantadores dentre outros.
2.4.3
XP
O XP um mtodo gil para pequenas e mdias equipes desenvolverem software, em ambientes com requisitos instveis (DIAS, 2005). Suas prticas fundamentais tiveram origem nas
tradies do desenvolvimento em Smalltalk e datam de meados da dcada de 80, quando Kent
Beck e Ward Cunningham trabalhavam na Tektronixs, Inc. Prticas, tais como, refatorao,
programao em par, mudanas rpidas, feedback constante do cliente, desenvolvimento iterativo, testes automatizados, entre outras, so pontos chave da cultura da comunidade Smalltalk.
XP ento pode ser considerado como o modo de agir do Smalltalk generalizado para outros
ambientes (TELES, 2005). As prticas principais do XP esto descritas abaixo: (DIAS, 2005)
(PORTELA, 2009)
Planing poker (jogo do planejamento): No jogo do planejamento so realizadas as estimativas para as estrias de usurio. Tarefas so definidas para cada estria e estimadas a
fim de que se possa alocar um conjunto de estrias para a realizao da iterao de acordo
com a capacidade da equipe;
Pair programming (Programao em par): Todo cdigo implementado deve ser feito
em pares;
Pequenas verses: As verses do produto devem ser to pequenas quanto possivel e
trazerem valor para o negcio. Uma verso inicial do software deve ser colocada em
produo aps um pequeno nmero de iteraes e, em seguida, outras verses devem ser
disponibilizadas to logo faa sentido;
Metforas: A modelagem do sistema realizada a partir de metforas criadas pelos
clientes, gerentes e programadores;
Projeto simples: Os programadores so estimulados a desenvolver o cdigo da aplicao
o mais simples possvel;
Testes: Os programadores antes mesmo do desenvolvimento do cdigo do sistema devem
criar os testes de unidade e rod-los. Isso vale para todo o cdigo implementado. Deste
modo todo o desenvolvimento do cdigo acompanhando de testes para cada mdulo,
44
para cada funo implementada. Os testes de aceitao so escritos pelos clientes e so

usualmente rodados no final de cada iterao;
Reengenharia de software: O cdigo deve ser constantemente melhorado, sem que a
funcionalidade do sistema seja alterada;
Integrao contnua: Os programadores devem integrar os novos cdigos ao software
to rapidamente e com a maior freqncia possvel;
Propriedade coletiva do cdigo: O cdigo do programa deve ser propriedade de toda a
equipe e qualquer integrante pode fazer alteraes sempre que for necessrio;
Cliente no local: O cliente deve trabalhar com a equipe de projeto a todo momento,
respondendo perguntas, realizando testes de aceitao e assegurando que o desenvolvimento do software esteja sendo feito a seu contento;
Semana de 40 horas: Como trabalhar por longos perodos reduz o desempenho, o contedo de cada iterao deve ser planejado de forma a no haver necessidade de realizao
de horas extras;
Padro de codificao: No incio do projeto deve ser criado um padro de codificao,
simples e aceito por toda a equipe, que dever ser seguido de forma a padronizar e auxiliar
na conduo do trabalho.
2.4.3.1
CICLO DE VIDA
O ciclo de vida do XP baseado nos ciclos trimestrais, as releases, e no ciclo semanal que
so as iteraes. Uma release composta portanto de diversas iteraes. A Figura 13 ilustra
como funciona o ciclo semanal em XP:
No ciclo trimestral ocorre o replanejamento do projeto. Deve-se pensar nos temas que
sero implementados. Temas so vises mais gerais das funcionalidades do que as estrias de
usurios. Ao final de um ciclo trimestral, a equipe tambm deve refletir sobre quais foram as
dificuldades durante o andamento do ciclo e propor solues. No ciclo semanal os desenvolvedores reunem-se com o cliente com o propsito de entrarem em um acordo sobre o que dever
ser implementado naquela semana. Para isso, utilizada a dinmica do jogo do planejamento
(GUIMARES, 2009).
O objetivo deste jogo fazer com que os clientes descrevam quais funcionalidades desejam
que sejam implementadas naquela semana de modo que os desenvolvedores possam estima-las
45
Figura 13: Ciclo Semanal em XP.

(GUIMARES, 2009). Inicialmente os clientes escrevem as estrias em cartes. Estas estrias
descrevem as funcionalidade desejadas e so denominadas Estrias de Usurio e so o instrumento de trabalho para as estimativas. Para iniciar o processo de estimativa a equipe de desenvolvimento deve determinar a unidade de tempo que ser utilizada para estimar os cartes
podendo ser qualquer medida (horas, minutos ou dias), desde que todos da equipe tenham conscincia de qual medida ser utilizada durante o jogo.
Cada membro dever ter em mos um conjunto de cartas como se fossem cartas de baralho
que indiquem as unidades da medida escolhida. O jogo ocorre da seguinte forma: um membro
da equipe l uma estria escrita pelo usurio. Cada membro da equipe dever pensar quanto
tempo ele gastaria para desenvolver sozinho aquela funcionalidade sem nenhum tipo de interrupo. Aps todos terem concludo sua estimativa as informaes sero compartilhadas. Para
informar ao restante da equipe qual a sua estimativa, o membro dever escolher uma carta, dentre as do seu conjunto, que contenha o valor da sua estimativa. Quando o lder da equipe der a
ordem, todos devem mostrar sua estimativa ao mesmo tempo (GUIMARES, 2009).
Havendo divergncias o membro que estimou o maior tempo e o membro que estimou o
menor tempo devero confrontar as suas opinies. Depois da estimativa das estrias, o cliente
deve escolher quais estrias so prioritrias para o seu negcio. A quantidade de estrias selecionadas no deve ultrapassar o limite de horas de trabalho daquela semana. Com isso os
desenvolvedores dividem as estrias em tarefas e as implementam. No final do ciclo os desenvolvedores demonstram o que foi feito e o cliente aprova ou no o trabalho resultante. Alm
disso realizada um retrospectiva para avaliar o trabalho realizado durante o ciclo semanal
46
(GUIMARES, 2009).
2.4.3.2
PAPIS
XP no mantm uma estrutura rigda de ppeis. O principal objetivo fazer com que todos
contribuam de acordo com suas habilidades nas etapas do projeto (GUIMARES, 2009).
Testadores: Auxiliam os clientes e programadores na elaborao dos testes que devem
ser feitos para garantir que o software est correto;
Designers de interao: Ajudam os clientes nas definies das estrias e auxiliam na
criao e refinamento da interface;
Arquitetos: Auxiliam os programadores, estimulam a refatorao do cdigo. Realizam
testes mais amplos que envolvam toda a arquitetura;
Gerentes de Projeto: um facilitador na comunicao entre a equipe de desenvolvimento, clientes e demais fornecedores. Deve tambm gerenciar o progresso da equipe,
motivando-os sempre que necessrio;
Gerentes de Produto: Auxiliam na definio de estrias e temas alm de serem responsveis por reduzir o escopo da iterao quando sentir atraso na equipe;
Executivos: Representam os usurios do sistema e ajudam na definio do escopo e objetivos do projeto. Tm a responsabilidade de definir as prioridades de desenvolvimento,
informando as estrias que mais trazem retorno para a organizao;
Redatores tcnicos: Responsveis por criar e manter a documentao do projeto que,
assim como o cdigo, evolui de maneira iterativa;
Usurios: Do feedback sobre o que est sendo desenvolvido, ajudam na escolha das
estrias uma vez que conhecem o domnio e quais funcionalidades devem ser implementadas primeiro;
Programadores: Devero estimar as estrias e depois implement-las. So os responsveis por escrever testes para todo o cdigo desenvolvido, alm de refator-lo sempre
que necessrio.
47
2.5
CONSIDERAES FINAIS
Neste captulo foram detalhados os principais conceitos que possibilitam a compreenso

da proposta deste trabalho. As metodologias geis utilizadas na composio do FDWS foram
descritas de modo que possa-se perceber quais prticas e como cada uma delas relaciona-se
com a proposta deste trabalho.
Alm dos mtodos geis, foram detalhadas metodologias para gerncia e desenvolvimento
de projetos de BI que envolvem Data Warehousing.
No prximo captulo ser feita a anlise dos trabalhos relacionados a essa proposta de modo
que as principais contribuies deste trabalho possam ser evidenciadas.
48
AVALIAO DE TRABALHOS
RELACIONADOS
Neste captulo so discutidos os trabalhos relacionados a proposta dessa monografia de

modo que ao final possa-se estabelecer parmetros de comparao com a proposta que feita
neste trabalho.
3.1
AGILE DATA WAREHOUSING
A metodologia Agile Data Warehousing foi criada a partir das metodologias SCRUM e XP
(HUGHES, 2007) para a gerncia e o desenvolvimento de projetos de Data Warehousing. O
ciclo de desenvolvimento definido pelo Agile Data Warehousing e sua integrao com o ciclo
do SCRUM ilustrado na Figura 14.
Figura 14: Ciclo de Desenvolvimento Agile Data Warehousing. Adaptado de (HUGHES, 2007).
49
Este ciclo inicia-se com uma fase de diagnstico onde o Product Owner deve investigar as
necessidades e carncias da instituio. O Product Owner deve identificar grupos na organizao que possam fornecer estas informaes e os conjuntos de dados relacionados na segunda
fase do ciclo denominada de pesquisa. Na terceira fase, decomposio, as necessidades do
negcio devem estar muito claras assim como a combinao dos dados de origem que podem
satisfazer estas necessidades. Na fase de decomposio o Product Owner comea a articular os
mdulos de BI que ele quer que seja construdo. Essa articulao feita inicialmente ao nvel
de picos (picos podem ser considerados como estrias de usurio de tamanho muito grande
sendo composto por um conjunto de temas. Um tema um conjunto de estrias de usurio
relacionadas. As estrias de usurio devem ter um tamanho pequeno de modo que possam ser
implementadas em iteraes curtas.) que sero posteriormente decompostos com a ajuda do
Scrum Master e do time em temas e finalmente em estrias de usurio a partir de um conjunto
de categorias definidas anteriormente. A prxima fase, priorizao, onde ocorre a priorizao
das estrias de usurio categorizadas em seus temas e picos pelo Product Owner. Aps a priorizao, o ciclo passa para a fase de construo que correponde a uma sprint do SCRUM, as
estrias so revistas, implementadas e demonstradas ao Product Owner.
O Verbalization Cycle encerra-se com a fase de reviso onde os itens implementados so
revisados e ocorre a retrospectiva da sprint. Durante o Verbalization Cycle so utilizados dois
artefatos para dar apoio aos desenvolvedores no entendimento das bases de dados e definio
das rotinas de ETL:
Tiered Data Model: O Tiered Data Model uma simples reformatao de um tpico
diagrama entidade-relacionamento que fornece aos desenvolvedores a traduo das estrias de usurio a partir do agrupamento das tabelas do modelo em reas temticas. O
Tiered Data Model deve fornecer uma viso clara de quais tabelas so necessrias para a
implementao de uma determinada estria;
Process Flow Diagram: Pode ser pensado como uma reprojeo do conhecimento contido em um Tiered Data Model, devendo indicar os fluxos de processamento de dados.
As dependncias existentes no modelo de dados podem ser avaliadas contribuindo para o
trabalho dos projetistas de ETL.
3.2
EXTREME SCOPING
O Extreme Scoping (MOSS, 2007) fundamentando no conceito de release de software

que nada mais do que a quebra do processo de desenvolvimento de um software em partes
50
menores, as releases, de modo que o mesmo possa ser desenvolvido de forma iterativa. O
mbito de cada release ir conter apenas uma pequena parte das necessidades da aplicao, da
o nome "Extreme Scoping". O projeto ser composto por inmeras releases tantas quanto forem
necessrias para a concluso das aplicaes de BI assim como o DW construdo iterativamente
(MOSS, 2008).
3.2.1
PLANEJAMENTO DO PROCESSO
Com Extreme Scoping, a funo de gerenciamento do projeto realizada por uma equipe
central (equipe de ncleo) e no por um nico gerente de projetos. Os membros do ncleo
iniciam o processo reavaliando a metodologia e selecionando as tarefas em uma estrutura de
trabalho denominada Work Breakdown Structure (WBS) (MOSS, 2010a).
Usando a WBS como um guia, os membros do ncleo criam um roteiro de projeto de
alto nvel para dar uma compreenso do esforo global, recursos, custo, cronograma, riscos e
pressupostos para a aplicao inteira. Isso necessrio para estipular o nmero certo de releases
de software, a seqncia correta desses lanamentos, as dependncias entre os requisitos e,
portanto, os prazos e o escopo de cada lanamento (MOSS, 2007). Uma vez que os membros do
ncleo esto confortveis com o escopo e a seqncia das releases proposta e esto certos de
que cada verso do software factvel dentro do tempo alocado, eles criam um plano detalhado
do projeto com metas semanais para o lanamento da primeira release. Comeando com o
prazo e trabalhando para trs, os membros do ncleo determinam onde devem estar na semana
antes do prazo, a fim de cumprir o prazo, ou de outra forma, eles determinam em que estado o
projeto ou o produto deve estar na semana antes do prazo (MOSS, 2010a).
Eles nomeiam e descrevem o milestone (objetivos) e depois repetem o processo fazendo
o backup de uma semana a outra semana e assim por diante. Caso passem a data de incio
do projeto, os membros do ncleo devem determinar se o escopo muito grande para o prazo
ou se os perodos de tempo entre as etapas so superestimadas. Todos os membros da equipe
devem concordar que as metas so atingveis, e que a qualidade no ser comprometida, dada
a extenso e os recursos (MOSS, 2010b). Aps as atividades de projeto para a primeira release
estarem organizadas em etapas, os membros da ncleo se auto-organizam em um nmero adequado de equipes de trabalho. Conhecendo a composio das equipes e os objetivos semanais,
os membros do ncleo decidem sobre o detalhamento das tarefas e resultados para cada etapa.
Eles tambm decidem sobre quais as tarefas e que resultados so atribudos para qual pessoa
e que equipe de trabalho. O detalhamento, atribuies de tarefas dirias e os resultados esperados so documentados em um quadro branco, flip chart, uma planilha ou outro meio informal,
51
que pode ser modificado de forma rpida e facilmente. Os membros do ncleo usam esse plano
de projeto informal detalhado em uma base diria para orientar as atividades de trabalho do
dia-a-dia, gerenciar o controle de mudanas durante o processo de prototipagem, e acompanhar
o andamento do projeto. Eles no usam este plano detalhado para relatar o status do projeto
para a gesto (MOSS, 2007).
Se a primeira verso do software foi concluda a tempo e sem problemas no previstos, os
membros do ncleo podem planejar a prxima release. No entanto, se houve problemas com
a primeira release, tais como tarefas subestimadas, produto incompleto, ajustes constantes no
escopo, e assim por diante, os membros do ncleo devem revisar e ajustar o plano do projeto
de alto nvel para todo o aplicativo. Eles devem rever as suas estimativas e sua compreenso
do esforo global, recursos, custo, cronograma, riscos e hipteses de todo o aplicativo. Em
seguida, eles devem fazer as adaptaes necessrias para as releases restantes (MOSS, 2010a).
Durante as releases, o Extreme Scoping trabalha com o paralelismo das tarefas de back-end
(Modelagem e ETL), front-end (Aplicaes de BI) e o repositrio de metadados.
3.3
APLICAO DE PRTICAS GEIS NA CRIAO DE

DATA WAREHOUSE EVOLUTIVO
Em (CARVALHO, 2009) apresentado o uso das prticas geis para desenvolvimento iterativo e incremental de DW. Desta forma, o esquema do DW construdo iterativamente a partir
da seleo gradual de consultas e relatrios a serem oferecidos ao cliente. Inicialmente, foi
realizada uma anlise das etapas da metodologia definida por Kimball a respeito de quais etapas
poderiam ser afetadas pelas prticas de desenvolvimento iterativo e incremental. A partir dessa
anlise foram realizadas trs iteraes a fim de cobrir o estudo de caso realizado pelo trabalho.
A Figura 15 ilustra como o esquema do DW construdo evoluiu nas iteraes realizadas pelo
trabalho. Um ponto crucial a ser destacado nesse trabalho que para dar suporte ao processo de
evoluo do esquema do banco so utilizadas prticas de refatorao de banco de dados a fim
de oferecer consistncia ao esquema em evoluo.
Segundo essa abordagem, pode-se demonstrar ao cliente o potencial de uma aplicao de
BI em um curto intervalo de tempo. Isto por que, em pequenos ciclos oferecido um conjunto
de anlises e consultas que crescer a partir da realizao de novas iteraes, at que sejam
esgotadas as possibilidades de consultas em um determinado modelo de dados. O esquema do
DW cresce com o tempo, ao invs de ser concebido de uma nica vez. A proposta apresentada
quebra, ainda, o ciclo de criao de DMs (que podem ser grandes e complexos) em unidades de
52
Figura 15: Exemplo de trs ciclos de desenvolvimento curtos, ou "semanais"(CARVALHO, 2009).

tempo menores, o que possibilita um processo de explorao e aprendizado em torno do negcio
do cliente maior do que se o esquema do DW fosse concebido de modo nico. A eficcia do
processo de coleta de requisitos maior pois este processo realizado a cada ciclo de trabalho.
3.4
AGILE BI - PENTAHO
O Agile BI da Pentaho oferece uma soluo integrada que permite passar diretamente do
processo de ETL para a modelagem da informao e explorao de dados. O fluxo de trabalho
sugerido, comea com a produo de dados e termina com um esquema Mondrian 1
testado
que est pronto para ser usado em um relatrio ou uma consulta destinada ao usurio final. Este
ciclo pode ser visualizado atravs da Figura 16.
Segundo o Agile BI da Pentaho o processo acima integrado na ferramenta de ETL, o PDI.
Com isso o projetista de ETL torna-se capaz de manusear os dados conforme o necessrio, e,
com base na entrada de um analista de negcios, pode ir diretamente para a modelagem de
dados, visualizao dos dados e gerao de relatrios e anlises. Com a integrao do processo
de ETL, modelagem, visualizao e relatrios em uma nica ferramenta os projetistas de ETL e
analistas de negcios trabalham de forma integrada e podem fazer as mudanas necessrias nos
dados de forma rpida e eficaz.
Enquanto constri o DW, o projetista de ETL pode imediatamente criar um modelo baseado
em dados que ele j construiu e assim pode explorar (visualizar) os dados. Por exemplo, em
cooperao com um analista de BI, o projetista de ETL pode determinar que certas dimenses
1 Um esquema Mondrian um esquema OLAP do cubo que ser utilizado pelo Mondrian para a visualizao
dos dados.
2 O Mondrian um servidor OLAP escrito em Java utilizado pela sute de BI da Pentaho Corporation
53
Figura 16: Ciclo Tradicional de Desenvolvimento na Plataforma Pentaho

no so aplicveis ou que as hierarquias no so mais necessrias. A etapa de visualizao
tambm permite que as questes de qualidade de dados sejam identificadas e corrigidas. Neste
ponto, o projetista de ETL pode retornar ao PDI e construir hierarquias adicionais, o modelo,
e em seguida, visualizar os dados novamente. Ajustes podem ser feitos de forma iterativa at
que os dados sejam exatamente o que o analista de BI e usurios finais desejam ver (PENTAHOCORPORATION,
3.5
2010b).
APLICAO DE PRTICAS GEIS EM PROJETOS

DE BI
Se analisarmos as metodologias de abordagem bottom-up como, por exemplo, Kimball

(KIMBALL, 2002) vemos que todas elas trabalham com processos iterativos. O DW construdo por partes, geramente DMs orientados a reas especficas do negcio. Porm elas falham naquilo que as metodologias geis defendem como desenvolvimento incremental (pequenas partes do produto com valor de negcio so entregues frequentemente), pois um DM pode
ter um grau de complexidade e tamanho extremamente elevado. Com isso, mesmo em um processo iterativo ou espiral, observa-se que projetos de DW mantm uma alta mdia de fracassos,
so lentos para produzir resultados e possuem pouca flexibidade para se adaptar a mudanas de
negcio (WAILGUM, 2010) (NBREGA, 2010).
54
Abordagens geis envolvem desenvolvimento incremental, desenvolvimento iterativo e colaborao entre equipes multifuncionais compostas por profissionais de TI e usurios corporativos. Em desenvolvimento gil, as equipes de trabalho so auto-organizadas e os requisitos so
refinados ao longo do projeto a partir de um processo de explorao e aprendizado constante.
As equipes realizaro reunies peridicas de verificao de status para revisar o trabalho em
andamento e priorizar tarefas. Em cada ponto de um programa gil, a equipe desenvolve prottipos teis que podem funcionar isolados, ou podem funcionar como blocos de construo
para um sistema maior, mais complexo, os sistemas multifuncionais.
Tratando-se de desenvolvimento incremental, em BI, podemos considerar como incremento
de software com valor de negcio, relatrios, consultas OLAP, dashboards, cdigo de ETL em
funcionamento. A existncia desses vrios produtos d margem a vrias concepes da aplicao de mtodos geis em projetos de BI. Pode-se quebrar o desenvolvimento das aplicaes
de BI em ciclos completos (relatrios, dashboards, OLAP, data mining), seguindo os ciclos
do processo iterativo de construo de DMs como feito pelo "Extreme Scoping" de (MOSS,
2010b) ou at mesmo conceber o DW como um banco evolutivo e constru-lo orientado s consultas que esto sendo fornecidas aos usurios em um ciclo menor. Isso tranforma o ciclo de
construo dos DMs em vrios ciclos de construo, onde o modelo dimensional ir crescer
iterativamente e incrementalmente. Isto feito por (CARVALHO, 2009).
Alm desses detalhes, a Forester Research ao declarar o termo "Agile BI" em seu relatrio
(WAILGUM, 2010), o define como nada muito diferente do que qualquer metodologia gil j faz
porm junta ao paradigma da metodologia aspectos como arquitetura da soluo e ferramentas
como tendo a necessidade de serem geis e flexveis. Nesse contexto a Pentaho Corporation
(PENTAHO-CORPORATION, 2010a), cria o seu Agile BI, transformando a sua ferramenta de ETL,
o PDI, em uma ferramenta integrada com as funes de modelagem e visualizao. Este fato
permite aos projetistas de ETL inmeras operaes sobre os dados logo aps a carga dos dados,
diminuindo o tempo gasto at a preparao das ferramentas de visualizao.
O uso e a melhor forma de aplicao de prticas geis em projetos de BI um campo aberto,
devido principalmente as caractersticas diferenciadas desse tipo de projeto (metodologias geis
foram feitas para projetos de software e no para projetos de integrao de dados como ocorre
em projetos de BI) e as variadas metodologias geis existentes com um conjunto diversificado
de prticas. Um dos parmetros que podem ser utilizados para avaliar como as metodologias
geis podem ser utilizadas em projetos de BI a anlise de cada um dos itens contidos no
"Manifesto gil"(BECK et al., 2001) (GRAZIANO, 2010):
1. Nossa maior prioridade satisfazer os clientes atravs de rpidas e contnuas entre-
55
gas de software com valor agregado: Duas definies devem ser feitas em um projeto
de BI: Quem o Cliente ? O que software com valor agregado em BI (uma consulta
OLAP?, uma definio de tabelas?, um relatrio? um modelo de metadados?)? Estes dois
itens devem estar bem definidos para a execuo dos trabalhos, pois os clientes devero
participar do projeto como membros do time e a definio de software com valor agregado em BI permite definir o que ser entregue a cada iterao de modo que a mesma seja
pequena o suficiente;
2. Mudanas de requisitos so bem vindas, at mesmo tarde no desenvolvimento. O
processo gil assume a mudana como parte da vantagem competitiva de seus clientes:
O processo gil flexvel a mudanas e ao aparecimento de novos requisitos. Inicia-se o
trabalho no projeto de BI com uma pequena lista de funcionalidades que ser incrementada a partir do momento que os usurios finais passem a utilizar a primeira entrega do
produto;
3. Entregar software funcionando freqentemente, em algumas semanas ou meses,
com preferncia ao menor tempo possvel: No ser trabalhado um escopo que relacionese com toda a organizao. Deve ser definido uma rea prioritria e a partir dela sero
definidas as funcionalidades e o plano de desenvolvimento. O escopo de cada iterao
reduzido justamente para permitir entregas frequentes do produto;
4. Homens de negcios e desenvolvedores devem trabalhar juntos durante todo o projeto: Projetos de BI necessitam da presena das pessoas de negcio, o ideal que fossem
feitas interaes dirias com os times de desenvolvimento;
5. Construa projetos atravs de indivduos motivados. D a equipe um ambiente que
atenda suas necessidades, e confie em sua capacidade para realizar o trabalho: O
time do projeto tem que estar motivado e tem de ser treinado se necessrio. Alm disso,
pequenas unidades de trabalho ajudam a manter uma atmosfera de sucesso e facilita a
comunicao entre os membros do time;
6. A forma mais eficiente e efetiva de circular, criar consenso, uma informao para
a equipe de desenvolvimento atravs da comunicao cara-a-cara: O time deve
possuir um relacionamento dirio. Reunies dirias devem ser utilizadas para monitorar
o processo e a execuo das tarefas realizadas;
7. Software em funcionamento a primeira medida de progresso: Primeiro deve ser
definido o que entregvel e tem valor de negcio para os clientes. Aps esta definio,
entregas contnuas devem ser feitas no mesmo intervalo de tempo;
56
8. O processo gil promove o desenvolvimento sustentvel. Os clientes, desenvolvedores e usurios devem ser capazes de manter uma paz constante indefinidamente:
Projetos de BI duram muito tempo, no deve-se cansar os times com prazos irracionais.
Isso deve ser feito com um bom planejamento, controle de escopo e com a implementao
da menor unidade de trabalho com valor de negcio. Ao usar um mtodo gil, o mesmo
deve ser avaliado e adaptado s necessidades particulares do projeto e do time;
9. Ateno contnua a excelncia tcnica e bom design inspira Agilidade: Deve se ter um
cuidado extremo com o design da soluo. A fim de evitar re-trabalhos e impossibilidades
de implementaes;
10. Simplicidade - a arte de maximizar a quantidade de trabalho no feito - essencial.
As solues mais simples devem ser priorizadas no projeto;
11. As melhores arquiteturas, requisitos e designs surgem a partir de equipes autogerenciveis: A equipe de trabalho deve assumir as responsabilidades como um time,
tendo maturidade para se auto policiar e definir em conjunto as tarefas e responsabilidades de cada membro do time;
12. Em intervalos regulares a equipe reflete sobre como tornar-se mais eficiente, ento
adaptando seu comportamento de acordo: Encontrar a soluo de um problema, tornase o problema da equipe. Alm disso, frequentemente a equipe deve avaliar e refletir sobre
seu trabalho.
Um ponto crucial em qualquer abordagem utilizada que o DW construdo por ser o provedor dos dados utilizados nas aplicaes de front-end deve ser flexvel e gil, podendo responder
facilmente as mudanas exigidas pelas necessidades do negcio. Neste caso o termo "Agile
Data Warehouse" usado por (LI, 2006) para definir a capacidade evolutiva do DW em termos
de suas respostas s mudanas requeridas pelas necessidades do negcio.
3.6
ANLISE DOS TRABALHOS RELACIONADOS
Os trabalhos relacionados foram avaliados com relao a seus pontos fortes e fracos:
1. Agile Data Warehousing:
Pontos Fortes: Apresenta um modelo de processo para gerncia e desenvolvimento
de projetos de Data Warehousing baseado em XP e SCRUM com algumas adaptaes para o processo da definio das estrias de usurio. Tenta diminuir o esforo
57
do processo de ETL a partir de artefatos como o Tiered Data Model e o Process Flow
Diagram;
Pontos Fracos: O processo de quebra de picos em temas e em estrias de usrio
no intuitivo e dependente de muitos passos. A abordagem muito genrica e no
h foco em reas especificas do negcio. Alm disso o processo de levantamento de
requisitos muito concentrado na atuao de apenas um Product Owner e no corresponde por completo s abordagens de orientao a dados, orientao a objetivos,
orientao a utilizadores e orientao a processos. Existe pouca especificidade com
as etapas definidas na literatura para a gerncia e desenvolvimento de projetos de
Data Warehousing como as etapas de manuteno, operao e evoluo.
2. Extreme Scoping:
Pontos Fortes: O ciclo de desenvolvimento de uma soluo de BI quebrado em
ciclos denominados, releases, onde ocorre o desenvolvimento paralelo dos itens de
back-end, front-end e metadados;
Pontos Fracos: A abordagem muito genrica e no inclui especificidades relativas
a gerncia e desenvolvimento de projetos de Data Warehousing. Sua abordagem de
levantamento de requisitos deficiente e no contempla as abordagens de orientao
a dados, orientao a objetivos, orientao a utilizadores e orientao a processos.
3. Aplicao de Prticas geis na Criao de Data Warehouse Evolutivo:
Pontos Fortes: Promove o desenvolvimento do DW a partir das consultas que so
disponibilizadas. Deste modo o modelo do DW evolutivo e cresce a partir das
refatoraes realizadas;
Pontos Fracos: A proposta do trabalho no inclui prticas para a gerncia de projetos de Data Warehousing contabilizando apenas a forma como o DW evolui, ou seja
como o projeto deve ser desenvolvido.
4. Agile BI - Pentaho:
Pontos Fortes: Integrao das atividades de modelagem de dados e visualizao na
ferramenta de ETL, permitindo a aproximao dos usurios finais com os projetistas
de ETL. Atende ao requisito ferramentas no que o relatrio da Forester Research
denomina de Agile BI;
58
Pontos Fracos: No constitui um processo para gerncia e desenvolvimento de

projetos de Data Warehousing. Seu foco apenas na agilidade da ferramenta de
trabalho.
3.7
CONSIDERAES FINAIS
Neste captulo foram apresentados os trabalhos relacionados a proposta deste trabalho. No

captulo seguinte, ser detalhada a especificao da metodologia FDWS. A partir desta especificao podero ser evidenciadas as principais contribuies deste trabalho, na composio dos
mtodos geis SCRUM, FDD e XP para a gerncia e desenvolvimento de projetos de BI.
As principais diferenas que podem ser percebidas referem-se ao planejamento do projeto,
elicitao de requisitos, estrutura da iterao, dinmica de desenvolvimento do projeto e o alinhamento com as prticas tradicionais para projetos de BI. As prticas de cada metodologia gil
utilizada foram analisadas de modo que seus pontos de convergncia podessem resultar na especificao da metodologia proposta e serem altamente exploradas no processo descrito pela
metodologia proposta.
59
METODOLOGIA FDWS
O FDWS uma composio de prticas dos mtodos geis SCRUM, XP e FDD em uma
metodologia para o gerenciamento e desenvolvimento de projetos geis de BI a partir da definio
de artefatos, papis, prticas e processos. A Figura 17 ilustra a contextualizao do FDWS com
relao s metodologias utilizadas em sua composio. O FDWS promove o reuso de prticas geis consolidadas com prticas de metodologias de gerenciamento de projetos de BI geis
(Extreme Scoping (MOSS, 2010b) e Agile Data warehousing (HUGHES, 2007) ) e tradicionais
(Kimball (KIMBALL, 2002) e S (S, 2009)). O nome FDWS baseado nas abreviaturas FDD,
DW e SCRUM. A descrio das prticas utilizadas e seu reuso na especificao da metodologia
ser detalhada nas sees seguintes. No Apndice E feito o detalhamento da modelagem e da
especificao da metodologia proposta neste trabalho.
Figura 17: FDWS - Contextualizao
60
4.1
CARACTERSTICAS
O FDWS uma metodologia para o desenvolvimento iterativo e incremental de solues de

BI. Seu processo feito a partir da definio de quais funcionalidades so prioritrias e agregam
o maior valor de negcios aos clientes. Uma funcionalidade no FDWS pode ser definida como
uma consulta OLAP, um relatrio, um dashboard, a aplicao de uma tcnica de Data Mining
etc... a depender da organizao em que o projeto est sendo realizado. As funcionalidades no
FDWS podem ser dos seguintes tipos:
Construo: So funcionalidades tipicamente novas referentes a uma rea de negcio ou
processo ainda no explorados durante a execuo dos trabalhos;
Manuteno: Referem-se a funcionalidades existentes no ambiente de produo que devero ser ajustadas mediante a necessidade dos clientes;
Evoluo: So funcionalidades tipicamente novas referentes a uma rea de negcio ou
processo que j foram explorados durante a execuo dos trabalhos e por conseguinte j
possuem itens em produo.
O FDWS promove o desenvolvimento da soluo de BI a partir da entrega destas funcionalidades que so mapeadas de acordo com os processos e reas de negcio existentes na
organizao durante o planejamento do projeto e releases. As iteraes, por conseguinte, devem ser curtas, tendo entre 7 a 15 dias, pois o escopo do trabalho reduzido suficientemente
de modo que vrias entregas de produto possam ser feitas no menor espao de tempo e com o
maior retorno de investimento possvel ao cliente. Este por sua vez, torna-se membro integral
da equipe, devido a grande interao entre a equipe de projeto, os clientes e usurios finais a
qual o desenvolvimento de solues de BI necessitam.
O FDWS composto por um conjunto de subprocessos e atividades que devem ser adequados realidade do trabalho que est sendo feito em cada organizao. Sua proposta estabelecer
um processo de desenvolvimento de solues de BI flexvel e adaptvel a necessidades particulares. Seu processo de levantamento de requisitos e definio do esquema do DW baseado na
abordagem hbrida citada por (S, 2009) relacionando assim a orientao a dados, orientao
a objetivos, orientao a utilizadores e a orientao aos processos. Isto feito com o mapeamento das reas, processos e atividades de negcio existentes na organizao de onde podem
ser coletadas as funcionalidades que expressem no apenas as necessidades de usurios, mas
que tambm correspondam aos indicadores e objetivos organizacionais.
61
4.2
PAPIS
No FDWS os papis foram categorizados em 3 grupos: Gerncia de aplicao, Gerncia de

Negcios e Ncleo de Desenvolvimento, os quais sero detalhados nas subsees a seguir.
4.2.1
GERNCIA DE APLICAO
Devem fazer parte deste grupo os futuros utilizadores das aplicaes de BI (gestores da organizao, chefes de departamentos etc...). Estes stakeholders devem ser identificados na fase
inicial do projeto, pois devero fazer parte de todo o processo de desenvolvimento da soluo
de BI experimentando e validando as entregas dos ciclos de desenvolvimento. O tamanho deste
grupo no pr-definido sendo aconselhvel que existam um representante de cada rea de
negcio da instituio e um possvel suplente. Os stakeholders devem oferecer os requisitos
em torno de necessidades pessoais, necessidades orientadas aos processos e objetivos organizaconais.
A integrao entre clientes e a equipe de trabalho pode ser considerada com um desafio (isto
bem visvel em processos de desenvolvimento de software devido a inmeros motivos como
por exemplo o tempo em que os usurios finais tem para se dedicar a participar do projeto).
Porm tal proximidade de crucial importncia para o sucesso do projeto de BI, pois so estes
usurios que alm de deter o poder de deciso na organizao, detm os recursos financeiros
necessrios ao projeto e compreendem as necessidades e o dia a dia do negcio da organizao.
4.2.2
GERNCIA DE NEGCIO
Devem fazer parte deste grupo os membros da equipe de TI da organizao, pois so estes
que conhecem o negcio ao nvel operacional, contribuindo na elicitao de requisitos e oferecendo a equipe de trabalho o conhecimento necessrio a respeito do ambiente operacional
e do negcio da organizao. Podem ainda fazer parte deste grupo pessoas com alto nvel de
conhecimento sobre os objetivos e processos organizacionais, servindo tambm de ligao com
os membros da gerncia de aplicao.
Alm de participarem do processo de elicitao de requisitos, os membros deste grupo
sero considerados como os representantes do grupo de gerncia da aplicao, em virtude das
dificuldades vivenciadas em projetos com relao a participao dos clientes e usurios finais. A
gerncia de negcio, participar ativamente das definies do projeto, dos testes e da validao
dos produtos desenvolvidos. A quantidade de membros deste grupo no pr-definida devendo
62
haver um titular e um suplente para cada rea de negcio existente.
4.2.3
NCLEO DE DESENVOLVIMENTO
O ncleo de desenvolvimento formado por trs elementos:

Coordenador Tcnico: A figura e as responsabilidades exclusivas do coordenador tcnico, existem apenas quando houverem mais de um time de trabalho. Neste caso ele
ser responsvel por gerenciar o trabalho dos treinadores dos times e o processo como
um todo. Na existncia de apenas um time, o treinador do mesmo pode ser considerado
como coordenador tcnico do projeto. Em termos de responsabilidade, as diferenas do
seu papel que suas atividades tem aspecto geral dentro do projeto englobando todos
os times enquando que os treinadores tem rea de influncia concentrada apenas em seu
time de trabalho. Sua principal misso alinhar todo o trabalho realizado independente
da quantidade de equipes existentes;
Treinador: O treinador gerencia o processo do FDWS no mbito de seu time de trabalho.
Ao contrrio dos lderes de projetos tradicionais (o Treinador no responsvel por ditar
as atividades a serem realiazadas pelo time. O Treinador existe para ajudar o time no
cumprimento de suas atividades), seu principal objetivo auxiliar o time na realizao de
suas tarefas potencializando assim o desempenho do mesmo.
As funes desempenhadas pelo Treinador so explicitadas abaixo:
Gerncia de conhecimento: O treinador deve definir junto ao time as ferramentas de gerncia do conhecimento a ser utilizada durante o processo, bem como a
abordagem de gerncia a ser utilizada;
Elicitao de requisitos: O treinador o responsvel pelas sesses de coleta de
requisitos com a gerncia de aplicao e gerncia de negcio;
Capacitao do time: O treinador responsvel por capacitar o time a respeito da
metodologia a ser utilizada no projeto;
Gesto do processo: O treinador deve definir as mtricas que sero utilizadas na
medio do andamento do processo. Isto inclui recursos e ferramentas que permitam a visibilidade do progresso para todas as instncias dos recursos humanos
envolvidos no processo;
Documentao: Alm da gesto do conhecimento, o treinador responsvel pela
documentao e manuteno dos artefatos tcnicos do projeto. importante que
63
seja mantido um registro histrico de todas as mudanas realizadas e que esse registro histrico seja facilmente rastrevel;
Apoio ao Time: O treinador deve fornecer subsdios para potencializar o trabalho
realizado pelo time. Dessa forma qualquer impedimento que aparea durante o processo dever ser removido pelo treinador do time.
Time: O time (equipe de trabalho) dever ser composto idealmente por um nmero par de
membros, por conta das atividades realizadas em dupla durante o processo. Recomendase um tamanho entre 4 ou 8 membros a depender dos recursos humanos da organizao,
possuindo habilidades especificas que se complementem a partir do trabalho realizado em
grupo. O time dever ser auto-organizado e auto-gerencivel e responsvel pela diviso
e alocao das tarefas dentro das iteraes. Os membros do time devem possuir funes
especificas e as mesmas so detalhadas abaixo:
Arquiteto de ETL: Responsvel pela definio da arquitetura do processo de ETL
e integrao de diversas fontes de dados, definio das transformaes e do mapeamento das tabelas no processo de ETL;
Gerente de Modelagem: Assume a funo de consultor da equipe durante a etapa
de modelagem dimensional. Deste modo, o membro do time que assumir esta
funo dever ser um especialista em modelagem;
Gestor do Ambiente de Aplicao: Deve possuir uma boa experincia em design
de interfaces, usabilidade e acessibilidade pois o responsvel pela prototipagem
das aplicaes de explorao das informaes advindas do DW;
Gestor do Ambiente de Configurao: O gestor do ambiente de configurao
o responsvel pela configurao do ambiente de produo e homologao e deve
garantir o bom funcionamento da soluo de BI desenvolvida. tambm o responsvel pela integrao de todos os itens produzidos pelo Time;
Gestor do Ambiente de Testes: Todo produto desenvolvido submetido h um
grande conjunto de testes antes que seja colocado no ambiente de produo. Deste
modo o gestor do ambiente de testes o responsvel pela configurao e manuteno
do ambiente de testes e a avaliao do produto antes que o mesmo possa ser colocado
em produo.
64
4.3
CICLO DE VIDA
O ciclo de vida da metodologia proposta ilustrado na Figura 18, o qual composto por
quatro subprocessos principais: Planejamento do Projeto, Planejamento da Release, Iterao e
Ps-Iterao.
Planejamento do Projeto: Este subprocesso responsvel por oferecer uma viso geral
sobre a soluo de BI que ser desenvolvida. A viso inicial do produto estabelecida e
a partir dela realizado um planejamento alto-nvel de todo o projeto com o mapeamento
de todas as reas de negcio existentes na organizao, definio dos objetivos e critrios
de sucesso do projeto. O plano de projeto gerado dever ser reavaliado a cada finalizao
das releases;
Planejamento da Release: Este subprocesso responsvel por aprimorar a viso do produto estabelecida no planejamento do projeto. No planejamento do projeto so definidas
diversas releases a fim de cobrir as reas de negcio existentes. Preferencialmente cada
release atender a uma rea de negcio ou dependendo da prioridade a duas reas de
negcio que tenham alto nvel de relacionamento e interao. No planejamento da release os processos de negcio de sua rea alvo so mapeados e os requisitos de usurio
so coletados com base em cada processo de negcio levando-se em conta os objetivos
organizacionais, os indicadores necessrios para cada processo e as necessidades dos
usurios. Com a lista de funcionalidades populada pode-se definir a sequncia de execuo das iteraes. A cada iterao realizada o planejamento da release revisto e a
lista de funcionalidades atualizada. esperado que durante o processo novos requisitos
sejam coletados;
Iterao: Na iterao ocorre a implementao de uma parte da soluo de BI que agregue
valor de negcio ao cliente.
Ps-Iterao: Na ps-iterao realizada a implantao do produto na rea de produo
assim como a reunio de retrospectiva da iterao para que o time, o treinador e o coordenador tcnico (caso exista) possam avaliar o trabalho da equipe durante a iterao e
propor melhorias. O planejamento da release dever ser revisto e a lista de funcionalidades dever ser alterada. Nesta etapa dever ser avaliado se o planejamento inicial das
iteraes ser seguido ou modificado. Alm disso, durante a execuo das iteraes o time
dever dar suporte aos itens j existentes no ambiente de produo. Deste modo podero
ser includos nas iteraes funcionalidades de manuteno e evoluo alm das j esperadas funcionalidades de construo. Opcionalmente ser realizado o treinamento dos
Figura 18: FDWS - Ciclo de Vida - Viso Geral
65
66
utilizadores da aplicao de DW, desenvolvimento do manual de uso e acompanhamento

dos primeiros dias de sua utilizao.
Estes processos sero detalhados nas sees a seguir:
4.3.1
PLANEJAMENTO DO PROJETO
O ciclo de vida do FDWS possibilita um processo exploratrio gradual que permite que o
conhecimento a respeito da soluo a ser desenvolvida seja expandido iterativamente. Deste
modo este ciclo inicia-se com uma explorao inicial dos requisitos para que um plano geral de
projeto seja definido. Este plano geral ser revisado a partir da execuo das releases definidas
durante esta etapa.
O planejamento do projeto no deve consumir mais de 7 dias preferencialmemte. Deve-se
evitar grandes detalhamentos nesta etapa, o que far com que o consumo de tempo de execuo seja ainda maior e perca-se a agilidade esperada. Apenas uma viso geral da soluo de
BI a ser desenvolvida deve ser feita e no uma completa explorao dos requisitos e grandes
detalhamentos que resultem em uma extensa documentao do processo.
No planejamento do projeto iniciado o processo de mapeamento das reas de negcio
da organizao para a avaliao de qual rea a mais prioritria no processo. Este processo
baseia-se no uso de uma estrutura muito utilizada pela FDD, na construo de seu backlog,
a Feature Breackdown Structure (FBS) ilustrada na Figura 19. A FBS, originalmente faz o
mapeamento das reas de negcio e atividades existentes, relacionando assim as atividades do
sistema que ser desenvolvido. Este modelo de FBS foi adaptado no FDWS (Figura 20) de
modo que as reas de negcio, processos de negcio e atividades de negcio sejam mapeadas e
a partir deles a lista de funcionalidades possa ser construda. Tomando como exemplo a UFBA,
podemos mapear a rea de negcio acadmica e a partir dela mapear processos de negcio como
matrcula de alunos, inscrio semestral em disciplinas, registro de notas, alocao de salas para
disciplinas etc... Este mapeamento realizado de modo a verificar o maior conjunto possvel de
consultas gerenciais a serem implementadas durante o processo com uma avaliao detalhada
de toda a organizao. Esse processo dever ser iterativo e distribudo deste o planejamento
do projeto at o planejamento das releases com um constante refinamento na execuo das
iteraes.
A Figura 21 nos fornece uma viso geral dos subprocessos relacionados ao Planejamento
do Projeto: Anlise Organizacional, Criar/Priorizar FBS do Projeto, Projeto de Arquitetura
Tcnica, Plano de Projeto, Montagem dos Times.
67
Figura 19: FBS Verso Original (VERSION-ONE, 2010).
Figura 20: FBS Adaptada ao FDWS.
Figura 21: FDWS - Planejamento do Projeto - Processo
68
69
Os seguintes artefatos esto definidos para esta etapa:

Documento de Viso Organizacional: O documento de viso organizacional deve oferecer uma descrio suscinta da cultura organizacional, estrutura, patrocinadores do projeto,
membros da gerncia de negcio, membros da gerncia de aplicao etc... Seu principal
objetivo transmitir uma viso geral da organizao e de seu negcio;
FBS do Projeto: A FBS do Projeto uma estrutura que ir mapear as reas de negcio
existentes, processos e atividades e as funcionalidades que estejam relacionadas aos items
mapeados;
Documento de Viso Arquitetural: O documento de viso arquitetural deve oferecer
uma viso tanto da estrutura tecnolgica da organizao, como da arquitetura da soluo
de BI que ser desenvolvida;
Plano de Projeto: O plano de projeto contm estimativas de custo e prazo para o projeto, definio do pessoal que estar envolvido, dentre outros itens como os objetivos do
projeto, benefcios esperados etc....
O detalhamento dos subprocessos e atividades relativos ao Planejamento do Projeto feito
nas sees a seguir:
4.3.1.1
ANLISE ORGANIZACIONAL
Este subprocesso tem o objetivo de oferecer um panorama geral da organizao, para que o
pessoal envolvido no projeto que no faa parte da mesma possa se familiarizar com o negcio
da organizao. As atividades referentes a este subprocesso so detalhadas na lista a seguir:
1. Avaliar Cultura Organizacional: A primeira atividade deste subprocesso refere-se a avaliao da cultura organizacional de modo que o negcio da organizao seja conhecido por
todos os envolvidos no projeto;
2. Avaliar Riscos Associados: O segundo passo refere-se a anlise dos riscos associados
ao projeto e as possibilidades de insucesso para o mesmo. Estes pontos devero ser
contornados no planejamento do projeto de modo que possa se garantir o sucesso do
mesmo;
3. Avaliar Nvel de Preparao da Organizao para Solues de BI: O terceiro passo referese a avaliao da preparao da organizao a fim de ter uma soluo de BI;
70
4. Avaliar Motivao: Uma das atividades mais importantes a avaliao da motivao da

organizao para o projeto que est sendo planejado;
5. Definir Patrocinadores: Outra atividade de extrema importncia a definio dos patrocinadores do projeto de modo a garatir os recursos financeiros necessrios para a realizao
do mesmo;
6. Definir Gerncia de Aplicao: Devem ser identificados na organizao usurios finais
que possa participar intensamente do projeto;
7. Definir Gerncia de Negcio: Assim como a gerncia de aplicao deve ser identificada,
devem ser definidos os membros da gerncia de negcio do projeto;
8. Elaborar Documento de Viso Organizacional: O documento de viso organizacional
deve englobar os itens trabalhados nas etapas deste subprocesso, explicitando de modo
claro e objetivo a cultura organizacional, os riscos associados, a motivao da organizao
entre outros.
4.3.1.2
CRIAR/PRIORIZAR FBS DO PROJETO
As atividades referentes a este subprocesso so detalhadas na lista a seguir:

1. Entrevistar a Gerncia de Aplicao e a Gerncia de Negcio: Algumas entrevistas e reunies sero realizadas neste subprocesso de modo que as reas de negcio da organizao possam ser mapeadas e as principais necessidades destas reas possam ser coletadas;
2. Mapear Estrutura Organizacional Hierarquicamente (reas de Negcio): A partir dos
resultados da atividade anterior, as reas de negcio da organizao so mapeadas e organizadas hierarquicamente, podendo at uma rea ser formada por sub-reas de negcio.
Essa estrutura organizacional, dever ser mapeada junto a gerncia de negcio e a gerncia de aplicao de modo que atenda a realidade da organizao;
3. Criar FBS do Projeto: Com o mapeamento hierrquico realizado a FBS do Projeto pode
ser criada e validada com a gerncia de negcio e a gerncia de aplicao;
4. Priorizar FBS do Projeto: A partir da criao da FBS do Projeto a mesma poder ser
priorizada, a fim de que se identifique qual a rea de negcio que ser trabalhada durante
a release. Caso haja recursos humanos suficientes e duas ou mais reas de negcio tenham
prioridade igualitria, vrias releases podero ser iniciadas em conjunto ou duas reas de
negcio fazerem parte da mesma release.
71
4.3.1.3
PROJETO DE ARQUITETURA TCNICA
Neste subprocesso a infra-estrutura tecnolgica avaliada e realizada a definio da arquitetura geral da soluo que ser desenvolvida no projeto. As atividades referentes a estes
sub-processos so detalhadas na lista a seguir:
1. Investigar Infra-Estrutura Tecnolgica: Esta atividade refere-se ao levantamento inicial
que deve ser feito de todos os recursos tecnolgicos da instituio, servidores, mquinas,
estrutura de rede entre outros;
2. Identificar Necessidades de Instalaes e Equipamentos: Aps levantar a infra-estrutura
tecnolgica existente, feita uma anlise das necessidades de instalaes e equipamentos
a serem adquiridos para a execuo do projeto;
3. Anlise de Ferramentas: Este subprocesso engloba atividades referentes a anlise das
ferramentas que sero utilizadas na construo da soluo de BI.
(a) Definir Conjunto de Avaliao: Inicialmente deve ser definido um conjunto de ferramentas que ser avaliado por todas as partes envolvidas, gerncia de negcio e
gerncia de aplicao. Os custos, modos de demonstrao, possibilidade de visita
de consultores das empresas devero ser avaliados assim como qual a estratgia de
avaliao ser realizada;
(b) Avaliao: Aps o conjunto de ferramentas ser decidido e os critrios de avaliao
esquematizados as ferramentas sero brevemente avaliadas pelas gerncias do projeto com a interveno do coordenador tcnico do projeto;
(c) Seleo: Finalizando-se a avaliao, devero ser selecionadas as ferramentas que
sero utilizadas na execuo dos trabalhos;
(d) Prototipagem: A atividade de prototipagem s ocorrer caso seja decidido na etapa
de seleo que a organizao necessita de uma ferramenta especfica. Nesse caso
a atividade de prototipagem, ser responsvel pelo desenvolvimento do modelo da
ferramenta que ser construdo pelo time durante as iteraes do projeto.
4. Definir Documento de Viso Arquitetural: O documento de viso arquitetural deve oferecer uma viso geral de todos os itens que foram trabalhados nas atividades anteriores,
desde a definio de ferramentas a anlise da infra-estrutra da organizao;
72
4.3.1.4
PLANO DE PROJETO
Este subprocesso responsvel pela definio do plano de projeto. Este plano dever oferecer uma viso geral dos trabalhos a serem realizados em todo o processo. As atividades
referentes a este subprocesso so detalhadas na lista a seguir:
1. Definir Critrios de Sucesso: Os critrios de sucesso para o projeto devem ser decididos
em conjunto pelas gerncias e pelo lder do projeto. A partir destes critrios a soluo
desenvolvida ser avaliada para que o nvel de satisfao de seus usurios possa ser mensurado;
2. Definir Benefcios: Assim como os critrios de sucesso devem ser definidos, os benefcios
da construo da soluo de BI devem ser avaliados e registrados, servindo como uma
motivao para o incio das atividades do projeto;
3. Definir Custos e Respectivo Retorno: Deve ser realizada uma anlise de custos do projeto, incluindo no apenas despesas de pessoal, mas tambm despesas com ferramentas e
materiais de consumo. E alm disso, o retorno de investimento esperado no projeto deve
ser definido;
4. Definir Objetivos: os objetivos gerais do projeto so delineados em conformidade com os
interesses dos patrocinadores e das gerncias do projeto;
5. Definir Membros do Projeto: Deve ser definido os recursos humanos disponveis para a
composio dos times de trabalho;
6. Definir Sequncia de Releases por reas de Negcio: Com a priorizao da FBS e
definio de recursos humanos pode ser definido a sequncia de desenvolvimento pelas
reas de negcio mapeadas e priorizadas na FBS do projeto.
4.3.1.5
MONTAGEM DOS TIMES

1. Definir Tamanho: Avaliando-se os recursos humanos disponveis, ser definido pelo coordenador tcnico do projeto e as gerncias qual o tamanho dos times de trabalho;
2. Definir Treinadores: A partir dos recursos humanos disponveis e do tamanho do time
definido sero definidos treinadores para cada time de trabalho;
73
3. Alocar Membros dos Times: Aps a definio dos treinadores, os membros dos times
podem ser alocados s suas respectivas equipes.
4.3.2
PLANEJAMENTO DA RELEASE
No planejamento da release realizada uma explorao mais aprofundada do negcio da

instituio cuja soluo de BI est sendo construda. A FBS do projeto expandida a partir do
mapeamento dos processos e atividades de negcio existentes. Com este mapeamento a matriz
de necessidades dos usurios finais pode ser preenchida e a lista de funcionalidades da release
construda. A partir desta lista definido a sequncia de iteraes e as funcionalidades so
alocadas aos times de trabalho. A Figura 22 nos fornece uma viso geral dos subprocessos
relacionados ao planejamento da release:
Os seguintes artefatos esto definidos para esta etapa:
Matriz de Necessidades: A matriz de necessidades uma estrutura que permite mapear
as necessidades dos usurios atravs de uma tabela na qual as colunas representam quantificadores (os quantificadores indicam unidades de medida para um determinado item,
por exemplo quantidade de vendas, percentual de lucros, mdia de preos de produtos) e
as linhas representam agrupadores e itens de detalhamento para um determinado assunto
(os agrupadores definem os parmetros nos quais os itens em que os quantificadores so
aplicados sero avaliados, por exemplo, para o quantificador percentual sobre o item lucros podemos ter agrupadores para o ms, semestre e ano). A Figura 23 oferece uma
viso detalhada da estrutura dessa matriz;
Modelo Abrangente da Release: O modelo abrangente da release um esboo do
modelo dimensional do Data Mart que ser produzido nas iteraes. Este modelo dever conter apenas uma definio alto-nvel das tabelas fatos e dimenses. O modelo
abrangente ser detalhado e revisado a cada iterao a partir da insero das mtricas, da
definio das chaves de dimenses e das colunas das dimenses;
Lista de Funcionalidades da Release: A lista de funcionalidades da release engloba o
conjunto de anlises gerenciais esperados para a release. Esta lista ser revisada a cada
iterao, pois novas funcionalidades podem surgir a qualquer momento no processo e o
processo deve responder bem a quaisquer mudanas nos requisitos;
Plano de Iteraes: O plano de iteraes define quais funcionalidades foram alocadas a
que times e qual a sequncia de desenvolvimento das mesmas. Ele criado a partir da
Figura 22: FDWS - Planejamento da Release
74
75
Figura 23: Matriz de Necessidades (OLIVEIRA, 2010).

estimativa de custo das funcionalidades e da priorizao dos itens realizada pela gerncia
de negcio e gerncia de aplicao.
O detalhamento dos subprocessos e atividades relativos ao planejamento da release feito
nas subsees a seguir:
4.3.2.1
LEVANTAR REQUISITOS DA RELEASE
Neste subprocesso os requisitos funcionais e no-funcionais da release so coletados para

que a lista de funcionalidades seja criada. Esta lista ser a base para a definio das iteraes.
1. Entrevistar a Gerncia de Aplicao e a Gerncia de Negcio: Assim como no planejamento do projeto, reunies e entrevistas com a gerncia de aplicao e a gerncia de
negcio sero realizadas a fim de possibilitarem a coleta dos requisitos da release;
2. Mapear Macro-Processos, Processos, Atividades e Tarefas: Os processos e atividades
de negcio da rea de negcio alvo da release sero mapeados a fim de possibilitarem
uma melhor explorao do domnio e potencializar o trabalho de anlise de requisitos. O
FDWS possui uma estrutura de levantamento de requisitos estruturada de modo a esgotar
as anlises de possveis funcionalidades para a soluo de BI e este levantamento de
requisitos direcionado no apenas s necessidades dos usurios, mas s necessidades
dos processos e dos objetivos organizacionais. O mapeamento dos processos e atividades
de negcio possibilita uma alta cobertura de todos os requisitos que podem ser coletados;
76
3. Incrementar FBS do Projeto: Ao realizar o mapeamento de processos e atividades de

negocio a FBS do projeto pode ser incrementada de modo a incluir estes itens;
4. Popular Matriz de Necessidades: Ao mapear os processos e atividades de negcio os
usurios entrevistados devem preencher a matriz de necessidades com o apoio dos treinadores
e do coordenador tcnico do projeto, avaliando as anlises de interesse relativas a estes
processos e atividades, suas necessidades como gestor e necessidades organizacionais em
geral. As matrizes preenchidas sero catalogadas pelo time e daro origem ao modelo
abrangente da release e tambm a lista de funcionalidades da release;
4.3.2.2
DESENVOLVER MODELO ABRANGENTE DA RELEASE
No desenvolvimento do modelo abrangente criado um modelo dimensional alto-nvel da

release que ser posteriormente refinado a cada iterao realizada. As atividades referentes a
este subprocesso so detalhadas na lista a seguir:
1. Formar Grupos de Modelagem: A primeira etapa deste subprocesso consiste na formao
dos grupos de modelagem, deste modo o time ser disposto em duplas que modelaro
partes no negcio da release;
2. Estudo Dirigido do Domnio (Estudar Documentao): Um estudo dirigido da rea de
negcio alvo da release ser feito de modo que o time possa explorar os detalhes existentes do dominio;
3. Desenvolver Modelo de Pequenos Grupos: Aps o estudo dirigido, os pequenos grupos
faro propostas de modelagem para partes da FBS do projeto referente a release. Aps
um determinado tempo, um grupo ser escolhido e apresentar seu modelo alto-nvel,
os outros grupos opinaro e o modelo desenvolvido ser refinado. Este processo ser
repetido at que toda a FBS do projeto referente a release seja modelada.;
4. Desenvolver Modelo dos Times: O modelo dos times gerado a partir da integrao de
todos os modelos de pequenos grupos. Como o processo de modelagem alto nvel o
modelo dos times construdo aos poucos baseando-se na prtica de design incremental;
5. Refinar Modelo Abrangente: Alguns refinamentos podem ser feitos logo aps a primeira
verso do modelo. Lembrando que o modelo abrangente apenas um modelo alto-nvel
que serve como uma guia para a modelagem detalhada que ser feita nas iteraes;
77
6. Validar Modelo Abrangente: Aps a elaborao do modelo, o mesmo ser validado junto
a gerncia de negcio e novas idias podero ser colhidas e o modelo ter de ser novamente refinado.
4.3.2.3
CRIAR/PRIORIZAR LISTA DE FUNCIONALIDADES DA RELEASE
Com a criao do modelo abrangente e de posse da FBS do projeto incrementada com os

itens da release e as matrizes de necessidades preenchidas o time pode sintetizar e criar a lista
de funcionalidades da release. As atividades referentes a este subprocesso so detalhadas na
lista a seguir:
1. Construir Lista de Funcionalidades: A lista de funcionalidades criada a partir da matriz
de necessidades, do modelo abrangente e da FBS do projeto. Incialmente no espera que
esta lista seja esgotada de itens. Espera-se que ela venha crescer exponencialmente a
partir da realizao das iteraes;
2. Validar Lista de Funcionalidades: A lista de funcionalidades criada pelo time dever ser
validada pela gerncia de negcio e gerncia de aplicao, pois estes tero a posse desta
lista e podero adcionar itens a ela a qualquer momento;
3. Priorizar Lista de Funcionalidades: Os itens da lista de funcionalidades devero ser priorizados com relao ao seu valor de negcio preferencialmente pela gerncia de aplicao
tendo o apoio da gerncia de negcio;
4. Estimar Custo de Desenvolvimento: Aps a priorizao o time dever estimar o custo do
desenvolvimento das funcionalidades de modo que o planejamento das iteraes possa
ser feito de acordo com a capacidade do time em desenvolver estas funcionalidades.
4.3.2.4
CRIAR PLANO DE ITERAES
Este subprocesso determina a quantidade de iteraes pertencentes a release e a distribuio

da lista de funcionalidades pelas iteraes bem como a alocao das funcionalidades aos times
de trabalho. As atividades referentes a este subprocesso so detalhadas na lista a seguir:
1. Determinar Sequncia de Desenvolvimento: Com base na lista de funcionalidades priorizada e estimada pelos desenvolvedores, pode-se definir a sequncia de desenvolvimento
dos itens. A quantidade de iteraes necessrias estipulada a partir do custo das funcionalidades, do tamanho da iterao, do tamanho dos times e da priorizao das funcionalidades;
78
2. Alocar Funcionalidades aos Times: Com a definio das funcionalidades pertencentes s

iteraes, estas podem ser alocadas ao time ou aos vrios times caso existam.
4.3.2.5
REVISAR ARQUITETURA TECNOLGICA/FERRAMENTAS
O lder do projeto, treinadores e o time devem sempre verificar se as ferramentas utilizadas

atendem aos clientes e se no h a necessidade de adquirir outras ferramentas ou desenvolver
alguma ferramenta especifca.
4.3.3
ITERAO
na iterao que ocorre a implementao dos itens da Lista de Funcionalidades da Release pelos membros do time. Os subprocessos relacionados so ilustrados na Figura 24. O
detalhamento dos subprocessos e atividades relativos a iterao feito nas sees a seguir:
4.3.3.1
CONFIGURAO DO AMBIENTE DE TESTES, PRODUO E HOMOLOGAO
Os ambientes de testes, produo e homologao sero configurados pelo time durante

a primeira iterao. Caso haja mudanas nesses ambientes esta atividade poder realizar-se
novamente;
4.3.3.2
CONFIGURAO DE FERRAMENTAS
As ferramentas a serem utilizadas sero configuradas pelo time. Esta atividade provavelmente s ocorrer na primeira iterao. Pode acontecer de o conjunto de ferramentas ou a
verso das ferramentas utilizadas mudarem durante o processo, fato este que far com que essa
etapa seja novamente realizada;
4.3.3.3
CRIAR VERSO DE TESTE, PRODUO E HOMOLOGAO
O time dever criar as verses de teste, produo e homologao a fim de atender ao fluxo
de desenvolvimento e as funcionalidades que sero implementadas. Esta atividade s ocorrer
na primeira iterao do projeto. A no ser que haja alguma mudana esta atividade poder se
repetir em outras iteraes.
Figura 24: FDWS - Iterao
79
80
4.3.3.4
DETALHAR FUNCIONALIDADES
Neste subprocesso realizado um detalhamento de cada funcionalidade da iterao e por

conseguinte do modelo abrangente da release para incluir as definies de tabelas fato, dimenses e mtricas. Esse detalhamento possibilitado por um estudo dirigido do domnio mais
aprofundado do que o realizado no subprocesso de planejamento da release. Suas atividades
so detalhadas na lista a seguir:
1. Estudo Dirigido do Domnio (Estudar Documentao): No estudo dirigido do domnio
na iterao dever ser realizado o detalhamento das dimenses e tabelas fato contidas
no modelo abrangente da release referentes s funcionalidades da iterao. Este estudo
ser realizado com o apoio da gerncia de negcio que dever apresentar ao time maiores
detalhamentos de cada funcionalidade com relao as bases transacionais. As documentaes existentes para estes itens como dicionrio de dados, modelos ER sero investigados pelo time;
2. Refatorar rea de Staging (Incluir Itens do Novo Modelo): A rea de staging refatorada
de modo a atender ao novo conjunto de dados que ser utilizado durante a iterao;
3. Refatorar Modelo Dimensional (Incluir Itens do Novo Modelo): O DW refatorado de
modo a atender ao novo conjunto de dados que ser utilizado durante a iterao. Estas
refatoraes incluem a adio/remoo de colunas e tabelas, defies de chaves etc...;
4. Refinar Modelo Abrangente: Com o detalhamento do modelo dimensional da iterao,
o modelo abrangente pode ser refinado de modo a oferecer a viso dos itens que esto
sendo trabalhados durante a iterao. Deste modo as definies de mtricas, colunas de
dimenses passam a fazer parte do modelo abrangente.
4.3.3.5
PROJETO FSICO
Neste subprocesso todos os itens modelados na etapa anterior so implementados nas bases
de dados do projeto. As atividades referentes a este subprocesso so detalhadas na lista a seguir:
1. rea de Staging: O projeto fsico da rea de staging refere-se a aplicao dos itens modelados e refatorados no subprocesso anterior;
2. DW: O projeto fsico do DW refere-se a aplicao dos itens modelados e refatorados no
subprocesso anterior;
81
3. Implementar e Integrar Mudanas no Banco: Todos os itens modelados so implementados e integrados aos que j existiam no ambiente de produo antes da iterao.
4.3.3.6
PROJETO DE METADADOS
Neste subprocesso realizado a definio, implementao, integrao e validao do metamodelo referente s funcionalidades da iterao. As atividades referentes a este subprocesso
so detalhadas na lista a seguir:
1. Definio do Metamodelo: O time deve especificar o modelo de metadados para as funcionalidades referentes a iterao;
2. Implementao e Integrao do Metamodelo: Aps a especificao do metamodelo o
mesmo deve ser implementado e integrado com o metamodelo existente;
3. Teste e Validao: Aps a atividade de implementao e integrao o metamodelo precisa
ser validado e testado pelo time.
4.3.3.7
PROJETO DE ETL
No subprocesso de Projeto de ETL so realizadas as operaes de integrao dos dados

das bases transacionais para que estes possam ser carregados no DW do projeto. As atividades
1. Mapeamento do ETL/Regras de ETL - Dicionrio de Transformaes: A primeira atividade deste subprocesso refere-se ao mapeamento das tabelas de origem e destino do processo de ETL e a definio de quais transformaes os dados das colunas destas tabelas
iro sofrer durante o processo;
2. Implementao e Integrao das Rotinas de ETL: Aps o mapeamento das tabelas origem/destino e das transformaes nos dados, as rotinas de ETL podem ser implementadas e integradas s rotinas que j existem;
3. Teste e Validao dos Dados: Aps a implementao e integrao de todas as rotinas,
estas devero ser devidamente testadas de modo que as rotinas que j existiam continuem retornando o mesmo conjunto de dados e as novas operem corretamente. Os dados
resultantes devem ser validados pelo time, pela gerncia de negcio e pela gerncia de
aplicao do projeto (Este processo de validao tambm pode ser chamado de Anlise
82
de Dados. O maior objetivo garantir que os dados carregados no DW sejam corretos e

fiis a realidade organizacional).
4.3.3.8
PROJETO DA APLICAO DE BI
Neste subprocesso as aplicaes de explorao da informao so modeladas, implementadas, integradas a soluo existente e devidamente testadas para sua validao. As atividades
1. Modelagem da Aplicao de Explorao da Informao: Nesta atividade devem ser construdos os templates dos relatrios, dashboards e todos os mecanismos que sero utilizados para a explorao dos dados fornecidos pelo DW;
2. Implementao e Integrao: Aps a modelagem, os itens so implementados e integrados aos itens j existentes;
3. Teste e Validao de Interfaces: Aps a implementao e integrao, todos os itens desenvolvidos devem ser devidamente testados para que se faa a validao de todas as
interfaces e mecanismos de explorao da informao.
4.3.3.9
VALIDAO E VERIFICAO (TESTES INTEGRADOS)
Os testes realizados no subprocesso de validao e verificao so realizados pelo time, pela

gerncia de negcios e pela gerncia de aplicao. Alm destes testes que ocorrem no ambiente
de testes do time, outros testes sero realizados posteriormente no ambiente de homologao
com um conjunto maior de usurios. As atividades referentes a este subprocesso so detalhadas
na lista a seguir:
1. Teste de Qualidade: A qualidade dos dados resultantes deve ser rigorosamente avaliada
pelo time com a ajuda das gerncias do projeto;
2. Testes das Operaes do Processo: Todas as operaes do processo devem ser devidamente testadas para garantia do pleno funcionamento da soluo;
3. Teste de Desempenho: O desempenho de todas as operaes do processo e do acesso aos
dados devem ser testados e avaliados;
4. Testes de Implantao: A implantao da soluo desenvolvida em cada ambiente deve
ser devidamente testada, antes de seu uso ser liberado aos usurios;
83
5. Teste de Acessibilidade de Usurios: A acessibilidade dos usurios com relao as aplicaes de explorao da informao deve ser avaliada e testada pelo time;
6. Teste de Aceitao: Testes de aceitao devem ser feitos com os usurios finais de modo
a validar todos os itens desenvolvidos.
4.3.3.10
IMPLANTAO NO AMBIENTE DE HOMOLOGAO
Na execuo da iterao, o time trabalha basicamente no ambiente de testes at que cada

item desenvolvido seja devidamente testado e validado pela gerncia de negcios e gerncia de
aplicao. Aps todos os itens serem desenvolvidos e testados os mesmos podem ser implantados no ambiente de homologao para testes adicionais com um conjunto maior de usurios
finais. Esse processo acompanhado da demonstrao das funcionalidades desenvolvidas para
as gerncias do projeto. A grande quantidade de testes realizados justifica-se pela necessidade
de uma exaustiva validao de todos os itens desenvolvidos. Alm disso na execuo dos testes
novos requisitos de usurio podem ser levantados, pois neste momento que os usurios finais
podem experimentar as potencialidades de uma soluo de BI.
4.3.4
PS-ITERAO
No subprocesso da ps-iterao so realizadas atividades referentes a implantao em ambiente de produo dos itens desenvolvidos na iterao, acompanhamento de seu uso pelos
clientes da soluo, retrospectiva da iterao pelo time, treinador e coordenador tcnico e avaliao da iterao. Estes itens so detalhados na lista a seguir e ilustrados na Figura 25:
Retrospectiva da Iterao: O time, o treinador e o coordenador tcnico (caso exista)
se reunem para que possam avaliar o trabalho da equipe durante a iterao, identificar
os problemas ocorridos e propor melhorias a fim de potencializar ainda mais o trabalho
desenvolvido pelo time;
Implantao no Ambiente de Produo: Aps o final da iterao e realizao de todos
os testes no ambiente de homologao a soluo desenvolvida deve ser colocada no ambiente de produo, afim de que possa ser utilizada por um nmero maior de usurios. Esta
imaplantao deve ser acompanhada pela equipe durante os seus primeiros dias, afim de
que possveis problemas possam ser observados e a aceitao pelos clientes ser avaliada;
Formao dos Utilizadores: Complementando a atividade anterior, ao time responsvel pela formao dos utilizadores da soluo de BI, seja com a elaborao de manuais
Figura 25: FDWS - Ps-Iterao
84
85
de uso ou com a realizao de capacitaes especifcas;

Avaliao da Iterao: O planejamento da release deve ser revisto, o que pode ocasionar em uma mudana na ordem de execuo das iteraes. Nesta avaliao dever ser
verificada a existncia de novos requisitos com as gerncias do projeto.
4.4
ANLISE DA METODOLOGIA FDWS
Nesta seo ser feita uma anlise do FDWS em relao s prticas geis utilizadas em sua
composio e com os trabalhos relacionados a esta proposta.
4.4.1
PAPIS
A estrutura de papis do FDWS origina-se das metodologias SCRUM e FDD. Como j

citado, no SCRUM temos a figura do Product Owner, Scrum Master e Time. No FDWS a
figura do Product Owner transforma-se em um grupo de pessoas denominado de Gerncia de
Negcio, continuando a ser os representantes do cliente nos momentos em que este no tiver
disponibilidade de interagir diretamente com o Ncleo de Desenvolvimento. Este ncleo, foi
formado pela aglutinao do Time com o Scrum Master que no FDWS chama-se Treinador.
Neste grupo tambm foi adicionado a figura de um Coordenador Tcnico do Projeto que pode
ser o prprio treinador do time na existncia de apenas um time do trabalho ou um membro do
Ncleo de Desenvolvimento que assuma a coordenao geral na existncia de vrios times.
Foi tambm adcionado uma Gerncia de Aplicao devido a necessidade que projetos de
BI tm da participao dos usurios finais e clientes para seu pleno sucesso. O gestor da organizao quem conhece bem as necessidades do negcio e alm disso ele que tem o poder de
deciso. A Gerncia de Aplicao pode ento interagir diretamente com o Ncleo de Desenvolvimento ou com a Gerncia de Negcio que servir como ponte entre os dois grupos.
Do FDD vem a concepo da equipe onde os membros possuem funes bem definidas.
Por isso foram definidos cinco papis que os membros do time podem assumir. Alm disso
a figura do Treinador ganha no FDWS responsabilidades adicionais em comparao com as
responsabilidades do Scrum Master do SCRUM. Alm de gerenciar o processo e trabalhar para
potencializar o trabalho realizado pelo time, o Treinador responsvel pelas sesses de coleta
de requisitos, documentao e gerncia do conhecimento.
86
4.4.2
CICLO DE VIDA
O ciclo de vida do FDWS uma composio dos ciclos de vida do SCRUM, FDD e XP.
Do XP vem a realizao das releases e iteraes, do SCRUM vem a idia do planejamento do
projeto e da construo da lista de funcionalidades do produto. Tanto XP como SCRUM no
definem bem como o planejamento do projeto deve ser feito. Eles especificam que uma viso
inicial do produto deve ser gerada, mas concentram-se muito em detalhar os aspectos ligados
a iterao. O FDWS possui as etapas de planejamento do projeto e planejamento da release
bem definidas com o apoio do esquema de planejamento definido pela FDD. Esse planejamento
inicial crucial em projetos de BI, pois deve ser realizada uma avaliao geral da organizao
em que a soluo ser desenvolvida e os recursos necessrios devem ser garantidos. Alm
disso esse planejamento inicial relaciona-se com o processo de levantamento de requisitos. Se
nos processos de desenvolvimento de software tradicionais a coleta de requisitos pode ser um
problema. Em BI esse problema ainda maior; os usurios finais s descobrem efetivamente as
potencialidades da soluo quando esta colocada em produo e a partir da que efetivamente
os requisitos dos usurios iro aparecer.
O processo do FDWS comea com uma mapeamento das reas de negcio inicialmente.
Esta a viso inicial do produto que ser desenvolvido. Para cada rea de negcio, ser realizada uma release os processos e atividades de negcio sero mapeados e a partir da as funcionalidades so coletadas. Um modelo abrangente da release feito e a sequncia de desenvolvimento planejada com base na lista de funcionalidades construda. A cada iterao, o modelo
abrangente e as funcionalidades sero detalhadas e implementadas. Este basicamente o ciclo
definido pela FDD: Desenvolver um modelo abrangente, construir a lista de funcionalidades,
planejar por funcionalidades, detalhar por funcionalidades e construir por funcionalidades.
A iterao no FDWS incorpora prticas do SCRUM como as reunies dirias, reunies de
demonstrao do produto e reunies de retrospectiva. Alm do SCRUM alguns itens do XP so
utilizados, como a programao em par e o desenvolvimento dirigido por testes. Estes itens so
melhor explicados na listagem a seguir:
Itens do SCRUM Utilizados na Iterao do FDWS:
1. Sprint Backlog: O sprint backlog do SCRUM no FDWS pode ser traduzido como
a lista de funcionalidades definida para a iterao e as tarefas relativas a seu desenvolvimento;
2. Sprint Planning: Assim como no SCRUM, antes das sprints ocorrem as reunies
de planejamento (Sprint Planning), no FDWS antes do inicio de cada iterao
87
realizada uma reunio de planejamento, afim de que possam ser avaliados os itens
da lista de funcionalidades referentes a iterao;
3. Sprint Review: Aps cada iterao feita uma reunio de demonstrao do que foi
desenvolvido, assim como no SCRUM so realizadas as Sprint Review;
4. Sprint Retrospective: A sprint no SCRUM encerra-se com a Sprint Retrospective de
modo que o time possa avaliar seu trabalho e seu processo de desenvolvimento. Do
mesmo modo no FDWS a cada final de iterao ocorre uma reunio de retrospectiva
entre o time, o coordenador tcnico e os treinadores;
5. Daily Scrum Meeting: Assim como no SCRUM, o FDWS determina que sejam realizadas reunies dirias pelo time para que o seguinte conjunto de perguntas possa
ser respondido: O que eu fiz ontem ? O que eu farei hoje ? Quais foram os impedimentos no processo ?
6. Burndown Charts: O treinador e o coordenador tcnico do projeto devero definir
quais grficos sero utilizados para acompanhamento durante o projeto
Itens do XP Utilizados na Iterao do FDWS:
1. Programao em Par: As atividades durante a iterao devem prioritariamente ser
realizadas em pares;
2. Desenvolvimento Orientado a Testes: O desenvolvimento dos itens durante a iterao dever ser pensado com base nos testes que podero ser executados e alm disso
todos os itens devem ser devidamente testados e validados;
3. Design Incremental: O design da soluo comea simples e vai se aperfeioando
com o tempo;
4. Propriedade Coletiva do Cdigo: Todo cdigo ou artefato gerado de propriedade
de todos e deve estar disponvel em um lugar de acesso comum;
5. Ambiente de Trabalho Informativo: O ambiente de trabalho deve ser preenchido
pelo Kanban, grficos de acompanhamento, ou seja, dados sobre o projeto e o que
est sendo desenvolvido;
6. Padro de Codificao: O time deve ter um padro de codificao comum e aceitvel
por todos. O cdigo e os itens desenvolvidos pertencem ao time e no a um membro
em especial;
7. Rtimo Sustentvel / Trabalho Energizado: O ritmo de trabalho do time deve ser
constante, por exemplo se o regime de 40 horas semanais o time deve trabalhar
apenas 40 horas semanais, sem horas extras, sem tempo adicional.
88
4.4.3
FDWS E OS TRABALHOS RELACIONADOS
Tanto o FDWS como o Extreme Scoping trabalham com o conceito de releases. Tanto
a metodologia SCRUM como a XP fazem parte de seu processo assim como no Agile Data
Warehousing. Porm o diferencial do FDWS est na incorporao das prticas de FDD em seu
processo de planejamento. A composio com o FDD faz com que a lista de funcionalidades
gerada no FDWS tenha uma ligao muito forte com os processos de negcio o que permite
facilmente mapear os indicadores desejados e os ndices ligados aos objetivos organizacionais.
Alm disso, os requisitos de usurio so avaliados iterativamente e a lista de funcionalidades
expandida iterativamente e incrementalmente.
A partir da Ps-Iterao, o plano de execuo das iteraes reavaliado, o que permite ao
time realizar operaes de manuteno, melhorias e evoluo na soluo de BI existente em produo. Basta apenas que as gerncias do projeto definam funcionalidades do tipo manuteno
ou evoluo. Tanto o Extreme Scoping como o Agile Data Warehousing no definem claramente como essas atividades so feitas. O FDWS incorpora ainda a idia trazida no trabalho de
(CARVALHO, 2009). O modelo do DW evolui a partir das consultas que so disponibilizadas aos
usurios finais. Para isso o FDWS define uma funcionalidade como uma consulta OLAP, ou um
relatrio, ou at mesmo a aplicao de uma tcnica de Data Mining. A partir das funcionalides
as atividades de back-end e front-end podem ser realizadas em conjunto durante a iterao.
89
ESTUDO DE CASO
Para avaliar a proposta deste trabalho foram realizados dois estudos de casos. Estes estudos
de caso serviram ainda para aprimorar a especificao da metodologia. O primeiro estudo de
caso, descrito na seo 5.1 foi realizado entre os meses de maro e julho de 2010 como parte
de um Projeto Permanecer denominado DW-UFBA. Este projeto possibilitou a maturao das
idias em torno do FDWS e o refinamento da sua especificao, a qual foi finalizada no segundo
estudo de caso, descrito na seo 5.2 realizado nos trabalhos da disciplina Tpicos em Banco de
Dados do Departamento de Cincia da Computao da Universidade Federal da Bahia (DCCUFBA), no semestre de 2010-2. Foi realizada, ainda, uma avaliao qualitativa, com a aplicao
de um questionrio aos participantes de ambos projetos. O questionrio aplicado encontra-se no
Apndice C e os resultados dessa avaliao so descritos na sesso 5.3. Maiores detalhes com
relao as etapas de cada subprocesso realizadas nos estudos de caso encontram-se no Apndice
B.
5.1
PROJETO PERMANECER
O objetivo das atividades do projeto Permanecer DW-UFBA foi evoluir uma soluo de
BI construda para a UFBA no semestre de 2009-2 durante a disciplina Tpicos em Banco de
Dados. A soluo inicial contemplava anlises referentes ao banco de pessoal da UFBA, o
UFBADB. A seguir descreveremos como foram desempenhadas as atividades do FDWS nesse
projeto.
5.1.1
No planejamento do projeto, foi definido pelo time, gerncia de negcio, treinador e coordenador tcnico a sequncia de releases do projeto de modo a cobrir o tempo de execuo
dos trabalhos entre os meses de maro a novembro de 2010. O time e o treinador definiram
que cada release seria composta de trs iteraes de duas semanas ou quinze dias. Na primeira
90
release a soluo de BI construda no semestre de 2009-2 deveria ser colocada em produo

no Centro de Processamento de Dados da UFBA (CPD-UFBA) avaliada e melhorada. Nas releases subsequentes, o time iria trabalhar com os dados do vestibular da UFBA (Questionrio
Scio-Econmico, Questionrio Geral do Candidato e Lista de Candidatos Aprovados) e por
fim com os dados do Sistema Acadmico. Essa definio foi feita a partir do mapeamento das
reas de negcio prioritrias com relao a anlises gerenciais na UFBA e que tivessem ligao
direta com a soluo j construda.
Os objetivos do projeto foram definidos, assim como, um calendrio de reunies para acompanhamento do projeto entre o time, o coordenador tcnico, a gerncia de negcio e o treinador.
Devido ao financiamento do projeto, pode-se contar com um time de apenas dois bolsistas.
5.1.2
Apesar do planejamento feito anteriormente apenas uma release foi realizada durante todo
o projeto devido a um conjunto de problemas que so listados abaixo:
O planejamento do projeto foi mal realizado e as estimativas das tarefas tiveram baixa
confiabilidade. Alm disso no foi trabalhado a construo de uma lista de funcionalidades com o time o que dificultou no acompanhamento das tarefas e no gerenciamento do
projeto;
O nvel de conhecimento do time a respeito das ferramentas utilizadas pode ser considerado como baixo. O time amadureceu no uso das ferramentas durante o processo.
Portanto o item estudo de ferramentas e treinamento deveria ter sido levado em conta
durante o planejamento inicial;
Um dos itens que mais contribuiram com o atraso do projeto, foram as tarefas relacionadas s rotinas de ETL. A lio aprendida foi que o processo de ETL necessita ser
melhor especificado e dimensionado, para que no hajam surpresas relativas ao estouro
do prazo pr-estabelecido. Alm disso, muito importante que o time tenha completo
domnio da definio da arquitetura de ETL e da realizao das tarefas necessrias como
programao em SQL;
A falta de interao com uma gerncia de negcios, dificultou a realizao de algumas
atividades que dependiam do conhecimento do negcio da instituio e, alm disso, possibilitaram que erros conceituais ocorressem durante o processo. No houve a participao
de uma gerncia de aplicao.
91
Devido a estes motivos o plano de iteraes seguiu at o ms de julho sem que os objetivos
da release fossem completamente alcanados. Aps este ms, o projeto seguiu seu ritmo de
trabalho sem a realizao de mais iteraes. A falta de uma lista de funcionalidades bem detalhada e um escopo bem definido prejudicaram substancialmente no andamento do projeto. O
time acabou ficando preso e perdido em meio as dificuldades enfrentadas e a tentativa de evoluir
no trabalho realizado.
5.1.3
ITERAO
Prticas como o planejamento da iterao e reunies dirias foram trabalhados alm de algumas reunies de demonstrao com a coordenao tcnica e o treinador j no final do projeto.
Atividades relativas a modelagem dimensional, projeto fsico, projeto de metadados, projeto de
ETL e projeto das aplicaes de BI foram todas realizadas. Algumas reunies de acompanhamento geral do projeto tambm foram feitas durante o processo. A programao em par foi
aplicada de modo que os membros do time realizassem as mesmas atividades em ambientes de
trabalho diferentes (Windows e Linux), porm a divergncia de horrios e faltas dos membros
do time dificultaram a adoo desta prtica durante todo o processo e a mesma deixou de ser
usada aps trs iteraes.
O grande problema com as iteraes foi que algumas funcionalidades programadas para a
segunda e terceira iterao perduraram por vrias iteraes da release. Dentre estas funcionalidades destacam-se a criao dos dashboards e a refatorao do processo de ETL. Muito tempo
foi investido em estudo e pesquisas a fim de que os problemas enfrentados fossem resolvidos.
A sntese das lies aprendidas neste estudo de caso so detalhadas na lista abaixo:
1. Mtodos geis so simples porm difceis de implementar, pois dependem muito da maturidade e disciplina dos envolvidos e alm disso seu pleno sucesso depende da existncia
de uma equipe auto-organizada e auto-gerencivel;
2. Mtodos geis foram feitos para gerncia e desenvolvimento de projetos de software e no
de projetos de integrao de dados. As estimativas de tarefas na aplicao de mtodos
geis em BI exigem um certo cuidado principalmente nas tarefas relativas a integrao
de dados. Alm disso, desejvel que o time tenha bom conhecimento das ferramentas
utilizadas e programao em SQL, caso contrrio, algum tempo da iterao ser destinado
a este estudo;
3. O escopo da iterao deve ser tangvel ao seu tamanho o que implica em um bom planejamento da sequncia de iteraes a serem realizadas;
92
4. Equipes de tempo integral: Para a aplicao da programao em par necessrio que o

time seja de tempo integral e que os horrios de seus membros tenham plena coaliso;
5. Iterao com a gerncia de negcios: No possvel ter sucesso no trabalho realizado
sem que a gerncia de negcios seja considerada parte do time e tenha participao ativa
no processo;
6. Visibilidade e acompanhamento: Uma das prticas que no foram utilizadas durante o
estudo de caso refere-se a visibilidade do projeto. Itens como o Kanban, grficos de
medio de velocidade da equipe, pontos de projeto consumidos, esforo restante so de
extrema importncia para a visibilidade do projeto e devem ser utilizados na iterao;
7. Gerncia do conhecimento: importante que o processo seja documentado de modo que
possa existir um registro histrico das lies aprendidas e das decises do projeto. Este
pode ser considerado como um dos pontos fracos do estudo de caso;
8. Coaching: Outro ponto fraco do estudo de caso refere-se ao coaching. Entre as atividades
esperadas do treinador do time (ou coach) esto a vigilncia a adoo e aplicao da
metodologia gil no projeto e a interao com a gerncia de negcios. Alm disso,
interessante que o mesmo possa treinar o time com relao a metodologias geis e as
prticas a serem adotadas durante o processo.
Durante a execuo dos trabalhos o time pode realizar testes de qualidade, teste das operaes do processo e implantao. As lies aprendidas durante a realizao desse estudo de
caso possibilitaram o amadurecimento em torno de metodologias e prticas geis culminando
em melhorias na especificao do FDWS e sua aplicao no segundo estudo de caso descrito na
seo 5.2.
5.1.4
PS-ITERAO
O nico item trabalhado na ps-iterao foram as reunies de retrospectiva entre o time e

o treinador para a avaliao dos trabalhos executados, verificao das dificuldades e impedimentos existentes. As reunies de retrospectiva foram constantes tentativas de solucionar os
problemas que ocorreram e melhorar o trabalho realizado.
93
5.2
TPICOS EM BANCO DE DADOS - SEMESTRE 20102
A aplicao do FDWS nesta disciplina ocorreu de modo a apoiar os projetos finais dos
alunos. Para tanto, os times de trabalho tiverem dois clientes: A UFBA e a SANTA CASA
de MISERICRDIA do ESTADO da BAHIA. Os trabalhos foram realizados no perodo de
Outubro a Dezembro de 2010, abrangendo duas iteraes de um ms cada.
As sees a seguir detalham os trabalhos realizados destacando sua ligao com os subprocessos e atividades do FDWS.
5.2.1
Anlise Organizacional:
Em ambos os projetos foi realizada a etapa de avaliao da cultura organizacional de
modo que o time, os treinadores e os coordenadores tcnicos podessem obter uma compreenso geral de cada uma das organizaes e de suas principais atividades. A motivao
organizacional foi avaliada com relao a SANTA CASA, pois este foi o primeiro projeto
realizado em parceria com a mesma. As gerncias de aplicao e negcio foram definidas
para os dois projetos a partir das reunies realizadas;
Criar/Priorizar FBS do Projeto:
Algumas reunies foram realizadas com a gerncia de negcio pelos coordenadores tcnicos do projeto, de modo que o escopo do trabalho que seria realizado na disciplina fosse
planejado e avaliado. As reas de negcio de cada instituio foram mapeadas atravs das
reunies realizadas de um modo bastante intuitivo e sem a formalidade da documentao
na FBS do projeto. A priorizao das reas de negcio foi realizada pela prpria gerncia de negcio da Santa Casa na primeira reunio de projeto. Apesar da no existncia
fisca do FBS do projeto foi definido que a rea de negcio a ser trabalhada na disciplina seria a Maternidade. Com relao ao Projeto UFBA, os coordenadores tcnicos j
haviam definido que a rea de negcio a ser trabalhada seria a Acadmica, isto devido
a grande proximidade dos mesmos com a instituio e o conhecimento pr-existente das
necessidades gerenciais da UFBA;
Projeto de Arquitetura Tcnica:
A anlise de ferramentas foi realizada na 2 iterao do projeto para a avaliao de aplicaes de explorao da informao (OLAP + Relatrios + Dashboards) que poderiam
94
ser utilizadas no projeto. Aps definido o conjunto de testes, as ferramentas foram avaliadas pelas equipes utilizando o conjunto de dados gerado na 1 iterao do projeto;
Plano de Projeto:
Nesta fase houve a definio dos objetivos para cada projeto, definio dos membros
conforme as gerncias de negcio e aplicao identificadas, os alunos da disciplina e
os coordenadores tcnicos do projeto e a definio do tempo de execuo da release do
projeto;
Montagem dos Times:
O tamanho definido para cada time foi de 3 pessoas (devido a quantidade de alunos da
disciplina, 5 times de 3 pessoas), sendo que uma destas assumiria a funo de treinador
do time. A alocao dos membros dos times foi feita mediante sorteio obedecendo.
5.2.2
Levantar Requisitos da Release:

Algumas reunies e entrevistas foram realizadas pelos coordenadores tcnicos do projeto
para a coleta de requisitos necessria a elaborao da lista de funcionalidades da release
junto a gerncia de negcio de cada projeto;
Desenvolver Modelo Abrangente da Release:
A documentao das bases de dados utilizadas no projeto foram estudadas com o apoio
da gerncia de negcio tanto pelos times como pelos coordenadores tcnicos do projeto.
Para o projeto UFBA, foi criado um modelo abrangente da release de modo a guiar o
processo de modelagem a ser feito pelos times. Porm este modelo no foi disponibilizado s equipes. Os coordenadores tcnicos atuaram como consultores em modelagem
dimensional e utilizaram deste modelo geral para guiar o trabalho de modelagem dos
times;
Criar/Priorizar Lista de Funcionalidades da Release:
A lista de funcionalidades foi criada pela coordenao tcnica e validada junto a gerncia
de negcio de ambos os projetos. A estimativa de custo de desenvolvimento para cada
funcionalidade foi realizada pelos times, o que lhes possibilitou separar as funcionalidades nas duas iteraes que formaram a release do projeto.
Criar Plano de Iteraes:
95
Para cada time foi destinado um "perfil de trabalho"contendo um conjunto de funcionalidades relativas a um determinado processo de negcio referente a rea em que estavam
trabalhando. Como os times fizeram a estimativa de custo de desenvolvimento das funcionalidades e no houve priorizao da lista pela gerncia de negcios, os membros do
time determinaram a sequncia de desenvolvimento a partir da seleo de um conjunto de
funcionalidades para cada iterao;
5.2.3
ITERAO
Detalhar Funcionalidades:
Na iterao os times realizaram um estudo mais detalhado do dominio para fazerem a
modelagem dimensional a partir da lista de funcionalidades e dos modelos de dados
transacionais. Na primeira iterao foi modelada uma rea de staging de modo a receber
os dados oriundos das bases transacionais de ambos os projetos. Na segunda iterao
esta rea de staging necessitou ser refatorada de modo a atender aos novos dados disponibilizados. Isto tambm aconteceu para o DW modelado na 1 iterao que teve de ser
refatorado na 2 iterao do projeto;
Projeto Fsico:
Com a modelagem lgica da rea de staging e do DW os projetos fsicos de ambos
poderam ser implementados e integrados aos itens existentes no ambiente de produo
(na 2 iterao);
Projeto de Metadados:
O modelo de metadados para cada iterao foi criado de acordo com as funcionalidades, integrado ao modelo existente no ambiente de produo (na 2 iterao), testado e
devidamente validado pelos times;
Projeto de ETL:
Os times realizaram o mapeamento das tabelas de origem/destino no processo de ETL
e registraram as transformaes necessrias nas colunas das tabelas de origem criando
assim o mapeamento do ETL e o dicionrio de transformaes. De posse desse mapeamento e do dicionrio de transformaes as rotinas de ETL poderam ser implementadas,
integradas (na 2 iterao), testadas e validadas;
Projeto da Aplicao de BI:
96
Os times criaram os projetos de interface para os relatrios e dashboards especficados

na lista de funcionalidades da release. Estes itens foram implementados, integrados (na
2 iterao), testados e validados pelos times antes da apresentao para os clientes;
5.2.4
PS-ITERAO
Na ps-iterao foi feita uma reunio de retrospectiva em conjunto com a demonstrao

dos itens implementados a gerncia de negcio do projeto.
5.3
AVALIAO
O FDWS foi aplicado sem que o pessoal envolvido tivesse conhecimento sobre o mesmo.
No projeto Permanecer foi realizada uma reunio no qual foram discutidos alguns aspectos
relacionados a especificao da metodologia proposta e sua relao com o framework SCRUM.
Durante as aulas da disciplina Tpicos em Banco de Dados, os alunos tiveram uma palestra
sobre Mtodos geis e BI onde tiveram acesso a uma viso geral da proposta do FDWS e
detalhamentos de como os mtodos geis podem ser aplicados a projetos de BI. Alm disso,
membros de ambos projetos participaram de uma palestra na qual foi feita a avaliao da experincia da adoo de mtodos geis em projetos de BI de acordo com a execuo dos trabalhos
no projeto Permanecer DW-UFBA.
Antes da execuo dos questionrios, participantes de ambos os projetos assistiram a uma
apresentao detalhada sobre o FDWS e como a metodologia proposta foi aplicada no projeto
da disciplina Tpicos em Banco de Dados.
5.3.1
EXECUO DA AVALIAO
O questionrio de avaliao foi aplicado a 12 estudantes da Universidade Federal da Bahia

e a professora da disciplina, em um perodo de aproximadamete 1 hora aps a apresentao
geral da metodologia FDWS em uma das aulas de Tpicos em Banco de Dados no semestre de
2010-2, para que o mesmo podesse ser avaliado com relao aos trabalhos realizados. Detalhes
dos perfis dos avaliadores encontram-se no Apndice D.
97
5.3.2
ANLISE DOS RESULTADOS
De um modo geral, a metodologia FDWS foi avaliada positivamente pelo conjunto de avaliadores que observaram nela um grande potencial, necessitando esta de algum refinamento adicional, mais estudos de caso e avaliaes de modo que o mesma possa ser considerada ou no
como um padro de desenvolvimento e suas vulnerabilidades serem avaliadas e contornadas.
Porm a divergncia de opinies em algumas respostas da seo, Questionrio, da avaliao,
em especial as que avaliavam as caractersticas do FDWS e sua aplicao nos projetos indicam
que a curva de aprendizagem da metodologia proposta realmente alta e a mesma no to
simples de ser entendida com apenas uma apresentao como foi feito. A falta de entendimento
da mesma dificulta sua avaliao e, alm disso, a falta de conhecimento e experincia em mtodos geis dificulta a compreenso das prticas adotadas na metodologia FDWS e como ela foi
composta.
O FDWS, foi considerado em algumas citaes como um processo complexo e burocrtico,
de difcil entendimento e compreenso. O maiores pontos das discusses esto relacionados
a simplicidade, intuitividade, praticidade e agilidade da metodologia. O grande nmero de
atividades foi mal visto por alguns avaliadores enquanto que uma boa parte elogiou a estrutura
e organizao do mesmo e suas razes em prticas consolidadas de outras metodologias. A
aplicao da metodologia FDWS na disciplina tambm foi questionada, pois a mesma no foi
aplicada em sua totalidade, contudo, os avaliadores destacaram a influncia de sua aplicao nos
resultados, mesmo que em uma escala menor do que se o mesma fosse completamente aplicada.
A flexibilidade e a adaptabilidade da metodologia foram pontos destacados pelos avaliadores assim como a possibilidade de um entrega rpida de produto ao cliente, fato que pode
despert-lo para o projeto de BI. A integrao da metodologia com as atividades da disciplina
e sua apresentao apenas no final dos trabalhos foi criticada por alguns avaliadores. Porm
mesmo com essas deficincias alguns avaliadores julgaram que sua aplicao ajudou na organizao e planejamento dos trabalhos, na definio do escopo do projeto o que aumentou o foco
das equipes potencializando os resultados conquistados.
A anlise literria sobre metodologias para projetos de BI baseados em Data Warehousing
indicam que estes processos so longos e formados por um substancial conjunto de atividades.
O FDWS foi moldado a partir de processos tradicionais como Kimball (KIMBALL, 2002) e (S,
2009) com a adaptao de prticas geis. Deste modo ele oferece uma base para a gerncia de
projetos de BI de modo gil, mesmo que seja composto por um vasto conjunto de subprocessos
e atividades. O FDWS deve ser utilizado como um guia para a gerncia e desenvolvimento de
projetos, no necessitando ser utilizado em sua totalidade. Cabe a quem o estiver utilizando,
98
verificar quais itens da metodologia atendem ao seu projeto e a sua organizao e adapt-lo. Por
isso, o FDWS flexvel e adaptvel, no sendo ento um processo rgido e fechado ao contrrio
do que foi avaliado em alguns casos.
O estudo de caso executado no suficiente para a avaliao da metodologia proposta,
devido ao seu cenrio de aplicao e a experincia da equipe que o utilizou. O fato de o FDWS
no ter sido especificado completamente antes do inicio das atividades da disciplina tornou-se
tambm um empecilho para sua avaliao. Contudo, como foi observado na avaliao, o FDWS
despertou interesses, o que valida seu potencial e indica a necessidade de uma avaliao mais
rigorosa para que as deficincias da metodologia possam ser ajustadas e uma verso 2.0 de
sua especificao possa ser feita. O escopo e tempo deste trabalho no possibilitaram que um
nmero maior de testes fosse feito, o que ser indicado como um dos trabalhos futuros dessa
proposta.
99
CONCLUSO
A aplicao de metodologias geis em BI uma rea de pesquisa em expanso devido a diversidade de metodologias e prticas geis existentes e suas possibilidades de aplicao. Alm
disso, projetos de integrao de dados so bastante diferentes dos projetos de desenvolvimento
de software. Espera-se que problemas como a alta taxa de insucesso dos projetos, falta de flexibilidade de ferramentas, lentido na entrega de resultados significativos aos gerentes envolvidos
e insatisfao dos clientes sejam minimizados com esta nova concepo do desenvolvimento de
solues de BI baseada nos prncipios descritos no manifesto gil. O alinhamento de prticas
geis com as etapas de gerncia e desenvolvimento de projetos de BI j consagradas pela literatura um grande desafio. A metodologia FDWS prope-se a realizar este trabalho, a partir da
composio das metodologias geis XP, SCRUM e FDD.
Comparando a metodologia proposta com os trabalhos relacionados, o FDWS traz como um
de seus diferenciais o uso da metodologia gil FDD para potencializar o processo de elicitao
de requisitos e a criao da lista de funcionalidades de modo que esta seja vinculada diretamente aos processos de negcio, aos objetivos organizacionais e as necessidades de usurios.
A concepo do modelo de dados no FDWS segue portando uma abordagem hbrida, ao das
metodologias detalhadas neste trabalho.
O FDWS atende a todas as etapas de gerncia e desenvolvimento de projetos de BI j
consagradas, a partir de uma metodologia que promove o desenvolvimento gil, com um bom
controle de escopo e interao com clientes e usurios finais. O processo do FDWS parece
complexo a primeira vista, fato que comprovado pelas anlises feitas na avaliao do trabalho.
Porm, o FDWS destina-se a ser um guia de boas prticas para a gerncia e desenvolvimento
de projetos geis de BI definindo assim um conjunto de subprocessos, atividades, artefatos e
ppeis, podendo ento ser adaptado a times, projetos e realidades especficas. O prprio estudo
de caso, demonstra como a metodologia especificada pode ser aplicada sem que todas as suas
atividades fossem realizadas, sem prejudicar no sucesso do trabalho realizado.
Alm disso o FDWS foi especificado de modo a atender aos requisitos de processo que
100
alguns mtodos tradicionais de gerenciamento e desenvolvimento de projetos de BI recomendam. Pode se observar que estes mtodos so complexos e formados por um grande conjunto
de atividades. O FDWS incorpora as prticas geis ao processo tradicional de BI, promovendo
uma novo fluxo de execuo das atividades.
A incorporao da metodologia FDD no FDWS tambm influi na questo da quantidade
de atividades existentes e na execuo do processo de planejamento, definio dos requisitos e
escopo do trabalho. A partir de um modelo abrangente constri-se a lista de funcionalidades,
a partir dessa lista o desenvolvimento das funcionalidades planejado, cada funcionalidade
detalhada e por fim implementada.
Apesar de sua composio atravs de prticas consagradas tando em metologias tradicionais
para BI como em metodologias geis, o FDWS necessita ser aplicado em um conjunto maior
de projetos para que possa ser validado e suas possveis vulnerabilidades avaliadas. No foi o
escopo deste trabalho, mas como pode ser observado nos estudos de caso as atividades de ETL
so crticas em termos de estimativas de custo e portanto necessitam de ateno especial, alm
disso no foi abordado na especificao da metodologia a realizao de testes automatizados no
produto desenvolvido.
6.1
CONTRIBUIES
As principais contribuies deste trabalho so listadas abaixo:

Anlise e avaliao de prticas convergentes em Mtodos geis para Projetos de Software, Metodologias geis para Projetos de BI e Metodologias Tradicionais para Projetos
de BI;
Especificao de uma metodologia para gerncia e desenvolvimento de projetos geis de
BI de acordo com as prticas e metodologias avaliadas;
Realizao dos estudos de casos a avaliao dos resultados alcanados e lies aprendidas
nos processos.
6.2
DIFICULDADES ENCONTRADAS
Mtodos geis no foram feitos para projetos de integrao de dados. Portanto sua aplicao direta em projetos de BI necessita de adaptaes. O maior desafio desse trabalho foi
101
justamente, alinhar os mtodos geis ao que j existe de metodologias e prticas para o desenvolvimento de solues de BI de modo que o processo resultante fosse considerado gil e
atendesse a todos os princpios existentes no manifesto gil.
O texto do trabalho mostra como essa composio foi feita, quais itens foram originados de
cada metodologia e como estes foram combinados. A metodologia FDWS em resumo, apenas
uma composio do que existe de melhor no ambiente gil e no ambiente de BI tradicional. Isso
no significa que seja melhor que outras metodologias citadas neste trabalho. Cada metodologia
adequada a uma situao, a um time, a um projeto especifco. O FDWS se destaca pelo
processo de elicitao de requisitos e ao curto espao de tempo no qual consegue oferecer ao
cliente itens entregveis com valor de negcio associado.
A especificao da metodologia, por ter sido um processo custoso, acabou prejudicando a
fase do estudo de caso, pois enquanto o estudo de caso foi realizado a metodologia ainda estava
sendo especificada. Este fato, apesar de interferir diretamente na avaliao da mesma, permite
observar que esta pode ser executada de forma resumida a partir da abstrao de algumas de
suas atividades. Alm disso, a sua especificao utilizando uma notao formal como a BPMN
demandou um custo de aprendizado das tcnicas de modelagem e da notao a ser utilizada.
6.3
TRABALHOS FUTUROS
Alguns itens so de grande importncia em projetos de BI, como a participao dos usurios
finais e clientes, elicitao de requisitos, modelagem dimensional e a metodologia FDWS lida
de modo satisfatrio com todos estes. Porm a fase de determinao dos custos de desenvolvimento de cada funcionalidade necessita ser melhor detalhada e explorada. A experincia dos
estudos de casos pode mostrar que o processo de ETL custoso e as vezes imprevisvel podendo
interferir negativamente no planejamento do projeto. Deste modo necessrio trabalhar em um
mtodo que permita definir o custo com alta previso das tarefas ligadas ao ETL do projeto. A
metodologia proposta carece ainda de processos relativos aos testes automatizados que possam
ser aplicados pelo time a cada produto desenvolvido.
Como j foi dito no estudo de caso, alguns dos itens especificados na metodologia no foram
utilizados e alm disso, as organizaes que participaram do estudo de caso j tinham certa
experincia com projetos de BI, o que facilitou na execuo dos projetos. O FDWS necessita
ser testado em um projeto desde seu incio de modo que todas as suas atividades e subprocessos
possam ser realizadas. de interesse tambm que a organizao participante do projeto, no
tenha nenhuma experincia em projetos de BI.
102
Na avaliao realizada, os itens simplicidade, adaptabilidade, intuitividade foram bastante

questionados e em alguns casos a metodologia foi classificada como burocrtica. Na execuo
deste trabalho o FDWS foi testado parcialmente em apenas um projeto. de interesse que seja
feito um estudo de caso maior, abrangendo organizaes e times com perfis completamente
diferentes de modo que esses aspectos e o comportamento da metodologia possam ser melhor
avaliados e um conjunto mnimo de atividades da metodologia possa ser determinado como
indispensvel a qualquer projeto. O maior objetivo que a partir da metodologia proposta neste
trabalho, possa ser derivado um framework processual de suporte a projetos de BI. Para tanto, a
metodologia precisa ser refinada e rigorosamente avaliada.
Alm disso a documentao da metodologia necessita ser revisada e melhorada e devem ser
especificados os modelos para cada artefato definida na mesma.
103
REFERNCIAS
ALMEIDA, G. R. mPentaho uma ferramenta de acesso s anlises OLAP da sute de Business
Intelligence Pentaho em dispositivos mveis Android. [S.l.], Dezembro 2010.
ANZANELLO, C. A. OLAP Conceitos e Utilizao. [S.l.], 2002.
ARAJO, E. M. T.; BATISTA, M. de L. S.; MAGALHES, T. M. de. OLAP: Caractersticas,
Arquitetura e Ferramentas. [S.l.], Outubro 2007.
BECK, K. et al. Manifesto for Agile Software Development. 2001. http://agilemanifesto.
org/. ltimo acesso em 26 de Setembro de 2010.
BPMI. Business Process Modeling Notation. 2010. http://www.omg.org/cgi-bin/doc?
dtc/10-06-04.pdf. ltimo acesso em 05 de Dezembro de 2010.
BROWN, T. Data Warehouse Implementation with the SAS System. 2000. http:
//www2.sas.com/proceedings/sugi22/DATAWARE/PAPER132.PDF. ltimo acesso em 29
de Setembro de 2010.
CARVALHO, G. T. de. Aplicao de Prticas geis na Construo de Data Warehouse
Evolutivo. Dissertao (Mestrado) Universidade de So Paulo, So Paulo, Junho 2009.
CAVALCANTI, E. de O. FIRESCRUM: Ferramenta de Apoio A Gesto gil de Projetos
Utilizando SCRUM. Dissertao (Mestrado) C.E.S.A.R - Centro de Estudos e Sistemas
Avanados do Recife, Recife, Julho 2009.
COHN, M. Agile Estimating and Planning. [S.l.]: Prentice Hall, 2005.
COSTA, A. F. da; ANCIES, F. C. Aspectos de Criao e Carga de Um Ambiente de Data
Warehouse. Rio de Janeiro, Maro 2001.
CRAIG, R. S.; VIVONA, J. A.; BERKOVITCH, D. Microsoft Data Warehousing: Building
Distributed Decision Support Systems. [S.l.]: John Wiley & Sons, 1999.
CRAMER, R. OLAP: Caractersticas, Arquitetura e Ferramentas. [S.l.], Agosto 2006.
DAYAL, U. et al. Data integration flows for business intelligence. In: Extending Database
Technology; Vol. 360 - Proceedings of the 12th International Conference on Extending
Database Technology: Advances in Database Technology. [S.l.]: ACM, 2009. p. 111. ISBN
978-1-60558-422-5.
DAYAL, U.; CHAUDHURI, S. An overview of data warehousing and olap technology. In:
ACM SIGMOD Record. [S.l.]: ACM, 1997. p. 6574. ISSN 0163-5808.
DIAS, M. V. B. Um Novo Enfoque para o Gerenciamento de Projetos de Desenvolvimento de
Software. Dissertao (Mestrado) Universidade de So Paulo, So Paulo, 2005.
104
FAYYAD, U.; PIATETSKY-SHAPIRO, G.; SMYTH, P. From data mining to knowledge

discovery in databases. 1996.
FAYYAD, U. M. Tutorial Report. Summer School of Data Mining. [S.l.], Junho 2003.
FERNNDEZ, J.; MAYOL, E.; PASTOR, J. A. Agile business intelligence governance: Su
justificacin y presentacin. 2008.
GRAZIANO, K. Agile Methods and Data Warehousing. 2010. Disponvel em http:
//www.rmoug.org/TD2010Pres/graziano_01.pdf. Acessado em 25/03/2011.
GUIMARES, C. P. Integrando o Design de Interfaces centrado na Experincia do Usurio
ao processo de Desenvolvimento de Software com Extreme Programming. [S.l.], 2009.
HEPTAGON. FDD - Feature Driven Development. 2010. http://www.heptagon.com.br/
fdd. ltimo acesso em 28 de Setembro de 2010.
HUGHES, R. Agile Data Warehousing: Delivering World-Class Business Intelligence
Systems Using Scrum and XP. [S.l.]: iUniverse.com, Incorporated, 2007. ISBN 0595471676,
9780595471676.
INMON, W. H. Como construir o Data Warehouse. [S.l.]: Campus, 1997. Traduo Ana Maria
Netto Guz. 2.ed. Rio de Janeiro.
INMON, W. H.; HACKATHORN, R. D. Como usar o Data Warehouse. [S.l.]: Infobook, 1997.
Traduo Olavo Faria Guz. 2.ed. Rio de Janeiro.
INTEL. Business Intelligence. [S.l.], 2010.
JUNIOR, I. P. de A. Adaptao do mtodo gil Feature Driven Development (FDD) para
auxiliar no processo de identificao de servios de negcio em Arquitetura Orientada a
Servios (SOA). Dissertao (Mestrado) Instituto de Pesquisas Tecnolgicas do Estado de
So Paulo, So Paulo, Junho 2008.
KIMBALL, R. Data Warehouse toolkit: o guia completo para modelagem multidimensional.
[S.l.]: Campus, 2002.
LI, X. Building an agile data warehouse: A proative approach to managing chances. In:
Proceedings of the Fouth IASTED Internacional Conference - Communications, Internet, and
Information Technology. St.Thomas, US Virgin Islands: Acta Press, 2006.
MARAL, A. S. C. SCRUMMI: Um processo de gesto gil baseado no SCRUM e aderente
ao CMMI. Dissertao (Mestrado) Universidade de Fortaleza, Fortaleza, Julho 2009.
MOSS, L. Extreme Scoping - An Agile Project Management Approach. 2007. http://www.eiminstitute.org/library/
eimi-archives/volume-1-issue-5-july-2007-edition/
extreme-scoping-an-agile-project-management-approach. ltimo acesso em
02 de Outubro de 2010.
MOSS, L. Extreme scoping: What iterative development really means. 2008. http:
//www.technologytransfer.eu/article/64/2008/5/Extreme_scoping_What_
iterative_development_really_means.html. ltimo acesso em 02 de Outubro de 2010.
105
MOSS, L. EXTREME SCOPING: An Agile Approach to Data Warehousing and Business

Intelligence. 2010. http://www.datamanager.it/news/business-intelligence/
extreme-scoping-agile-approach-data-warehousing-and-business-intelligence.
ltimo acesso em 02 de Outubro de 2010.
MOSS, L. Extreme Scoping TM: An Agile Approach to Data Warehousing and Business
Intelligence. 2010. http://www.technologytransfer.eu/article/85/2010/6/
Extreme_Scoping\%E2\%84\%A2_An_Agile_Approach_to_Data_Warehousing_and_
Business_Intelligence.html. ltimo acesso em 02 de Outubro de 2010.
NCR-TERADATA. NCR Announces Details for Completion of Teradata Spin Off. 2007.
http://www.ncr.com/about_ncr/media_information/news_releases/2007/august/
082807a.jsp. ltimo acesso em 29 de Setembro de 2010.
NBREGA, J. Forrester defende novo modo de desenvolver BI. [S.l.]:
Computerworld, 2010. http://www.computerworld.com.pt/2010/04/29/
forrester-defende-novo-modo-de-desenvolver-bi/. ltimo acesso em 25 de
Setembro de 2010.
OLIVEIRA, G. L. de. Matriz de Necessidades. 2010. http://bicomvatapa.blogspot.com/.
ltimo acesso em 05 de Dezembro de 2010.
PALMER, S. R.; FELSING, J. M. A Practical Guide to Feature-Driven Development. [S.l.]:
Prentice Hall Inc, 2002. ISBN 0-13-067615-2.
PENTAHO-CORPORATION. Agile BI. 2010. http://www.pentaho.com/agile_bi/.
ltimo acesso em 02 de Outubro de 2010.
PENTAHO-CORPORATION. Introduction to Agile BI. 2010. http://wiki.pentaho.com/
display/AGILEBI/Documentation. ltimo acesso em 02 de Outubro de 2010.
PETRINI, M.; FREITAS, M. T.; POZZEBON, M. Inteligncia de negcios ou inteligncia
competitiva? noivo neurtico, noiva nervosa. Setembro 2006.
PORTELA, C. dos S. Uma Proposta De Gerenciamento gil Dos Projetos De Desenvolvimento
De Software Do CTIC/UFPA. [S.l.], Dezembro 2009.
PRESTON, R. Down To Business: Business Intelligence Still In Its Infancy. [S.l.]:
InformationWeek, 2003. http://www.informationweek.com/news/business_
intelligence/showArticle.jhtml?articleID=196801521. ltimo acesso em 25 de
Setembro de 2010.
PRISM-SOLUTIONS. Iterations TM The Data Warehouse Methodology. 2002. http:
//www.gantthead.com/content/attachments/patrick2001_2706021154.PDF. ltimo
acesso em 29 de Setembro de 2010.
S, J. V. de Oliveira e. Metodologia de Sistema de Datawarehouse. Tese (Doutorado)
Universidade do Minho, Portugal, 2009.
SCHWABER, K. Agile Project Management with Scrum. [S.l.]: Microsoft Press, 2004.
SCWABER, K.; BEEDLE, M. Agile Project Management with Scrum. [S.l.]: Prentice Hall,
2002.
106
TELES, V. M. Um Estudo de Caso da Adoo das Prticas e Valores do Extreme Programming.

Dissertao (Mestrado) Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2005.
TESSARI, R. Gesto de Processos de Negcio: Um Estudo de Caso da BPMN em Uma
Empresa do Setor Moveleiro. Dissertao (Mestrado) Universidade de Caxias do Sul Programa de Ps Graduao em Administrao, Caxias do Sul, Agosto 2008.
UDO, N.; KOPPENSTEINER, S. Will agile change the way we manage software projects?
agile from a pmbok guide perspective. Projectway, 2003.
VERSION-ONE. Feature Estimation. 2010. http://www.versionone.com/Agile101/
Feature_Estimation.asp. ltimo acesso em 05 de Dezembro de 2010.
WAILGUM, T. BI representa desafio para empresas, aponta Forrester.
[S.l.]: CIO/EUA, 2010. http://cio.uol.com.br/gestao/2010/04/26/
bi-representa-desafio-para-empresas-aponta-forrester/. ltimo acesso em
25 de Setembro de 2010.
WILLIAMS, S.; WILLIAMS, N. The Profit Impact of Business Intelligence. [S.l.]: Morgan
Kaufmann Publishers, 2007. ISBN 978-0-12-372499-1.
107
APNDICE A -- MODELO GERAL DE

PROCESSO PARA DATA
WAREHOUSING
As sees a seguir detalham as etapas que compem o processo especificado por (S, 2009).
A.1
PERCEPO
Nesta etapa ser definido o esquema e o contedo do DW. Esse processo deve seguir uma
abordagem hbrida a partir das quatro abordagens de orientao j citadas: orientao a dados, objetivos, utilizadores e processos. A combinao dessas orientaes permite cobrir as
deficincias existentes em cada uma delas. Alm destas orientaes ainda temos a orientao
tecnolgica que permite identificar a atual capacidade tecnolgica da organizao, avaliando os
gargalos existentes que devero ser resolvidos, caso contrrio criaro entraves ao funcionamento
do sistema de DW.
A etapa de Percepo composta pelo seguinte conjunto de atividades:
Percepo do Negcio: Permite identificar o/ou os problemas que afetam o negcio alm
dos futuros utilizados do sistema. O analista de negcio junto aos patrocinadores devero
justificar aos gestores da organizao a importncia e a necessidade do projeto de DW;
Definio da Arquitetura Tecnolgica: Possibilita a seleo do tipo de arquitetura para o
sistema de DW. Definies como o tipo de DW (repositrio nico ou DMs deparmentais),
repositrio de metadados, arquitetura do processo de ETL e aplicaes para explorao e
anlise dos dados armazenados no DW fazem parte do escopo desta etapa;
Ainda nesta atividade devem ser definidos critrios para selecionar produtos, ou seja,
hardware, software e redes de comunicaes necessrios ao projeto;
108
Definio de Requisitos/Modelagem: Para a obteno dos requisitos, como j citado,

recomenda-se a abordagem hbrida por questes de completude das abordagens. Assim
os objetivos organizacionais, os processos organizacionais, as necessidades dos usurios
e os modelos de dados transacionais estaro contemplados alm de termos a percepo
da capacidade tecnolgica existente. A partir dos requisitos coletados pode-se realizar
a modelagem do esquema do DW e descrever o processo de ETL que ser aplicado nas
fontes de dados;
Modelagem das Aplicaes de Explorao da Informao: Esta atividade aborda a
definio do tipo de aplicaes que sero construdas para que os utilizadores possam
acessar as informaes do sistema de DW. Por exemplo, pode se definir e conceber os
templates de relatrios a serem disponibilizados aos utilizadores. Recomenda-se que essas aplicaes e ferramentas tenham interfaces amigveis, sejam fceis de utilizar, rpidas
e disponibilizem informaes adequadas e corretas para que o projeto do DW seja encarado como sucesso pelos seus utilizadores.
Esta etapa complementada com atividades existentes na etapa de Planejamento, Gesto e
Controle do Projeto:
Avaliao: Identificar, analisar e avaliar o nivel de preparao da organizao para ter
um sistema de DW, tendo em conta o tamanho, setor da indstria, mercado, concorrncia,
motivaes, nvel de maturidade de BI e cultura organizacional;
Arranque: Identificar e ponderar quais os riscos associados ao projeto alm de definir o
patrocinador;
Recursos: Reunir a equipe de trabalho, garantir recursos financeiros, identificar necessidades de instalaes, equipamentos e ferramentas;
Definir Campo de Ao: De acordo com as atividades de Percepo do Negcio dever
ser produzido um documento preliminar com a definio do mbito do projeto que deve
conter critrios de sucesso bem definidos, benefcios, custos e respectivo retorno;
Planejamento, Gesto e Controle do Projeto: Construir um plano de projeto com a
gesto e pontos de controle bem definidos.
A Figura 26 oferece uma viso geral das atividades da etapa de Percepo:
Figura 26: Atividades da etapa de Percepo. Adaptado de (S, 2009).
109
110
Estas atividades identificadas e descritas so relevantes para a primeira iterao. Nas iteraes seguintes dever haver alguns ajustes, pois existem atividades que j no sero necessrias
ou obrigatrias de serem realizadas ou podem ser parcialmente realizadas.
111
A.2
CONCEPO
A etapa de Concepo consiste na construo dos itens definidos na etapa de Perceo.

Deste modo as atividades compreendidas nesta etapa so detalhadas a seguir:
Seleo dos Produtos e Instalao: Nesta atividade realizada a seleo dos fornecedores e produtos, a aquisio dos produtos e ferramentas e sua instalao de acordo com
o levantamento de caractersticas dos produtos e ferramentas necessrias para a implementao do sistema de DW, realizado na etapa anterior;
Construo do Sistema de Data Warehouse: Consiste na construo especfica do sistema de DW. realizada a modelagem fsica da base e sua implementao no sistema de
banco de dados escolhido. O projeto fsico de ETL criado e executado sendo previstas
cargas perodicas de dados no DW. Por fim, devem ser efetuados testes e integrao do
resultado desta atividade na arquitetura tecnolgica do sistema de DW;
Desenvolvimento de aplicaes de explorao da Informao: Aps modelagem das
aplicaes de explorao de informao esta atividade compreende o seu desenvolvimento, testes e integrao na arquitetura tecnolgica do sistema de DW.
A Figura 27 oferece uma viso geral das atividades da etapa de Concepo:
Figura 27: Atividades da etapa de Concepo. Adaptado de (S, 2009).
A.3
ENTREGA
A etapa de Entrega abrange a instalao e preparao do sistema de DW para comear a ser

utilizado, compreendendo as seguintes etapas:
112
Instalao: Espera-se que todos os artefatos (produtos e ferramentas) estejam construdos, testados, integrados na arquitetura do sistema de DW e os repositrios de metadados,
DW e DMs estejam populados para que o sistema de DW possa ser utilizado. Alm disso,
deve ser compilada e completada a documentao tanto tcnica como a de apoio aos utilizadores;
Formao dos Utilizadores: Isto inclui a formao nas ferramentas de explorao da
informao e nos tipos de informao que os utilizadores podero ter acesso;
Suporte: Deve ser oferecida uma plataforma de suporte aos usurios, seja atravs de
call center, portal eletrnico, fruns de modo que os usurios tenham acesso facilitado
documentao do sistema de DW e at mesmo possam tirar dvidas e discutir assuntos
com outros utilizadores.
A Figura 28 oferece uma viso geral das atividades da etapa de Entrega e de Planejamento,
Gesto e Controle do Projeto. A etapa de Planejamento, Gesto e Controle do Projeto composta pela atividade de Gesto e Controle, a qual relevante para gerir e controlar a Etapa de
Entrega nas suas atividades de Instalao, Formao e Suporte.
Figura 28: Atividades da etapa de Entrega. Adaptado de (S, 2009).
A.4
OPERAO
Esta etapa deve garantir que o sistema de DW se mantenha em constante funcionamento,

compreendendo ento os seguintes objetivos:
Manter o DW e DMs em termos dos nveis de detalhe da agragao da informao e
garantir o bom desempenho do sistema;
113
Garantir os servioes de ETL e sua gesto de modo que o DW esteja sempre atualizado;
Manter as ferramentas de explorao analticas e seus acessos ao DW ou DMs.
A Figura 29 oferece uma viso geral das atividades da etapa de Operao:
Figura 29: Atividades da etapa de Operao. Adaptado de (S, 2009).
A.5
AJUSTES/MELHORIAS
Esta etapa engloba o monitoramento do sistema de DW de modo a:

Modificar, ajustar e melhorar seus componentes tecnolgicos;
Gerir os processos e operaes (incluindo otimizaes e a periodicidade do processo de
ETL);
Alterar os esquemas do contedo do DW e DMs para responder s alteraes que ocorrem
nos registros dos sistemas transacionais.
Esta etapa compreende a atividade de Evoluo, pois apenas quando os usurios comeam
a utilizar o sistema que ganham percepo das capacidades reais do sistema de DW e por
conseguinte novas demandas anliticas acabam surgindo.
A Figura 30 oferece uma viso geral das atividades da etapa de Ajustes/Melhorias:
Figura 30: Atividades da etapa de Ajustes/Melhorias. Adaptado de (S, 2009).
114
APNDICE B -- ANLISE DOS ESTUDO DE

CASO
B.1
APLICAO DA METODOLOGIA FDWS NO PROJETO PERMANECER DW-UFBA
B.1.1
B.1.2
B.1.3
ITERAO
B.1.4
PS-ITERAO
115
Tabela 2: Descrio das Etapas do Planejamento do Projeto Executadas no Projeto Permanecer

DW-UFBA
Etapa
Aplicao no Projeto
Anlise Organizacional
Avaliar Cultura Organizacional
No
Avaliar Riscos Associados
No
Avaliar Nvel de Preparao da Organizao para
No
Solues de BI
Avaliar Motivao
No
Definir Patrocinadores
No
Definir Gerncia de Aplicao
Sim
Definir Gerncia de Negcio
Sim
Elaborar Documento de Viso Organizacional
No
Criar/Priorizar FBS do Projeto
Entrevistar a Gerncia de Aplicao e Gerncia de Negcio
Sim
Mapear Estrutura Organizacional Hierarquicamente (reas de Negcio)
No
Criar FBS do Projeto
No
Priorizar FBS do Projeto
Sim
Projeto de Arquitetura Tcnica
Investigar Infra-Estrutura Tecnolgica
No
Identificar Necessidades de Instalaes e Equipamentos
No
Anlise de Ferramentas
Definir Conjunto de Avaliao
No
Avaliao
No
Seleo
No
Prototipagem
No
Definir Documento de Viso Arquitetural
No
Plano de Projeto
Critrios de Sucesso
No
Benefcios
No
Custos e Respectivo Retorno
No
Objetivos
Sim
Membros do Projeto
Sim
Definir Sequncia de Releases por reas de Negcio
Sim
Montagem dos Times
Definir Tamanho
Sim
Definir Treinadores
Sim
Alocar Membros dos Times
Sim
116
Tabela 3: Descrio das Etapas do Planejamento da Release Executadas no Projeto Permanecer

DW-UFBA
Etapa
Aplicao no Projeto
Levantar Requisitos da Release
Entrevistar a Gerncia de Aplicao e a Gerncia de Negcios
Sim
Mapear Macro-Processos, Processos, Atividades e Tarefas
No
Incrementar FBS do Projeto
No
Popular Matriz de Necessidades
No
Desenvolver Modelo Abrangente da Release
Formar Grupos de Modelagem
No
Estudo Dirigido do Domnio (Estudar Documentao)
No
Desenvolver Modelo de Pequenos Grupos
No
Desenvolver Modelo dos Times
No
Refinar Modelo Abrangente
No
Validar Modelo Abrangente
No
Criar/Priorizar Lista de Funcionalidades da Release
Construir Lista de Funcionalidades
Sim
Validar Lista de Funcionalidades
Sim
Priorizar Lista de Funcionalidades
Sim
Estimar Custo de Desenvolvimento
No
Criar Plano de Iteraes
Determinar Sequncia de Desenvolvimento
Sim
Alocar Funcionalidades aos Times
Sim
Revisar Arquitetura Tecnolgica/Ferramentas
No
117
Tabela 4: Descrio das Etapas da Iterao Executadas no Projeto Permanecer DW-UFBA

Etapa
Aplicao no Projeto
Configurao do Ambiente de Testes, Produo e Homologao
No
Criar Verso de Teste, Produo e Homologao
No
No
Detalhar Funcionalidades
No
Refatorar rea de Staging (Incluir Itens do Novo Modelo)
Sim
Refatorar Modelo Dimensional (Incluir Itens do Novo Modelo)
Sim
No
Projeto Fsico
rea de Staging
Sim
DW
Sim
Implementar e Integrar Mudanas no Banco
Sim
Projeto de Metadados
Definio do Metamodelo
Sim
Implementao e Integrao do Metamodelo
Sim
Teste e Validao
Sim
Projeto de ETL
Mapeamento do ETL/Regras de ETL - Dicionrio de Transformaes
Sim
Implementao e Integrao das Rotinas de ETL
Sim
Teste e Validao dos Dados
Sim
Projeto da Aplicao de BI
Modelagem da Aplicao de Explorao da Informao
Sim
Implementao e Integrao
Sim
Teste e Validao de Interfaces
Sim
Validao e Verificao (Testes Integrados)
Teste de Qualidade
Sim
Testes das Operaes do Processo
Sim
Teste de Desempenho
No
Testes de Implantao
Sim
Teste de Acessibilidade de Usurios
No
Teste de Aceitao
No
Implantao no Ambiente de Homologao
No
118
Tabela 5: Descrio das Etapas da Ps-Iterao Executadas no Projeto Permanecer DW-UFBA

Etapa
Aplicao no Projeto
Retrospectiva da Iterao
Sim
Implantao no Ambiente de Produo
No
Formao dos Utilizadores
No
Avaliao da Iterao
Sim
B.2
APLICAO DA METODOLOGIA FDWS NA DISCIPLINA TPICOS EM BANCO DE DADOS
B.2.1
B.2.2
B.2.3
ITERAO
B.2.4
PS-ITERAO
119
Tabela 6: Descrio das Etapas do Planejamento do Projeto Executadas na Disciplina Tpicos

em Banco de Dados
Etapa
Aplicao no Projeto
Anlise Organizacional
Avaliar Cultura Organizacional
Sim
Avaliar Riscos Associados
No
Avaliar Nvel de Preparao da Organizao para
No
Solues de BI
Avaliar Motivao
Sim
Definir Patrocinadores
No
Definir Gerncia de Aplicao
Sim
Definir Gerncia de Negcio
Sim
Elaborar Documento de Viso Organizacional
No
Criar/Priorizar FBS do Projeto
Entrevistar a Gerncia de Aplicao e Gerncia de Negcio
Sim
Mapear Estrutura Organizacional Hierarquicamente (reas de Negcio)
Sim
Criar FBS do Projeto
No
Priorizar FBS do Projeto
Sim
Projeto de Arquitetura Tcnica
Investigar Infra-Estrutura Tecnolgica
No
Identificar Necessidades de Instalaes e Equipamentos
No
Anlise de Ferramentas
Definir Conjunto de Avaliao
Sim
Avaliao
Sim
Seleo
Sim
Prototipagem
No
Definir Documento de Viso Arquitetural
No
Plano de Projeto
Critrios de Sucesso
No
Benefcios
No
Custos e Respectivo Retorno
No
Objetivos
Sim
Membros do Projeto
Sim
Definir Sequncia de Releases por reas de Negcio
Sim
Montagem dos Times
Definir Tamanho
Sim
Definir Treinadores
Sim
Alocar Membros dos Times
Sim
120
Tabela 7: Descrio das Etapas do Planejamento da Release Executadas na Disciplina Tpicos

em Banco de Dados
Etapa
Aplicao no Projeto
Levantar Requisitos da Release
Entrevistar a Gerncia de Aplicao e a Gerncia de Negcios
Sim
Mapear Macro-Processos, Processos, Atividades e Tarefas
No
Incrementar FBS do Projeto
No
Popular Matriz de Necessidades
No
Desenvolver Modelo Abrangente da Release
Formar Grupos de Modelagem
No
Sim
Desenvolver Modelo de Pequenos Grupos
No
Desenvolver Modelo dos Times
Sim
No
Validar Modelo Abrangente
No
Criar/Priorizar Lista de Funcionalidades da Release
Construir Lista de Funcionalidades
Sim
Validar Lista de Funcionalidades
Sim
Priorizar Lista de Funcionalidades
No
Estimar Custo de Desenvolvimento
No
Criar Plano de Iteraes
Determinar Sequncia de Desenvolvimento
Sim
Alocar Funcionalidades aos Times
Sim
Revisar Arquitetura Tecnolgica/Ferramentas
No
121
Tabela 8: Descrio das Etapas da Iterao Executadas na Disciplina Tpicos em Banco de

Dados
Etapa
Aplicao no Projeto
Configurao do Ambiente de Testes, Produo e Homologao
No
No
No
Detalhar Funcionalidades
Sim
Refatorar rea de Staging (Incluir Itens do Novo Modelo)
Sim
Refatorar Modelo Dimensional (Incluir Itens do Novo Modelo)
Sim
No
Projeto Fsico
rea de Staging
Sim
DW
Sim
Implementar e Integrar Mudanas no Banco
Sim
Projeto de Metadados
Definio do Metamodelo
Sim
Implementao e Integrao do Metamodelo
Sim
Teste e Validao
Sim
Projeto de ETL
Mapeamento do ETL/Regras de ETL - Dicionrio de Transformaes
Sim
Implementao e Integrao das Rotinas de ETL
Sim
Teste e Validao dos Dados
Sim
Projeto da Aplicao de BI
Modelagem da Aplicao de Explorao da Informao
Sim
Implementao e Integrao
Sim
Teste e Validao de Interfaces
Sim
Validao e Verificao (Testes Integrados)
Teste de Qualidade
No
Testes das Operaes do Processo
No
Teste de Desempenho
No
Testes de Implantao
No
Teste de Acessibilidade de Usurios
No
Teste de Aceitao
No
Implantao no Ambiente de Homologao
No
122
Tabela 9: Descrio das Etapas da Ps-Iterao Executadas na Disciplina Tpicos em Banco de

Dados
Etapa
Aplicao no Projeto
Retrospectiva da Iterao
Sim
Implantao no Ambiente de Produo
No
Formao dos Utilizadores
No
Avaliao da Iterao
No
123
APNDICE C -- QUESTIONRIO DE
AVALIAO DA
METODOLOGIA FDWS
C.1
INFORMAES PESSOAIS
1.Sexo:
(a)Masculino( )
(b)Feminino ( )
2.Idade:
3.Profisso:
4.Escolaridade:
(a)Superior Cursando ( )
(b)Superior Completo ( )
(c)Ps-Graduao ( )
(d)Mestrado ( )
(e)Doutorado ( )
(f)Outro ( )
5.Tempo de Experincia em BI e Data Warehousing:
(a)Menor que 6 meses ( )
(b)Menor que 2 anos ( )
(c)Menor que 5 anos ( )
(d)5 anos ou mais ( )
124
C.2
QUESTIONRIO
1.Qual seu nvel de conhecimento sobre Prticas geis ?:

(a)Avanado ( )
(b)Intermedirio ( )
(c)Iniciante ( )
(d)Nenhum ( )
2.Qual seu nvel de conhecimento sobre a Metodologia SCRUM ?:
(a)Avanado ( )
(b)Intermedirio ( )
(c)Iniciante ( )
(d)Nenhum ( )
3.Qual seu nvel de conhecimento sobre a Metodologia XP ?:
(a)Avanado ( )
(b)Intermedirio ( )
(c)Iniciante ( )
(d)Nenhum ( )
4.Qual seu nvel de conhecimento sobre a Metodologia FDD ?:
(a)Avanado ( )
(b)Intermedirio ( )
(c)Iniciante ( )
(d)Nenhum ( )
5.Como voc avalia a aplicao da metodologia FDWS na disciplina Tpicos em Banco de
Dados ? (Ou no Projeto Permanecer)
6.Considerando seu conhecimento antes e depois da apresentao sobre o FDWS, como
voc avalia a metodologia adotada na disciplina ? (Ou no Projeto Permanecer)
125
7.Voc considera que a aplicao da metodologia FDWS foi benfica na execucao das
atividades da disciplina ? Voc considera que a aplicao da metodologia teve alguma
interferncia nos resultados alcanados ? Esta interferncia foi positiva ou negativa ? (Ou
no Projeto Permanecer)
8.Como voc avalia a aplicao de mtodos/prticas geis em BI, com base na experincia
vivenciada na disciplina ? (Ou no Projeto Permanecer)
9.Considerando a apresentao realizada e a aplicao do FDWS na disciplina. Como voc
o avalia com relao a: Agilidade ? Praticidade ? Flexibilidade ? Adaptabilidade ?
Intuitividade ? Simplicidade ? (Ou no Projeto Permanecer)
10.Caso, voc continue a trabalhar com BI, voc gostaria de continuar trabalhando com o
FDWS ? Quais os pontos fortes e fracos avaliados por voc com relao ao mesmo ?
11.Comentrios Gerais e Sugestes ?
126
APNDICE D -- PERFIL DOS AVALIADORES
Figura 31: Avaliadores por sexo
Figura 32: Avaliadores por escolaridade
127
Figura 33: Avaliadores por tempo de experincia em BI e DW
Figura 34: Avaliadores por nvel de conhecimento em Prticas geis
Figura 35: Avaliadores por nvel de conhecimento na Metodologia SCRUM
128
Figura 36: Avaliadores por nvel de conhecimento na Metodologia XP
Figura 37: Avaliadores por nvel de conhecimento na Metodologia FDD
129
APNDICE E -- ESPECIFICAO E
MODELAGEM DA
METODOLOGIA FDWS
E.1
MAPEAMENTO DOS SUBPROCESSOS E ATIVIDADES

DA METODOLOGIA FDWS DE ACORDO COM AS
METODOLOGIAS DE ORIGEM
A Figura 38 detalha cada subprocesso do Planejamento do Projeto de acordo com as metodogias

utilizadas na composio do FDWS:
A Figura 39 detalha cada subprocesso do Planejamento da Release de acordo com as
metodogias utilizadas na composio do FDWS:
A Figura 40 detalha cada subprocesso da Iterao de acordo com as metodogias utilizadas
na composio do FDWS:
A Figura 40 detalha cada subprocesso da Ps-Iterao de acordo com as metodogias utilizadas na composio do FDWS:
130
Figura 38: FDWS - Planejamento do Projeto - Mapeamento das Etapas e Metodologias de

Origem
131
Figura 39: FDWS - Planejamento da Release - Mapeamento das Etapas e Metodologias de

Origem
132
Figura 40: FDWS - Iterao - Mapeamento das Etapas e Metodologias de Origem
Figura 41: FDWS - Ps-Iterao - Mapeamento das Etapas e Metodologias de Origem
133
E.2
MODELAGEM DA METODOLOGIA FDWS
O padro escolhido para o modelagem da Metodologia FDWS foi o Business Process Modeling Notation (BPMN) devido a sua facilidade de uso e entendimento. A simbologia da BPMN
permite criar diagramas de processos de negcio (BPD) , do ingls Business Process Diagrams ,
para finalidades de documentao e comunicao. Esses modelos seguem uma notao padro,
desenvolvida pelo Instituto de Gesto de Processos de Negcio - The Business Process Management Initiative (BPMI) e foi lanada publicamente em maio de 2004 (TESSARI, 2008). A
descrio completa de sua notao pode ser encontrada em (BPMI, 2010). Na subseo E.2.1
feita uma descrio suscinta da notao. Os modelos para cada subprocesso do FDWS so
ilustrados na E.2.2.
E.2.1
DESCRIO DA NOTAO BPMN
A descrio da notao BPMN contida nesta seo foi retirada da Dissertao de Mestrado
do Rogrio Tessari (TESSARI, 2008).
E.2.1.1
ELEMENTOS BSICOS DA NOTAO
As quatro categorias bsicas de elementos so os objetos de fluxo, objetos de conexo, raias

e artefatos, que so descritos em detalhe a seguir:
1.Objetos de Fluxo: A BPMN descreve um conjunto de trs objetos de fluxo: eventos,
atividades e gateways (Figura 42). Os eventos so representados por crculos e demonstram acontecimentos no curso de um processo e afetam o fluxo de um processo e eventualmente podem ter uma causa ou impacto. As atividades so representadas por retngulos
com cantos arredondados e so usadas para demonstrar algum tipo de trabalho realizado
na empresa. Os gateways so representados por um losango e so usados para controlar a
divergncia e a convergncia de um fluxo de controle, determinando decises tradicionais
e tambm caminhos paralelos ou junes de caminhos.
2.Objetos de Conexo: Os objetos de conexo, ou objetos de fluxo, so conectados ao diagrama para criar o esqueleto estrutural bsico de um processo de negcio. Existem trs
tipos bsicos de objetos para prover esta funo (Figura 43). O fluxo de seqncia, que
representado por uma linha slida e uma seta slida, usado para demonstrar a ordem que
as atividades sero executadas em um processo. O fluxo de mensagens representado por
uma linha pontilhada, com uma seta aberta na sua extremidade e usado para demonstrar
134
Figura 42: Objetos de Fluxo Bsicos da BPMN (TESSARI, 2008).

o fluxo de mensagens entre dois participantes de processos separados de forma organizacional, como, setores diferentes, unidades de negcio distintas, ou at mesmo uma outras
empresas. A associao representada por uma linha pontilhada com uma seta aberta na
extremidade e usada para associar dados, textos e outros artefatos com objetos do fluxo.
Figura 43: Objetos de Conexo da BPMN (TESSARI, 2008).

3.Artefatos: A especificao da BPMN define trs tipos de artefatos bsicos: objetos de
dados, anotaes e grupos (Figura 44). Os objetos de dados so mecanismos que demonstram como os dados so requeridos ou produzidos por atividades. Eles so conectados
em atividades atravs de associaes. Os grupos so representados por um retngulo pontilhado e pode ser usado com o propsito de destaque, documentao ou anlise, porm
no afeta o fluxo de seqncia. As anotaes so mecanismos que provm ao modelador
a capacidade de descrever informaes textuais adicionais ao leitor do diagrama.
4.Raias: A BPMN, assim como muitas outras notaes para representao de processos,
utiliza o conceito de raias de natao (swimlanes) como um mecanismo para organizar
atividades em diferentes categorias visuais, de forma a ilustrar diferentes capacidades
135
Figura 44: Artefatos Bsicos da BPMN (TESSARI, 2008).

funcionais ou responsabilidades. Estas categorias so suportadas pelo BPMN atravs de
dois tipos de construtos, pools e lanes (Figura 45).
Figura 45: Elementos de Raia da BPMN (TESSARI, 2008).
E.2.1.2
REFINAMENTO DOS ELEMENTOS
Para cada categoria de elementos bsicos existem variaes da notao para representar as
diferentes situaes de processos de negcios.
1.Atividades: As atividades podem ser atmicas ou no-atmicas (compostas). Atividades
podem ainda ser executada uma vez ou repetidamente em iteraes definidas. Os tipos de
atividades que podem compor um modelo de processos so: tarefas e sub-processos. A
tarefa uma atividade atmica enquanto que os sub-processos so atividades compostas
que podem, hierarquicamente, levar a um nvel de detalhe mais fino do processo, atravs
de um conjunto de sub-atividades. A Figura 46 demonstra um sub-processo fictcio em
seus dois nveis de granularidade.
136
Figura 46: Representao de Uma Atividade em Diferentes Nveis de Granularidade (TESSARI,

2008).
2.Eventos: Os eventos podem ter trs estados diferentes: incio, intermedirio ou fim,
com representaes especficas para cada um deles. Eventos ainda podem ter diferentes
tipos, com significados relacionados, que servem para representar diferentes situaes.
Os eventos de incio so representados por crculos com bordas simples e so usados para
representar o incio de um processo. A Figura 47 demonstra os tipos possveis de eventos
de incio de um BPD.
Figura 47: Tipos de Eventos BPMN de Incio para um BPD (TESSARI, 2008).
Eventos intermedirios ocorrem aps o processo ter iniciado e antes do seu trmino. Este
tipo de evento representado por um crculo com borda dupla. Diferentes tipos indicam
especficas circunstncias de disparo destes eventos (Figura 48).
Eventos intermedirios colocados ao longo do processo representam coisas que acontecem durante o fluxo normal de operaes do processo. Podem representar a resposta de
um evento, como, por exemplo o recebimento ou envio de uma mensagem ou a criao
137
Figura 48: Tipos de Eventos BPMN Intermedirios para um BPD (TESSARI, 2008).
de um evento. Eventos anexados a borda de uma atividade (Figura 49) indica que a atividade deve ser interrompida quanto tal evento for disparado. So usualmente usadas para
tratamento de excees ou compensaes.
Figura 49: Exemplo de Evento Intermedirio Anexado a uma Atividade (TESSARI, 2008).
O exemplo apresentado na Figura 49 demonstra uma situao onde o fluxo normal seria
o recebimento da confirmao, caso esta atividade no acontea em at 2 dias o fluxo
desviado para a atividade "Enviar nota de cancelamento". Eventos de trmino indicam
onde o processo ir terminar. Diferentes resultados indicam especfica circunstncias que
encerraram o processo (Figura 50).
3.Gateways
Os gateways so sempre representados por losangos, porm os marcadores internos da
138
Figura 50: Tipos de Evento BPMN para o Trmino de um Processo (TESSARI, 2008).
figura indicam diferentes tipos de comportamento (Figura 51).
Figura 51: Tipos de Elementos do Tipo Gateway na BPMN (TESSARI, 2008).
E.2.2
DIAGRAMAS DE PROCESSO DA METODOLOGIA FDWS
1.Planejamento do Projeto
Anlise Organizacional: Figura 52;
Criar/Priorizar FBS do Projeto: Figura 53;
Projeto de Arquitetura Tcnica: Figura 54;
Projeto de Arquitetura Tcnica - Anlise de Ferramentas: Figura 55;
139
Plano de Projeto: Figura 56;

Montagem da Equipe: Figura 57.
2.Planejamento da Release
Levantar Requisitos da Release: Figura 58;
Desenvolver Modelo Abrangente da Release: Figura 59;
Criar/Priorizar Lista de Funcionalidades da Release: Figura 60;
Criar Plano de Iteraes: Figura 61.
3.Iterao
Detalhar Funcionalidades: Figura 62;
Projeto Fsico: Figura 63;
Projeto de Metadados: Figura 64;
Projeto de ETL: Figura 65;
Projeto da Aplicao de BI: Figura 66;
Validao e Verificao (Testes Integrados): Figura 67;
Figura 52: FDWS - Planejamento do Projeto: Anlise Organizacional
140
Figura 53: FDWS - Planejamento do Projeto: Criar/Priorizar FBS do Projeto

141
Figura 54: FDWS - Planejamento do Projeto: Projeto de Arquitetura Tcnica

142
Figura 55: FDWS - Planejamento do Projeto: Projeto de Arquitetura Tcnica - Anlise de Ferramentas
143
Figura 56: FDWS - Planejamento do Projeto: Plano de Projeto
144
Figura 57: FDWS - Planejamento do Projeto: Montagem da Equipe
145
Figura 58: FDWS - Planejamento da Release: Levantar Requisitos da Release
146
Figura 59: FDWS - Planejamento da Release: Desenvolver Modelo Abrangente da Release
147
Figura 60: FDWS - Planejamento da Release: Criar/Priorizar Release Backlog
148
Figura 61: FWDS - Planejamento da Release: Criar Plano de Sprints
149
Figura 62: FDWS - Iterao: Detalhar Funcionalidade
150
Figura 63: FDWS - Iterao: Projeto Fsico
151
Figura 64: FDWS - Iterao: Projeto de Metadados

152
Figura 65: FDWS - Iterao: Projeto de ETL

153
Figura 66: FDWS - Iterao: Projeto da Aplicao de BI

154
Figura 67: FDWS - Iterao: Validao e Verificao
155

Monografia FDWS

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Monografia FDWS

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DA BAHIA

Mauricio Cesar Santos da Purificao

FDWS: Uma Metodologia para Gerncia e

Mauricio Cesar Santos da Purificao

FDWS: Uma Metodologia para Gerncia e

Monografia apresentada ao curso de

chefe e profissional, muito obrigado pelo exemplo de vida.

Arquitetura de BI - Viso Simplificada. Adaptado de (COSTA; ANCIES, 2001).

Viso Geral de um Data Mart (COSTA; ANCIES, 2001). . . . . . . . . . . . . .

Exemplo de Arquitetura de Povoamento e Descrio das Atividades de ETL

Exemplo de Modelo Estrela (CRAMER, 2006). . . . . . . . . . . . . . . . . . .

Exemplo de Modelo Floco De Neve (CRAMER, 2006). . . . . . . . . . . . . . .

Exemplo de Cubo Multidimensional (CRAMER, 2006). . . . . . . . . . . . . .

Etapas comuns aos Mtodos. Adaptado de (S, 2009). . . . . . . . . . . . . .

Mtodo Kimball (CARVALHO, 2009). . . . . . . . . . . . . . . . . . . . . . . .

Viso Geral do Processo SCRUM (MARAL, 2009). . . . . . . . . . . . . . . .

Exemplo de Product Burndown exibindo o consumo de story points de cada

Exemplo de Sprint Burndown exibindo o consumo de horas das tarefas durante

Ciclo de vida de um projeto com o FDD (HEPTAGON, 2010). . . . . . . . . . .

Ciclo Semanal em XP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ciclo de Desenvolvimento Agile Data Warehousing. Adaptado de (HUGHES,

Exemplo de trs ciclos de desenvolvimento curtos, ou "semanais"(CARVALHO,

Ciclo Tradicional de Desenvolvimento na Plataforma Pentaho . . . . . . . . .

FDWS - Ciclo de Vida - Viso Geral . . . . . . . . . . . . . . . . . . . . . . .

FBS Verso Original (VERSION-ONE, 2010). . . . . . . . . . . . . . . . . . . .

FBS Adaptada ao FDWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FDWS - Planejamento do Projeto - Processo . . . . . . . . . . . . . . . . . . .

FDWS - Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . .

Matriz de Necessidades (OLIVEIRA, 2010). . . . . . . . . . . . . . . . . . . . .

Atividades da etapa de Percepo. Adaptado de (S, 2009). . . . . . . . . . . . 109

Atividades da etapa de Concepo. Adaptado de (S, 2009). . . . . . . . . . . 111

Atividades da etapa de Entrega. Adaptado de (S, 2009). . . . . . . . . . . . . 112

Atividades da etapa de Operao. Adaptado de (S, 2009). . . . . . . . . . . . 113

Atividades da etapa de Ajustes/Melhorias. Adaptado de (S, 2009). . . . . . . 113

Avaliadores por sexo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Avaliadores por escolaridade . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Avaliadores por tempo de experincia em BI e DW . . . . . . . . . . . . . . . 127

Avaliadores por nvel de conhecimento em Prticas geis . . . . . . . . . . . . 127

Avaliadores por nvel de conhecimento na Metodologia SCRUM . . . . . . . . 127

Avaliadores por nvel de conhecimento na Metodologia XP . . . . . . . . . . . 128

Avaliadores por nvel de conhecimento na Metodologia FDD . . . . . . . . . . 128

FDWS - Planejamento do Projeto - Mapeamento das Etapas e Metodologias de

FDWS - Planejamento da Release - Mapeamento das Etapas e Metodologias de

FDWS - Iterao - Mapeamento das Etapas e Metodologias de Origem . . . . . 132

FDWS - Ps-Iterao - Mapeamento das Etapas e Metodologias de Origem . . 132

Objetos de Fluxo Bsicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . 134

Objetos de Conexo da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . 134

Artefatos Bsicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . . 135

Elementos de Raia da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . 135

Representao de Uma Atividade em Diferentes Nveis de Granularidade (TESSARI,

Tipos de Eventos BPMN de Incio para um BPD (TESSARI, 2008). . . . . . . . 136

Tipos de Eventos BPMN Intermedirios para um BPD (TESSARI, 2008). . . . . 137

Exemplo de Evento Intermedirio Anexado a uma Atividade (TESSARI, 2008). . 137

Tipos de Evento BPMN para o Trmino de um Processo (TESSARI, 2008). . . . 138

Tipos de Elementos do Tipo Gateway na BPMN (TESSARI, 2008). . . . . . . . 138

FDWS - Planejamento do Projeto: Anlise Organizacional . . . . . . . . . . . 140

FDWS - Planejamento do Projeto: Criar/Priorizar FBS do Projeto . . . . . . . 141

FDWS - Planejamento do Projeto: Projeto de Arquitetura Tcnica . . . . . . . 142

FDWS - Planejamento do Projeto: Projeto de Arquitetura Tcnica - Anlise de

FDWS - Planejamento do Projeto: Plano de Projeto . . . . . . . . . . . . . . . 144

FDWS - Planejamento do Projeto: Montagem da Equipe . . . . . . . . . . . . 145

FDWS - Planejamento da Release: Levantar Requisitos da Release . . . . . . . 146

FDWS - Planejamento da Release: Desenvolver Modelo Abrangente da Release 147