UNIVERSIDADE FEDERAL DA BAHIA         INSTITUTO DE MATEMÁTICA   DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO         Mauricio Ces...
Mauricio Cesar Santos da PurificaçãoFDWS: Uma Metodologia para Gerência e  Desenvolvimento de Projetos Ágeis de         Bus...
AGRADECIMENTOS    Agradeço em primeiro lugar a Deus, pois sem ele nada do que foi feito poderia ter sidorealizado. Finaliz...
chefe e profissional, muito obrigado pelo exemplo de vida.    Falando de SIAC e CPD, tenho de citar muitas pessoas aqui, An...
RESUMO    Soluções de Business Intelligence (BI) são de grande importância para os gestores das em-presas e dos seus respo...
ABSTRACT     Business Intelligence(BI) solutions is a great importance for business managers and their ITmanagers due to t...
LISTA DE FIGURAS1    Arquitetura de BI - Visão Simplificada. Adaptado de (COSTA; ANCIÃES, 2001).             222    Visão G...
19   FBS Versão Original (VERSION-ONE, 2010). . . . . . . . . . . . . . . . . . . .      6720   FBS Adaptada ao FDWS. . . ...
44   Artefatos Básicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . . 13545   Elementos de Raia da BPMN (TES...
LISTA DE TABELAS2   Descrição das Etapas do Planejamento do Projeto Executadas no Projeto Per-    manecer DW-UFBA . . . . ...
LISTA DE ABREVIATURAS E SIGLAS    BI         Business Intelligence (Inteligência de Negócios),               17    BPD    ...
ETL    Extract, Transform and Load, 21FBS    Feature Breackdown Structure, 66FDD    Feature Driven Development, 18OLAP   O...
SUMÁRIO1   Introdução                                                                                  17    1.1   Motivaç...
2.4.2   FDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       39                  2.4.2.1    Cic...
4.3.1.2   Criar/Priorizar FBS do Projeto . . . . . . . . . . . . . . . .       70              4.3.1.3   Projeto de Arquit...
5   Estudo de Caso                                                                                89    5.1   Projeto Perm...
Apêndice B -- Análise dos Estudo de Caso                                                    114   B.1 Aplicação da Metodol...
171        INTRODUÇÃO    Este capítulo apresenta a motivação para este trabalho, discute seus objetivos e os resultadosque...
18BI ainda é um desafio. Isso porque, atualmente, na rede das empresas existem grandes volumesde dados inseridos em ambient...
19      de BI.  • Investigar, analisar e selecionar as práticas das metodologias SCRUM, FDD e XP a serem      instaciadas ...
202        CONCEITOS2.1     BUSINESS INTELLIGENCE    BI pode ser visto como um processo sistemático de aquisição, tratamen...
21Por fim, a inteligência eleva a informação a um nível mais alto, como resultado do completoentendimento de ações, context...
22Figura 1: Arquitetura de BI - Visão Simplificada. Adaptado de (COSTA; ANCIÃES, 2001).           Figura 2: Visão Geral de ...
232.2     DATA WAREHOUSE    Segundo (INMON, 1997) a definição de DW é: "uma coleção de dados orientada por assun-tos, integ...
242.2.1       DATA WAREHOUSING    Data Warehousing é um conjunto de tecnologias de suporte a decisão destinadas a possi-bi...
25dos sistemas transacionais, em segunda instância a transformação destes dados de modo aintegrá-los e resolver problemas ...
26portadas. As medidas a serem realizadas necessitam ser vistas sob diferentes perspectivas (ouseja, através de várias dim...
27               Figura 5: Exemplo de Modelo Floco De Neve (CRAMER, 2006).2.2.4   OLAP    A tecnologia OLAP possibilita às...
28               Figura 6: Exemplo de Cubo Multidimensional (CRAMER, 2006).2.3    METODOLOGIAS PARA GERÊNCIA E DESENVOLVI-...
29      negócio;   5. Mudanças organizacionais (cultura organizacional). Projetos de BI acabam transfor-      mando a cult...
302.3.1     ABORDAGENS PARA IMPLEMENTAÇÃO DE UM DW    A abordagem Top-Down é defendida por Inmon (INMON, 1997) e define bas...
31      indicadores de desempenho desejados.    Existem, ainda, na literatura propostas que fazem a junção dessas abordage...
32    A partir da definição destas etapas (SÁ, 2009) define um modelo geral de processo para DataWarehousing e uma recomenda...
33   3. Trilha da Tecnologia: Consiste na sequência de passos necessários a implantação da        infra-estrutura técnica....
34   5. Trilha das Aplicações de BI: Podemos listar algumas categorias básicas de aplicações       de BI que vão desde ace...
35      de desenvolvimento e monitoração das atividades com frequente acompanhamento do      cronograma geral.2.4    METOD...
36    Muitos especialistas criaram métodos próprios para se adaptar às constantes mudançasexigidas pelo mercado e as indefi...
37                Figura 9: Visão Geral do Processo SCRUM (MARÇAL, 2009).    A Figura 9, mostra como funciona o ciclo comp...
382.4.1.2 ARTEFATOS    Em (SCHWABER, 2004), os seguintes artefatos estão definidos para o SCRUM ao longo doseu fluxo de dese...
392.4.1.4 MEDIÇÃO DE PROGRESSO    No SCRUM, o monitoramento do progresso do projeto é realizado por meio de dois gráficospr...
40Figura 11: Exemplo de Sprint Burndown exibindo o consumo de horas das tarefas durante asprint (CAVALCANTI, 2009).do sist...
41        Figura 12: Ciclo de vida de um projeto com o FDD (HEPTAGON, 2010).        construído e tem seu conteúdo atualiza...
42          aliza o refinamento do modelo de objetos. Os programadores então escrevem os          prefácios das classes e m...
43    Para projetos maiores ou complexos, FDD fornece um conjunto maior de papéis, como porexemplo: Gerente de release, te...
44      para cada função implementada. Os testes de aceitação são escritos pelos clientes e são      usualmente rodados no...
45                              Figura 13: Ciclo Semanal em XP.(GUIMARÃES, 2009). Inicialmente os clientes escrevem as est...
46(GUIMARÃES, 2009).2.4.3.2 PAPÉIS   XP não mantém uma estrutura rigída de pápeis. O principal objetivo é fazer com que to...
472.5     CONSIDERAÇÕES FINAIS    Neste capítulo foram detalhados os principais conceitos que possibilitam a compreensãoda...
483        AVALIAÇÃO DE TRABALHOS         RELACIONADOS    Neste capítulo são discutidos os trabalhos relacionados a propos...
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence
Upcoming SlideShare
Loading in...5
×

Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence

2,267

Published on

Published in: Technology
4 Comments
5 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,267
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
4
Likes
5
Embeds 0
No embeds

No notes for slide

Transcript of "Monografia: FDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence"

  1. 1. UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Mauricio Cesar Santos da Purificação FDWS: Uma Metodologia para Gerência eDesenvolvimento de Projetos Ágeis de Business Intelligence Salvador - Bahia 2010-2
  2. 2. Mauricio Cesar Santos da PurificaçãoFDWS: Uma Metodologia para Gerência e Desenvolvimento de Projetos Ágeis de Business Intelligence Monografia apresentada ao curso de bacharelado em Ciência da Computação do Departamento de Ciência da Computação da Universidade Federal da Bahia, como requisito para obtenção do grau de Bacharel em Ciência da Computação. Orientadora: Profa . Vaninha Vieira dos Santos Salvador - Bahia 2010-2
  3. 3. AGRADECIMENTOS Agradeço em primeiro lugar a Deus, pois sem ele nada do que foi feito poderia ter sidorealizado. Finalizar esta monografia foi uma tarefa árdua e se não houvesse fé e a certeza daajuda divina não seria possível concluí-la. Como está escrito em: (Provérbios 21.31) "‘O cavalo prepara-se para o dia da batalha, masdo SENHOR vem a vitória."’ A Ele eu dedico a conclusão dessa monografia e toda a honra,como só ele é digno de receber. Amém ! Agradeço também a meus pais: Rosenaide Vitória Santos da Purificação e Paulo CesarPereira da Purificação, por me possibilitarem acreditar que heróis existem. Sim, posso dizer,vocês são meus heróis e depois de Deus devo tudo o que tenho e sou a vocês. Minhas vitóriassão fruto da luta e do suor de vocês também. Sei bem as dificuldades e os sacrifícios que os doisenfrentaram para me educar e garantir que eu possa ter um futuro abençoado. Não posso deixarde incluir minhas Tias Dilma e Neide por todas as horas de jejum e oração e a minha famíliaem geral pela força, apoio e carinho. A Professora Dra. Vaninha Vieira dos Santos, orientadora desta monografia, pelo apoio,dedicação, broncas, muitos puxões de orelha, cobranças, sempre de forma gentil e adequadapara o desenvolvimento deste trabalho. Posso dizer que o profissional que sou hoje é muitodiferente daquele quando eu lhe conheci e isto é fruto do trabalho que tivemos em conjunto ede toda a nossa interação. Te agradecer por tudo é muito pouco. Valeu pelo aprendizado, peloamadurecimento, pela amizade e pela parceria. À Professora Dra. Christina von Flach GarciaChave e a Me. Karla Carvalho de Aleluia por terem aceitado participar da banca de defesa destamonografia e por todas as contribuições dadas a este trabalho. Chris, um agradecimento especial, pelo tempo que fui teu monitor em Engenharia de Soft-ware, nem tenho palavras para dizer o quanto foi bom trabalhar contigo e o quanto lhe admiropela figura humana que tu és. Obrigado por tudo ! Faço um agradecimento em especial a equipe do SIAC, que muito mais do que uma equipe,tornou-se uma família pra mim. Vivaldo, André, Helder, Mário, Fernando... vocês foram fun-damentais na execução deste trabalho. Agradeço muito a ajuda, a força, a paciência de cada umde vocês. Não posso deixar de citar aqui, o grande mestre Antônio, exemplo de ser humano,
  4. 4. chefe e profissional, muito obrigado pelo exemplo de vida. Falando de SIAC e CPD, tenho de citar muitas pessoas aqui, Aninha, Heraldo, Juliana,Marcel (muito obrigado com o Abstract dessa monografia), André Andrade, Rosinha, o pessoalque assistiu minha defesa (Alan, Carlinha...) (Como é bom ter amigos !!!) entre outros. Cadaum de vocês contribuiu tanto para este trabalho, como para minha formação. Agradeço também aos alunos da disciplina Tópicos em Banco de Dados dos semestres de2009-2 e 2010-2, a Gustavo pela amizade, parceria e companherismo na monitoria da disciplina,a equipe do Projeto Permanecer, Hugo e Marcondes... como foi bom trabalhar com vocês e aosmembros do DW-UFBA (João e Elane). Agradeço de um modo geral a todos os que passaram em minha vida, amigos, colegas,conhecidos... (Caso eu tenha esquecido de citar nomes, me perdoem...) Como diria CharlesChaplin: "‘Cada pessoa que passa em nossa vida, passa sozinha, é porque cada pessoa é únicae nenhuma substitui a outra. Cada pessoa que passa em nossa vida passa sozinha, e nãonos deixa só, porque deixa um pouco de si e leva um poquinho de nós. Essa é a mais belaresponsabilidade da vida e a prova de que as pessoas não se encontram por acaso."’
  5. 5. RESUMO Soluções de Business Intelligence (BI) são de grande importância para os gestores das em-presas e dos seus responsáveis de TI devido aos benefícios advindos de sua implementação euso, referentes a melhoria do processo decisório das organizações, como por exemplo, compa-nhias privadas e instituições de ensino como a Universidade Federal da Bahia (UFBA). Porém,a implementação de soluções de BI é uma missão difícil por causa dos ambientes de Tecnologiada Informação (TI) altamente complexos e grandes volumes de dados não-integrados oriun-dos de bases distintas sejam estas externas ou internas. Além disso, as abordagens tradicionaisde desenvolvimento de soluções de BI como Kimball (KIMBALL, 2002) não possibilitam queos gestores das empresas experimentem os benefícios destas soluções a curto prazo e muitasvezes os projetos encerram-se sem ter havido nenhum resultado visível aos gestores da organi-zação. Nesse contexto surgem os conceitos de Agile BI e Agile Data Warehousing, que nadamais são do que a aplicação de práticas advindas das metodologias ágeis no universo do de-senvolvimento de soluções de BI. O conceito de Agile BI ultrapassa a fronteira da metodologiae interfere em vários outros aspectos do desenvolvimento das soluções como, por exemplo, aarquitetura da solução e o próprio comportamento das ferramentas usadas durante o processo.Este trabalho apresenta a especificação de uma metodologia para gerência e desenvolvimentode projetos ágeis de BI usando práticas combinadas das metodologias Extreme Programming(XP), SCRUM e Feature Driven Development (FDD) de modo a atender ao requisito metodolo-gia e processo de desenvolvimento sob o conceito de Agile BI. O uso dessa metodologia foiavaliado em dois projetos realizados na disciplina "Tópicos em Banco de Dados"do Departa-mento de Ciência da Computação da Universidade Federal da Bahia (DCC-UFBA) e no projetoPermanecer DW-UFBA. Os resultados de sua aplicação são explicitados e analisados. Palavras-chave: Business Intelligence, Data Warehouse, Métodologias Ágeis, SCRUM,FDD, XP, Agile Data Warehousing, Agile BI.
  6. 6. ABSTRACT Business Intelligence(BI) solutions is a great importance for business managers and their ITmanagers due to the arising benefits from their implementation and use, regarding the improve-ment of making decisions for organizations, for example, private companies and institutionsof education such as Federal University of Bahia (UFBA). However, the implementation of BIsolutions is a difficult task because of the environments of Information Technology (IT) highlycomplex and large volumes of non-integrated data coming from these different external or in-ternal bases. Moreover, traditional approaches to development of BI solutions such as Kimball(KIMBALL, 2002) do not enable business managers to experience the benefits of these short-termsolutions and often the projects are close without having been visible results to managers of theorganization. In this context the concepts of Agile BI and Agile Data Warehousing, which arenothing more than the application of practices from the world of agile development of BI solu-tions. The concept of Agile BI surpass the border of the methodology and interfere other aspectsof the development of solutions, for example, the architecture solution and the actual behaviorof the tools used during the process. This paper presents the specification of a methodologyfor management and development of agile BI projects using combined practical methodologiesof Extreme Programming (XP), Scrum and Feature Driven Development (FDD) to meet therequirement of the methodology and process of development under the Agile BI concept. Theuse of this methodology was evaluated in two projects in the course "Topics in Database"of theDepartment of Computer Science of the Federal University of Bahia (DCC-UFBA) and into theproject Permanecer DW-UFBA. The results of its application are described and analyzed. Keywords: Business Intelligence, Data Warehouse, Agile Methodologies, SCRUM, FDD,XP, Agile Data Warehousing, Agile BI.
  7. 7. LISTA DE FIGURAS1 Arquitetura de BI - Visão Simplificada. Adaptado de (COSTA; ANCIÃES, 2001). 222 Visão Geral de um Data Mart (COSTA; ANCIÃES, 2001). . . . . . . . . . . . . . 223 Exemplo de Arquitetura de Povoamento e Descrição das Atividades de ETL (COSTA; ANCIÃES, 2001). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Exemplo de Modelo Estrela (CRAMER, 2006). . . . . . . . . . . . . . . . . . . 265 Exemplo de Modelo Floco De Neve (CRAMER, 2006). . . . . . . . . . . . . . . 276 Exemplo de Cubo Multidimensional (CRAMER, 2006). . . . . . . . . . . . . . 287 Etapas comuns aos Métodos. Adaptado de (SÁ, 2009). . . . . . . . . . . . . . 318 Método Kimball (CARVALHO, 2009). . . . . . . . . . . . . . . . . . . . . . . . 329 Visão Geral do Processo SCRUM (MARÇAL, 2009). . . . . . . . . . . . . . . . 3710 Exemplo de Product Burndown exibindo o consumo de story points de cada sprint (CAVALCANTI, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . 3911 Exemplo de Sprint Burndown exibindo o consumo de horas das tarefas durante a sprint (CAVALCANTI, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . 4012 Ciclo de vida de um projeto com o FDD (HEPTAGON, 2010). . . . . . . . . . . 4113 Ciclo Semanal em XP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4514 Ciclo de Desenvolvimento Agile Data Warehousing. Adaptado de (HUGHES, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4815 Exemplo de três ciclos de desenvolvimento curtos, ou "semanais"(CARVALHO, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5216 Ciclo Tradicional de Desenvolvimento na Plataforma Pentaho . . . . . . . . . 5317 FDWS - Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5918 FDWS - Ciclo de Vida - Visão Geral . . . . . . . . . . . . . . . . . . . . . . . 65
  8. 8. 19 FBS Versão Original (VERSION-ONE, 2010). . . . . . . . . . . . . . . . . . . . 6720 FBS Adaptada ao FDWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6721 FDWS - Planejamento do Projeto - Processo . . . . . . . . . . . . . . . . . . . 6822 FDWS - Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . 7423 Matriz de Necessidades (OLIVEIRA, 2010). . . . . . . . . . . . . . . . . . . . . 7524 FDWS - Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7925 FDWS - Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8426 Atividades da etapa de Percepção. Adaptado de (SÁ, 2009). . . . . . . . . . . . 10927 Atividades da etapa de Concepção. Adaptado de (SÁ, 2009). . . . . . . . . . . 11128 Atividades da etapa de Entrega. Adaptado de (SÁ, 2009). . . . . . . . . . . . . 11229 Atividades da etapa de Operação. Adaptado de (SÁ, 2009). . . . . . . . . . . . 11330 Atividades da etapa de Ajustes/Melhorias. Adaptado de (SÁ, 2009). . . . . . . 11331 Avaliadores por sexo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12632 Avaliadores por escolaridade . . . . . . . . . . . . . . . . . . . . . . . . . . . 12633 Avaliadores por tempo de experiência em BI e DW . . . . . . . . . . . . . . . 12734 Avaliadores por nível de conhecimento em Práticas Ágeis . . . . . . . . . . . . 12735 Avaliadores por nível de conhecimento na Metodologia SCRUM . . . . . . . . 12736 Avaliadores por nível de conhecimento na Metodologia XP . . . . . . . . . . . 12837 Avaliadores por nível de conhecimento na Metodologia FDD . . . . . . . . . . 12838 FDWS - Planejamento do Projeto - Mapeamento das Etapas e Metodologias de Origem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13039 FDWS - Planejamento da Release - Mapeamento das Etapas e Metodologias de Origem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13140 FDWS - Iteração - Mapeamento das Etapas e Metodologias de Origem . . . . . 13241 FDWS - Pós-Iteração - Mapeamento das Etapas e Metodologias de Origem . . 13242 Objetos de Fluxo Básicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . 13443 Objetos de Conexão da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . 134
  9. 9. 44 Artefatos Básicos da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . . 13545 Elementos de Raia da BPMN (TESSARI, 2008). . . . . . . . . . . . . . . . . . 13546 Representação de Uma Atividade em Diferentes Níveis de Granularidade (TES- SARI, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13647 Tipos de Eventos BPMN de Início para um BPD (TESSARI, 2008). . . . . . . . 13648 Tipos de Eventos BPMN Intermediários para um BPD (TESSARI, 2008). . . . . 13749 Exemplo de Evento Intermediário Anexado a uma Atividade (TESSARI, 2008). . 13750 Tipos de Evento BPMN para o Término de um Processo (TESSARI, 2008). . . . 13851 Tipos de Elementos do Tipo Gateway na BPMN (TESSARI, 2008). . . . . . . . 13852 FDWS - Planejamento do Projeto: Análise Organizacional . . . . . . . . . . . 14053 FDWS - Planejamento do Projeto: Criar/Priorizar FBS do Projeto . . . . . . . 14154 FDWS - Planejamento do Projeto: Projeto de Arquitetura Técnica . . . . . . . 14255 FDWS - Planejamento do Projeto: Projeto de Arquitetura Técnica - Análise de Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14356 FDWS - Planejamento do Projeto: Plano de Projeto . . . . . . . . . . . . . . . 14457 FDWS - Planejamento do Projeto: Montagem da Equipe . . . . . . . . . . . . 14558 FDWS - Planejamento da Release: Levantar Requisitos da Release . . . . . . . 14659 FDWS - Planejamento da Release: Desenvolver Modelo Abrangente da Release 14760 FDWS - Planejamento da Release: Criar/Priorizar Release Backlog . . . . . . . 14861 FWDS - Planejamento da Release: Criar Plano de Sprints . . . . . . . . . . . . 14962 FDWS - Iteração: Detalhar Funcionalidade . . . . . . . . . . . . . . . . . . . 15063 FDWS - Iteração: Projeto Físico . . . . . . . . . . . . . . . . . . . . . . . . . 15164 FDWS - Iteração: Projeto de Metadados . . . . . . . . . . . . . . . . . . . . . 15265 FDWS - Iteração: Projeto de ETL . . . . . . . . . . . . . . . . . . . . . . . . 15366 FDWS - Iteração: Projeto da Aplicação de BI . . . . . . . . . . . . . . . . . . 15467 FDWS - Iteração: Validação e Verificação . . . . . . . . . . . . . . . . . . . . 155
  10. 10. LISTA DE TABELAS2 Descrição das Etapas do Planejamento do Projeto Executadas no Projeto Per- manecer DW-UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153 Descrição das Etapas do Planejamento da Release Executadas no Projeto Per- manecer DW-UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164 Descrição das Etapas da Iteração Executadas no Projeto Permanecer DW-UFBA 1175 Descrição das Etapas da Pós-Iteração Executadas no Projeto Permanecer DW- UFBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186 Descrição das Etapas do Planejamento do Projeto Executadas na Disciplina Tópicos em Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197 Descrição das Etapas do Planejamento da Release Executadas na Disciplina Tópicos em Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208 Descrição das Etapas da Iteração Executadas na Disciplina Tópicos em Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219 Descrição das Etapas da Pós-Iteração Executadas na Disciplina Tópicos em Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
  11. 11. LISTA DE ABREVIATURAS E SIGLAS BI Business Intelligence (Inteligência de Negócios), 17 BPD Business Process Diagrams (Diagramas de Pro- cessos de Negócio), 133 BPMI The Business Process Management Initiative, 133 BPMN Business Process Modeling Notation (Notação para Modelagem de Processos de Negócio), 133 CIOs Chief Information Officers (Diretores de Tec- nologia da Informação), 17 CLF Construir a Lista de Funcionalidades, 41 CPD-UFBA Centro de Processamento de Dados da UFBA, 89 CPF Construir por Funcionalidade, 42 DCC-UFBA Departamento de Ciência da Computação da Universidade Federal da Bahia, 89 DM Data Mart, 24 DMA Desenvolver um Modelo Abrangente, 40 DMs Data Marts, 21 DPF Detalhar por Funcionalidade, 41 DW Data Warehouse, 17 ETC Extração, Transformação e Carga, 21
  12. 12. ETL Extract, Transform and Load, 21FBS Feature Breackdown Structure, 66FDD Feature Driven Development, 18OLAP On-Line Analytical Processing (Processamento Analítico Online), 24PPF Planejar por Funcionalidade, 41TI Tecnologia da Informação, 17WBS Work Breakdown Structure, 50XP Extreme Programing, 18
  13. 13. SUMÁRIO1 Introdução 17 1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Conceitos 20 2.1 Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.1 Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.2 ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.3 Modelagem Multidimensional . . . . . . . . . . . . . . . . . . . . . . 25 2.2.4 OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3 Metodologias para Gerência e Desenvolvimento de Projetos de Data Warehousing 28 2.3.1 Abordagens para Implementação de um DW . . . . . . . . . . . . . . 30 2.3.2 Modelo Geral de Processo para Data Warehousing . . . . . . . . . . . 31 2.3.3 Método Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4 Metodologias Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.4.1 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.4.1.1 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.4.1.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.4.1.3 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.4.1.4 Medição de Progresso . . . . . . . . . . . . . . . . . . . . . 39
  14. 14. 2.4.2 FDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.4.2.1 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.4.2.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.4.3 XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4.3.1 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.4.3.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 Avaliação de Trabalhos Relacionados 48 3.1 Agile Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.2 Extreme Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2.1 Planejamento do Processo . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3 Aplicação de Práticas Ágeis na Criação de Data Warehouse Evolutivo . . . . . 51 3.4 Agile BI - Pentaho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.5 Aplicação de Práticas Ágeis em Projetos de BI . . . . . . . . . . . . . . . . . . 53 3.6 Análise dos Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . 56 3.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 Metodologia FDWS 59 4.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.2 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2.1 Gerência de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2.2 Gerência de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2.3 Núcleo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 62 4.3 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.3.1.1 Análise Organizacional . . . . . . . . . . . . . . . . . . . . 69
  15. 15. 4.3.1.2 Criar/Priorizar FBS do Projeto . . . . . . . . . . . . . . . . 70 4.3.1.3 Projeto de Arquitetura Técnica . . . . . . . . . . . . . . . . 71 4.3.1.4 Plano de Projeto . . . . . . . . . . . . . . . . . . . . . . . . 72 4.3.1.5 Montagem dos Times . . . . . . . . . . . . . . . . . . . . . 72 4.3.2 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.3.2.1 Levantar Requisitos da Release . . . . . . . . . . . . . . . . 75 4.3.2.2 Desenvolver Modelo Abrangente da Release . . . . . . . . . 76 4.3.2.3 Criar/Priorizar Lista de Funcionalidades da Release . . . . . 77 4.3.2.4 Criar Plano de Iterações . . . . . . . . . . . . . . . . . . . . 77 4.3.2.5 Revisar Arquitetura Tecnológica/Ferramentas . . . . . . . . 78 4.3.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.3.3.1 Configuração do Ambiente de Testes, Produção e Homologação 78 4.3.3.2 Configuração de Ferramentas . . . . . . . . . . . . . . . . . 78 4.3.3.3 Criar Versão de Teste, Produção e Homologação . . . . . . . 78 4.3.3.4 Detalhar Funcionalidades . . . . . . . . . . . . . . . . . . . 80 4.3.3.5 Projeto Físico . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.3.3.6 Projeto de Metadados . . . . . . . . . . . . . . . . . . . . . 81 4.3.3.7 Projeto de ETL . . . . . . . . . . . . . . . . . . . . . . . . 81 4.3.3.8 Projeto da Aplicação de BI . . . . . . . . . . . . . . . . . . 82 4.3.3.9 Validação e Verificação (Testes Integrados) . . . . . . . . . . 82 4.3.3.10 Implantação no Ambiente de Homologação . . . . . . . . . 83 4.3.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.4 Análise da Metodologia FDWS . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.4.1 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.4.2 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.4.3 FDWS e os Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . 88
  16. 16. 5 Estudo de Caso 89 5.1 Projeto Permanecer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.1.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.1.2 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.1.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.1.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2 Tópicos em Banco de Dados - Semestre 2010-2 . . . . . . . . . . . . . . . . . 93 5.2.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.2 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.2.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.2.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.1 Execução da Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.2 Análise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 976 Conclusão 99 6.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.2 Dificuldades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Referências 103Apêndice A -- Modelo Geral de Processo para Data Warehousing 107 A.1 Percepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.2 Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.3 Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.4 Operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 A.5 Ajustes/Melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
  17. 17. Apêndice B -- Análise dos Estudo de Caso 114 B.1 Aplicação da Metodologia FDWS no Projeto Permanecer DW-UFBA . . . . . 114 B.1.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 114 B.1.2 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 114 B.1.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 B.1.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 B.2 Aplicação da Metodologia FDWS na Disciplina Tópicos em Banco de Dados . 118 B.2.1 Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 118 B.2.2 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . . 118 B.2.3 Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 B.2.4 Pós-Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Apêndice C -- Questionário de Avaliação da Metodologia FDWS 123 C.1 Informações Pessoais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 C.2 Questionário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Apêndice D -- Perfil dos Avaliadores 126Apêndice E -- Especificação e Modelagem da Metodologia FDWS 129 E.1 Mapeamento dos Subprocessos e Atividades da Metodologia FDWS de Acordo com as Metodologias de Origem . . . . . . . . . . . . . . . . . . . . . . . . . 129 E.2 Modelagem da Metodologia FDWS . . . . . . . . . . . . . . . . . . . . . . . 133 E.2.1 Descrição da Notação BPMN . . . . . . . . . . . . . . . . . . . . . . 133 E.2.1.1 Elementos Básicos da Notação . . . . . . . . . . . . . . . . 133 E.2.1.2 Refinamento dos Elementos . . . . . . . . . . . . . . . . . . 135 E.2.2 Diagramas de Processo da Metodologia FDWS . . . . . . . . . . . . . 138
  18. 18. 171 INTRODUÇÃO Este capítulo apresenta a motivação para este trabalho, discute seus objetivos e os resultadosque se pretende alcançar com sua realização e descreve a estrutura deste documento.1.1 MOTIVAÇÃO Soluções de Inteligência de Negócios (BI, do inglês Business Intelligence) possibilitam umamelhora significativa no processo decisório das organizações ao oferecer informações úteis, demodo rápido e facilitado, a partir dos próprios dados existentes nelas. Por isso, continuam a serde grande prioridade para os gestores das empresas e dos seus responsáveis de Tecnologia daInformação (TI) (NÓBREGA, 2010). Porém, segundo (FAYYAD, 2003 apud FERNÁNDEZ; MAYOL; PASTOR, 2008, p. 1) a grandemaioria destes projetos têm falhado em conseguir seus objetivos. Este fato não é estranhotratando-se de sistemas de suporte a decisão e da imaturidade da disciplina de BI com umadiversidade de enfoques metodológicos diferentes (PRESTON, 2003). De acordo com (NÓBREGA, 2010) no relatório da Forrester Research intitulado "Agile BIOut of the Box", realizado a partir de um estudo com empresas dos Estados Unidos, os uti-lizadores empresariais de aplicações de BI estão largamente insatisfeitos com a falta de agili-dade e flexibilidade das soluções desenvolvidas. Segundo o relatório, é necessário criar umanova forma de conceber e construir as aplicações de BI, defendendo que o processo tradicionalde recuperação de informações sobre todas as fontes de dados, documentação de todos os atri-butos, criação do Data Warehouse (DW) baseado nos dados recolhidos e a compilação de es-pecificações para aplicações de BI nem sempre é uma abordagem suficiente para enfrentar osdesafios colocados pelos complexos ambientes de TI dos dias de hoje e pelas necessidades dosseus utilizadores. Para muitos Diretores de Tecnologia da Informação (CIOs do inglês Chief Information Offi-cers), apesar do desejo das corporações, conseguir empregar aplicativos novos e inovadores de
  19. 19. 18BI ainda é um desafio. Isso porque, atualmente, na rede das empresas existem grandes volumesde dados inseridos em ambientes complexos de TI que não conversam entre si. Consequente-mente, o departamento de tecnologia tem enfrentado obstáculos para suprir as necessidades dosusuários por soluções intuitivas e aplicações de fácil utilização (WAILGUM, 2010). Outro detalhe importante é que os clientes estão cada vez mais impacientes para obter osbenefícios do BI, seja por causa do aumento da competitividade da economia global ou por quejá perceberam como o desenvolvimento de soluções de BI pode ser um processo demorado.A maioria dos clientes enxerga um grande risco nas abordagens tradicionais, onde os projetostendem a demorar meses e meses para mostrarem os primeiros resultados (HUGHES, 2007). Devido a este cenário, o relatório da Forrester Research defende uma abordagem definidacomo "Agile BI"para a construção de soluções de BI. O conceito de "Agile BI"não difere muitodas metodologias ágeis de desenvolvimento de software, o que demanda a criação de soluçõesem pequena escala (WAILGUM, 2010), com uma maior proximidade dos clientes e resultadosefetivos mais rápidos. O uso de metodologias ágeis também é defendido por (HUGHES, 2007) no que pode serchamado de "Agile Data Warehousing", como forma de tornar as equipes de desenvolvimento deDW: um dos componentes de soluções de BI, mais rápidas e eficazes. Ainda segundo (HUGHES,2007) o uso do "Agile Data Warehousing"influi diretamente nos prazos de entrega, na qualidadeda aplicação desenvolvida e na redução dos custos de produção. Apesar de alguns esforços já existentes, o alinhamento de práticas ágeis com o desenvolvi-mento de soluções de BI é um grande desafio. Os métodos ágeis foram concebidos para gerênciae desenvolvimento de projetos de software e não de projetos de integração de dados, como sãoos projetos de BI. Existe uma diversidade de metodologias que podem ser utilizadas de acordocom as adaptações necessárias para o suporte a projetos de integração de dados.1.2 OBJETIVOS O objetivo geral deste trabalho é especificar uma metodologia para gerência e desenvolvi-mento de projetos ágeis de BI derivada do SCRUM, com a composição de práticas advindas dasmetodologias ágeis Feature Driven Development (FDD) e Extreme Programming (XP) . Paratanto tem-se os seguintes objetivos específicos: • Investigar os processos tradicionais de construção de soluções de BI. • Investigar a utilização de metodologias ágeis nos processos de construções de soluções
  20. 20. 19 de BI. • Investigar, analisar e selecionar as práticas das metodologias SCRUM, FDD e XP a serem instaciadas no universo do processo de construção de soluções de BI. • Especificar uma metodologia para gerência e desenvolvimento de projetos ágeis de BI derivado das metodologias SCRUM, FDD e XP. • Realizar estudos de caso a partir do uso da metodologia especificada e avaliar seu uso a partir dos feedbacks das equipes de desenvolvimento e dos stakeholders dos projetos desenvolvidos.1.3 ESTRUTURA DO TRABALHO Além deste capítulo introdutório este documento está organizado nos seguintes capítulos: • O Capítulo 2 fornece uma visão geral dos principais conceitos relacionados a este tra- balho: BI, DW, Metodologias Ágeis e Metodologias para Data Warehousing; • No Capítulo 3 é realizada uma análise dos trabalhos relacionados a esta monografia, a fim de oferecer uma base de comparação com a metodologia proposta neste trabalho; • O Capítulo 4 trata do detalhamento e especificação da metodologia FDWS; • No Capítulo 5 são detalhados os estudos de casos realizados e a avaliação da aplicação da metodologia proposta; Por fim, o Capítulo 6 apresenta a conclusão deste trabalho, bem como destaca as suas principais contribuições e definições para trabalhos futuros.
  21. 21. 202 CONCEITOS2.1 BUSINESS INTELLIGENCE BI pode ser visto como um processo sistemático de aquisição, tratamento e análise de infor-mações em que os dados internos e externos da empresa são integrados para gerar informaçãopertinente para o processo de tomada de decisão. O papel do BI é criar um ambiente informa-cional com processos através dos quais os dados operacionais possam ser coletados, tanto dossistemas transacionais como de fontes externas, e analisados, revelando dimensões "estratégi-cas"do negócio (PETRINI; FREITAS; POZZEBON, 2006). A necessidade do cruzamento e análise de informações para uma plena gestão organiza-cional é uma realidade não apenas de nosso tempo, mas também de épocas passadas. O interessepelo tema BI iniciou-se no ano de 1996, devido ao avanço tecnológico que possibilitou a criaçãode ferramentas para captação, extração, armazenamento, filtragem, disponibilização e personal-ização de dados. O mesmo tem crescido na medida em que se descobre no BI uma solução paraos problemas relacionados a tomada de decisão dentro das corporações (INTEL, 2010). No geralas empresas não dispõem de uma informação acionável e instrumentos analíticos necessáriospara melhorar os lucros e desempenho, sendo portanto ricas em dados e probres em informação.O BI surge então como uma resposta para esta necessidade (WILLIAMS; WILLIAMS, 2007). Considerando o termo BI, vale considerar em que sentido a palavra inteligência relaciona-secom o ambiente de negócios. De acordo com (PETRINI; FREITAS; POZZEBON, 2006), inteligên-cia é o resultado de um processo que começa com a coleta de dados. A explicação sobre comoas organizações adquirem "inteligência"reside na transformação dado-informação-inteligência.Os dados referem-se a uma descrição elementar de coisas, eventos, atividades e transações quesão registrados, classificados e armazenados, mas não são organizados para transmitir qualquersignificado. Por exemplo, em uma empresa de vendas podemos ter dados armazenados rela-tivos ao cadastro de produtos, cadastro de clientes e vendas realizadas. A partir destes dadoscontextualizados mediante sua transformação e consolidação podemos obter informações a res-peito das vendas dos clientes, produtos mais vendidos e comparativos de vendas por períodos.
  22. 22. 21Por fim, a inteligência eleva a informação a um nível mais alto, como resultado do completoentendimento de ações, contextos e decisões. As soluções de BI, realizam o ciclo de transfor-mação dado-informação-inteligência, de modo a melhorar o processo de tomada de decisõesdentro das organizações, que com o BI deixam de ser apenas ricas em dados e tornam-se ricasem "‘inteligência"’. Várias iniciativas têm recebido o nome de BI, devido ao fato de o mesmo constituir-se poruma vasta categoria de software e soluções para coleta, consolidação, análise e disseminaçãode informações visando melhorar o processo decisório. Não existe, portanto um modelo desolução fechado para BI. BI pode, então, englobar um grande grupo de aplicações ou soluçõesdiferenciadas contanto que elas possibilitem a melhoria do processo de tomada de decisõespor meio de processos realizados nos dados uniformizados da organização (PETRINI; FREITAS;POZZEBON, 2006). Analisando a Figura 1, podemos visualizar uma arquitetura tradicional para soluções deBI. Segundo esta arquitetura, temos basicamente dois componentes representados pela Arquite-tura Técnica de Povoamento e pela Arquitetura de Acesso aos Dados. A Arquitera Técnica dePovoamento define como os dados oriundos dos sistemas operacionais (fontes de dados exter-nas e internas) são carregadas no DW através do processo de Extração, Transformação e Carga(ETC) (do inglês Extract, Transform and Load (ETL)). No processo de ETL, os dados opera-cionais são uniformizados, selecionados, transformados, e carregados no DW da solução deBI. A Arquitetura de Acesso aos Dados define como os dados armazenados no DW serão aces-sados pelos usuários. Por exemplo, pode-se construir Data Marts (DMs) (Figura 2), que sãocomo um DW armazenando dados a níveis departamentais ou vínculados a áreas específicas donegócio, de modo que caso o DW necessite de algum suporte ou manutenção os departamentoscontinuem acessando seus dados nos respectivos DMs. Por conseguinte, um novo processo deETL será realizado para que do DW possa se dar carga nos dados dos DMS. Além desses doiscomponentes, existe uma camada de metadados que engloba toda a solução. Os metadadosdevem possibilitar o registro de todas as informações sobre os dados como suas origens e osprocessos de transformação sofridos. São de extrema importância dentro do ambiente de DW,pois representam uma visão integrada das bases de dados que fazem parte deste ambiente. Sãoutilizados para construir, manter, gerenciar e utilizar o DW (COSTA; ANCIÃES, 2001). A Figura 2 ilustra como a partir de um DW podem ser gerados diversos DMs de acordocom os departamentos ou as áres de negócio existentes. Enquanto o DW concentra os dados detoda a organização, cada DM serve a um departamento ou área de negócio específica.
  23. 23. 22Figura 1: Arquitetura de BI - Visão Simplificada. Adaptado de (COSTA; ANCIÃES, 2001). Figura 2: Visão Geral de um Data Mart (COSTA; ANCIÃES, 2001).
  24. 24. 232.2 DATA WAREHOUSE Segundo (INMON, 1997) a definição de DW é: "uma coleção de dados orientada por assun-tos, integrada, variante no tempo, e não volátil, que tem por objetivo dar suporte aos processosde tomada de decisão". • Orientado por assunto: Os dados não estão mais organizados de acordo com as regras de negócios dos sistemas, mas sim de acordo com as áreas de interesse da organização. Por exemplo: vendas de produtos a diferentes tipos de clientes, atendimentos e diagnósticos de pacientes, rendimento de estudantes, produção científica de professores e grupos de pesquisa, índices de aprovação e reprovação. • Integrado: Diferentes nomenclaturas, formatos e estruturas das fontes de dados precisam ser agrupados em um único esquema para prover uma visão unificada e consistente da informação. Por exemplo, um sistema pode tratar o gênero das pessoas como masculino e feminino, outro como m e f. Ao serem passados para a base do DW estes dados deverão ser unificados para um único esquema de apresentação. • Variante no tempo: Ao contrário dos sistemas transacionais, os dados em um DW não sofrem constantes atualizações, eles são armazenados periodicamente o que permite que os mesmos possam ser analisados historicamente. • Não volátil: Os dados de um DW em geral não são modificados como em sistemas transacionais (exceto para correções), mas somente carregados e acessados para leituras, com atualizações apenas periódicas. Nos sistemas transacionais busca-se otimizar ao máximo a performance de acesso às tran-sações, já em um DW o que se prioriza é a qualidade da informação que pode ser consultadaem tempo hábil pelos gestores, analistas e executivos. O DW torna-se então o ponto central daarquitetura proposta para uma solução de suporte a tomada de decisões na medida em que con-solida as informações necessárias para o processo de tomada de decisões através de um alicercesólido de integração de dados corporativos e históricos para a realização de análises gerenci-ais (INMON; HACKATHORN, 1997). Para construí-lo é necessário combinar as necessidades deinformações de uma comunidade de usuários com os dados que realmente estão disponíveis(KIMBALL, 2002).
  25. 25. 242.2.1 DATA WAREHOUSING Data Warehousing é um conjunto de tecnologias de suporte a decisão destinadas a possi-bilitar que as pessoas que trabalhem a partir de informações (gerentes, analistas, executivos)possam tomar melhores decisões mais rapidamente (DAYAL; CHAUDHURI, 1997). O Data Ware-housing possibilita então a integração das fontes de dados transacionais na construção do DWque pode ser usado ou não com o objetivo final de suportar analíses gerenciais, o que amplia oescopo do Data Warehousing chegando no nível do conceito de BI. Pode-se considerar o Data Warehousing como um processo fundamental na construção desoluções de BI pois oferece o suporte necessário às ferramentas que serão utilizadas para aanálise dos dados, como o Processamento Analítico Online (OLAP do inglês On-Line Analyti-cal Processing) e a Mineração de Dados (do inglês Data Mining 1 ). Porém, para construir umasolução de BI não necessariamente necessita-se realizar o processo de Data Warehousing, istopode ser feito a partir de uma planilha eletrônica por exemplo, sem que tenha-se o trabalho derealizar qualquer processo de integração de dados. O Data Warehousing é um elemento que potencializa a construção de soluções de BI poisfornece às ferramentas de análise dados uniformizados e integrados, diminuindo o risco darealização de análises gerenciais a partir de dados incorretos e não contextualizados. Observa-se que os termos Data Warehousing e BI são tratados como sinônimos na literatura devidoa proximidade de seus conceitos. Desenvolver uma solução de Data Warehousing é tambémdesenvolver uma solução de BI, caso esta solução destine-se a servir para o processo de tomadade decisões a partir das análises gerenciais realizadas. Na metodologia proposta neste trabalho otermo BI é utilizado neste sentido, pois a solução de BI construída com sua aplicação é baseadaem Data Warehousing para a melhoria do processo de tomada de decisões gerenciais.2.2.2 ETL O ETL constitui-se como um elemento básico para a construção de um DW. Os dados queserão armazenados no DW provém de várias bases que não estão integradas e, além disso,podem ter sido modeladas de maneiras extremamente diferentes. Para tanto é crucial que taisdados passem por um processo de ETL para enfim serem utilizados no projeto de DW. As operações relacionadas ao ETL referem-se inicialmente a extração dos dados das bases 1 DataMining é uma das etapas no Processo de Descoberta do Conhecimento que consiste na aplicação dealgoritmos de análise de dados e descoberta de conhecimento a fim de encontrar padrões e modelos sobre os dados(FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996).
  26. 26. 25dos sistemas transacionais, em segunda instância a transformação destes dados de modo aintegrá-los e resolver problemas relacionados a modelagens diferentes como, por exemplo, umsistema que defina o gênero de uma pessoa como masculino e feminino e outro sistema que de-fina o mesmo item como m ou f. No DW todos os dados advindos de sistemas diferentes devemser uniformizados e tal uniformização só é garantida no processo de transformação dos dados.A última operação a ser realizada é a carga dos dados depois de extraídos e transformados noDW ou no Data Mart (DM) do projeto. Os conceitos relacionados ao ETL parecem simples, mas o êxito do processo de designe implementação do ETL é de vital importância para o sucesso do projeto de DW. Segundoestatísticas, em um projeto de DW, o processo de ETL pode consumir até 70% do esforço detodo o trabalho (DAYAL et al., 2009). A Figura 3 ilustra uma arquitetura básica para ETL e asprincipais atividades envolvidas: Extração, Transformação e Carga.Figura 3: Exemplo de Arquitetura de Povoamento e Descrição das Atividades de ETL (COSTA;ANCIÃES, 2001).2.2.3 MODELAGEM MULTIDIMENSIONAL Os requisitos de uma modelagem para DW são diferentes das aplicações do ambientetransacional. Para um DW deverá haver uma extensa flexibilidade nas análises a serem su-
  27. 27. 26portadas. As medidas a serem realizadas necessitam ser vistas sob diferentes perspectivas (ouseja, através de várias dimensões) e o entendimento e a visualização de problemas típicos nouniverso das organizações devem ser facilitados. O modelo multidimensional surge como uma técnica que responde a estes requisitos e au-xilia no processo de análise de dados que descrevem aspectos comuns de negócios. Um modelomultidimensional possui três elementos básicos: Fatos, dimensões e medidas. Um fato é umacoleção de itens de dados implementados sobre tabelas de fatos que representam um item denegócio, sendo composto por dados de medida e de contexto. Uma dimensão constitui-se comoos elementos que fazem parte de um determinado fato. Por exemplo, para um dado fato ven-das de um produto teríamos as dimensões: tempo, local, clientes e vendedores. As medidasconstituem-se como os valores numéricos que representam os fatos. Considerando a modelagem multidimensional, podemos modelar nossos dados sob doisesquemas básicos: modelo estrela (star scheme) (Figura 4) e floco-de-neve (snow-flake scheme)(Figura 5). Figura 4: Exemplo de Modelo Estrela (CRAMER, 2006). No modelo estrela temos uma entidade central denominada fato e entidades menores ao re-dor desta denominadas dimensões, no modelo floco-de-neve ao contrário do modelo estrela astabelas de dimensões encontra-se todas normalizadas (DAYAL; CHAUDHURI, 1997). O modelofloco-de-neve possibilita a diminuição da redundância de dados que pode ser bastante alta nomodelo estrela, porém este modelo aumenta a complexidade do esquema e dificulta as imple-mentações por parte das ferramentas de análises de dados e até mesmo a compreensão por partedos usuários. O modelo estrela contribui para o ganho de desempenho mesmo que este ganhoseja a custo de maior espaço de armazenamento.
  28. 28. 27 Figura 5: Exemplo de Modelo Floco De Neve (CRAMER, 2006).2.2.4 OLAP A tecnologia OLAP possibilita às organizações um método de acesso, visualização, eanálise de dados corporativos com alta flexibilidade e desempenho. Deste modo, as ferramentasOLAP permitem a geração de relatórios, análise de um grande volume de dados e a obtençãode informações estratégicas que podem facilitar a tomada de decisão (ARAÚJO; BATISTA; MA-GALHÃES, 2007). O termo OLAP refere-se a um conjunto de ferramentas voltadas para acessoe análise ad-hoc de dados, com o objetivo final de transformar dados em informações capazesde dar suporte às decisões gerenciais de forma amigável, flexível e em tempo hábil ao usuário(ARAÚJO; BATISTA; MAGALHÃES, 2007). Segundo (ANZANELLO, 2002), OLAP é mais do que uma aplicação, é uma solução de ambi-ente, integração e modelagem de dados. Os dados utilizados pela solução OLAP são origináriosde um DW ou simplesmente de um DM. Para formular a topologia e o projeto de uma soluçãoOLAP multidimensional as seguintes perguntas devem ser feitas: Quando?, O quê?, Onde? eQuem ?. Essas perguntas formam a base de todos os arrays multidimensionais (estruturas dedados que armazenam os valores em mais de uma dimensão). A obtenção dos dados origináriosdas respostas é destinada aos DW e, daí, possivelmente para um ou vários Data Marts (DMs). Podemos definir um cubo de dados como uma representação intuitiva do fato, por que todasas dimensões coexistem para todo o ponto no cubo e são independentes entre si. Além disso,são nos cubos multidimensionais que são gravados os valores quantitativos e as medidas dasinformações armazenadas.
  29. 29. 28 Figura 6: Exemplo de Cubo Multidimensional (CRAMER, 2006).2.3 METODOLOGIAS PARA GERÊNCIA E DESENVOLVI- MENTO DE PROJETOS DE DATA WAREHOUSING Nesta seção serão discutidas algumas das abordagens tradicionais existentes na literaturapara a gerência e desenvolvimento de projetos de BI que envolvem Data Warehousing (Naliteratura essas metodologias são descritas apenas como metodologias para Data Warehousing,apesar da relação existente entre Data Warehousing e BI como sinônimos, por isto o termo DataWarehousing foi mantido). A aplicação de metodologias ágeis em BI tem sido motivada devido a alguns problemasque tem sido observados com estas abordagens: 1. Envolvimento com os clientes, usuários e patrocinadores do projeto. Se em projetos de desenvolvimento de software tal envolvimento é importante, em BI, este envolvimento é uma dos grandes fatores que possibilitam o sucesso do projeto; 2. Escopo do projeto muitas vezes é grande demais, resultando em projetos caros e difíceis de implementar. O ideal é que se inicie o projeto com um pequeno protótipo do que será a solução de BI; 3. Demora na entrega de funcionalidades aos clientes. Muitos projetos de BI são encerrados sem que os gestores tenham tido resultados satisfatórios; 4. Avaliação inicial e foco estratégico do projeto. Muitos projetos de BI falham por não ter sido feito um planejamento adequado de acordo com as necessidades emergentes do
  30. 30. 29 negócio; 5. Mudanças organizacionais (cultura organizacional). Projetos de BI acabam transfor- mando a cultural organizacional. Dependendo de como o processo é feito, essa mudança de cultura pode trazer um impacto muito grande na instituição. A solução de BI deve ser experimentada e utilizada aos poucos de modo que a cultura antes existente possa ser moldada aos poucos; 6. Ferramentas de consulta. Os gestores e usuários finais, precisam de tempo para experi- mentar e avaliar as ferramentas de consulta e exploração das informações. O conjunto de ferramentas utilizado deve ser flexível e atender às necessidades do negócio; 7. Extensibilidade e adaptação a mudanças. Mudanças de requisitos são frequentes, prin- cipalmente em projetos de BI. O processo de desenvolvimento deve responder bem a quaisquer tipo de mudanças, seja esta feita em qualquer fase do projeto. Além disso, a solução desenvolvida deve ser projetada de modo que possa estar sempre em espan- são, pois novas consultas sempre serão solicitadas desde que os gestores e usuários finais percebam os benefícios da solução de BI; 8. ETL. O processo de ETL é altamente custoso. Integrar muitas bases pode demorar um longo tempo. O ideal é reduzir o escopo, diminuindo assim a complexidade do processo; 9. Qualidade dos dados. Um dos itens mais importantes em projetos de BI é a análise da qualidade dos dados. Para tanto, testes exaustivos devem ser realizados a cada passo de desenvolvimento, assim como testes automatizados de todo o processo. Uma metodologia para Data Warehousing define como o DW deve ser construído e imple-mentado, mapeando assim os resultados esperados das várias atividades e técnicas adotadas naconstrução e projeto de Data Warehousing (SÁ, 2009). Não existe, por enquanto, um consensoem termos de qual seja a melhor metodologia e em que cenários uma ou outra é mais adequada.Existem, portanto, na literatura, várias propostas metodológicas e estudos de caso de aplicações.Em alguns casos a metodogia de Data Warehousing está ligada com uma proposta de arquite-tura para o DW. De um modo geral podemos agrupar as metodologias de Data Warehousingem dois grupos que também correspondem a abordagens de arquitetura: Abordagem top-downe Abordagem bottom-up.
  31. 31. 302.3.1 ABORDAGENS PARA IMPLEMENTAÇÃO DE UM DW A abordagem Top-Down é defendida por Inmon (INMON, 1997) e define basicamente duasetapas para a implementação de DW. Na primeira etapa é realizada a especificação do esquemade todo o DW. Na segunda etapa, é feita a construção de DMs de acordo com as característicase particularidades de cada área do negócio/departamento (SÁ, 2009). Um dos maiores problemas dessa abordagem é que realizar o levantamento de todos osrequisitos do DW em uma única etapa é extremamente difícil devido a dimensão do negócioque está sendo trabalhada e a dificuldade em se extrair os requisitos de usuário. O maior defensor da abordagem Bottom-Up é Ralph Kimball (KIMBALL, 2002). Segundoesta abordagem, o DW deve ser concebido iterativamente a partir da construção de DMs queserão posteriormente integrados dando origem ao DW. Deve existir um cuidado intenso nadefinição dos esquemas dos DMs, pois os mesmos deverão ser integrados posteriormente. Destemodo a concepção de cada modelo deve ser feita pensando-se nesta posterior integração. Em(SÁ, 2009) são indicadas quatro abordagens que podem ser utilizadas para se determinar omodelo de dados de um DW e por conseguinte seu conteúdo: abordagem orientada a dados,orientada aos objetivos, orientada aos utilizadores e orientada aos processos: • Orientada a dados: Segundo esta abordagem o modelo de dados do DW deve ser derivado diretamente dos modelos de dados transacionais. Isto por que os usuários do DW são incapazes inicialmente de formular as necessidades informacionais antes de perce- berem e experimentarem as capacidades do DW. Por isso, em um primeiro momento, os requisitos de usuário são ignorados vindo a ser percebidos apenas após o lançamento de uma primeira versão do mesmo; • Orientada aos objetivos: Esta abordagem consiste, inicialmente, em recolher e iden- tificar os objetivos organizacionais. Esses objetivos podem ser identificados a partir de entrevistas com stakeholders nos processos organizacionais e que serão posteriormente quantificados em indicadores que permitam avaliar o desempenho do processo; • Orientada aos utilizadores: Segundo esta abordagem devem ser coletados as necessi- dades e expectativas dos futuros utilizadores do DW. Os requisitos de usuário são, por- tanto, colhidos e documentados servindo de base para a construção do modelo de dados do DW; • Orientada a processos: Segundo esta abordagem os processos essenciais da organiza- ção devem ser identificados. A partir dos processos mapeados devem ser definidos os
  32. 32. 31 indicadores de desempenho desejados. Existem, ainda, na literatura propostas que fazem a junção dessas abordagens de modo amelhorar o processo de definição do modelo de dados do DW.2.3.2 MODELO GERAL DE PROCESSO PARA DATA WAREHOUSING Em (SÁ, 2009), o autor realiza uma análise entre algumas metodologias de implementaçãode DW: Método Kimball (KIMBALL, 2002), NCR/Teradata (NCR-TERADATA, 2007), Microsoft(CRAIG; VIVONA; BERKOVITCH, 1999), SAS (BROWN, 2000), Iterations, (PRISM-SOLUTIONS,2002) e identifica algumas etapas metodológicas comuns a estes métodos que podem ser visu-alizadas na Figura 7. Essas etapas são detalhas no Apêndice A. Figura 7: Etapas comuns aos Métodos. Adaptado de (SÁ, 2009). • Percepção: É a etapa de identificação e definição de requisitos, arquitetura, modelos, aplicações analíticas, aplicações e ferramentas de apoio bem como a ordem em que as iterações do processo deverão ser realizadas; • Concepção: É considerada a etapa mais técnica, pois é onde o DW é construído; • Entrega: Consiste em colocar o sistema de DW em produção, obrigando a montagem de toda a estrutura de apoio ao funcionamento do sistema de DW, isso inclui a documentação e a formação/suporte aos utilizadores; • Operação: Consiste em garantir que o Sistema de DW está a funcionar, cumprindo com os requisitos para os quais foi implementado; • Ajustes/Melhorias: Esta etapa pode ser subdividida em duas atividades. A primeira atividade consiste em monitorar o funcionamento do sistema de DW de forma a eliminar anomalias e melhorar seu desempenho. A segunda atividade consiste em recuperar su- gestões e reclamações dos utilizadores, através dos canais de suporte montados na etapa de Entrega, que poderão ser transformados em novos requisitos.
  33. 33. 32 A partir da definição destas etapas (SÁ, 2009) define um modelo geral de processo para DataWarehousing e uma recomendação de metodologia para que um processo de Data Warehousingpossa obter sucesso. O processo definido por (SÁ, 2009) é detalhado no Apêndice A.2.3.3 MÉTODO KIMBALL O método de Kimball é um dos métodos mais referenciados em termos acadêmicos e pro-fissionais, por isto foi incluido neste capítulo. O modelo geral do processo está descrito naFigura 8. Esse método é iterativo e defende que a construção do DW seja incremental a partirda contínua construção/integração de DMs. Suas etapas são: Figura 8: Método Kimball (CARVALHO, 2009). 1. Planejamento do Projeto: Esta etapa engloba o seguinte conjunto de atividades (CAR- VALHO, 2009): Análise inicial do ambiente, definição do escopo e data de entrega, mon- tagem da equipe, definição do cronograma de atividades da iteração, definição de um plano de comunicação para a equipe. Durante esta etapa devem ser avaliados e iden- tificados: o nível de preparação da organização para ter um sistema de DW, os riscos associados, patrocinadores, motivação e cultura organizacionais (SÁ, 2009). 2. Especificação de Requisitos de Negócio: Nesta etapa os requisitos funcionais e não- funcionais devem ser coletados a partir de entrevistas com analistas de negócio, gestores, executivos e membros da área de TI. A partir da coleta, análise e especificação dos re- quisitos existem três grupos de atividades que podem ser executados em paralelo. Estes grupos correspondem exatamente à trilha da tecnologia, trilha dos dados e trilha das apli- cações de BI.
  34. 34. 33 3. Trilha da Tecnologia: Consiste na sequência de passos necessários a implantação da infra-estrutura técnica. Assim, o desenho técnico do ambiente precisa ser projetado, fer- ramentas e utilitários devem ser definidos e tudo precisa ser devidamente configurado e testado (CARVALHO, 2009). Engloba as seguintes atividades: • Projeto da Arquitetura Técnica: Todo o conjunto de tecnologias que serão necessárias quando o DW estiver em produção e em uso devem ser definidas, incluindo, por exemplo, as ferramentas, os utilitários e as plataformas necessárias para que o fluxo dos dados ocorra (CARVALHO, 2009). • Escolha e Configuração de Ferramentas: Subdivide-se em dois eixos principais: A criação do plano de arquitetura, que tem como meta a efetiva implantação da arquitetura de todo o ambiente e, a seleção de produtos, cujo objetivo é selecionar as ferramentas mais adequadas a cada necessidade identificada no plano de arquitetura (CARVALHO, 2009). 4. Trilha dos Dados: Compreende as etapas de modelagem dimensional, projeto físico e extração, transformação e carga no DW (ETL). • Modelagem Dimensional: Promove a definição do modelo de dados (modelagem dimensional) do DW; • Projeto Físico: Esta atividade é executada após a modelagem dimensional sendo re- alizada a partir dos seguintes passos: Definição de padrões de desenvolvimento para os diversos componentes do sistema de DW e BI, desenvolver o modelo físico de dados, instanciar a base relacional para a execução dos testes de ETL, desenvolver o modelo inicial de indexação dos dados, definição das politicas de segurança, audito- ria e criação da área de stagging2 , desenvolver a base OLAP, definição de agregações e criação da base física. • Projeto do ETL e Desenvolvimento: No trabalho de Kimball são descritos trinta e quatro subsistemas que, juntos, definem as diversas frentes de trabalho em um am- biente de desenvolvimento de ETL. Estes subsistemas se dividem em quatro subca- tegorias, que são extração de dados, limpeza e padronização dos dados, entrega dos dados para apresentação e gerenciamento do ambiente de ETL (CARVALHO, 2009). 2A área de stagging consiste numa área de armazenamento temporário dos dados antes que os mesmos sejamcarregados em um DM ou DW, servindo para a movimentação dos mesmos a partir de bases de dados diferentes(COSTA; ANCIÃES, 2001).
  35. 35. 34 5. Trilha das Aplicações de BI: Podemos listar algumas categorias básicas de aplicações de BI que vão desde acessos convencionais ad-hoc por consultas SQL até relatórios pré- definidos e dashboards3 , capazes de apresentar uma visão global de desempenho dos processos de negócio em uma interface unificada (CARVALHO, 2009). O desenvolvimento destas aplicações são iniciadas logo após a especificação de requisitos, primeiro com a compreensão dos relatórios mais utilizados pelos usuários e, em seguida, pelo desenho dos primeiros relatórios e aplicações que serão desenvolvidos (CARVALHO, 2009). A Trilha das Aplicações de BI compreende as seguintes atividades: • Projeto de Aplicações de BI: Com a ajuda do pessoal de negócio os desenvolvedores devem listar os principais relatórios que possam ser fornecidos pela aplicação de BI e que tragam valor ao negócio de modo que os modelos para estes relatórios possam ser criados e documentados. • Desenvolvimento da Aplicação de BI: A partir da especificação dos relatórios, os mesmos podem ser implementados pela equipe de desenvolvimento. 6. Integração e Implantação: Na atividade de integração todos os sistemas desenvolvidos são colocados no mesmo ambiente para a execução de testes globais. São realizados testes de qualidade de dados, testes das operações do processo, testes de desempenho, testes de implantação, testes de acessibilidade de usuários. Após a realização da bateria de testes pode se realizar a implantação do que foi desenvolvido na iteração. 7. Manutenção: Nesta etapa o sistema de DW é monitorado de modo a garantir seu pleno funcionamento, desde as atividades de back-end como as de front-end. Novas solicitações de desenvolvimento podem ser avaliadas e deve-se oferecer suporte especializado aos utilizadores do sistema. 8. Crescimento: Após a entrada em produção e a montagem da estrutura de manutenção e suporte, a expansão do DW é o primeiro grande desafio que o gerente do projeto enfrenta. É natural que a versão que acaba de entrar em produção contemple bem alguma área, que logo pedirá novos relatórios, enquanto outras áreas são menos atendidas e solicitam novos desenvolvimentos (CARVALHO, 2009). 9. Gerenciamento do Projeto: Suas atividades estão relacionadas com todo o processo de engenharia de DW. Dentre as atividades de gerenciamento durante o desenvolvimento do projeto estão a condução das reuniões de equipes, o sincronismo entre todas as frentes 3 Painelcom um conjunto de indicadores gráficos que, por estar num formato visual, facilita a compreensão eassimilação das informações. Geralmente estes indicadores gráficos são integrados entre si (ALMEIDA, 2010).
  36. 36. 35 de desenvolvimento e monitoração das atividades com frequente acompanhamento do cronograma geral.2.4 METODOLOGIAS ÁGEIS As metodologias ágeis surgem como uma resposta às crescentes pressões por inovaçãoem prazos cada vez mais reduzidos, às necessidades de constantes mudanças de requisitos eao mau desempenho de grande parte dos projetos de desenvolvimento de software. Por contadesses fatores, houve um movimento na comunidade de desenvolvimento de software, que deuorigem aos métodos ágeis. Posteriormente, o conceito chave deste movimento evoluiu, de umaabordagem técnica para o âmbito gerencial, criando um novo enfoque de gerenciamento deprojetos que pode ser denominado de Gerenciamento Ágil de Projetos (DIAS, 2005). Os métodos ágeis de desenvolvimento de software surgiram como uma reação aos métodosclássicos de desenvolvimento e do reconhecimento da necessidade preeminente de se criar umaalternativa a estes "processos pesados", caracterizados pelo foco excessivo na criação de umadocumentação completa a respeito do produto a ser desenvolvido (BECK et al., 2001). No anode 2001, dezessete (17) especialistas em processos de desenvolvimento de software represen-tando as metodologias SCRUM, XP e outras, estabeleceram princípios comuns compartilhadospor todos esses métodos. Foi então constituído o "Manifesto Ágil". O termo "MetodologiasÁgeis"torna-se então popular através do estabelecimento do manifesto (BECK et al., 2001). Osconceitos chave do "Manifesto Ágil"são: • Indivíduos e interações sobre processos e ferramentas; • Software executável sobre documentação; • Colaboração do cliente sobre negociação de contratos; • Respostas rápidas a mudanças sobre seguir planos. Traçando um comparativo com os chamados métodos clássicos de desenvolvimento desoftware, podemos observar que os métodos ágeis priorizam os itens situados a esquerda nadeclaração deste manifesto. Isto não significa que os itens a direita sejam desprezados. Agrande diferença é quanto ao foco e a importância que estes itens recebem em contraposiçãoaos métodos clássicos de desenvolvimento de software.
  37. 37. 36 Muitos especialistas criaram métodos próprios para se adaptar às constantes mudançasexigidas pelo mercado e as indefinições de requisitos iniciais dos projetos. A família dos méto-dos ágeis de desenvolvimento de software tem origem no agrupamento de todos estes métodos,como por exemplo o SCRUM, o XP e o FDD (DIAS, 2005). Os métodos SCRUM, FDD e XPserão detalhados nas subseções seguintes.2.4.1 SCRUM SCRUM é um framework ágil para gestão e planejamento de projetos de desenvolvimentode software (SCHWABER, 2004). Foi desenvolvido por Ken Schwaber e Mike Beedle na décadade 1990, baseando-se em experiências no desenvolvimento de sistemas e processos, a partir doreconhecimento de que o desenvolvimento de software é muito complexo para ser planejadocorretamente desde o início. Por ser um framework, SCRUM servirá como um guia de boaspráticas para atingir o sucesso. Entretanto, as decisões de quando e como usá-lo, quais táticase estratégias seguir para obter produtividade e realizar as entregas ficam por conta de quem oestiver aplicando. O conhecimento das suas práticas permite a aplicação destas de forma variadae este é um dos aspectos positivos do SCRUM, a adaptabilidade (PORTELA, 2009).2.4.1.1 CICLO DE VIDA O ciclo de vida do SCRUM é baseado em três fases principais, divididas em sub-fases:pré-planejamento, desenvolvimento e pós-planejamento (SCWABER; BEEDLE, 2002). • Pré-Planejamento: Nesta fase é definida a visão do produto e as expectativas dos stake- holders. Os requisitos dos clientes são coletados e priorizados para o planejamento dos trabalhos. Devem ser garantidos o financiamento/orçamento para a realização do projeto e os riscos associados ao projeto devem ser identificados; • Desenvolvimento: Nesta fase são executadas atividades de refinamento de requisitos, análise, projeto, desenvolvimento e testes, devendo resultar em um incremento funcional do produto que está sendo desenvolvido. • Pós-Planejamento: O ciclo de desenvolvimento é encerrado e avaliado. Realizada a demonstração e a liberação do incremento de produto ao cliente o time de trabalho deve refletir sobre as práticas empregadas, os indicadores finais e o aprendizado geral da equipe.
  38. 38. 37 Figura 9: Visão Geral do Processo SCRUM (MARÇAL, 2009). A Figura 9, mostra como funciona o ciclo completo do SCRUM. Este ciclo tem o seu progresso baseado em uma série de iterações bem definidas, cada umacom duração de 2 a 4 semanas, chamadas sprints. Antes de cada sprint, realiza-se uma reuniãode planejamento (sprint planning meeting) onde o time (equipe) de desenvolvedores entra emcontato com o representante do cliente (product owner) para priorizar o trabalho que precisaser feito (itens do product backlog), selecionar e estimar as tarefas que o time pode realizardentro da sprint construindo assim a lista de funcionalidades da sprint (sprint backlog). Apróxima fase é a execução da sprint onde o time controla o andamento do desenvolvimentorealizando reuniões diárias (daily meeting), não mais que 15 minutos de duração onde todosos participantes devem estar prioritariamente de pé, e observando o seu progresso usando umgráfico chamado sprint burndown. Ao final de cada sprint, é feita uma revisão no produto entregue para verificar se tudorealmente foi implementado. Realiza-se então uma reunião de revisão (sprint review), onde otime demonstra o produto gerado ao product owner e este valida se o objetivo foi atingido. Logoem seguida, realiza-se a reunião de retrospectiva (sprint retrospective), uma reunião de liçõesaprendidas, com a finalidade de melhorar o processo, ou o time e/ou produto para a próximasprint (PORTELA, 2009).
  39. 39. 382.4.1.2 ARTEFATOS Em (SCHWABER, 2004), os seguintes artefatos estão definidos para o SCRUM ao longo doseu fluxo de desenvolvimento: Product Backlog, Sprint Backlog e incremento de funcionalidadedo produto (MARÇAL, 2009). • Product Backlog: Contém uma lista de itens priorizados que incluem os requisitos fun- cionais e não funcionais do sistema que está sendo desenvolvido no projeto. O product backlog nunca está completo e evolui de acordo com a evolução do produto e do ambiente ao qual está inserido; • Sprint Backlog: Corresponde a lista de tarefas que o time do projeto define para imple- mentar na sprint os requisitos selecionados do product backlog; • Incremento de Funcionalidade: No SCRUM o time deverá entregar incrementos de funcionalidade a cada sprint. Os incrementos de funcionalidade consistem de códigos testados, bem estruturados e bem escritos, que são executáveis acompanhados da docu- mentação necessária para a sua operação.2.4.1.3 PAPÉIS (SCHWABER, 2004) define que as atividades no framework SCRUM são realizadas por trêspápeis: Product Owner, Scrum Master e Time (CAVALCANTI, 2009) (MARÇAL, 2009). • Product Owner: Define as funcionalidades do produto, os itens do product backlog, o valor de negócio para cada item do backlog, prioriza tais itens, aceita ou rejeita o resultado do trabalho. Pode ser o cliente, uma pessoa que represente o cliente, alguém de marketing e que deve estar disponível durante todo o projeto; • Scrum Master: Assegura que as práticas do SCRUM estão sendo executadas, remove os impedimentos levantados pelo time, protege o time de interferências externas, garante a colaboração entre os diversos papéis e funções; • Time: Estima e desenvolve as funcionalidades do produto; define como transformar o product backlog em incremento de funcionalidades numa iteração gerenciando seu próprio trabalho, sendo responsáveis coletivamente pelo sucesso da iteração e, conse- qüentemente, pelo projeto como um todo.
  40. 40. 392.4.1.4 MEDIÇÃO DE PROGRESSO No SCRUM, o monitoramento do progresso do projeto é realizado por meio de dois gráficosprincipais: Consumo do Produto (Product Burndown) e Consumo da Sprint (Sprint Backlog).Estes gráficos mostram ao longo do tempo a correlação entre a quantidade de trabalho que faltaser feita (em qualquer ponto) e o progresso do time do projeto em reduzir este trabalho (COHN,2005) (CAVALCANTI, 2009). • Product Burndown: Representa o quanto de story points foram entregues do produto em cada sprint. Ou seja, o gráfico é iniciado com o total de story points estimado para o projeto e a cada sprint são exibidos a quantidade ainda existente de story points. Deste modo ao compararmos as barras do gráfico podemos saber o quanto de story points foram consumidas a cada iteração e quanto ainda falta de story points a serem consumidas no projeto. A story points pode ser considerada como uma unidade de tamanho relativo utilizado na estimativa de requisitos como uma alternativa a unidade de tempo. Points é uma medida de complexidade a/ou tamanho de um requisito;Figura 10: Exemplo de Product Burndown exibindo o consumo de story points de cada sprint(CAVALCANTI, 2009). • Sprint Burndown: Representa a quantidade de horas restante da sprint, respectivamente, na linha do tempo como um todo. O gráfico inicia com o total de horas estimado para a sprint. A cada dia de trabalho deve ser marcado no gráfico a quantidade de horas ainda restante. Deste modo, fazendo a comparação entre dois dias no gráfico pode se saber a quantidade de horas consumidas.2.4.2 FDD FDD se baseia em processos bem definidos que podem ser repetidos. Além disso, suaabordagem é concentrada nas fases de projeto e construção tendo uma alta ênfase na modelagem
  41. 41. 40Figura 11: Exemplo de Sprint Burndown exibindo o consumo de horas das tarefas durante asprint (CAVALCANTI, 2009).do sistema em um ciclo de vida iterativo com algumas atividades de gerenciamento de projetos(UDO; KOPPENSTEINER, 2003). Um dos conceitos básicos utilizados é o conceito de features (funcionalidades). Segundo(PALMER; FELSING, 2002) o termo feature em FDD é muito específico correspondendo a umafunção de tamanho pequeno que represente algum tipo de valor para o cliente. Podem serrepresentadas a partir do seguinte template: <ação><resultado><objeto> com o uso de umapreposição apropriada entre a ação, o resultado e o objeto (Por exemplo: <calcular>o<total>deuma<venda> e <calcular>o<total de compras>de um<cliente> (JUNIOR, 2008)). O tamanho deuma feature não pode ultrapassar o tamanho definido para as iterações que é de duas semanas.2.4.2.1 CICLO DE VIDA Como pode ser visualizado na Figura 12 o processo de desenvolvimento de software baseadono FDD possui duas fases (Concepção/Planejamento e Construção) que podem ser divididas emcinco processos (Desenvolver um Modelo Abrangente, Construir a Lista de Funcionalidades,Planejar por Funcionalidade, Detalhar por Funcionalidade e Construir por Funcionalidade. 1. Concepção e Planejamento: Os processos realizados na fase de Concepção e Planeja- mento abrangem todo o projeto e são realizados apenas uma vez. • Desenvolver um Modelo Abrangente (DMA) - Análise Orientada por Objetos: É realizado um estudo dirigido sobre o escopo do sistema e seu contexto, além de estudos detalhados sobre o domínio de negócio para cada área a ser modelada. O objetivo geral é a elaboração de um modelo abrangente do sistema. Isto é realizado por sessões de modelagem de parte do domínio em grupos. O modelo abrangente é
  42. 42. 41 Figura 12: Ciclo de vida de um projeto com o FDD (HEPTAGON, 2010). construído e tem seu conteúdo atualizado iterativamente pela integração dos mode- los criados pelos grupos de modelagem; • Construir a Lista de Funcionalidades (CLF) - Decomposição Funcional: Deve- rão ser identificadas as funcionalidades que satisfaçam os requisitos. O domínio é decomposto funcionalmente em áreas de negócio, atividades de negócio dentro das áreas mapeadas e funcionalidades dentro das atividades de negócio mapeadas. Esse mapeamento permite estabelecer a lista categorizada de funcionalidades; • Planejar por Funcionalidade (PPF) - Planejamento Incremental: Tem o objetivo de produzir o plano de desenvolvimento do projeto. É definido a ordem na qual as funcionalidades serão implementadas, baseada nas dependências entre elas, na carga de trabalho da equipe de desenvolvimento e também na complexidade das funcionalidades a serem implementadas.2. Construção: Os processos realizados na fase de Construção são realizados uma vez para cada funcionalidade existente. • Detalhar por Funcionalidade (DPF) - Desenho (Projeto) Orientado por Objeto: Um conjunto de funcionalidades são agendadas para o desenvolvimento ao serem atribuídas a um programador líder. O programador-líder pode então formar uma equipe de funcionalidades identificando quais serão os proprietários das classes (de- senvolvedores). Esta equipe deverá produzir os diagramas de sequência para a(s) funcionalidade(s) atribuída(s). De posse desses diagramas o programador-lider re-
  43. 43. 42 aliza o refinamento do modelo de objetos. Os programadores então escrevem os prefácios das classes e métodos e realiza-se uma inspeção no projeto (design); • Construir por Funcionalidade (CPF) - Programação e Teste Orientados por Objetos: Seu objetivo é produzir uma função com valor para o cliente (funcio- nalidade). Iniciando com o pacote de projeto (design), os proprietários de classes implementam os itens necessários para que suas classes suportem o projeto para esta funcionalidade. O código desenvolvido passa pelo teste de unidade e pela inspeção em uma ordem determinada pelo programador-líder. Após passar pela inspeção, o código é promovido a versão atual (build).2.4.2.2 PAPÉIS FDD admite os seguintes principais pápeis dentro de um projeto: • Gerente do projeto: Responsável por todos os assuntos administrativos ligados ao pro- jeto. Sua principal função é oferecer subsídios para que nenhum fator externo interfira na produtividade da equipe; • Especialista do negócio: Deve usar o conhecimento a respeito do negócio para apresentar a equipe de projeto as necessidades para que o software possa ter real valor para o cliente. É um membro fixo da equipe e deve fornecer o feedback sobre as entregas a todos os envolvidos. Além disso, está disponível para o detalhamento das funcionalidades a todo o momento; • Arquiteto: Atua como um consultor da equipe em termos da arquitetura do sistema; • Gerente de desenvolvimento: Responsável por liderar o dia a dia do desenvolvimento do produto. Todos os conflitos técnicos entre os programadores-chefes estão sob sua responsabilidade; • Programador-chefe: Responsável por liderar pequenos grupos de desenvolvedores du- rante a construção das funcionalidades. Pode atuar como desenvolvedor sendo o respon- sável pelas classes mais complexas do sistema. Possui papel fundamental nas atividades de absorção do conhecimento do negócio e no planejamento das atividades; • Programador (Class Owner): Compõem as equipes de funcionalidades e realizam ativi- dades de programação, criação de diagramas, testes e documentação de funcionalidades.
  44. 44. 43 Para projetos maiores ou complexos, FDD fornece um conjunto maior de papéis, como porexemplo: Gerente de release, testadores, escritores técnicos, guru da linguagem, administradorde sistemas, implantadores dentre outros.2.4.3 XP O XP é um método ágil para pequenas e médias equipes desenvolverem software, em am-bientes com requisitos instáveis (DIAS, 2005). Suas práticas fundamentais tiveram origem nastradições do desenvolvimento em Smalltalk e datam de meados da década de 80, quando KentBeck e Ward Cunningham trabalhavam na Tektronixs, Inc. Práticas, tais como, refatoração,programação em par, mudanças rápidas, feedback constante do cliente, desenvolvimento itera-tivo, testes automatizados, entre outras, são pontos chave da cultura da comunidade Smalltalk.XP então pode ser considerado como o modo de agir do Smalltalk generalizado para outrosambientes (TELES, 2005). As práticas principais do XP estão descritas abaixo: (DIAS, 2005)(PORTELA, 2009) • Planing poker (jogo do planejamento): No jogo do planejamento são realizadas as esti- mativas para as estórias de usuário. Tarefas são definidas para cada estória e estimadas a fim de que se possa alocar um conjunto de estórias para a realização da iteração de acordo com a capacidade da equipe; • Pair programming (Programação em par): Todo código implementado deve ser feito em pares; • Pequenas versões: As versões do produto devem ser tão pequenas quanto possivel e trazerem valor para o negócio. Uma versão inicial do software deve ser colocada em produção após um pequeno número de iterações e, em seguida, outras versões devem ser disponibilizadas tão logo faça sentido; • Metáforas: A modelagem do sistema é realizada a partir de metáforas criadas pelos clientes, gerentes e programadores; • Projeto simples: Os programadores são estimulados a desenvolver o código da aplicação o mais simples possível; • Testes: Os programadores antes mesmo do desenvolvimento do código do sistema devem criar os testes de unidade e rodá-los. Isso vale para todo o código implementado. Deste modo todo o desenvolvimento do código é acompanhando de testes para cada módulo,
  45. 45. 44 para cada função implementada. Os testes de aceitação são escritos pelos clientes e são usualmente rodados no final de cada iteração; • Reengenharia de software: O código deve ser constantemente melhorado, sem que a funcionalidade do sistema seja alterada; • Integração contínua: Os programadores devem integrar os novos códigos ao software tão rapidamente e com a maior freqüência possível; • Propriedade coletiva do código: O código do programa deve ser propriedade de toda a equipe e qualquer integrante pode fazer alterações sempre que for necessário; • Cliente no local: O cliente deve trabalhar com a equipe de projeto a todo momento, respondendo perguntas, realizando testes de aceitação e assegurando que o desenvolvi- mento do software esteja sendo feito a seu contento; • Semana de 40 horas: Como trabalhar por longos períodos reduz o desempenho, o con- teúdo de cada iteração deve ser planejado de forma a não haver necessidade de realização de horas extras; • Padrão de codificação: No início do projeto deve ser criado um padrão de codificação, simples e aceito por toda a equipe, que deverá ser seguido de forma a padronizar e auxiliar na condução do trabalho.2.4.3.1 CICLO DE VIDA O ciclo de vida do XP é baseado nos ciclos trimestrais, as releases, e no ciclo semanal quesão as iterações. Uma release é composta portanto de diversas iterações. A Figura 13 ilustracomo funciona o ciclo semanal em XP: No ciclo trimestral ocorre o replanejamento do projeto. Deve-se pensar nos temas queserão implementados. Temas são visões mais gerais das funcionalidades do que as estórias deusuários. Ao final de um ciclo trimestral, a equipe também deve refletir sobre quais foram asdificuldades durante o andamento do ciclo e propor soluções. No ciclo semanal os desenvolve-dores reunem-se com o cliente com o propósito de entrarem em um acordo sobre o que deveráser implementado naquela semana. Para isso, é utilizada a dinâmica do jogo do planejamento(GUIMARÃES, 2009). O objetivo deste jogo é fazer com que os clientes descrevam quais funcionalidades desejamque sejam implementadas naquela semana de modo que os desenvolvedores possam estima-las
  46. 46. 45 Figura 13: Ciclo Semanal em XP.(GUIMARÃES, 2009). Inicialmente os clientes escrevem as estórias em cartões. Estas estóriasdescrevem as funcionalidade desejadas e são denominadas Estórias de Usuário e são o instru-mento de trabalho para as estimativas. Para iniciar o processo de estimativa a equipe de de-senvolvimento deve determinar a unidade de tempo que será utilizada para estimar os cartõespodendo ser qualquer medida (horas, minutos ou dias), desde que todos da equipe tenham cons-ciência de qual medida será utilizada durante o jogo. Cada membro deverá ter em mãos um conjunto de cartas como se fossem cartas de baralhoque indiquem as unidades da medida escolhida. O jogo ocorre da seguinte forma: um membroda equipe lê uma estória escrita pelo usuário. Cada membro da equipe deverá pensar quantotempo ele gastaria para desenvolver sozinho aquela funcionalidade sem nenhum tipo de inter-rupção. Após todos terem concluído sua estimativa as informações serão compartilhadas. Parainformar ao restante da equipe qual a sua estimativa, o membro deverá escolher uma carta, den-tre as do seu conjunto, que contenha o valor da sua estimativa. Quando o líder da equipe der aordem, todos devem mostrar sua estimativa ao mesmo tempo (GUIMARÃES, 2009). Havendo divergências o membro que estimou o maior tempo e o membro que estimou omenor tempo deverão confrontar as suas opiniões. Depois da estimativa das estórias, o clientedeve escolher quais estórias são prioritárias para o seu negócio. A quantidade de estórias se-lecionadas não deve ultrapassar o limite de horas de trabalho daquela semana. Com isso osdesenvolvedores dividem as estórias em tarefas e as implementam. No final do ciclo os desen-volvedores demonstram o que foi feito e o cliente aprova ou não o trabalho resultante. Alémdisso é realizada um retrospectiva para avaliar o trabalho realizado durante o ciclo semanal
  47. 47. 46(GUIMARÃES, 2009).2.4.3.2 PAPÉIS XP não mantém uma estrutura rigída de pápeis. O principal objetivo é fazer com que todoscontribuam de acordo com suas habilidades nas etapas do projeto (GUIMARÃES, 2009). • Testadores: Auxiliam os clientes e programadores na elaboração dos testes que devem ser feitos para garantir que o software está correto; • Designers de interação: Ajudam os clientes nas definições das estórias e auxiliam na criação e refinamento da interface; • Arquitetos: Auxiliam os programadores, estimulam a refatoração do código. Realizam testes mais amplos que envolvam toda a arquitetura; • Gerentes de Projeto: É um facilitador na comunicação entre a equipe de desenvolvi- mento, clientes e demais fornecedores. Deve também gerenciar o progresso da equipe, motivando-os sempre que necessário; • Gerentes de Produto: Auxiliam na definição de estórias e temas além de serem respon- sáveis por reduzir o escopo da iteração quando sentir atraso na equipe; • Executivos: Representam os usuários do sistema e ajudam na definição do escopo e ob- jetivos do projeto. Têm a responsabilidade de definir as prioridades de desenvolvimento, informando as estórias que mais trazem retorno para a organização; • Redatores técnicos: Responsáveis por criar e manter a documentação do projeto que, assim como o código, evolui de maneira iterativa; • Usuários: Dão feedback sobre o que está sendo desenvolvido, ajudam na escolha das estórias uma vez que conhecem o domínio e quais funcionalidades devem ser implemen- tadas primeiro; • Programadores: Deverão estimar as estórias e depois implementá-las. São os respon- sáveis por escrever testes para todo o código desenvolvido, além de refatorá-lo sempre que necessário.
  48. 48. 472.5 CONSIDERAÇÕES FINAIS Neste capítulo foram detalhados os principais conceitos que possibilitam a compreensãoda proposta deste trabalho. As metodologias ágeis utilizadas na composição do FDWS foramdescritas de modo que possa-se perceber quais práticas e como cada uma delas relaciona-secom a proposta deste trabalho. Além dos métodos ágeis, foram detalhadas metodologias para gerência e desenvolvimentode projetos de BI que envolvem Data Warehousing. No próximo capítulo será feita a análise dos trabalhos relacionados a essa proposta de modoque as principais contribuições deste trabalho possam ser evidenciadas.
  49. 49. 483 AVALIAÇÃO DE TRABALHOS RELACIONADOS Neste capítulo são discutidos os trabalhos relacionados a proposta dessa monografia demodo que ao final possa-se estabelecer parâmetros de comparação com a proposta que é feitaneste trabalho.3.1 AGILE DATA WAREHOUSING A metodologia Agile Data Warehousing foi criada a partir das metodologias SCRUM e XP(HUGHES, 2007) para a gerência e o desenvolvimento de projetos de Data Warehousing. Ociclo de desenvolvimento definido pelo Agile Data Warehousing e sua integração com o ciclodo SCRUM é ilustrado na Figura 14.Figura 14: Ciclo de Desenvolvimento Agile Data Warehousing. Adaptado de (HUGHES, 2007).

×