Este documento apresenta uma metodologia para gerência e desenvolvimento de projetos ágeis de Business Intelligence (BI) chamada FDWS, que combina práticas de SCRUM, FDD e XP. A metodologia foi avaliada em projetos na UFBA.

1. UNIVERSIDADE FEDERAL DA BAHIA
INSTITUTO DE MATEMÁTICA
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
Mauricio Cesar Santos da Purificação
FDWS: Uma Metodologia para Gerência e
Desenvolvimento de Projetos Ágeis de Business
Intelligence
Salvador - Bahia
2010-2

2. Mauricio Cesar Santos da Purificação
FDWS: Uma Metodologia para Gerência e
Desenvolvimento de Projetos Ágeis de
Business Intelligence
Monografia apresentada ao curso de
bacharelado em Ciência da Computação do
Departamento de Ciência da Computação
da Universidade Federal da Bahia, como
requisito para obtenção do grau de Bacharel
em Ciência da Computação.
Orientadora: Profa . Vaninha Vieira dos Santos
Salvador - Bahia
2010-2

3. AGRADECIMENTOS
Agradeço 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 não houvesse fé e a certeza da
ajuda divina não seria possível concluí-la.
Como está escrito em: (Provérbios 21.31) "‘O cavalo prepara-se para o dia da batalha, mas
do SENHOR vem a vitória."’ A Ele eu dedico a conclusão dessa monografia e toda a honra,
como só ele é digno de receber. Amém !
Agradeço também a meus pais: Rosenaide Vitória Santos da Purificação e Paulo Cesar
Pereira da Purificação, por me possibilitarem acreditar que heróis existem. Sim, posso dizer,
vocês são meus heróis e depois de Deus devo tudo o que tenho e sou a vocês. Minhas vitórias
são fruto da luta e do suor de vocês também. Sei bem as dificuldades e os sacrifícios que os dois
enfrentaram para me educar e garantir que eu possa ter um futuro abençoado. Não posso deixar
de incluir minhas Tias Dilma e Neide por todas as horas de jejum e oração e a minha família
em geral pela força, apoio e carinho.
A Professora Dra. Vaninha Vieira dos Santos, orientadora desta monografia, pelo apoio,
dedicação, broncas, muitos puxões de orelha, cobranças, 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 interação. 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 contribuições dadas a este trabalho.
Chris, um agradecimento especial, pelo tempo que fui teu monitor em Engenharia de Soft-
ware, 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 !
Faço um agradecimento em especial a equipe do SIAC, que muito mais do que uma equipe,
tornou-se uma família pra mim. Vivaldo, André, Helder, Mário, Fernando... vocês foram fun-
damentais na execução deste trabalho. Agradeço muito a ajuda, a força, a paciência de cada um
de vocês. Não posso deixar de citar aqui, o grande mestre Antônio, exemplo de ser humano,

4. 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 vocês contribuiu tanto para este trabalho, como para minha formação.
Agradeço também aos alunos da disciplina Tópicos 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 vocês e aos
membros do DW-UFBA (João e Elane).
Agradeço 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 não
nos deixa só, porque deixa um pouco de si e leva um poquinho de nós. Essa é a mais bela
responsabilidade da vida e a prova de que as pessoas não se encontram por acaso."’

5. RESUMO
Soluções de Business Intelligence (BI) são de grande importância para os gestores das em-
presas e dos seus responsáveis de TI devido aos benefícios advindos de sua implementação e
uso, referentes a melhoria do processo decisório das organizações, como por exemplo, compa-
nhias privadas e instituições de ensino como a Universidade Federal da Bahia (UFBA). Porém,
a implementação de soluções de BI é uma missão difícil por causa dos ambientes de Tecnologia
da Informação (TI) altamente complexos e grandes volumes de dados não-integrados oriun-
dos de bases distintas sejam estas externas ou internas. Além disso, as abordagens tradicionais
de desenvolvimento de soluções de BI como Kimball (KIMBALL, 2002) não possibilitam que
os gestores das empresas experimentem os benefícios destas soluções a curto prazo e muitas
vezes os projetos encerram-se sem ter havido nenhum resultado visível aos gestores da organi-
zação. Nesse contexto surgem os conceitos de Agile BI e Agile Data Warehousing, que nada
mais são do que a aplicação de práticas advindas das metodologias ágeis no universo do de-
senvolvimento de soluções de BI. O conceito de Agile BI ultrapassa a fronteira da metodologia
e interfere em vários outros aspectos do desenvolvimento das soluções como, por exemplo, a
arquitetura da solução e o próprio comportamento das ferramentas usadas durante o processo.
Este trabalho apresenta a especificação de uma metodologia para gerência e desenvolvimento
de projetos ágeis de BI usando práticas combinadas das metodologias Extreme Programming
(XP), SCRUM e Feature Driven Development (FDD) de modo a atender ao requisito metodolo-
gia e processo de desenvolvimento sob o conceito de Agile BI. O uso dessa metodologia foi
avaliado em dois projetos realizados na disciplina "Tópicos em Banco de Dados"do Departa-
mento de Ciência da Computação da Universidade Federal da Bahia (DCC-UFBA) e no projeto
Permanecer DW-UFBA. Os resultados de sua aplicação são explicitados e analisados.
Palavras-chave: Business Intelligence, Data Warehouse, Métodologias Ágeis, SCRUM,
FDD, XP, Agile Data Warehousing, Agile BI.

6. 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 improve-
ment 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 in-
ternal 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 solu-
tions. 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.

