Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
INSTITUTO DE MATEMTICA
DEPARTAMENTO DE CINCIA DA COMPUTAO
Salvador - Bahia
2010-2
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,
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
22
22
25
26
27
28
31
32
37
10
11
39
40
12
41
13
45
14
15
48
52
16
53
17
FDWS - Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
18
65
19
67
20
67
21
68
22
74
23
75
24
FDWS - Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
25
FDWS - Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
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
BI
BPD
BPMI
BPMN
CIOs
CLF
CPD-UFBA
CPF
DCC-UFBA
DM
Data Mart, 24
DMA
DMs
Data Marts, 21
DPF
DW
Data Warehouse, 17
ETC
ETL
FBS
FDD
OLAP
PPF
TI
Tecnologia da Informao, 17
WBS
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
30
2.3.2
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
48
3.1
48
3.2
Extreme Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.2.1
Planejamento do Processo . . . . . . . . . . . . . . . . . . . . . . . .
50
3.3
51
3.4
Agile BI - Pentaho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.5
53
3.6
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
70
4.3.1.3
71
4.3.1.4
Plano de Projeto . . . . . . . . . . . . . . . . . . . . . . . .
72
4.3.1.5
72
Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.3.2.1
75
4.3.2.2
76
4.3.2.3
77
4.3.2.4
77
4.3.2.5
78
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.3.3.1
4.3.3.2
Configurao de Ferramentas . . . . . . . . . . . . . . . . .
78
4.3.3.3
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
82
83
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
85
4.4.1
Papis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.4.2
Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
4.4.3
88
4.3.4
4.4
4.3.1.2
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
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.1.4
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
93
5.2.1
Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.2.2
Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.2.3
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.2.4
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.3.1
Execuo da Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.3.2
97
5.2
5.3
Concluso
99
6.1
Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2
6.3
Referncias
103
107
114
B.1.2
B.1.3
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.1.4
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.2.2
B.2.3
Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.4
Ps-Iterao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
123
126
129
E.2.2
E.2.1.2
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
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).
22
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
2.2.3
MODELAGEM MULTIDIMENSIONAL
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).
27
2.2.4
OLAP
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
2.3
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
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
2.3.2
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.
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:
33
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
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
2.4.1
SCRUM
CICLO DE VIDA
37
38
2.4.1.2
ARTEFATOS
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
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
41
42
PAPIS
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
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
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
48
AVALIAO DE TRABALHOS
RELACIONADOS
3.1
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
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
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
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
3.5
2010b).
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
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
3.7
CONSIDERAES FINAIS
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.
60
4.1
CARACTERSTICAS
61
4.2
PAPIS
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
4.2.3
NCLEO DE DESENVOLVIMENTO
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
65
66
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
68
69
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
71
4.3.1.3
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
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
74
75
76
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
78
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 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
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.
79
80
4.3.3.4
DETALHAR FUNCIONALIDADES
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
82
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
referentes a este subprocesso so detalhadas na lista a seguir:
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
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
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
84
85
4.4
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
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
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
PLANEJAMENTO DO PROJETO
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
5.1.2
PLANEJAMENTO DA RELEASE
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
5.1.4
PS-ITERAO
93
5.2
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
PLANEJAMENTO DO PROJETO
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
PLANEJAMENTO DA RELEASE
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
5.2.4
PS-ITERAO
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
97
5.3.2
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
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
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
105
106
107
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
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.3
ENTREGA
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.
A.4
OPERAO
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:
A.5
AJUSTES/MELHORIAS
114
B.1
B.1.1
PLANEJAMENTO DO PROJETO
B.1.2
PLANEJAMENTO DA RELEASE
B.1.3
ITERAO
B.1.4
PS-ITERAO
115
No
No
No
Solues de BI
Avaliar Motivao
No
Definir Patrocinadores
No
Sim
Sim
No
Sim
No
No
Sim
No
No
Anlise de Ferramentas
No
Avaliao
No
Seleo
No
Prototipagem
No
No
Plano de Projeto
Critrios de Sucesso
No
Benefcios
No
No
Objetivos
Sim
Membros do Projeto
Sim
Sim
Definir Tamanho
Sim
Definir Treinadores
Sim
Sim
116
Sim
No
No
No
No
No
No
No
No
No
Sim
Sim
Sim
No
Sim
Sim
No
117
No
No
No
Detalhar Funcionalidades
No
Sim
Sim
No
Projeto Fsico
rea de Staging
Sim
DW
Sim
Sim
Projeto de Metadados
Definio do Metamodelo
Sim
Sim
Teste e Validao
Sim
Projeto de ETL
Sim
Sim
Sim
Projeto da Aplicao de BI
Sim
Implementao e Integrao
Sim
Sim
Teste de Qualidade
Sim
Sim
Teste de Desempenho
No
Testes de Implantao
Sim
No
Teste de Aceitao
No
No
118
Sim
No
No
Avaliao da Iterao
Sim
B.2
B.2.1
PLANEJAMENTO DO PROJETO
B.2.2
PLANEJAMENTO DA RELEASE
B.2.3
ITERAO
B.2.4
PS-ITERAO
119
Sim
No
No
Solues de BI
Avaliar Motivao
Sim
Definir Patrocinadores
No
Sim
Sim
No
Sim
Sim
No
Sim
No
No
Anlise de Ferramentas
Sim
Avaliao
Sim
Seleo
Sim
Prototipagem
No
No
Plano de Projeto
Critrios de Sucesso
No
Benefcios
No
No
Objetivos
Sim
Membros do Projeto
Sim
Sim
Definir Tamanho
Sim
Definir Treinadores
Sim
Sim
120
Sim
No
No
No
No
Sim
No
Sim
No
No
Sim
Sim
No
No
Sim
Sim
No
121
No
No
No
Detalhar Funcionalidades
Sim
Sim
Sim
No
Projeto Fsico
rea de Staging
Sim
DW
Sim
Sim
Projeto de Metadados
Definio do Metamodelo
Sim
Sim
Teste e Validao
Sim
Projeto de ETL
Sim
Sim
Sim
Projeto da Aplicao de BI
Sim
Implementao e Integrao
Sim
Sim
Teste de Qualidade
No
No
Teste de Desempenho
No
Testes de Implantao
No
No
Teste de Aceitao
No
No
122
Sim
No
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
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
127
128
129
APNDICE E -- ESPECIFICAO E
MODELAGEM DA
METODOLOGIA FDWS
E.1
130
131
132
133
E.2
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
A descrio da notao BPMN contida nesta seo foi retirada da Dissertao de Mestrado
do Rogrio Tessari (TESSARI, 2008).
E.2.1.1
134
135
E.2.1.2
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 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).
E.2.2
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
140
Figura 55: FDWS - Planejamento do Projeto: Projeto de Arquitetura Tcnica - Anlise de Ferramentas
143
144
145
146
147
148
149
150
151
155