Escolar Documentos
Profissional Documentos
Cultura Documentos
ABSTRACT:
Marcelo Gomes Marques, MBA em Gesto Integrada de Negcios e e-Business pela Universidade
Federal do Rio de Janeiro mgm2000@terra.com.br
2
Arnaldo Lyrio Barreto Barreto, Universidade Federal do Rio de Janeiro, Doutor em Epistemologia pelo
programa HCTE, Cidade Universitria Ilha do Fundo Centro de Tecnologia, Bloco A, 7 andar C.P.
68563, CEP 21.945- 970, Rio de Janeiro, RJ, Brasil, arnaldo.barreto@ufrj.br.
INTRODUO:
A abordagem de mtodos geis so muito
aplicadas
com
sucesso
no
desenvolvimento
de
software,
j
comprovada como uma alternativa vivel
aos mtodos tradicionais. Contudo, para a
sua adequada aplicao em projetos de BI
(Business Intelligence) necessria a
adaptao de um conjunto de prticas,
valores e princpios geis utilizados na
construo de software,
dada a sua
complexidade e caractersticas que tratam
de todo o processo de coleta, organizao,
anlise,
compartilhamento
e
monitoramento de informaes, atravs de
um conjunto de aplicaes e tecnologias
que oferecem suporte gesto de
negcios.
Segundo Hughes (2011), a construo de
uma soluo de BI corporativa trata-se de
um projeto bastante complexo, visto a sua
abrangncia
e
caracterstica
multidisciplinares,
envolvendo
muitas
tecnologias e pessoal, de diferentes nveis
e reas da organizao, traduzindo-se em
um grande esforo conjunto para construir
esperada viso nica para a tomada de
deciso.
Alm disso, Camargo (2007) afirma que
mudanas fazem parte do processo
evolutivo, sobretudo no mbito competitivo
do ambiente de negcios atual, onde
emergem cada vez mais rapidamente
novas estratgias,
e por conseguinte,
novos requisitos, sobretudo com foco em
inovao,
tratamento de ameaas e
oportunidades oriundas de fatores externos
em constante mudana.
No contexto do BI, para Hughes (2012), o
processo tradicional de construo de
solues falha ao buscar atender a esta
demanda, sobretudo quanto h tendncia
atual de se perceber projetos de trs (3)
meses como muito longos. Soma-se a isso
o fato de ser comum a contratao do
projeto sob o modelo de preo fixo,
tendendo ao escopo fechado.
Alm disso, segundo Collier (2011), a
abordagem de projetos de BI atravs de
mtodos tradicionais conduz a um aumento
dos seguintes riscos do projeto:
FUNDAMENTAO TERICA:
Hughes (2012) afirma que o mtodo em
cascata, assim como outras metodologias
pr-descritivas,
tambm conhecidas por
ciclo de vida clssico,
BIG BANG,
plan-driven, single-pass, Big Design Up
Front (BDUF) e abordagem de entrega
nica,
so intuitivas e de fcil
gerenciamento, mas apresentam diversos
problemas decorrentes de sua estrutura,
que prope um desenvolvimento em fases
sequenciais,
com uma fase inicial de
levantamento e detalhamento exaustiva de
requisitos,
posteriormente um longo
perodo de desenvolvimento sem a
arquitetura,
por ele denominada Bus
Architecture, estabelecendo com isso uma
viso nica da empresa.
Segundo Corr et all (2011), dimenses
conformes tratam-se de componentes
fundamentais e reutilizveis da modelagem
dimensional,
viabilizando
anlises
cruzadas entre fatos e comparaes de
medidas de mltiplos processos de
negcios. Para isso, Corr et all (2011)
recomendam a adoo da DW Bus
Architecture de Kimball (2002), por esta
suportar o desenvolvimento incremental e
realmente gil de DM integrados.
Para Corr et all (2011, p.99), tambm
importante atentar para a conformidade de
medidas e indicadores de performance,
garantindo que mtricas relacionas, ou
mesmo redundantes em outras fatos
apresente os mesmos conceitos e tenham
unidades de medidas comuns ou
compatibilizadas.
Contudo, Hughes (2012) afirma que este,
e outros mtodos que prope um processo
iterativo, no na prtica uma proposta
gil, mas sim uma resposta natural, aps
o volumoso insucesso de projetos de
software
conduzidos
sob
mtodos
tradicionais,
sobretudo
nos
que
apresentam um escopo muito grande.
Segundo Hughes (2012),
neste caso o
mtodo continuam exigindo todo o conjunto
de burocracias de um grande projeto de
software tradicional, porm conduzido de
acordo com um cascateamento de
iteraes focadas no detalhamento mximo
dos requisitos. Essa a limitao pode
ainda ser observada na proposta de
Kimball et all (2008), pois, para ele, o DM
deve ser inteiramente desenvolvido, antes
que um novo ciclo se inicie.
De acordo com Corr et all (2011) e Hughes
(2012),
qualquer evoluo requer
adaptao, e esse elemento alcanado
atravs da contnua maturao de
funcionalidades inicialmente simples que,
de forma incremental e ao longo das
iteraes,
adquirem um nvel de
complexidade mais elevado.
Para Collier (2011), o mtodo incremental
baseia-se na entrega de funcionalidades
parciais aos usurios, a cada iterao.
Hughes (2012), destaca que sobre este
mtodo fcil observar que cada etapa
subsequente depender intrinsecamente
das fases anteriores,
ou seja,
a
implementao se baseia completamente
no que j foi desenvolvido. Da surge
Tendem
a
almejar
o
desenvolvimento
ao
nvel
organizacional, ou com elevada
amplitude de funes, o que
aumenta a complexidade e dificulta
a determinao correta do escopo;
Com
o
ganho
de
melhor
entendimento
por
parte
dos
usurios,
seus desejos
ou
necessidades mudam;
5
o Extrapolam custos e prazos
o Apresentam funcionalidades
esperadas que no foram
implementadas
o Deixam usurios insatisfeitos
o Possuem
performance,
disponibilidade
ou
escalabilidade inaceitveis
o Exibem dados sem valor (so
pobres aos olhos do usurio).
Dadas estas caractersticas, para Collier
(2011), abordar um projeto de BI atravs
dos mtodos em cascata leva a um
aumento no risco do projeto por diversas
razes:
Projeto
de
ETL
(Extraction,
Transformation and Loader), que
tratam dos processos automao
de extrao, transformao e carga
de uma origem de dados a outro
destino;
Desconexo entre
desenvolvedores;
Implantao.
usurios
Scrum Master:
responsvel por
assegurar que a equipe respeite e
siga os valores e as prticas do
Scrum.
Ele tambm protege a
equipe assegurando que ela no se
comprometa excessivamente com
relao quilo que capaz de
realizar durante uma iterao. Alm
disso, o Scrum Master atua como
facilitador do Daily Scrum e torna-se
responsvel por remover quaisquer
obstculos que sejam levantados
pela equipe durante essas reunies.
Dado as caractersticas de arquitetura e
complexidades de integrao inerentes aos
projetos de BI, Hughes (2012) subdivide
estes projetos em dois grandes grupos:
parte da manh,
para ajudar a
estabelecer as prioridades do novo
dia de trabalho. Durante a reunio
no se deve discutir detalhadamente
ou tratar da resoluo de problemas.
Os problemas levantados devem ser
tratados
aps
a
mesma,
normalmente por um grupo menor de
pessoas que
tenham a
ver
diretamente com o problema ou
possam contribuir para solucion-lo.
No segundo,
so delineadas
adaptaes mais profundas ao
Scrum,
que visam tratar as
demandas
que
requerem
integrao
de
dados
mais
complexas e ao logo das camadas.
10
Figura 2. Exigncias de adequao do mtodo X Complexidade de integrao de dado
11
Figura 3. Viso Geral da Proposta de Adaptao de Mtodos gil a Projetos de BI
Problemas Crticos
Especificaes 80/20
Rapidez na Inicializao
Test-Driven Development e
Teste Integrado Contnuo
Elevar Qualidade
Parceria com o Negocio
Integrada e Colaborativa
Falhar Rpido e
Corrigir Rapidamente
Revises do Cliente
Frequentes
1
Preciso das
Estimativas
Estimativas Baseadas
por Tamanho
Agilidade na
Percepo de Valor
Pacotes de Trabalho
Pequenos e Homogneos
Melhorar a Produtividade
dos Programadores
Burn-up Chart
Prazo de Liberao
Entregar
Constantemente e
Frequentemente
Melhoria Continua
Reduzir os Custos
de Desenvolvimento
Legenda:
Prtica gil
1
Objetivos
Problema Crtico
DW/BI
Muito
Caros
Conector
2 e
Demorados
Mtrica - KPI
Conector 3
Dificuldade
de definir
requisitos
antes de ter
visto algo
em produo
Entregar constantemente e
frequentemente;
Reduzir os custos de
desenvolvimento.
12
Qualidade da passagem
basto (Quality of hand-offs)
de
As
caractersticas
de
especializao
dos
recursos,
comuns aos
projetos de BI, que resulta
em uma conduo do
pipeline por
frentes de
trabalho;
O requisito de maior
velocidade
para
inicializao
do
desenvolvimento,
que
orienta a equipe a produzir
especificaes mais leves
e focadas em apenas 80%
dos
aspectos
mais
importantes
de
cada
modulo.
Distribuio
Histrias:
de
Pontos
de
13
Distribuio
Ciclos:
dos
Prazos
dos
Prazo de Liberao:
Burn-up Chart:
Grfico
de
barras
verticais
acumulativas que demostra o nmero
de pontos entregues por iterao, mais
o total de pontos de histrias de
desenvolvimento que ainda esto em
progresso na mesma iterao.
Arquiteto do Projeto:
fundamental,
sobretudo quando as equipes no
trabalham como esperado, o que
comum nas primeiras iterao de
projetos,
requerendo um liderana
mais forte do Arquiteto de Projetos, o
que tambm seria facilitado caso haja
uma formalizao de sua autoridade no
que diz respeito ao rumo do projeto ou
de todo o programa de BI, inclusive
sobre o Product Owner.
Modelador de Dados:
14
distintos,
porem complementares,
distribudos
em
camadas
de
arquiteturas com funes especificas
de
estagio,
integrao,
apresentao/dimensional, semntica
e consumo/ dashboards como descritos
em Hughes (2012, p.187).
Alm disso, ao detalhar o papel do
modelador de dados, Hughes (2012)
deixa claro que necessrio a atuao
de um especialista no ramo de
modelagem de DW, no apenas de
dados, visto a suas consideraes
quanto a correta definio de
granularidade e a necessidade deste
profissional estar atualizado em relao
ao emprego de novas e avanadas
tcnicas,
que
continuam em
desenvolvimento,
a exemplo da
abordagem hipernormalizada, como
as propostas sexta forma normal, data
vaulting e a modelagem por ncora.
Analistas de Sistemas:
Analistas de Testes:
programadores,
histrias de testes
junto ao Product Owner e testes
funcionais e no funcionais junto aos
demais membros da equipe residente
do projeto de BI gil. De fato, este
recurso acaba por ser o responsvel
pela padronizao dos testes e por
liderar a equipe a atender tais padres.
15
Configurao de ambientes
desenvolvimento (Sandboxes)
Testes
de
Leveza no desenvolvimento:
Neste caso,
deve-se modelar e
documentar apenas o suficiente para
que o desenvolvimento possa ocorrer.
Qualquer documentao que mantida
dentro do projeto deve sofrer
manuteno com o tempo,
pois
ocorrem mudanas no ambiente, o
qual estes artefatos representam.
Neste ponto, Ambler (2003) ressalta
que deve ser mantido um equilbrio
entre a perda de agilidade e a
vantagem de dispor de um modelo que
representada a informao de uma
maneira mais abstrata.
16
Crie mltiplos
necessrio:
modelos
quando
Simplicidade:
Neste ponto, Ambler (2003) apoia-se
na viso de simplicidade de Beck
(1999), onde ele afirma que, na
maioria das vezes, a soluo mais
simples funciona da melhor maneira,
devido a ela ser simples, de fcil
implementao.
Portanto
a
modelagem no deve sobrecarregar o
sistema
com
esquemas
de
complexidade elevada. Esse princpio
se traduz na prtica de modelar da
maneira mais simples os requisitos
existentes e refatorar o sistema no
futuro para acomodar os requisitos que
evoluram.
Certifique-se
da
qualidade
trabalho executado:
do
Collier (2011,
p.151) destaca,
Modelos de alta qualidade so
elegantes e ricos de informaes uteis,
no sendo aceitvel que sejam
incompletos,
inconsistentes
ou
desleixados.
compreensveis.
Ou seja,
na
modelagem deve ser respondida a
questo se para modelar para
entender ou modelar para comunicar
algo.
Modelagem Incremental:
17
vrios
propsitos
Colunas
inteligentes
podem
apresentar complexas regras de
decodificao para gerar valores com
significado;
Tabelas utilizadas para armazenar
tipos diferentes de entidades podem
significar vulnerabilidades no modelo
de dados;
Tabelas com nmero excessivo de
linhas, acarretando em problemas de
desempenho;
Tabelas com nmero excessivo de
colunas, faltando coeso, tornado a
tabela sem propsito definido e
armazena
dados
de
diversas
entidades.
Especificamente para o ambiente de
DW/BI, Collier (2011, p.163), acrescenta
os seguintes fatores que indicam a possvel
necessidade de refatorao de esquemas
de dados em produo:
Objetos de ETL complexos, com
muitos caminhos e complexos ns de
transformao, dificultando a sua
manuteno
e
identificao
de
problemas;
Longos mdulos de SQL, PL/SQL e
similares;
Dimenses no conformes gerando
sobreposio
de
informaes,
inconsistncias e redundncia;
Uso
indiscriminado
de
views
materializadas, pois podem ofuscar o
modelo do DW/BI, distanciando os
usurios do modelo implementado e
dificultando sua compreenso;
Solues de BI/DW que acesso
apenas diretamente as tabelas,
subutilizando materializadas views,
apresentam
grandes
riscos
de
fragilidades. A recomendao fazer
uso de uma seleo de views
materializadas de forma a balancear
performance, custos para mante-las
e flexibilidade de acesso as tabelas;
Excesso
de
confiana
na
documentao da soluo de BI, que
no so facilmente compreendidas
sem o suporte das mesmas.
18
Figura 4. Processo iterativo de refatorao
1. Confirmar a necessidade da refatorao
6. Migrar dados
Migrao
necessria?
necessidade
da
19
8. Executar todos
regressivas:
os
testes
de
20
Tabela 1. Descrio dos 7Ws
7Ws
Tipo de dado
Exemplo
Who (Quem)
Pessoas e Organizaes.
Empregados e Clientes.
What (O que)
Coisas.
When (Quando)
Tempo
Where (Onde)
Localizaes.
Endereos e estabelecimentos
Razes e causalidades.
Promoes e temporadas
How (Como)
Identificadores de transaes
e cdigo de status.
Medidas e indicadores de
performance
21
Figura 7. Dbito Tcnico Gerado por Silos de DMs
22
Diagrama
Tabela BEAM
Grfico de Hierarquia
Emprego
Modelagem dos eventos de negcio e suas dimenses de anlise,
uma por vez, fazendo uso de exemplos de dados que documentam
os seus detalhes atravs da exposio dos 7Ws.
Descoberta dos padres de hierarquias e sua relao com as
dimenses e atributos para a anlise dimensional.
Contribui tambm para a identificao de requisitos tcnicos para a
definio de percursos de anlise (drill) e nveis de agregao.
Linha do Tempo
Matriz de Eventos
Esquema em Estrela
Aprimorado
23
Eventos
que
j
foram
entregues
em
iteraes
anteriores recebem nota zero;
As
dimenses
devem
ser
ranqueadas com notas superiores
a nota de importncia do respectivo
evento relacionado;
Ao final,
obtm-se a priorizao dos
eventos em respectivas dimenses de
forma ordenada em um nico product
backlog.
Aps essa reunio, um product owner,
designado para a iterao priorizada, pode
ainda promover ajustes na mesma baseado
nos resultados dos data profiling e no
retorno das estimativas e da execuo das
atividades da equipe de desenvolvimento.
Corr et all (2011) ainda determinam que a
essa lista tambm deve ser acrescido a
lista de requerimentos de relatrios e
painis,
que devem tambm sofrer
priorizao. Essa priorizao pode vir a ser
conduzida pelo comit anterior ou apenas
pelo product owner responsvel pela
iterao devidamente priorizada pelo
processo anterior. De acordo com Corr et
all (2011, p.119),
a priorizao dos
requisitos de relatrios e paineis deve ser
atribuda
antes
do
incio
de
desenvolvimento,
para a qual so
concedidas notas decrementais a nota do
respectivo evento a ela associados, na
ordem de 5 ou 10 pontos de importncia.
Antes de conduzir o incio do planejamento
da interao priorizada, o autor indica a
necessidade de se proceder antes com
uma reviso minuciosa do modelo e da
matriz de eventos,
iniciando pela
identificao de suas origens de dados,
seguindo-se pela aplicao de tcnicas
geis de data profiling e confirmao dos
resultados com a adequao do modelo. O
24
Desenho:
Quando a iterao
dispuser do modelo dimensional,
novos prottipos de ETL podem
carregar o modelo de dados o mais
breve possvel,
permitindo a
25
26
27
28
tambm estabelecer o
Identificar e Monitorar
Tcnicos.
objetivo de
os Dbitos
29
CONCLUSO:
Em segundo lugar,
o processo de
desenvolvimento iterativo obriga uma
seleo constante das informaes e
funcionalidades prioritrias, o que ajuda a
minimizar o problema da equipe gastar
tempo e recursos em desenvolvimentos
que nunca,
ou raramente,
sero
utilizadas, como comumente acontecem
com as abordagens com base em BDUF.
Para isso, essencial o emprego das
tcnicas de modelagem gil e de
prototipao,
uma vez que estas
promovem a ruptura das barreiras entre os
profissionais de BI e stakeholders, que
passam a focar na elaborao colaborativa
de modelos de dados compreensveis e
compilveis, ao invs de documentos de
requerimentos, assim como em prottipos
de relatrios e paineis ao invs de
mockups.
Os pontos anteriores, quando somados
proposta de emprego das tcnicas geis de
data profiling,
permitem no somente
melhorar estimativas, mas acabam por
contribuir para a melhoria da qualidade da
soluo como um todo, visto que regras,
comportamentos e caractersticas dos
dados capturadas na formas de exemplos
podem ser conferidos diretamente contra
os dados reais das origens da futura
soluo.
Alm disso, a proposta colaborativa de
Corrr et all (2011) com o devido emprego
de seus diagramas e ateno a
conformidade de indicadores e dimenses,
contribuem para a captura dos requisitos
essenciais, ao passo que atendem ao
principio de Simplicidade: a arte de
30
31
Perda
do
conhecimento
desenvolvido no projeto;
Perda do prazo;
Estudo
e
catalogao
das
possveis categorias de dbitos
tcnicos especficos de BI, assim
como de suas tcnicas soluo.
32
BIBLIOGRAFIA:
Ambler,S ; Sadalage P. Refactoring
Databases :Evolutionary Database
Design. Boston, MA, Estados Unidos:
Addison-Wesley Professional, 2006.
33