7. LISTA DE FIGURAS
1 Arquitetura de BI - Visão Simplificada. Adaptado de (COSTA; ANCIÃES, 2001). 22
2 Visão Geral de um Data Mart (COSTA; ANCIÃES, 2001). . . . . . . . . . . . . . 22
3 Exemplo de Arquitetura de Povoamento e Descrição das Atividades de ETL
(COSTA; ANCIÃES, 2001). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Exemplo de Modelo Estrela (CRAMER, 2006). . . . . . . . . . . . . . . . . . . 26
5 Exemplo de Modelo Floco De Neve (CRAMER, 2006). . . . . . . . . . . . . . . 27
6 Exemplo de Cubo Multidimensional (CRAMER, 2006). . . . . . . . . . . . . . 28
7 Etapas comuns aos Métodos. Adaptado de (SÁ, 2009). . . . . . . . . . . . . . 31
8 Método Kimball (CARVALHO, 2009). . . . . . . . . . . . . . . . . . . . . . . . 32
9 Visão Geral do Processo SCRUM (MARÇAL, 2009). . . . . . . . . . . . . . . . 37
10 Exemplo de Product Burndown exibindo o consumo de story points de cada
sprint (CAVALCANTI, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11 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). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
15 Exemplo de três ciclos de desenvolvimento curtos, ou "semanais"(CARVALHO,
2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
16 Ciclo Tradicional de Desenvolvimento na Plataforma Pentaho . . . . . . . . . 53
17 FDWS - Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
18 FDWS - Ciclo de Vida - Visão Geral . . . . . . . . . . . . . . . . . . . . . . . 65

8. 19 FBS Versão 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 - Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
25 FDWS - Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
26 Atividades da etapa de Percepção. Adaptado de (SÁ, 2009). . . . . . . . . . . . 109
27 Atividades da etapa de Concepção. Adaptado de (SÁ, 2009). . . . . . . . . . . 111
28 Atividades da etapa de Entrega. Adaptado de (SÁ, 2009). . . . . . . . . . . . . 112
29 Atividades da etapa de Operação. 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 experiência em BI e DW . . . . . . . . . . . . . . . 127
34 Avaliadores por nível de conhecimento em Práticas Ágeis . . . . . . . . . . . . 127
35 Avaliadores por nível de conhecimento na Metodologia SCRUM . . . . . . . . 127
36 Avaliadores por nível de conhecimento na Metodologia XP . . . . . . . . . . . 128
37 Avaliadores por nível 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 - Iteração - Mapeamento das Etapas e Metodologias de Origem . . . . . 132
41 FDWS - Pós-Iteração - Mapeamento das Etapas e Metodologias de Origem . . 132
42 Objetos de Fluxo Básicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . 134
43 Objetos de Conexão da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . 134

9. 44 Artefatos Básicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . . 135
45 Elementos de Raia da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . 135
46 Representação de Uma Atividade em Diferentes Níveis de Granularidade (TES-
SARI, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
47 Tipos de Eventos BPMN de Início para um BPD (TESSARI, 2008). . . . . . . . 136
48 Tipos de Eventos BPMN Intermediários para um BPD (TESSARI, 2008). . . . . 137
49 Exemplo de Evento Intermediário Anexado a uma Atividade (TESSARI, 2008). . 137
50 Tipos de Evento BPMN para o Término de um Processo (TESSARI, 2008). . . . 138
51 Tipos de Elementos do Tipo Gateway na BPMN (TESSARI, 2008). . . . . . . . 138
52 FDWS - Planejamento do Projeto: Análise Organizacional . . . . . . . . . . . 140
53 FDWS - Planejamento do Projeto: Criar/Priorizar FBS do Projeto . . . . . . . 141
54 FDWS - Planejamento do Projeto: Projeto de Arquitetura Técnica . . . . . . . 142
55 FDWS - Planejamento do Projeto: Projeto de Arquitetura Técnica - Análise 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 - Iteração: Detalhar Funcionalidade . . . . . . . . . . . . . . . . . . . 150
63 FDWS - Iteração: Projeto Físico . . . . . . . . . . . . . . . . . . . . . . . . . 151
64 FDWS - Iteração: Projeto de Metadados . . . . . . . . . . . . . . . . . . . . . 152
65 FDWS - Iteração: Projeto de ETL . . . . . . . . . . . . . . . . . . . . . . . . 153
66 FDWS - Iteração: Projeto da Aplicação de BI . . . . . . . . . . . . . . . . . . 154
67 FDWS - Iteração: Validação e Verificação . . . . . . . . . . . . . . . . . . . . 155

10. LISTA DE TABELAS
2 Descrição das Etapas do Planejamento do Projeto Executadas no Projeto Per-
manecer DW-UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3 Descrição das Etapas do Planejamento da Release Executadas no Projeto Per-
manecer DW-UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4 Descrição das Etapas da Iteração Executadas no Projeto Permanecer DW-UFBA 117
5 Descrição das Etapas da Pós-Iteração Executadas no Projeto Permanecer DW-
UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6 Descrição das Etapas do Planejamento do Projeto Executadas na Disciplina
Tópicos em Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7 Descrição das Etapas do Planejamento da Release Executadas na Disciplina
Tópicos em Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8 Descrição das Etapas da Iteração Executadas na Disciplina Tópicos em Banco
de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
9 Descrição das Etapas da Pós-Iteração Executadas na Disciplina Tópicos em
Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

11. LISTA DE ABREVIATURAS E SIGLAS
BI Business Intelligence (Inteligência de Negócios),
17
BPD Business Process Diagrams (Diagramas de Pro-
cessos de Negócio), 133
BPMI The Business Process Management Initiative,
133
BPMN Business Process Modeling Notation (Notação
para Modelagem de Processos de Negócio), 133
CIOs Chief Information Officers (Diretores de Tec-
nologia da Informação), 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 Ciência da Computação 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 Extração, Transformação e Carga, 21

12. ETL Extract, Transform and Load, 21
FBS Feature Breackdown Structure, 66
FDD Feature Driven Development, 18
OLAP On-Line Analytical Processing (Processamento
Analítico Online), 24
PPF Planejar por Funcionalidade, 41
TI Tecnologia da Informação, 17
WBS Work Breakdown Structure, 50
XP Extreme Programing, 18

13. SUMÁRIO
1 Introdução 17
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 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 Metodologias para Gerência e Desenvolvimento de Projetos de Data Warehousing 28
2.3.1 Abordagens para Implementação de um DW . . . . . . . . . . . . . . 30
2.3.2 Modelo Geral de Processo para Data Warehousing . . . . . . . . . . . 31
2.3.3 Método Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 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 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.1.4 Medição de Progresso . . . . . . . . . . . . . . . . . . . . . 39

14. 2.4.2 FDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.2.1 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.2.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.3 XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.3.1 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.3.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3 Avaliação de Trabalhos Relacionados 48
3.1 Agile Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2 Extreme Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1 Planejamento do Processo . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Aplicação de Práticas Ágeis na Criação de Data Warehouse Evolutivo . . . . . 51
3.4 Agile BI - Pentaho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5 Aplicação de Práticas Ágeis em Projetos de BI . . . . . . . . . . . . . . . . . . 53
3.6 Análise dos Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . 56
3.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4 Metodologia FDWS 59
4.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.1 Gerência de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.2 Gerência de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.3 Núcleo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.1.1 Análise Organizacional . . . . . . . . . . . . . . . . . . . . 69

15. 4.3.1.2 Criar/Priorizar FBS do Projeto . . . . . . . . . . . . . . . . 70
4.3.1.3 Projeto de Arquitetura Técnica . . . . . . . . . . . . . . . . 71
4.3.1.4 Plano de Projeto . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3.1.5 Montagem dos Times . . . . . . . . . . . . . . . . . . . . . 72
4.3.2 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 Iterações . . . . . . . . . . . . . . . . . . . . 77
4.3.2.5 Revisar Arquitetura Tecnológica/Ferramentas . . . . . . . . 78
4.3.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3.3.1 Configuração do Ambiente de Testes, Produção e Homologação 78
4.3.3.2 Configuração de Ferramentas . . . . . . . . . . . . . . . . . 78
4.3.3.3 Criar Versão de Teste, Produção e Homologação . . . . . . . 78
4.3.3.4 Detalhar Funcionalidades . . . . . . . . . . . . . . . . . . . 80
4.3.3.5 Projeto Físico . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3.3.6 Projeto de Metadados . . . . . . . . . . . . . . . . . . . . . 81
4.3.3.7 Projeto de ETL . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.3.8 Projeto da Aplicação de BI . . . . . . . . . . . . . . . . . . 82
4.3.3.9 Validação e Verificação (Testes Integrados) . . . . . . . . . . 82
4.3.3.10 Implantação no Ambiente de Homologação . . . . . . . . . 83
4.3.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4 Análise da Metodologia FDWS . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4.1 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4.2 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.4.3 FDWS e os Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . 88

16. 5 Estudo de Caso 89
5.1 Projeto Permanecer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.1.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.1.2 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.1.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.1.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2 Tópicos em Banco de Dados - Semestre 2010-2 . . . . . . . . . . . . . . . . . 93
5.2.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.2.2 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.1 Execução da Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.2 Análise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6 Conclusão 99
6.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2 Dificuldades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Referências 103
Apêndice A -- Modelo Geral de Processo para Data Warehousing 107
A.1 Percepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A.2 Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.3 Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.4 Operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
A.5 Ajustes/Melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

17. Apêndice B -- Análise dos Estudo de Caso 114
B.1 Aplicação 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 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.1.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.2 Aplicação da Metodologia FDWS na Disciplina Tópicos em Banco de Dados . 118
B.2.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.2 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Apêndice C -- Questionário de Avaliação da Metodologia FDWS 123
C.1 Informações Pessoais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.2 Questionário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Apêndice D -- Perfil dos Avaliadores 126
Apêndice E -- Especificação 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 Descrição da Notação BPMN . . . . . . . . . . . . . . . . . . . . . . 133
E.2.1.1 Elementos Básicos da Notação . . . . . . . . . . . . . . . . 133
E.2.1.2 Refinamento dos Elementos . . . . . . . . . . . . . . . . . . 135
E.2.2 Diagramas de Processo da Metodologia FDWS . . . . . . . . . . . . . 138

18. 17
1 INTRODUÇÃO
Este capítulo apresenta a motivação para este trabalho, discute seus objetivos e os resultados
que se pretende alcançar com sua realização e descreve a estrutura deste documento.
1.1 MOTIVAÇÃO
Soluções de Inteligência de Negócios (BI, do inglês Business Intelligence) possibilitam uma
melhora significativa no processo decisório das organizações ao oferecer informações úteis, de
modo rápido e facilitado, a partir dos próprios dados existentes nelas. Por isso, continuam a ser
de grande prioridade para os gestores das empresas e dos seus responsáveis de Tecnologia da
Informação (TI) (NÓBREGA, 2010).
Porém, segundo (FAYYAD, 2003 apud FERNÁNDEZ; MAYOL; PASTOR, 2008, p. 1) a grande
maioria destes projetos têm falhado em conseguir seus objetivos. Este fato não é estranho
tratando-se de sistemas de suporte a decisão e da imaturidade da disciplina de BI com uma
diversidade de enfoques metodológicos diferentes (PRESTON, 2003).
De acordo com (NÓBREGA, 2010) no relatório da Forrester Research intitulado "Agile BI
Out of the Box", realizado a partir de um estudo com empresas dos Estados Unidos, os uti-
lizadores empresariais de aplicações de BI estão largamente insatisfeitos com a falta de agili-
dade e flexibilidade das soluções desenvolvidas. Segundo o relatório, é necessário criar uma
nova forma de conceber e construir as aplicações de BI, defendendo que o processo tradicional
de recuperação de informações sobre todas as fontes de dados, documentação de todos os atri-
butos, criação do Data Warehouse (DW) baseado nos dados recolhidos e a compilação de es-
pecificações para aplicações 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 Informação (CIOs do inglês Chief Information Offi-
cers), apesar do desejo das corporações, conseguir empregar aplicativos novos e inovadores de

19. 18
BI ainda é um desafio. Isso porque, atualmente, na rede das empresas existem grandes volumes
de dados inseridos em ambientes complexos de TI que não conversam entre si. Consequente-
mente, o departamento de tecnologia tem enfrentado obstáculos para suprir as necessidades dos
usuários por soluções intuitivas e aplicações de fácil utilização (WAILGUM, 2010).
Outro detalhe importante é que os clientes estão cada vez mais impacientes para obter os
benefícios do BI, seja por causa do aumento da competitividade da economia global ou por que
já perceberam como o desenvolvimento de soluções 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 cenário, o relatório da Forrester Research defende uma abordagem definida
como "Agile BI"para a construção de soluções de BI. O conceito de "Agile BI"não difere muito
das metodologias ágeis de desenvolvimento de software, o que demanda a criação de soluções
em pequena escala (WAILGUM, 2010), com uma maior proximidade dos clientes e resultados
efetivos mais rápidos.
O uso de metodologias ágeis também é 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 soluções de BI, mais rápidas e eficazes. Ainda segundo (HUGHES,
2007) o uso do "Agile Data Warehousing"influi diretamente nos prazos de entrega, na qualidade
da aplicação desenvolvida e na redução dos custos de produção.
Apesar de alguns esforços já existentes, o alinhamento de práticas ágeis com o desenvolvi-
mento de soluções de BI é um grande desafio. Os métodos ágeis foram concebidos para gerência
e desenvolvimento de projetos de software e não de projetos de integração de dados, como são
os projetos de BI. Existe uma diversidade de metodologias que podem ser utilizadas de acordo
com as adaptações necessárias para o suporte a projetos de integração de dados.
1.2 OBJETIVOS
O objetivo geral deste trabalho é especificar uma metodologia para gerência e desenvolvi-
mento de projetos ágeis de BI derivada do SCRUM, com a composição de práticas advindas das
metodologias ágeis Feature Driven Development (FDD) e Extreme Programming (XP) . Para
tanto tem-se os seguintes objetivos específicos:
• Investigar os processos tradicionais de construção de soluções de BI.
• Investigar a utilização de metodologias ágeis nos processos de construções de soluções

20. 19
de BI.
• Investigar, analisar e selecionar as práticas das metodologias SCRUM, FDD e XP a serem
instaciadas no universo do processo de construção de soluções de BI.
• Especificar uma metodologia para gerência 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
Além deste capítulo introdutório este documento está organizado nos seguintes capítulos:
• O Capítulo 2 fornece uma visão geral dos principais conceitos relacionados a este tra-
balho: BI, DW, Metodologias Ágeis e Metodologias para Data Warehousing;
• No Capítulo 3 é realizada uma análise dos trabalhos relacionados a esta monografia, a fim
de oferecer uma base de comparação com a metodologia proposta neste trabalho;
• O Capítulo 4 trata do detalhamento e especificação da metodologia FDWS;
• No Capítulo 5 são detalhados os estudos de casos realizados e a avaliação da aplicação
da metodologia proposta;
Por fim, o Capítulo 6 apresenta a conclusão deste trabalho, bem como destaca as suas
principais contribuições e definições para trabalhos futuros.

21. 20
2 CONCEITOS
2.1 BUSINESS INTELLIGENCE
BI pode ser visto como um processo sistemático de aquisição, tratamento e análise de infor-
mações em que os dados internos e externos da empresa são integrados para gerar informação
pertinente para o processo de tomada de decisão. O papel do BI é criar um ambiente informa-
cional com processos através dos quais os dados operacionais possam ser coletados, tanto dos
sistemas transacionais como de fontes externas, e analisados, revelando dimensões "estratégi-
cas"do negócio (PETRINI; FREITAS; POZZEBON, 2006).
A necessidade do cruzamento e análise de informações para uma plena gestão organiza-
cional é uma realidade não apenas de nosso tempo, mas também de épocas passadas. O interesse
pelo tema BI iniciou-se no ano de 1996, devido ao avanço tecnológico que possibilitou a criação
de ferramentas para captação, extração, armazenamento, filtragem, disponibilização e personal-
ização de dados. O mesmo tem crescido na medida em que se descobre no BI uma solução para
os problemas relacionados a tomada de decisão dentro das corporações (INTEL, 2010). No geral
as empresas não dispõem de uma informação acionável e instrumentos analíticos necessários
para melhorar os lucros e desempenho, sendo portanto ricas em dados e probres em informação.
O BI surge então como uma resposta para esta necessidade (WILLIAMS; WILLIAMS, 2007).
Considerando o termo BI, vale considerar em que sentido a palavra inteligência relaciona-se
com o ambiente de negócios. De acordo com (PETRINI; FREITAS; POZZEBON, 2006), inteligên-
cia é o resultado de um processo que começa com a coleta de dados. A explicação sobre como
as organizações adquirem "inteligência"reside na transformação dado-informação-inteligência.
Os dados referem-se a uma descrição elementar de coisas, eventos, atividades e transações que
são registrados, classificados e armazenados, mas não são organizados para transmitir qualquer
significado. Por exemplo, em uma empresa de vendas podemos ter dados armazenados rela-
tivos ao cadastro de produtos, cadastro de clientes e vendas realizadas. A partir destes dados
contextualizados mediante sua transformação e consolidação podemos obter informações a res-
peito das vendas dos clientes, produtos mais vendidos e comparativos de vendas por períodos.

22. 21
Por fim, a inteligência eleva a informação a um nível mais alto, como resultado do completo
entendimento de ações, contextos e decisões. As soluções de BI, realizam o ciclo de transfor-
mação dado-informação-inteligência, de modo a melhorar o processo de tomada de decisões
dentro das organizações, que com o BI deixam de ser apenas ricas em dados e tornam-se ricas
em "‘inteligência"’.
Várias iniciativas têm recebido o nome de BI, devido ao fato de o mesmo constituir-se por
uma vasta categoria de software e soluções para coleta, consolidação, análise e disseminação
de informações visando melhorar o processo decisório. Não existe, portanto um modelo de
solução fechado para BI. BI pode, então, englobar um grande grupo de aplicações ou soluções
diferenciadas contanto que elas possibilitem a melhoria do processo de tomada de decisões
por meio de processos realizados nos dados uniformizados da organização (PETRINI; FREITAS;
POZZEBON, 2006).
Analisando a Figura 1, podemos visualizar uma arquitetura tradicional para soluções de
BI. Segundo esta arquitetura, temos basicamente dois componentes representados pela Arquite-
tura Técnica de Povoamento e pela Arquitetura de Acesso aos Dados. A Arquitera Técnica de
Povoamento define como os dados oriundos dos sistemas operacionais (fontes de dados exter-
nas e internas) são carregadas no DW através do processo de Extração, Transformação e Carga
(ETC) (do inglês Extract, Transform and Load (ETL)). No processo de ETL, os dados opera-
cionais são uniformizados, selecionados, transformados, e carregados no DW da solução de
BI.
A Arquitetura de Acesso aos Dados define como os dados armazenados no DW serão aces-
sados pelos usuários. Por exemplo, pode-se construir Data Marts (DMs) (Figura 2), que são
como um DW armazenando dados a níveis departamentais ou vínculados a áreas específicas do
negócio, de modo que caso o DW necessite de algum suporte ou manutenção 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. Além desses dois
componentes, existe uma camada de metadados que engloba toda a solução. Os metadados
devem possibilitar o registro de todas as informações sobre os dados como suas origens e os
processos de transformação sofridos. São de extrema importância dentro do ambiente de DW,
pois representam uma visão integrada das bases de dados que fazem parte deste ambiente. São
utilizados para construir, manter, gerenciar e utilizar o DW (COSTA; ANCIÃES, 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 negócio existentes. Enquanto o DW concentra os dados de
toda a organização, cada DM serve a um departamento ou área de negócio específica.

23. 22
Figura 1: Arquitetura de BI - Visão Simplificada. Adaptado de (COSTA; ANCIÃES, 2001).
Figura 2: Visão Geral de um Data Mart (COSTA; ANCIÃES, 2001).

24. 23
2.2 DATA WAREHOUSE
Segundo (INMON, 1997) a definição de DW é: "uma coleção de dados orientada por assun-
tos, integrada, variante no tempo, e não volátil, que tem por objetivo dar suporte aos processos
de tomada de decisão".
• Orientado por assunto: Os dados não estão mais organizados de acordo com as regras de
negócios dos sistemas, mas sim de acordo com as áreas de interesse da organização. Por
exemplo: vendas de produtos a diferentes tipos de clientes, atendimentos e diagnósticos
de pacientes, rendimento de estudantes, produção científica de professores e grupos de
pesquisa, índices de aprovação e reprovação.
• Integrado: Diferentes nomenclaturas, formatos e estruturas das fontes de dados precisam
ser agrupados em um único esquema para prover uma visão unificada e consistente da
informação. Por exemplo, um sistema pode tratar o gênero das pessoas como masculino
e feminino, outro como m e f. Ao serem passados para a base do DW estes dados deverão
ser unificados para um único esquema de apresentação.
• Variante no tempo: Ao contrário dos sistemas transacionais, os dados em um DW não
sofrem constantes atualizações, eles são armazenados periodicamente o que permite que
os mesmos possam ser analisados historicamente.
• Não volátil: Os dados de um DW em geral não são modificados como em sistemas
transacionais (exceto para correções), mas somente carregados e acessados para leituras,
com atualizações apenas periódicas.
Nos sistemas transacionais busca-se otimizar ao máximo a performance de acesso às tran-
sações, já em um DW o que se prioriza é a qualidade da informação que pode ser consultada
em tempo hábil pelos gestores, analistas e executivos. O DW torna-se então o ponto central da
arquitetura proposta para uma solução de suporte a tomada de decisões na medida em que con-
solida as informações necessárias para o processo de tomada de decisões através de um alicerce
sólido de integração de dados corporativos e históricos para a realização de análises gerenci-
ais (INMON; HACKATHORN, 1997). Para construí-lo é necessário combinar as necessidades de
informações de uma comunidade de usuários com os dados que realmente estão disponíveis
(KIMBALL, 2002).

25. 24
2.2.1 DATA WAREHOUSING
Data Warehousing é um conjunto de tecnologias de suporte a decisão destinadas a possi-
bilitar que as pessoas que trabalhem a partir de informações (gerentes, analistas, executivos)
possam tomar melhores decisões mais rapidamente (DAYAL; CHAUDHURI, 1997). O Data Ware-
housing possibilita então a integração das fontes de dados transacionais na construção do DW
que pode ser usado ou não com o objetivo final de suportar analíses gerenciais, o que amplia o
escopo do Data Warehousing chegando no nível do conceito de BI.
Pode-se considerar o Data Warehousing como um processo fundamental na construção de
soluções de BI pois oferece o suporte necessário às ferramentas que serão utilizadas para a
análise dos dados, como o Processamento Analítico Online (OLAP do inglês On-Line Analyti-
cal Processing) e a Mineração de Dados (do inglês Data Mining 1 ). Porém, para construir uma
solução de BI não necessariamente necessita-se realizar o processo de Data Warehousing, isto
pode ser feito a partir de uma planilha eletrônica por exemplo, sem que tenha-se o trabalho de
realizar qualquer processo de integração de dados.
O Data Warehousing é um elemento que potencializa a construção de soluções de BI pois
fornece às ferramentas de análise dados uniformizados e integrados, diminuindo o risco da
realização de análises gerenciais a partir de dados incorretos e não contextualizados. Observa-
se que os termos Data Warehousing e BI são tratados como sinônimos na literatura devido
a proximidade de seus conceitos. Desenvolver uma solução de Data Warehousing é também
desenvolver uma solução de BI, caso esta solução destine-se a servir para o processo de tomada
de decisões a partir das análises gerenciais realizadas. Na metodologia proposta neste trabalho o
termo BI é utilizado neste sentido, pois a solução de BI construída com sua aplicação é baseada
em Data Warehousing para a melhoria do processo de tomada de decisões gerenciais.
2.2.2 ETL
O ETL constitui-se como um elemento básico para a construção de um DW. Os dados que
serão armazenados no DW provém de várias bases que não estão integradas e, além 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 operações relacionadas ao ETL referem-se inicialmente a extração dos dados das bases
1 DataMining é uma das etapas no Processo de Descoberta do Conhecimento que consiste na aplicação de
algoritmos de análise de dados e descoberta de conhecimento a fim de encontrar padrões e modelos sobre os dados
(FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996).

26. 25
dos sistemas transacionais, em segunda instância a transformação destes dados de modo a
integrá-los e resolver problemas relacionados a modelagens diferentes como, por exemplo, um
sistema que defina o gênero de uma pessoa como masculino e feminino e outro sistema que de-
fina o mesmo item como m ou f. No DW todos os dados advindos de sistemas diferentes devem
ser uniformizados e tal uniformização só é garantida no processo de transformação dos dados.
A última operação a ser realizada é a carga dos dados depois de extraídos 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 implementação do ETL é de vital importância para o sucesso do projeto de DW. Segundo
estatísticas, em um projeto de DW, o processo de ETL pode consumir até 70% do esforço de
todo o trabalho (DAYAL et al., 2009). A Figura 3 ilustra uma arquitetura básica para ETL e as
principais atividades envolvidas: Extração, Transformação e Carga.
Figura 3: Exemplo de Arquitetura de Povoamento e Descrição das Atividades de ETL (COSTA;
ANCIÃES, 2001).
2.2.3 MODELAGEM MULTIDIMENSIONAL
Os requisitos de uma modelagem para DW são diferentes das aplicações do ambiente
transacional. Para um DW deverá haver uma extensa flexibilidade nas análises a serem su-

27. 26
portadas. As medidas a serem realizadas necessitam ser vistas sob diferentes perspectivas (ou
seja, através de várias dimensões) e o entendimento e a visualização de problemas típicos no
universo das organizações devem ser facilitados.
O modelo multidimensional surge como uma técnica que responde a estes requisitos e au-
xilia no processo de análise de dados que descrevem aspectos comuns de negócios. Um modelo
multidimensional possui três elementos básicos: Fatos, dimensões e medidas. Um fato é uma
coleção de itens de dados implementados sobre tabelas de fatos que representam um item de
negócio, sendo composto por dados de medida e de contexto. Uma dimensão constitui-se como
os elementos que fazem parte de um determinado fato. Por exemplo, para um dado fato ven-
das de um produto teríamos as dimensões: tempo, local, clientes e vendedores. As medidas
constituem-se como os valores numéricos que representam os fatos.
Considerando a modelagem multidimensional, podemos modelar nossos dados sob dois
esquemas básicos: 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 re-
dor desta denominadas dimensões, no modelo floco-de-neve ao contrário do modelo estrela as
tabelas de dimensões encontra-se todas normalizadas (DAYAL; CHAUDHURI, 1997). O modelo
floco-de-neve possibilita a diminuição da redundância de dados que pode ser bastante alta no
modelo estrela, porém este modelo aumenta a complexidade do esquema e dificulta as imple-
mentações por parte das ferramentas de análises de dados e até mesmo a compreensão por parte
dos usuários. O modelo estrela contribui para o ganho de desempenho mesmo que este ganho
seja a custo de maior espaço de armazenamento.

28. 27
Figura 5: Exemplo de Modelo Floco De Neve (CRAMER, 2006).
2.2.4 OLAP
A tecnologia OLAP possibilita às organizações um método de acesso, visualização, e
análise de dados corporativos com alta flexibilidade e desempenho. Deste modo, as ferramentas
OLAP permitem a geração de relatórios, análise de um grande volume de dados e a obtenção
de informações estratégicas que podem facilitar a tomada de decisão (ARAÚJO; BATISTA; MA-
GALHÃES, 2007). O termo OLAP refere-se a um conjunto de ferramentas voltadas para acesso
e análise ad-hoc de dados, com o objetivo final de transformar dados em informações capazes
de dar suporte às decisões gerenciais de forma amigável, flexível e em tempo hábil ao usuário
(ARAÚJO; BATISTA; MAGALHÃES, 2007).
Segundo (ANZANELLO, 2002), OLAP é mais do que uma aplicação, é uma solução de ambi-
ente, integração e modelagem de dados. Os dados utilizados pela solução OLAP são originários
de um DW ou simplesmente de um DM. Para formular a topologia e o projeto de uma solução
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 dimensão). A obtenção dos dados originários
das respostas é destinada aos DW e, daí, possivelmente para um ou vários Data Marts (DMs).
Podemos definir um cubo de dados como uma representação intuitiva do fato, por que todas
as dimensões coexistem para todo o ponto no cubo e são independentes entre si. Além disso,
são nos cubos multidimensionais que são gravados os valores quantitativos e as medidas das
informações armazenadas.

29. 28
Figura 6: Exemplo de Cubo Multidimensional (CRAMER, 2006).
2.3 METODOLOGIAS PARA GERÊNCIA E DESENVOLVI-
MENTO DE PROJETOS DE DATA WAREHOUSING
Nesta seção serão discutidas algumas das abordagens tradicionais existentes na literatura
para a gerência e desenvolvimento de projetos de BI que envolvem Data Warehousing (Na
literatura essas metodologias são descritas apenas como metodologias para Data Warehousing,
apesar da relação existente entre Data Warehousing e BI como sinônimos, por isto o termo Data
Warehousing foi mantido).
A aplicação de metodologias ágeis em BI tem sido motivada devido a alguns problemas
que tem sido observados com estas abordagens:
1. Envolvimento com os clientes, usuários 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 difíceis
de implementar. O ideal é que se inicie o projeto com um pequeno protótipo do que será
a solução de BI;
3. Demora na entrega de funcionalidades aos clientes. Muitos projetos de BI são encerrados
sem que os gestores tenham tido resultados satisfatórios;
4. Avaliação inicial e foco estratégico do projeto. Muitos projetos de BI falham por não
ter sido feito um planejamento adequado de acordo com as necessidades emergentes do

30. 29
negócio;
5. Mudanças organizacionais (cultura organizacional). Projetos de BI acabam transfor-
mando a cultural organizacional. Dependendo de como o processo é feito, essa mudança
de cultura pode trazer um impacto muito grande na instituição. A solução 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 usuários finais, precisam de tempo para experi-
mentar e avaliar as ferramentas de consulta e exploração das informações. O conjunto de
ferramentas utilizado deve ser flexível e atender às necessidades do negócio;
7. Extensibilidade e adaptação a mudanças. Mudanças de requisitos são frequentes, prin-
cipalmente em projetos de BI. O processo de desenvolvimento deve responder bem a
quaisquer tipo de mudanças, seja esta feita em qualquer fase do projeto. Além disso,
a solução desenvolvida deve ser projetada de modo que possa estar sempre em espan-
são, pois novas consultas sempre serão solicitadas desde que os gestores e usuários finais
percebam os benefícios da solução 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 análise 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 construído e imple-
mentado, mapeando assim os resultados esperados das várias atividades e técnicas adotadas na
construção e projeto de Data Warehousing (SÁ, 2009). Não existe, por enquanto, um consenso
em termos de qual seja a melhor metodologia e em que cenários uma ou outra é mais adequada.
Existem, portanto, na literatura, várias propostas metodológicas e estudos de caso de aplicações.
Em alguns casos a metodogia de Data Warehousing está ligada com uma proposta de arquite-
tura para o DW. De um modo geral podemos agrupar as metodologias de Data Warehousing
em dois grupos que também correspondem a abordagens de arquitetura: Abordagem top-down
e Abordagem bottom-up.

31. 30
2.3.1 ABORDAGENS PARA IMPLEMENTAÇÃO DE UM DW
A abordagem Top-Down é defendida por Inmon (INMON, 1997) e define basicamente duas
etapas para a implementação de DW. Na primeira etapa é realizada a especificação do esquema
de todo o DW. Na segunda etapa, é feita a construção de DMs de acordo com as características
e particularidades de cada área do negócio/departamento (SÁ, 2009).
Um dos maiores problemas dessa abordagem é que realizar o levantamento de todos os
requisitos do DW em uma única etapa é extremamente difícil devido a dimensão do negócio
que está sendo trabalhada e a dificuldade em se extrair os requisitos de usuário.
O maior defensor da abordagem Bottom-Up é Ralph Kimball (KIMBALL, 2002). Segundo
esta abordagem, o DW deve ser concebido iterativamente a partir da construção de DMs que
serão posteriormente integrados dando origem ao DW. Deve existir um cuidado intenso na
definição dos esquemas dos DMs, pois os mesmos deverão ser integrados posteriormente. Deste
modo a concepção de cada modelo deve ser feita pensando-se nesta posterior integração. Em
(SÁ, 2009) são indicadas quatro abordagens que podem ser utilizadas para se determinar o
modelo de dados de um DW e por conseguinte seu conteúdo: 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 usuários do DW
são incapazes inicialmente de formular as necessidades informacionais antes de perce-
berem e experimentarem as capacidades do DW. Por isso, em um primeiro momento, os
requisitos de usuário são ignorados vindo a ser percebidos apenas após o lançamento de
uma primeira versão do mesmo;
• Orientada aos objetivos: Esta abordagem consiste, inicialmente, em recolher e iden-
tificar os objetivos organizacionais. Esses objetivos podem ser identificados a partir de
entrevistas com stakeholders nos processos organizacionais e que serão posteriormente
quantificados em indicadores que permitam avaliar o desempenho do processo;
• Orientada aos utilizadores: Segundo esta abordagem devem ser coletados as necessi-
dades e expectativas dos futuros utilizadores do DW. Os requisitos de usuário são, por-
tanto, colhidos e documentados servindo de base para a construção do modelo de dados
do DW;
• Orientada a processos: Segundo esta abordagem os processos essenciais da organiza-
ção devem ser identificados. A partir dos processos mapeados devem ser definidos os

32. 31
indicadores de desempenho desejados.
Existem, ainda, na literatura propostas que fazem a junção dessas abordagens de modo a
melhorar o processo de definição do modelo de dados do DW.
2.3.2 MODELO GERAL DE PROCESSO PARA DATA WAREHOUSING
Em (SÁ, 2009), o autor realiza uma análise entre algumas metodologias de implementação
de DW: Método Kimball (KIMBALL, 2002), NCR/Teradata (NCR-TERADATA, 2007), Microsoft
(CRAIG; VIVONA; BERKOVITCH, 1999), SAS (BROWN, 2000), Iterations, (PRISM-SOLUTIONS,
2002) e identifica algumas etapas metodológicas comuns a estes métodos que podem ser visu-
alizadas na Figura 7. Essas etapas são detalhas no Apêndice A.
Figura 7: Etapas comuns aos Métodos. Adaptado de (SÁ, 2009).
• Percepção: É a etapa de identificação e definição de requisitos, arquitetura, modelos,
aplicações analíticas, aplicações e ferramentas de apoio bem como a ordem em que as
iterações do processo deverão ser realizadas;
• Concepção: É considerada a etapa mais técnica, pois é onde o DW é construído;
• Entrega: Consiste em colocar o sistema de DW em produção, obrigando a montagem de
toda a estrutura de apoio ao funcionamento do sistema de DW, isso inclui a documentação
e a formação/suporte aos utilizadores;
• Operação: 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 su-
gestões e reclamações dos utilizadores, através dos canais de suporte montados na etapa
de Entrega, que poderão ser transformados em novos requisitos.

33. 32
A partir da definição destas etapas (SÁ, 2009) define um modelo geral de processo para Data
Warehousing e uma recomendação de metodologia para que um processo de Data Warehousing
possa obter sucesso. O processo definido por (SÁ, 2009) é detalhado no Apêndice A.
2.3.3 MÉTODO KIMBALL
O método de Kimball é um dos métodos mais referenciados em termos acadêmicos e pro-
fissionais, por isto foi incluido neste capítulo. O modelo geral do processo está descrito na
Figura 8. Esse método é iterativo e defende que a construção do DW seja incremental a partir
da contínua construção/integração de DMs. Suas etapas são:
Figura 8: Método Kimball (CARVALHO, 2009).
1. Planejamento do Projeto: Esta etapa engloba o seguinte conjunto de atividades (CAR-
VALHO, 2009): Análise inicial do ambiente, definição do escopo e data de entrega, mon-
tagem da equipe, definição do cronograma de atividades da iteração, definição de um
plano de comunicação para a equipe. Durante esta etapa devem ser avaliados e iden-
tificados: o nível de preparação da organização para ter um sistema de DW, os riscos
associados, patrocinadores, motivação e cultura organizacionais (SÁ, 2009).
2. Especificação de Requisitos de Negócio: Nesta etapa os requisitos funcionais e não-
funcionais devem ser coletados a partir de entrevistas com analistas de negócio, gestores,
executivos e membros da área de TI. A partir da coleta, análise e especificação dos re-
quisitos existem três grupos de atividades que podem ser executados em paralelo. Estes
grupos correspondem exatamente à trilha da tecnologia, trilha dos dados e trilha das apli-
cações de BI.

34. 33
3. Trilha da Tecnologia: Consiste na sequência de passos necessários a implantação da
infra-estrutura técnica. Assim, o desenho técnico do ambiente precisa ser projetado, fer-
ramentas e utilitários devem ser definidos e tudo precisa ser devidamente configurado e
testado (CARVALHO, 2009). Engloba as seguintes atividades:
• Projeto da Arquitetura Técnica: Todo o conjunto de tecnologias que serão necessárias
quando o DW estiver em produção e em uso devem ser definidas, incluindo, por
exemplo, as ferramentas, os utilitários e as plataformas necessárias para que o fluxo
dos dados ocorra (CARVALHO, 2009).
• Escolha e Configuração de Ferramentas: Subdivide-se em dois eixos principais:
A criação do plano de arquitetura, que tem como meta a efetiva implantação da
arquitetura de todo o ambiente e, a seleção 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 físico e
extração, transformação e carga no DW (ETL).
• Modelagem Dimensional: Promove a definição do modelo de dados (modelagem
dimensional) do DW;
• Projeto Físico: Esta atividade é executada após a modelagem dimensional sendo re-
alizada a partir dos seguintes passos: Definição de padrões de desenvolvimento para
os diversos componentes do sistema de DW e BI, desenvolver o modelo físico de
dados, instanciar a base relacional para a execução dos testes de ETL, desenvolver o
modelo inicial de indexação dos dados, definição das politicas de segurança, audito-
ria e criação da área de stagging2 , desenvolver a base OLAP, definição de agregações
e criação da base física.
• Projeto do ETL e Desenvolvimento: No trabalho de Kimball são descritos trinta e
quatro subsistemas que, juntos, definem as diversas frentes de trabalho em um am-
biente de desenvolvimento de ETL. Estes subsistemas se dividem em quatro subca-
tegorias, que são extração de dados, limpeza e padronização dos dados, entrega dos
dados para apresentação e gerenciamento do ambiente de ETL (CARVALHO, 2009).
2A área de stagging consiste numa área de armazenamento temporário dos dados antes que os mesmos sejam
carregados em um DM ou DW, servindo para a movimentação dos mesmos a partir de bases de dados diferentes
(COSTA; ANCIÃES, 2001).

35. 34
5. Trilha das Aplicações de BI: Podemos listar algumas categorias básicas de aplicações
de BI que vão desde acessos convencionais ad-hoc por consultas SQL até relatórios pré-
definidos e dashboards3 , capazes de apresentar uma visão global de desempenho dos
processos de negócio em uma interface unificada (CARVALHO, 2009). O desenvolvimento
destas aplicações são iniciadas logo após a especificação de requisitos, primeiro com a
compreensão dos relatórios mais utilizados pelos usuários e, em seguida, pelo desenho
dos primeiros relatórios e aplicações que serão desenvolvidos (CARVALHO, 2009). A
Trilha das Aplicações de BI compreende as seguintes atividades:
• Projeto de Aplicações de BI: Com a ajuda do pessoal de negócio os desenvolvedores
devem listar os principais relatórios que possam ser fornecidos pela aplicação de BI
e que tragam valor ao negócio de modo que os modelos para estes relatórios possam
ser criados e documentados.
• Desenvolvimento da Aplicação de BI: A partir da especificação dos relatórios, os
mesmos podem ser implementados pela equipe de desenvolvimento.
6. Integração e Implantação: Na atividade de integração todos os sistemas desenvolvidos
são colocados no mesmo ambiente para a execução de testes globais. São realizados testes
de qualidade de dados, testes das operações do processo, testes de desempenho, testes de
implantação, testes de acessibilidade de usuários. Após a realização da bateria de testes
pode se realizar a implantação do que foi desenvolvido na iteração.
7. Manutenção: 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 solicitações
de desenvolvimento podem ser avaliadas e deve-se oferecer suporte especializado aos
utilizadores do sistema.
8. Crescimento: Após a entrada em produção e a montagem da estrutura de manutenção e
suporte, a expansão do DW é o primeiro grande desafio que o gerente do projeto enfrenta.
É natural que a versão que acaba de entrar em produção contemple bem alguma área,
que logo pedirá novos relatórios, enquanto outras áreas são menos atendidas e solicitam
novos desenvolvimentos (CARVALHO, 2009).
9. Gerenciamento do Projeto: Suas atividades estão relacionadas com todo o processo de
engenharia de DW. Dentre as atividades de gerenciamento durante o desenvolvimento do
projeto estão a condução das reuniões de equipes, o sincronismo entre todas as frentes
3 Painelcom um conjunto de indicadores gráficos que, por estar num formato visual, facilita a compreensão e
assimilação das informações. Geralmente estes indicadores gráficos são integrados entre si (ALMEIDA, 2010).

36. 35
de desenvolvimento e monitoração das atividades com frequente acompanhamento do
cronograma geral.
2.4 METODOLOGIAS ÁGEIS
As metodologias ágeis surgem como uma resposta às crescentes pressões por inovação
em prazos cada vez mais reduzidos, às necessidades de constantes mudanças 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 métodos ágeis. Posteriormente, o conceito chave deste movimento evoluiu, de uma
abordagem técnica para o âmbito gerencial, criando um novo enfoque de gerenciamento de
projetos que pode ser denominado de Gerenciamento Ágil de Projetos (DIAS, 2005).
Os métodos ágeis de desenvolvimento de software surgiram como uma reação aos métodos
clássicos de desenvolvimento e do reconhecimento da necessidade preeminente de se criar uma
alternativa a estes "processos pesados", caracterizados pelo foco excessivo na criação de uma
documentação 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 represen-
tando as metodologias SCRUM, XP e outras, estabeleceram princípios comuns compartilhados
por todos esses métodos. Foi então constituído o "Manifesto Ágil". O termo "Metodologias
Ágeis"torna-se então popular através do estabelecimento do manifesto (BECK et al., 2001). Os
conceitos chave do "Manifesto Ágil"são:
• Indivíduos e interações sobre processos e ferramentas;
• Software executável sobre documentação;
• Colaboração do cliente sobre negociação de contratos;
• Respostas rápidas a mudanças sobre seguir planos.
Traçando um comparativo com os chamados métodos clássicos de desenvolvimento de
software, podemos observar que os métodos ágeis priorizam os itens situados a esquerda na
declaração deste manifesto. Isto não significa que os itens a direita sejam desprezados. A
grande diferença é quanto ao foco e a importância que estes itens recebem em contraposição
aos métodos clássicos de desenvolvimento de software.

37. 36
Muitos especialistas criaram métodos próprios para se adaptar às constantes mudanças
exigidas pelo mercado e as indefinições de requisitos iniciais dos projetos. A família dos méto-
dos ágeis de desenvolvimento de software tem origem no agrupamento de todos estes métodos,
como por exemplo o SCRUM, o XP e o FDD (DIAS, 2005). Os métodos SCRUM, FDD e XP
serão detalhados nas subseções seguintes.
2.4.1 SCRUM
SCRUM é um framework ágil para gestão e planejamento de projetos de desenvolvimento
de software (SCHWABER, 2004). Foi desenvolvido por Ken Schwaber e Mike Beedle na década
de 1990, baseando-se em experiências no desenvolvimento de sistemas e processos, a partir do
reconhecimento de que o desenvolvimento de software é muito complexo para ser planejado
corretamente desde o início. Por ser um framework, SCRUM servirá como um guia de boas
práticas para atingir o sucesso. Entretanto, as decisões de quando e como usá-lo, quais táticas
e estratégias seguir para obter produtividade e realizar as entregas ficam por conta de quem o
estiver aplicando. O conhecimento das suas práticas permite a aplicação 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 três fases principais, divididas em sub-fases:
pré-planejamento, desenvolvimento e pós-planejamento (SCWABER; BEEDLE, 2002).
• Pré-Planejamento: Nesta fase é definida a visão do produto e as expectativas dos stake-
holders. Os requisitos dos clientes são coletados e priorizados para o planejamento dos
trabalhos. Devem ser garantidos o financiamento/orçamento para a realização do projeto
e os riscos associados ao projeto devem ser identificados;
• Desenvolvimento: Nesta fase são executadas atividades de refinamento de requisitos,
análise, projeto, desenvolvimento e testes, devendo resultar em um incremento funcional
do produto que está sendo desenvolvido.
• Pós-Planejamento: O ciclo de desenvolvimento é encerrado e avaliado. Realizada a
demonstração e a liberação do incremento de produto ao cliente o time de trabalho deve
refletir sobre as práticas empregadas, os indicadores finais e o aprendizado geral da
equipe.

38. 37
Figura 9: Visão Geral do Processo SCRUM (MARÇAL, 2009).
A Figura 9, mostra como funciona o ciclo completo do SCRUM.
Este ciclo tem o seu progresso baseado em uma série de iterações bem definidas, cada uma
com duração de 2 a 4 semanas, chamadas sprints. Antes de cada sprint, realiza-se uma reunião
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
próxima fase é a execução da sprint onde o time controla o andamento do desenvolvimento
realizando reuniões diárias (daily meeting), não mais que 15 minutos de duração onde todos
os participantes devem estar prioritariamente de pé, e observando o seu progresso usando um
gráfico chamado sprint burndown.
Ao final de cada sprint, é feita uma revisão no produto entregue para verificar se tudo
realmente foi implementado. Realiza-se então uma reunião de revisão (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 reunião de retrospectiva (sprint retrospective), uma reunião de lições
aprendidas, com a finalidade de melhorar o processo, ou o time e/ou produto para a próxima
sprint (PORTELA, 2009).

39. 38
2.4.1.2 ARTEFATOS
Em (SCHWABER, 2004), os seguintes artefatos estão definidos para o SCRUM ao longo do
seu fluxo de desenvolvimento: Product Backlog, Sprint Backlog e incremento de funcionalidade
do produto (MARÇAL, 2009).
• Product Backlog: Contém uma lista de itens priorizados que incluem os requisitos fun-
cionais e não funcionais do sistema que está sendo desenvolvido no projeto. O product
backlog nunca está completo e evolui de acordo com a evolução do produto e do ambiente
ao qual está inserido;
• Sprint Backlog: Corresponde a lista de tarefas que o time do projeto define para imple-
mentar 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 códigos
testados, bem estruturados e bem escritos, que são executáveis acompanhados da docu-
mentação necessária para a sua operação.
2.4.1.3 PAPÉIS
(SCHWABER, 2004) define que as atividades no framework SCRUM são realizadas por três
pápeis: Product Owner, Scrum Master e Time (CAVALCANTI, 2009) (MARÇAL, 2009).
• Product Owner: Define as funcionalidades do produto, os itens do product backlog, o
valor de negócio 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, alguém de marketing
e que deve estar disponível durante todo o projeto;
• Scrum Master: Assegura que as práticas do SCRUM estão sendo executadas, remove os
impedimentos levantados pelo time, protege o time de interferências externas, garante a
colaboração entre os diversos papéis e funções;
• Time: Estima e desenvolve as funcionalidades do produto; define como transformar
o product backlog em incremento de funcionalidades numa iteração gerenciando seu
próprio trabalho, sendo responsáveis coletivamente pelo sucesso da iteração e, conse-
qüentemente, pelo projeto como um todo.

40. 39
2.4.1.4 MEDIÇÃO DE PROGRESSO
No SCRUM, o monitoramento do progresso do projeto é realizado por meio de dois gráficos
principais: Consumo do Produto (Product Burndown) e Consumo da Sprint (Sprint Backlog).
Estes gráficos mostram ao longo do tempo a correlação 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 gráfico é iniciado com o total de story points estimado para o
projeto e a cada sprint são exibidos a quantidade ainda existente de story points. Deste
modo ao compararmos as barras do gráfico podemos saber o quanto de story points foram
consumidas a cada iteração 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 gráfico inicia com o total de horas estimado para a
sprint. A cada dia de trabalho deve ser marcado no gráfico a quantidade de horas ainda
restante. Deste modo, fazendo a comparação entre dois dias no gráfico pode se saber a
quantidade de horas consumidas.
2.4.2 FDD
FDD se baseia em processos bem definidos que podem ser repetidos. Além disso, sua
abordagem é concentrada nas fases de projeto e construção tendo uma alta ênfase na modelagem

41. 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 básicos utilizados é o conceito de features (funcionalidades). Segundo
(PALMER; FELSING, 2002) o termo feature em FDD é muito específico correspondendo a uma
função de tamanho pequeno que represente algum tipo de valor para o cliente. Podem ser
representadas a partir do seguinte template: <ação><resultado><objeto> com o uso de uma
preposição apropriada entre a ação, 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 não pode ultrapassar o tamanho definido para as iterações 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 (Concepção/Planejamento e Construção) 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. Concepção e Planejamento: Os processos realizados na fase de Concepção e Planeja-
mento abrangem todo o projeto e são realizados apenas uma vez.
• Desenvolver um Modelo Abrangente (DMA) - Análise Orientada por Objetos:
É realizado um estudo dirigido sobre o escopo do sistema e seu contexto, além de
estudos detalhados sobre o domínio de negócio para cada área a ser modelada. O
objetivo geral é a elaboração de um modelo abrangente do sistema. Isto é realizado
por sessões de modelagem de parte do domínio em grupos. O modelo abrangente é

42. 41
Figura 12: Ciclo de vida de um projeto com o FDD (HEPTAGON, 2010).
construído e tem seu conteúdo atualizado iterativamente pela integração dos mode-
los criados pelos grupos de modelagem;
• Construir a Lista de Funcionalidades (CLF) - Decomposição Funcional: Deve-
rão ser identificadas as funcionalidades que satisfaçam os requisitos. O domínio é
decomposto funcionalmente em áreas de negócio, atividades de negócio dentro das
áreas mapeadas e funcionalidades dentro das atividades de negócio 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 serão implementadas, baseada nas dependências entre elas, na
carga de trabalho da equipe de desenvolvimento e também na complexidade das
funcionalidades a serem implementadas.
2. Construção: Os processos realizados na fase de Construção são realizados uma vez para
cada funcionalidade existente.
• Detalhar por Funcionalidade (DPF) - Desenho (Projeto) Orientado por Objeto:
Um conjunto de funcionalidades são agendadas para o desenvolvimento ao serem
atribuídas a um programador líder. O programador-líder pode então formar uma
equipe de funcionalidades identificando quais serão os proprietários das classes (de-
senvolvedores). Esta equipe deverá produzir os diagramas de sequência para a(s)
funcionalidade(s) atribuída(s). De posse desses diagramas o programador-lider re-

43. 42
aliza o refinamento do modelo de objetos. Os programadores então escrevem os
prefácios das classes e métodos e realiza-se uma inspeção no projeto (design);
• Construir por Funcionalidade (CPF) - Programação e Teste Orientados por
Objetos: Seu objetivo é produzir uma função com valor para o cliente (funcio-
nalidade). Iniciando com o pacote de projeto (design), os proprietários de classes
implementam os itens necessários para que suas classes suportem o projeto para esta
funcionalidade. O código desenvolvido passa pelo teste de unidade e pela inspeção
em uma ordem determinada pelo programador-líder. Após passar pela inspeção, o
código é promovido a versão atual (build).
2.4.2.2 PAPÉIS
FDD admite os seguintes principais pápeis dentro de um projeto:
• Gerente do projeto: Responsável por todos os assuntos administrativos ligados ao pro-
jeto. Sua principal função é oferecer subsídios para que nenhum fator externo interfira na
produtividade da equipe;
• Especialista do negócio: Deve usar o conhecimento a respeito do negócio 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. Além disso, está disponível 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: Responsável por liderar o dia a dia do desenvolvimento
do produto. Todos os conflitos técnicos entre os programadores-chefes estão sob sua
responsabilidade;
• Programador-chefe: Responsável por liderar pequenos grupos de desenvolvedores du-
rante a construção das funcionalidades. Pode atuar como desenvolvedor sendo o respon-
sável pelas classes mais complexas do sistema. Possui papel fundamental nas atividades
de absorção do conhecimento do negócio e no planejamento das atividades;
• Programador (Class Owner): Compõem as equipes de funcionalidades e realizam ativi-
dades de programação, criação de diagramas, testes e documentação de funcionalidades.

44. 43
Para projetos maiores ou complexos, FDD fornece um conjunto maior de papéis, como por
exemplo: Gerente de release, testadores, escritores técnicos, guru da linguagem, administrador
de sistemas, implantadores dentre outros.
2.4.3 XP
O XP é um método ágil para pequenas e médias equipes desenvolverem software, em am-
bientes com requisitos instáveis (DIAS, 2005). Suas práticas fundamentais tiveram origem nas
tradições do desenvolvimento em Smalltalk e datam de meados da década de 80, quando Kent
Beck e Ward Cunningham trabalhavam na Tektronixs, Inc. Práticas, tais como, refatoração,
programação em par, mudanças rápidas, feedback constante do cliente, desenvolvimento itera-
tivo, testes automatizados, entre outras, são pontos chave da cultura da comunidade Smalltalk.
XP então pode ser considerado como o modo de agir do Smalltalk generalizado para outros
ambientes (TELES, 2005). As práticas principais do XP estão descritas abaixo: (DIAS, 2005)
(PORTELA, 2009)
• Planing poker (jogo do planejamento): No jogo do planejamento são realizadas as esti-
mativas para as estórias de usuário. Tarefas são definidas para cada estória e estimadas a
fim de que se possa alocar um conjunto de estórias para a realização da iteração de acordo
com a capacidade da equipe;
• Pair programming (Programação em par): Todo código implementado deve ser feito
em pares;
• Pequenas versões: As versões do produto devem ser tão pequenas quanto possivel e
trazerem valor para o negócio. Uma versão inicial do software deve ser colocada em
produção após um pequeno número de iterações e, em seguida, outras versões devem ser
disponibilizadas tão logo faça sentido;
• Metáforas: A modelagem do sistema é realizada a partir de metáforas criadas pelos
clientes, gerentes e programadores;
• Projeto simples: Os programadores são estimulados a desenvolver o código da aplicação
o mais simples possível;
• Testes: Os programadores antes mesmo do desenvolvimento do código do sistema devem
criar os testes de unidade e rodá-los. Isso vale para todo o código implementado. Deste
modo todo o desenvolvimento do código é acompanhando de testes para cada módulo,

45. 44
para cada função implementada. Os testes de aceitação são escritos pelos clientes e são
usualmente rodados no final de cada iteração;
• Reengenharia de software: O código deve ser constantemente melhorado, sem que a
funcionalidade do sistema seja alterada;
• Integração contínua: Os programadores devem integrar os novos códigos ao software
tão rapidamente e com a maior freqüência possível;
• Propriedade coletiva do código: O código do programa deve ser propriedade de toda a
equipe e qualquer integrante pode fazer alterações sempre que for necessário;
• Cliente no local: O cliente deve trabalhar com a equipe de projeto a todo momento,
respondendo perguntas, realizando testes de aceitação e assegurando que o desenvolvi-
mento do software esteja sendo feito a seu contento;
• Semana de 40 horas: Como trabalhar por longos períodos reduz o desempenho, o con-
teúdo de cada iteração deve ser planejado de forma a não haver necessidade de realização
de horas extras;
• Padrão de codificação: No início do projeto deve ser criado um padrão de codificação,
simples e aceito por toda a equipe, que deverá ser seguido de forma a padronizar e auxiliar
na condução 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
são as iterações. Uma release é composta portanto de diversas iterações. 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
serão implementados. Temas são visões mais gerais das funcionalidades do que as estórias de
usuários. Ao final de um ciclo trimestral, a equipe também deve refletir sobre quais foram as
dificuldades durante o andamento do ciclo e propor soluções. No ciclo semanal os desenvolve-
dores reunem-se com o cliente com o propósito de entrarem em um acordo sobre o que deverá
ser implementado naquela semana. Para isso, é utilizada a dinâmica do jogo do planejamento
(GUIMARÃES, 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

46. 45
Figura 13: Ciclo Semanal em XP.
(GUIMARÃES, 2009). Inicialmente os clientes escrevem as estórias em cartões. Estas estórias
descrevem as funcionalidade desejadas e são denominadas Estórias de Usuário e são o instru-
mento de trabalho para as estimativas. Para iniciar o processo de estimativa a equipe de de-
senvolvimento deve determinar a unidade de tempo que será utilizada para estimar os cartões
podendo ser qualquer medida (horas, minutos ou dias), desde que todos da equipe tenham cons-
ciência de qual medida será utilizada durante o jogo.
Cada membro deverá ter em mãos 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 estória escrita pelo usuário. Cada membro da equipe deverá pensar quanto
tempo ele gastaria para desenvolver sozinho aquela funcionalidade sem nenhum tipo de inter-
rupção. Após todos terem concluído sua estimativa as informações serão compartilhadas. Para
informar ao restante da equipe qual a sua estimativa, o membro deverá escolher uma carta, den-
tre as do seu conjunto, que contenha o valor da sua estimativa. Quando o líder da equipe der a
ordem, todos devem mostrar sua estimativa ao mesmo tempo (GUIMARÃES, 2009).
Havendo divergências o membro que estimou o maior tempo e o membro que estimou o
menor tempo deverão confrontar as suas opiniões. Depois da estimativa das estórias, o cliente
deve escolher quais estórias são prioritárias para o seu negócio. A quantidade de estórias se-
lecionadas não deve ultrapassar o limite de horas de trabalho daquela semana. Com isso os
desenvolvedores dividem as estórias em tarefas e as implementam. No final do ciclo os desen-
volvedores demonstram o que foi feito e o cliente aprova ou não o trabalho resultante. Além
disso é realizada um retrospectiva para avaliar o trabalho realizado durante o ciclo semanal

47. 46
(GUIMARÃES, 2009).
2.4.3.2 PAPÉIS
XP não mantém uma estrutura rigída de pápeis. O principal objetivo é fazer com que todos
contribuam de acordo com suas habilidades nas etapas do projeto (GUIMARÃES, 2009).
• Testadores: Auxiliam os clientes e programadores na elaboração dos testes que devem
ser feitos para garantir que o software está correto;
• Designers de interação: Ajudam os clientes nas definições das estórias e auxiliam na
criação e refinamento da interface;
• Arquitetos: Auxiliam os programadores, estimulam a refatoração do código. Realizam
testes mais amplos que envolvam toda a arquitetura;
• Gerentes de Projeto: É um facilitador na comunicação entre a equipe de desenvolvi-
mento, clientes e demais fornecedores. Deve também gerenciar o progresso da equipe,
motivando-os sempre que necessário;
• Gerentes de Produto: Auxiliam na definição de estórias e temas além de serem respon-
sáveis por reduzir o escopo da iteração quando sentir atraso na equipe;
• Executivos: Representam os usuários do sistema e ajudam na definição do escopo e ob-
jetivos do projeto. Têm a responsabilidade de definir as prioridades de desenvolvimento,
informando as estórias que mais trazem retorno para a organização;
• Redatores técnicos: Responsáveis por criar e manter a documentação do projeto que,
assim como o código, evolui de maneira iterativa;
• Usuários: Dão feedback sobre o que está sendo desenvolvido, ajudam na escolha das
estórias uma vez que conhecem o domínio e quais funcionalidades devem ser implemen-
tadas primeiro;
• Programadores: Deverão estimar as estórias e depois implementá-las. São os respon-
sáveis por escrever testes para todo o código desenvolvido, além de refatorá-lo sempre
que necessário.

48. 47
2.5 CONSIDERAÇÕES FINAIS
Neste capítulo foram detalhados os principais conceitos que possibilitam a compreensão
da proposta deste trabalho. As metodologias ágeis utilizadas na composição do FDWS foram
descritas de modo que possa-se perceber quais práticas e como cada uma delas relaciona-se
com a proposta deste trabalho.
Além dos métodos ágeis, foram detalhadas metodologias para gerência e desenvolvimento
de projetos de BI que envolvem Data Warehousing.
No próximo capítulo será feita a análise dos trabalhos relacionados a essa proposta de modo
que as principais contribuições deste trabalho possam ser evidenciadas.

49. 48
3 AVALIAÇÃO DE TRABALHOS
RELACIONADOS
Neste capítulo são discutidos os trabalhos relacionados a proposta dessa monografia de
modo que ao final possa-se estabelecer parâmetros de comparação 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 gerência e o desenvolvimento de projetos de Data Warehousing. O
ciclo de desenvolvimento definido pelo Agile Data Warehousing e sua integração com o ciclo
do SCRUM é ilustrado na Figura 14.
Figura 14: Ciclo de Desenvolvimento Agile Data Warehousing. Adaptado de (HUGHES, 2007).