AGILEKDD: AN AGILE PROCESS MODEL TO KNOWLEDGE DISCOVERY IN DATABASES AND BUSINESS INTELLIGENCE SYSTEMATIZATION

AGILEKDD: AN AGILE PROCESS MODEL TO KNOWLEDGE DISCOVERY IN DATABASES AND BUSINESS INTELLIGENCE SYSTEMATIZATION Givanildo Santana do Nascimento (Petrobras, Sergipe, Brasil) - gsnascimento@petrobras.com.br Adicinéia Aparecida de Oliveira (Universidade Federal de Sergipe, Sergipe, Brasil) - adicineia@ufs.br In the context of knowledge-based economies and Knowledge Society, the global competition is increasingly based on the capacity of transforming data into information, information into knowledge and knowledge into value. Data, information and knowledge constitute fundamental intangible assets for all organizations working in this social and economical model. In this context, the mission of Software Engineering is to produce systems able to process large volumes of data, transform them into relevant knowledge and deliver them to customers, so they can make right decisions at the right time. The development of this kind of systems must have the guidance of a process capable of conduct the transformation of customers business requirements into explicit knowledge and software products, observing harder time, budget and quality constraints. The Knowledge Discovery in Databases and Business Intelligence systematization effort has resulted in several process models. However, companies still face failures in determining the process model used in their Knowledge Discovery in Databases and Business Intelligence projects. The available processes still do not consider Software Engineering fundamental capabilities as projects, requirements and changes managements disciplines. Several existing processes are unsuitable to the ever-changing business environments or lack of scientific experimentation in real cases, in order to confirm their qualities and identify their shortcomings. The process proposed in this work, the AgileKDD, aims to integrate the best practices of the main Knowledge Discovery in Databases processes with an agile software process. The AgileKDD applicability was verified by a real case study, in which common problems such as requirements changes and poor data quality strongly influenced the project results. The case study pointed out some process improvement needs, which were considered in AgileKDD refinement. The resulting refined process can be applied as an adaptive and flexible framework to develop software systems capable of discover knowledge from data and information. The process supports the early and continuous delivery of value to the costumer by means of an iterative and incremental lifecycle, immediate response to changes, as well as the adaptability and flexibility intrinsic to agile processes. Keywords: Software Process, Knowledge Discovery in Databases, Business Intelligence, Agile Software Development. 3120

I. INTRODUÇÃO A Organização para a Cooperação Econômica e Desenvolvimento definiu as economias, baseadas em conhecimento, como economias que são diretamente baseadas na produção, distribuição e uso de conhecimento e informação (OECD, 1996). No contexto das economias baseadas em conhecimento e, de forma mais ampla, na Sociedade do Conhecimento, a competição global é cada vez mais baseada na capacidade de transformar dados em informações, informações em conhecimento e conhecimento em valor. O conhecimento equipara-se aos fatores tradicionais de produção terra, capital, matériaprima, energia e mão-de-obra no processo de criação de riqueza. Desta forma, dados, informação e conhecimento constituem-se ativos intangíveis fundamentais para todas as organizações que atuam neste modelo sócio-econômico. Os processos produtivos tradicionais estão evoluindo para modelos de produção intensivos em informação e conhecimento e esta é uma das principais preocupações dos gestores no século XXI (BRASIL, 2010). As empresas estão organizadas como grandes coleções de processos que consomem e produzem quantidades crescentes de dados e informações (GONÇALVES, 2000). Os dados têm a capacidade de acumular conhecimento sobre os processos de negócio e este conhecimento, por sua vez, pode ser utilizado na análise e melhoria dos processos. De acordo com Pressman (2006), ao longo da história, a computação nas organizações evoluiu dos Centros de Processamento de Dados (CPD) para as Gerências de Tecnologia da Informação e a grande maioria do software desenvolvido durante esse período teve como finalidade processar dados e produzir informações. A Engenharia de Software, como sustenta Pressman, tem o desafio de construir software que processe dados e informações e produza conhecimento. A Descoberta de Conhecimento em Bases de Dados (DCBD), ou Knowledge Discovery in Databases (KDD), é o processo de busca e extração de conhecimento em bases de dados (BOENTE, OLIVEIRA e ROSA, 2007). Os Sistemas de Descoberta de Conhecimento em Banco de Dados (Sistemas de DCBD) apoiam a Gestão do Conhecimento possibilitando a extração e a disseminação de conhecimento organizacional oculto em grandes volumes de dados provenientes dos processos de negócio (DIAS, 2001). O Business Intelligence (BI) integra uma categoria de aplicações e tecnologias voltadas para a transformação de dados em informações e conhecimento (GOLFARELLI, RIZZI e CELLA, 2004). Fayyad et al. (1996) definiram DCBD como o processo não trivial de identificação de padrões válidos e potencialmente úteis, perceptíveis a partir dos dados. A Mineração de Dados (MD) é uma das principais técnicas utilizada tanto no BI quanto na DCBD, chegando a ser confundida com a própria DCBD (MARISCAL, MARBÁN e FERNÁNDEZ, 2010). Os Sistemas de DCBD são desenvolvidos a partir de tecnologias como BI e DCBD, formando um arcabouço essencial para as organizações que competem no contexto sócioeconômico do conhecimento. Esses sistemas são vitais para organizações que desejam desenvolver, integrar, gerenciar e compartilhar informações e conhecimento como ativos indispensáveis para o alcance dos objetivos organizacionais. Por exemplo, os investimentos feitos pela Continental Airlines em BI tiveram um Retorno sobre Investimento, ou Return on Investment (ROI), equivalente a 1000%, atribuídos ao aumento nas vendas e à redução de custos (ALNOUKARI et al., 2012; WATSON et al., 2006; WIXOM et al., 2008). Com o objetivo de sistematizar as atividades relacionadas à implementação de Sistemas de DCBD, alguns modelos de processos e metodologias foram propostos. Os dois modelos mais utilizados, citados na literatura e suportados por ferramentas, são o KDD 3121

Process (FAYYAD et al., 1996) e o CRoss Industry Standard Process for Data Mining (CRISP-DM) (CHAPMAN et al., 2000). Diversos outros processos foram propostos com o mesmo objetivo, entretanto o KDD Process e o CRISP-DM continuaram sendo os principais modelos e os outros processos são considerados variações deles (ALNOUKARI e SHEIKH, 2012; MARISCAL, MARBÁN e FERNÁNDEZ, 2010; ALNOUKARI et al., 2012). O KDD Process, o CRISP-DM e as suas variações são centrados nas técnicas de MD e não contemplam ciclos de vida, fases, disciplinas, papeis, produtos de trabalho e outros elementos tipicamente presentes na Engenharia de Sistemas de Software (KURGAN e MUSILEK, 2006). Entretanto, tais elementos são indispensáveis no desenvolvimento de Sistemas de DCBD. Por isso, Dias (2001) propôs um modelo para formalização do processo de desenvolvimento de Sistemas de DCBD. Nesse modelo, os dados são armazenados em um Data Warehouse (DW) 1 antes de serem submetidos aos algoritmos de mineração de dados. A partir do modelo de processo proposto por Dias (2001), Valentin (2006) descreveu uma arquitetura de referência para Sistemas de DCBD. Sobre esta arquitetura de referência, foi definido o Unified Process for Knowledge Discovery in Database (UPKDD) (HERDEN, 2007; HERDEN et al., 2011), um processo de software baseado no Processo Unificado (PU) 2 para aplicações analíticas centradas em objetivos de descoberta de conhecimento. O UPKDD oferece uma sequência ordenada e disciplinada de atividades para especificação, projeto, implementação e evolução de Sistemas de DCBD. 1.1 Problemática e Hipótese Apesar da prioridade dada pelas organizações à DCBD nos últimos anos, dos processos, metodologias e ferramentas criados, muitos projetos de DCBD não atingiram os seus objetivos ou foram cancelados (MARISCAL, MARBÁN e FERNÁNDEZ, 2010). O agravamento da crise financeira internacional provocou cortes significativos nos orçamentos de Tecnologia da Informação (TI) das organizações a partir de 2009, privilegiando iniciativas mais produtivas e econômicas, em detrimento das que possuem maior risco e maior prazo para ROI. Por esses motivos, o BI deixou de ocupar o primeiro lugar na lista das dez maiores prioridades em TI em 2010 e 2011, caindo para o quinto lugar na lista (GARTNER GROUP, 2005, 2006, 2007, 2008, 2009, 2010, 2011). Outro estudo revelou que mais de cinquenta por cento dos projetos de BI tiveram baixa aceitação ou falharam devido à baixa qualidade dos dados e à falta de envolvimento dos clientes (GARTNER GROUP, 2005). Assim como o desenvolvimento de sistemas de processamento operacional, o desenvolvimento de sistemas de processamento analítico, aqui denominados Sistemas de DCBD, deve ser guiado por processos de software. No entanto, as organizações ainda falham na determinação do modelo de processos utilizado para o desenvolvimento de Sistemas de DCBD (ALNOUKARI, 2011). À medida que os requisitos de negócio tornamse mais dinâmicos e incertos, os processos de software tradicionais tornam-se menos adequados ao desenvolvimento deste tipo de sistemas. Larson (2012) afirma que os processos tradicionais de desenvolvimento de software não são efetivos no 1 O Data Warehouse é uma coleção de dados orientada por assuntos, integrada, não-volátil e variante em relação ao tempo, que tem por objetivo apoiar os processos de tomada de decisão (INMON, 1997). 2 O Processo Unificado determina um conjunto de atividades necessárias para transformar requisitos em sistemas de software, de forma iterativa e incremental (JACOBSON, BOOCH e RUMBAUGH, 1999). 3122

desenvolvimento de Sistemas de DCBD porque são incompatíveis com a dinâmica e a evolução constante dos ambientes de negócios corporativos. O processo adotado para a implementação da maioria dos projetos de DCBD é o CRISP-DM, sendo este o padrão de facto. Contudo a adoção do CRISP-DM vem caindo devido à ausência de atividades relacionadas ao gerenciamento de projetos, requisitos e mudanças e à Engenharia de Software de forma geral (MARBÁN et al., 2008). Portanto, o desenvolvimento de Sistemas de DCBD necessita de um processo de software que garanta o envolvimento do cliente em todas as etapas e a qualidade mínima dos dados operacionais, antecipe o retorno do investimento, contenha disciplinas para gerenciamento de projetos, requisitos e mudanças. O processo precisa ser suficientemente simples para ser compreendido e seguido por seus praticantes, sem aumentar a complexidade natural dos projetos de DCBD. Essas características esperadas de um processo para desenvolvimento de Sistemas de DCBD vão ao encontro dos valores presentes no Manifesto para o Desenvolvimento Ágil de Software (BECK et al., 2001). Estes valores estão presentes nos processos ágeis de software, os quais são caracterizados por flexibilidade, adaptabilidade, comunicação face a face e fluxo contínuo de conhecimento entre as equipes de projetos (ALZOABI, 2012; LARSON, 2012). A hipótese deste trabalho é: um processo ágil de software pode aumentar o fator de sucesso dos projetos de desenvolvimento de Sistemas de DCBD em cenários nos quais há mudanças nos requisitos e baixa qualidade dos dados operacionais. 1.2 Contribuições Esperadas Com o desenvolvimento deste trabalho, podem-se apontar as seguintes contribuições: Avaliação dos processos de DCBD existentes; Adequação dos processos de DCBD a um processo ágil de Engenharia de Software; Definição de um processo ágil de software para a Engenharia de Sistemas de DCBD; Melhoria do fator de sucesso dos projetos de Sistemas de DCBD, minimizando os riscos de fracasso causados por mudança nos requisitos durante os projetos e baixa qualidade dos dados operacionais; e, Melhoria da satisfação dos clientes dos projetos de Sistemas de DCBD por meio da entrega antecipada e contínua de produtos de software, antecipando, por conseguinte, o retorno do investimento. 1.3 Organização do artigo Este artigo está organizado da seguinte forma: a seção um, que corresponde a esta introdução, trata da contextualização, problemática, hipótese, objetivos, contribuições esperadas e organização deste artigo. A seção dois apresenta o enquadramento metodológico desta pesquisa. A seção três aborda os processos para descoberta de conhecimento em bancos de dados existentes. A seção quatro descreve o processo AgileKDD, suas fases, atividades e papeis. O estudo de caso que confirmou a aplicabilidade do AgileKDD é apresentado na seção cinco. A seção seis explica o refinamento do processo AgileKDD a partir dos pontos de melhoria identificados no estudo de caso. Finalmente, a seção sete apresenta as conclusões, as considerações finais, as principais contribuições, limitações deste trabalho e as oportunidades de trabalhos futuros. 3123

II. METODOLOGIA A Figura 1 apresenta o enquadramento metodológico desta pesquisa. Sob o ponto de vista da sua natureza, esta pesquisa é aplicada, pois objetiva gerar conhecimentos para aplicação prática, dirigidos à solução de problemas específicos. Quanto à forma de abordagem do problema, esta pesquisa é qualitativa 3, pois é baseada na interpretação dos resultados e na atribuição de significados descritivos (MIGUEL, 2007). Na pesquisa qualitativa, diferentemente da quantitativa, o pesquisador busca compreender os fenômenos observando-os, interpretando-os e descrevendo-os (MELLO et al., 2012). Com relação aos seus objetivos, esta pesquisa é exploratória, pois visa proporcionar maior familiaridade com o problema com vistas a torná-lo explícito ou a construir hipóteses (GIL, 1996). Ela envolve levantamento bibliográfico e análise de exemplos que estimulam a compreensão. Este tipo de pesquisa assume, em geral, as formas de revisões bibliográficas e estudos de caso (SILVA, 2005). Sob a ótica dos procedimentos técnicos, esta pesquisa utilizará Estudo de Caso 4 para a validação de hipóteses. Para Severino (2007), esta modalidade de pesquisa científica se concentra no estudo de um caso particular, considerado representativo de um conjunto de casos análogos. Portanto, esta pesquisa é Aplicada, Qualitativa, Exploratória, com Estudo de Caso. O estudo de caso é um estudo de natureza empírica que investiga um determinado fenômeno dentro de um contexto real. Trata-se de uma análise aprofundada de um ou mais objetos (casos), para que permita o seu amplo e detalhado conhecimento (GIL, 1996; MIGUEL, 2007). Seu objetivo é aprofundar o conhecimento acerca de um problema não suficientemente definido, visando estimular a compreensão, sugerir hipóteses e questões ou desenvolver a teoria. Os estudos de casos podem ser classificados segundo a quantidade de casos como caso único ou casos múltiplos. A principal tendência das pesquisas realizadas com estudo de caso é que estes tentem esclarecer o motivo pelo qual foram tomadas uma decisão ou um conjunto de decisões, como foram implementadas e como os resultados foram alcançados (YIN, 2001). 3 Em pesquisas qualitativas os pesquisadores analisam os resultados indutivamente, sem utilizarem obrigatoriamente de métodos estatísticos, como acontece nas pesquisas quantitativas (MIGUEL, 2007). 4 Pesquisas com estudos de casos podem ser caracterizadas como exploratórias, pois provêem ao pesquisador e sua audiência um maior conhecimento sobre o tema, relacionando um caso real às teorias do assunto (MIGUEL, 2007). 3124

Enquadramento Metodológico Natureza da pesquisa Abordagem do problema Natureza do objetivo Procedimentos técnicos Aplicada Qualitativa Exploratória Estudo de caso Básica Quantitativa Descritiva Pesquisaação Qualiquantitativa Explanatória Pesquisa bibliográfica Pesquisa documental Pesquisa participante Figura 1 Enquadramento metodológico desta pesquisa. A Figura 2 ilustra o método de condução de estudos de casos definido por Miguel (2007) e adotado neste trabalho. Primeiramente, foi definida uma estrutura conceitualteórica acerca do tema estudado. Em seguida, planejou-se a execução do caso ou dos casos que serão trabalhados. Na sequência, o caso foi executado e os dados resultantes da execução do caso foram coletados e analisados. Finalmente, esta dissertação foi redigida para descrever a execução e as conclusões do trabalho. Este trabalho foi executado de acordo com o seguinte roteiro: (i) Definição da estrutura conceitual-teórica: revisão da literatura relacionada aos processos de BI e DCBD, associando-os aos processos da Engenharia de Software. Ao final desta fase, foi elaborado o processo AgileKDD, visando à solução dos problemas encontrados nos processos estudados. (ii) Planejamento do caso: foi selecionado um caso real de uma necessidade de Sistema de DCBD em uma empresa integrada de energia, para ser desenvolvido de acordo com o processo AgileKDD. (iii) Condução do piloto: o Sistema de DCBD foi desenvolvido visando à confirmação da aplicabilidade do processo AgileKDD. (iv) Coleta de dados: durante a condução do piloto, os dados relativos ao desenvolvimento do produto com base no processo AgileKDD foram coletados. (v) Análise dos dados: os dados coletados foram analisados e, com base nesta análise, o processo AgileKDD foi refinado. (vi) Geração do relatório: a presente dissertação foi escrita com a finalidade de descrever todas as etapas da pesquisa. 3125

Figura 2 Método de condução de estudos de casos. Fonte: Miguel (2007). III. PROCESSOS PARA DESCOBERTA DECONHECIMENTO EM BANCOS DE DADOS O esforço de sistematização da DCBD resultou em uma variedade de processos, cuja evolução, desde a definição do KDD Process em 1993, a definição do CRISP-DM em 2000 e do ASD-BI em 2012, está ilustrada na Figura 3. Entre todos os processos apresentados nesta figura, o KDD Process e o CRISP-DM destacam-se como os mais adotados, mais citados na literatura e suportados por ferramentas de DCBD. Esses dois processos são considerados os padrões de facto na área da DCBD (KURGAN e MUSILEK, 2006; MARISCAL, MARBÁN e FERNÁNDEZ, 2010; ALNOUKARI e SHEIKH, 2012; ALNOUKARI et al., 2012). Outro processo que merece destaque por associar as atividades da DCBD às práticas da Engenharia de Software é o Unified Process for Knowledge Discovery in Database, o qual é baseado no Processo Unificado. O KDD Process, o CRISP-DM e o UPKDD serão apresentados individualmente e, ao final do capítulo, serão comparados com o objetivo de destacar as lacunas deixadas por eles. 3.1 KDD Process O KDD Process foi proposto por Fayyad et al. (1996) como o resultado da primeira iniciativa de sistematização da DCBD, caracterizando-a como uma atividade multidisciplinar que envolve Bancos de Dados, Estatística, Reconhecimento de Padrões, Inteligência Computacional, entre outras disciplinas. O termo Process está relacionado à ideia de que a DCBD envolve um conjunto de passos que precisam ser executados para a descoberta de conhecimento útil a partir de um conjunto de dados. 3126

Figura 3 Evolução dos processos de DCBD, do KDD Process ao ASD-BI. Fonte: Adaptado de Mariscal, Marbán e Fernández (2010). O KDD Process é um processo iterativo e interativo, composto por nove passos que transformam dados operacionais em ações baseadas no conhecimento descoberto. O processo é interativo porque se não houver mecanismos de comunicação com o usuário, principalmente no domínio da aplicação, para a avaliação de padrões interessantes, a busca torna-se inválida e inadequada. É iterativo porque possibilita repetições entre quaisquer dos seus nove passos. A natureza iterativa proporciona maior interação do usuário ao processo de descoberta, visto que não é suficiente apenas seguir passos, mas sim interagir com o processo de descoberta várias vezes até que o conhecimento esperado pelo especialista seja encontrado. As iterações dos passos do processo indicam mais interação do usuário e a obtenção de conhecimento mais preciso, já que os refinamentos só podem ser realizados pelos usuários e não automaticamente pelas técnicas de mineração de dados (HERDEN, 2007). O primeiro passo tem como objetivo entender o domínio de negócio do qual se deseja extrair conhecimento. No segundo passo um conjunto de dados no qual será aplicada a descoberta de conhecimento é selecionado. Em seguida é realizada a limpeza para remoção de ruídos e inconsistências dos dados, além do preenchimento de valores importantes ausentes nos dados originais. No quarto passo é feita a redução no número de variáveis consideradas pelo processo de DCBD e a busca por representações invariantes dos dados, nas quais a MD é infrutífera. Continuando o fluxo do processo, os objetivos do projeto de DCBD, definidos no primeiro passo, são relacionados a um método de MD, para que sejam selecionados os algoritmos de MD no passo seguinte (FAYYAD et al., 1996). O sétimo passo é o da MD, no qual algoritmos procuram por relações de similaridade ou discordância entre dados, com o objetivo de encontrar padrões, irregularidades e regras. Os resultados da MD são interpretados por pessoas que possuem conhecimento tácito acerca do domínio de negócio. Caso sejam encontrados padrões inválidos, incoerentes ou os objetivos do projeto não sejam plenamente atingidos, volta-se a qualquer dos passos anteriores para que sejam realizados ajustes, até que sejam satisfeitas todas as expectativas do usuário. Finalmente, o conhecimento extraído dos dados é utilizado para subsidiar a tomada de decisões, podendo ser também representado, documentado e enviado ao seu 3127

público de interesse (FAYYAD et al., 1996). Uma possibilidade não prevista por Fayyad et al. (1996) é tradução do conhecimento descoberto para uma linguagem de representação do conhecimento, a fim de preservá-lo em bases de conhecimento. A Figura 4 ilustra o KDD Process com foco nas transformações realizadas nos dados até atingirem o grau de conhecimento que conduz à ação. O processo foi resumido na figura aos cinco passos nos quais os dados são transformados em informações e conhecimento. O passo 1 foi suprimido; o passo 2 é exibido com o rótulo de Seleção; os passos 3 e 4 são resumidos como Transformação; os passos 5, 6 e 7 são apresentados como Data Mining; o passo 8 é apresentado sem adaptações; e, finalmente, o passo 9 é representado pelas ações tomadas com base no conhecimento descoberto. Figura 4 KDD Process resumido. Fonte: Fayyad et al. (1996). O passo 7, Mineração de Dados, é o mais abordado pela literatura. Muitos trabalhos abordam as definições e otimizações dos algoritmos e ferramentas de mineração de dados. Entretanto, os outros passos são tão importantes quanto o sétimo para o sucesso de um projeto de DCBD (FAYYAD et al., 1996). O algoritmo mais eficiente para mineração de dados aplicado sobre um conjunto de dados mal selecionado não resultará em conhecimento útil. Da mesma maneira, a presença de ruídos em dados bem selecionados levará a distorções nos resultados da mineração de dados. Por fim, se não forem interpretados, os padrões minerados não serão convertidos em conhecimento e ação. 3.2 Cross-Industry Standard Process for Data Mining CRISP-DM O Cross-Industry Standard Process for Data Mining (CRISP-DM) é um modelo de processos iterativo, genérico e padronizado para o uso de mineração de dados (CHAPMAN et al., 2000). O CRISP-DM organiza o processo de MD em seis fases, descrevendo um roteiro a ser seguido pelas organizações que desejam planejar e executar projetos de MD. As fases e o ciclo iterativo descrito pelo processo são ilustrados pela Figura 5. A fase inicial do processo, Entendimento do Negócio, visa o entendimento dos objetivos do projeto e dos requisitos, sob o ponto de vista do negócio. Com base nesse entendimento, o problema de mineração de dados é definido e um plano preliminar do projeto é produzido. A fase Entendimento dos Dados inicia com uma coleta de dados e prossegue com atividades que visam descrever e explorar os dados, identificar problemas de qualidade e detectar subconjuntos interessantes para formar hipóteses da informação escondida. A terceira fase, Preparação de Dados, cobre todas as atividades de construção 3128

de um conjunto de dados (dataset) de trabalho. As atividades desta fase incluem a seleção, a limpeza, o preenchimento, a integração e a formatação dos dados (CHAPMAN, 2000). As fases do CRISP-DM e as atividades prescritas para elas estão apresentadas na Figura 5. Na fase Modelagem, técnicas de modelagem são selecionadas e aplicadas e seus parâmetros são ajustados para valores ótimos. Modelagem aqui significa encontrar um ou mais modelos que sejam compatíveis com os dados submetidos à MD. Ou seja, os modelos gerados correspondem aos padrões e às regras induzidos a partir dos dados. Geralmente, existem várias técnicas para o mesmo tipo de problema de mineração de dados, tais como indução de árvores de decisão, geração de redes neurais, regras de associação, entre outras. Algumas dessas técnicas têm requisitos específicos quanto à formatação dos dados, por isso pode ser necessário retornar à fase de preparação de dados. Nesta fase os conjuntos de dados de testes e treinamento são separados. O conjunto de testes tem a finalidade de assegurar a qualidade e a validade do modelo. A execução das técnicas de MD propriamente ditas ocorre na atividade Construir Modelo de Dados. A última atividade desta fase compreende a avaliação do modelo gerado (CHAPMAN, 2000). Entendimento do Negócio Entendimento dos Dados Preparação dos Dados Modelagem Avaliação Utilização Determinar Objetivos do Negócio Coleta Inicial de Dados Selecionar Dados Selecionar Técnicas de Modelagem Avaliar Resultados Planejar Publicação Avaliar Situação Descrever Dados Limpar Dados Gerar Projeto de Testes Revisar Processo Planejar Monitoram. e Manutenção Determinar Objetivos da MD Explorar Dados Construir Dados Construir Modelo Determinar Próximos Passos Produzir Relatório Final Produzir Plano de Projeto Verificar Qualidade dos Dados Integrar Dados Avaliar Modelo Revisar Projeto Formatar Dados Figura 5 Fases e atividades do CRISP-DM. Fonte: Shearer (2000). Na fase Avaliação, o modelo (ou os modelos) construído na fase anterior é avaliado e são revistos os passos executados na sua construção para se ter certeza de que o modelo representa os objetivos do negócio identificados na primeira fase. O propósito principal é determinar se existe algum objetivo de negócio importante que não foi alcançado. Após o modelo ser construído e avaliado, ele é publicado e interpretado na fase Utilização. Nesta fase, podem-se recomendar ações e decisões a serem tomadas com base nos resultados modelados ou pode-se repetir o fluxo com um novo conjunto de dados (DIAS, 2001). O projeto CRISP-DM 2.0 é uma proposta de evolução do CRISP-DM pela inclusão do suporte a novos tipos de dados como texto e conteúdo Web, além de novas técnicas para o pré-processamento e a análise dos dados. O projeto também prevê a integração da DCBD com as técnicas de Gerenciamento de Processos de Negócio. O CRISP-DM 2.0 também modificará os conjuntos de fases, atividades e produtos de trabalho do processo atual (MARISCAL, MARBÁN e FERNÁNDEZ, 2010). 3129

3.3 Unified Process for Knowledge Discovery in Database UPKDD O Unified Process for Knowledge Discovery in Database (UPKDD) é definido como um processo de software para aplicações de tecnologias analíticas e centradas em objetivos de descoberta de conhecimento (HERDEN, 2007). O UPKDD tem como referências principais os seguintes processos, arquiteturas e práticas: (1) disciplinas de DCBD segundo o KDD Process; (2) definição e implementação da arquitetura de DW segundo a Data Mart Bus Architecture; (3) Práticas de ES segundo o PU; e (4) conjunto de Elementos- Chave artefatos, papeis e atividades das áreas de processo, arquitetura e implementação de soluções de sistemas de apoio à decisão. Os princípios, as fases, os workflows e também os elementos-chave do UPKDD, são similares aos estabelecidos no processo de software PU (HERDEN et al., 2011). O UPKDD divide-se em duas fases: Concepção e Elaboração. As atividades do processo estão distribuídas nas disciplinas de Requisitos, Análise e Projeto. O processo não considera as disciplinas de Implementação e Teste, nem as fases de Construção e Transição do PU, devido às incertezas e às dependências do ambiente de implantação do Sistema de DCBD, também porque o UPKDD nada acrescenta a essas fases e disciplinas em relação ao PU. O processo é modelado em linguagem UML, com os diagramas de pacotes, atividades, caso de uso e classes, para representar a visão geral e as disciplinas do processo (HERDEN et al., 2011). Na fase de Concepção são definidos a visão do sistema, as listas de requisitos funcionais e não funcionais e os principais modelos de análise. Também é realizada a caracterização das ferramentas que serão utilizadas na implementação, juntamente com o modelo de projeto. Na fase Elaboração ocorre o detalhamento dos casos de usos, a definição da arquitetura do sistema, com foco na arquitetura do DW. Finalmente, o modelo dimensional do DW é elaborado. A Figura 6 mostra uma visão geral do UPKDD em um diagrama de atividades. O fluxo inicia na disciplina de Requisitos, na qual as expectativas do cliente são mapeadas, a visão do projeto é definida e os dados operacionais disponíveis são examinados. Na disciplina de Análise, os casos de uso são detalhados e na disciplina Projeto, a arquitetura dimensional do sistema é definida e o modelo dimensional é elaborado. Figura 6 Diagrama de atividades do processo UPKDD. Fonte: Herden et al. (2011). O UPKDD define os seguintes papeis para as pessoas envolvidas nos projetos: Engenheiro de Conhecimento responsável pela aquisição de conhecimento a partir das informações de negócio do sistema. Especialista de KDD implementa aplicações analíticas de MD e OLAP em resposta ao contexto de tomada de decisão. Usuário final ou Tomador de decisão visualiza as informações e o conhecimento descoberto, assim como determina os requisitos do projeto. Sob o ponto de vista da arquitetura de software, o UPKDD utiliza uma arquitetura de referência para Sistemas de DCBD definida por Valentin (2006). Essa arquitetura descreve o ciclo de vida dos dados desde as Fontes Operacionais, passando por uma Área de Estágio 3130

até serem preservados definitivamente em um DW. O DW passa a ser a fonte de dados preferencial para as operações de OLAP e MD. Os padrões, regras e tendências identificados na análise dos dados, são mantidos em uma base de conhecimento, definida genericamente como Armazém de Resultados. No UPKDD o DW é estruturado de acordo com a arquitetura Data Mart Bus Architecture, segundo Kimball e Ross (2002). Desta forma, o DW é composto por uma coleção de DM e não existe a figura do repositório central corporativo de dados (HERDEN, 2007; HERDEN et al., 2011). 3.4 Comparação dos processos Os três processos descritos neste capítulo foram comparados quanto às suas fases, disciplinas, arquitetura e papeis. Também foram observadas as capacidades relativas à gestão de projeto, configuração e mudança. Outro fator analisado foi a capacidade de controlar o ciclo de vida dos dados desde as fontes operacionais, passando pelo DW e culminando numa base de conhecimento. Quanto ao número de fases, o KDD Process é dividido em nove fases, o CRISP-DM em seis e o UPKDD em duas. O KDD Process e o CRISP-DM não especificam as disciplinas nas quais o esforço do projeto é distribuído. Já o UPKDD especifica as disciplinas Requisitos, Análise e Projeto. Este mesmo processo está alicerçado no PU e no KDD Process, utiliza a arquitetura de referência de Valentin (2006) e, como arquitetura de DW, a Data Mart Bus Architecture (KIMBALL e ROSS, 2002). No UPKDD o Armazém de resultados tem propósito semelhante ao de uma base de conhecimento. Quanto aos papeis, o UPKDD define o Engenheiro de conhecimento, o Especialista de KDD e o Usuário final ou tomador de decisão. Entre todas essas propriedades, somente as fases são especificadas no KDD Process e no CRISP-DM. Tanto o KDD Process quanto o CRISP-DM utilizam a MD como principal forma de exploração analítica dos dados. O KDD Process, inclusive, recomenda que as técnicas de MD sejam aplicadas sobre um ambiente DW, visto que este tipo de ambiente apresenta condições de qualidade e acesso aos dados favoráveis para a MD. No UPKDD a principal forma de exploração dos dados é por ferramentas OLAP operando sobre os DM que compõem o DW. As fases 1 (Entender o domínio da aplicação) e 2 (Selecionar um conjunto de dados alvo) do KDD Process são equivalentes às fases 1 (Entendimento do Negócio) e 2 (Entendimento dos Dados) do CRISP-DM. Já no UPKDD essa equivalência ocorre com a fase 1 (Concepção). As fases 3 (Limpeza e pré-processamento dos dados) e 4 (Redução e projeção de dados) do KDD Process são equivalentes à fase 3 (Preparação de Dados) do CRISP-DM e à 2 (Elaboração) do KDD Process. Já as fases 5 (Relacionar os objetivos do projeto a um método de MD), 6 (Escolha do algoritmo de MD) e 7 (Mineração de dados) do KDD Process correspondem à fase 4 (Modelagem) do CRISP-DM. As fases 8 (Interpretação) e 9 (Utilização do conhecimento descoberto) do KDD Process possuem os mesmos propósitos das fases 5 (Avaliação) e 6 (Utilização) do CRISP-DM, respectivamente. Todas essas fases não possuem correspondência no UPKDD. O controle do ciclo de vida dos dados é realizado parcialmente pelo UPKDD. Na arquitetura empregada neste processo, o repositório histórico dos dados continua sendo as bases operacionais, uma vez que não existe a figura do DW corporativo normalizado e de granularidade atômica. O processo também não especifica a estrutura do armazém de 3131

resultados para que ele possa ser considerado uma base de conhecimento. Para isto, seria necessária a utilização de técnicas para representação e preservação do conhecimento. No tocante às capacidades para gestão de projetos e gestão de configuração e mudança, nenhum dos três processos contempla. E, finalmente, esses processos não possuem ciclos de vida iterativos e incrementais, como é comum se observar em processos considerados ágeis. Na comparação entre as fases dos processos de DCBD e de ES, também é possível estabelecer relações de correspondência, como mostra o Quadro 1. As fases do KDD Process, do CRISP-DM e do UPKDD apresentam similaridades às do Processo Unificado e do OpenUP (SANTOS, 2009; HRISTOV, 2011). No entanto, somente no processo ágil de software OpenUP existem disciplinas específicas para gestão de projetos, configuração e mudanças. Quadro 1 Comparação entre as fases dos processos de DCBD e os processos de software. KDD Process 1 Entender o domínio da aplicação. 2 Selecionar um conjunto de dados alvo. CRISP-DM UPKDD Processo Unificado 1 Entendimento do Negócio. 2 Entendimento dos Dados. OpenUP 1 Concepção. 1 Concepção. 1 Concepção. 3 Limpeza e préprocessamento dos dados. 4 Redução e projeção de dados. 3 Preparação de Dados. 2 Elaboração. 2 Elaboração. 2 Elaboração. Fases 5 Relacionar os objetivos do projeto a um método de MD. 6 Escolha do algoritmo de MD. 4 Modelagem. Não possui. 3 Construção. 3 Construção. 7 Mineração de dados. 8 Interpretação. 5 Avaliação. Não possui. 4 Transição. 4 Transição. 9 Utilização do conhecimento descoberto. 6 Utilização. Faz Gestão de Projeto? Não. Não. Não. Sim. Sim. Faz Gestão de Configuração e Mudança? Não. Não. Não. Não. Sim. É iterativo e incremental? Não. Não. Não. Não. Sim. O último fator a ser mencionado na comparação diz respeito à utilização dos processos de DCBD em projetos acadêmicos e industriais. Segundo Kurgan e Musilek (2006), a maior parte das utilizações do KDD Process ocorreram em projetos acadêmicos, enquanto o CRISP-DM teve maior aceitação na indústria. Foi encontrada uma referência sobre a utilização do UPKDD em um projeto comercial, porém com o propósito acadêmico de avaliar experimentalmente o processo por meio de um estudo de caso (HERDEN et al., 2011). 3132

IV. AGILEKDD: UM PROCESSO ÁGIL PARA A ENGENHARIA DE SISTEMAS DE DESCOBERTA DE CONHECIMENTO O desenvolvimento de Sistemas de DCBD necessita da definição de processos que contemplem tanto os aspectos de Banco de Dados e Inteligência Computacional quanto as disciplinas da ES. Um processo dessa natureza, que também seja ágil e disciplinado, pode melhorar o fator de sucesso dos projetos de DCBD e, consequentemente, a promoção deste tipo de sistemas nas organizações. Desta forma, finalmente será possível dar o passo seguinte ao longo do espectro traçado por Pressman (2006) e desenvolver sistemas que processem dados e informações e produzam conhecimento. 4.1 Introdução ao processo AgileKDD O AgileKDD é um processo ágil e disciplinado para o desenvolvimento de Sistemas de DCBD, alicerçado pelos processos OpenUP, KDD Process e CRISP-DM (NASCIMENTO e OLIVEIRA, 2012a, 2012b). O OpenUP fornece o suporte relativo à ES, agregando também os valores e os princípios presentes no Manifesto para o Desenvolvimento Ágil de Software, especialmente a colaboração e a comunicação contínua entre os atores do processo, sem abrir mão das disciplinas de gerenciamento. Já o KDD Process e o CRISP-DM contribuem com os elementos específicos da DCBD relativos ao pré-processamento e mineração dos dados e ao pós-processamento do conhecimento descoberto. O esforço pessoal em um projeto AgileKDD está organizado em micro-incrementos. Cada micro-incremento representa uma unidade de trabalho que produz um passo do progresso do projeto. O processo aplica a colaboração intensiva à medida que o sistema é desenvolvido incrementalmente por uma equipe comprometida e auto-organizada. Estes micro-incrementos fornecem um ciclo de feedback extremamente curto que direciona decisões adaptativas durante cada iteração. O AgileKDD divide o projeto em iterações planejadas e com intervalos de tempo definidos, medidos em semanas. As iterações direcionam a equipe na entrega incremental do valor aos stakeholders de uma forma previsível. O plano de iteração define o que deve ser entregue durante a iteração e o resultado é uma versão demonstrável ou entregável do produto de software. As equipes dos projetos se auto-organizam para definir como atingir os objetivos da iteração e entregar o resultado. Elas fazem isso definindo e distribuindo tarefas detalhadas de uma lista de itens de trabalho. O processo define um ciclo de vida de iteração que estrutura como os micro-incrementos são aplicados para entregar versões estáveis e coesas do sistema, desenvolvidas incrementalmente até que todos os objetivos da iteração sejam alcançados. O ciclo de vida de projeto fornece aos stakeholders e à equipe visibilidade e pontos de decisão durante a execução do projeto. Este ciclo possibilita uma efetiva supervisão do projeto e pontos de controle para avaliação de resultados e revisão do planejamento. Um plano de projeto define o ciclo de vida e o resultado final é uma aplicação liberada. 4.2 Fases e atividades do AgileKDD O AgileKDD estrutura o ciclo de vida do projeto em quatro fases: Concepção, Elaboração, Construção e Transição. A Figura 7 apresenta uma visão geral das fases e atividades do AgileKDD. Resumidamente, o processo recebe como insumos os requisitos do projeto, a documentação e os dados dos sistemas operacionais e produz incrementos de 3133

software entregues sucessivamente ao cliente, até que todos os requisitos viáveis sejam contemplados. 4.2.1 Concepção A fase de Concepção (I) é a primeira das quatro fases no ciclo de vida do AgileKDD. Esta fase é representada na Figura 7 pela letra I (Inception). Desta fase resulta um entendimento geral sobre a visão, o escopo, os objetivos, a seleção dos dados alvo, a viabilidade e o planejamento geral do projeto. Os projetos podem ter uma ou mais iterações nesta fase, cujo foco recai na identificação dos requisitos, na comunicação com o cliente e no planejamento do projeto. Esta fase recebe como entradas os requisitos do projeto, os modelos de processos de negócio, os Diagramas Entidade-Relacionamento (DER), os dicionários de dados e os casos de uso dos sistemas transacionais, além das fontes de dados operacionais, sobre as quais os processos de descoberta de conhecimento serão executados. A fase de Concepção tem como saídas o documento de visão, o glossário inicial do projeto, a avaliação de viabilidade e riscos, o plano de projeto e os protótipos. Figura 7 Fases e atividades do AgileKDD inicial. As atividades entender o domínio da aplicação (I1) e identificar a visão e os objetivos do projeto de DCBD (I2) estão relacionadas à disciplina Gerência de Requisitos. A atividade entender o domínio da aplicação tem como objetivo principal analisar e desenvolver um conhecimento acerca do domínio de negócios no qual a aplicação está inserida. Esse conhecimento pode ser obtido em modelos de processos de negócio, na documentação dos sistemas transacionais, em entrevistas com os stakeholders e qualquer 3134

outra técnica de elicitação de requisitos. Um dos produtos de trabalhos criados nesta atividade é o glossário inicial do projeto, um documento no qual os principais termos e conceitos envolvidos no sistema são definidos. A atividade identificar a visão e os objetivos do projeto de DCBD (I2) tem como principal saída o documento de visão do projeto. A visão do projeto fornece uma descrição de alto nível para os requisitos funcionais e as restrições de projeto do sistema. A essência do sistema é apresentada e serve como entrada para o processo de aprovação do projeto, comunicando o propósito e os objetivos gerais do sistema. Na atividade selecionar um conjunto de dados alvo (I3), um conjunto de dados no qual será aplicada a descoberta de conhecimento é selecionado a partir das fontes de dados operacionais. Em geral, esses dados são obtidos nos bancos de dados operacionais dos sistemas OLTP, num subconjunto das tabelas mantidas por estes sistemas. A atividade gerir projeto, configuração e mudanças (I4) tem o objetivo principal de criar os planos de projeto e de configuração (versionamento, rótulos, ramos, etc.), bem como fazer a gestão das mudanças que o projeto ou a iteração provocarão nos dados e nos softwares existentes. Além de criar estes planos, o gerente de projeto avalia a viabilidade e os riscos do projeto com a equipe e atualiza Avaliação inicial de risco. A lista de riscos ajudará a equipe na priorização do que deve ser feito em cada iteração. Os riscos elevados são direcionados para as iterações iniciais. 4.2.2 Elaboração A fase de Elaboração (E) tem foco na análise e no projeto (design) do sistema, na comunicação com o cliente e na definição da arquitetura. Os insumos desta fase são as entradas e saídas da fase de Concepção. As saídas da fase de Elaboração compreendem a descrição da arquitetura do software, os modelos de DW e DM, os mapeamentos de origem dos dados e os dados pré-processados. As atividades limpeza e pré-processamento dos dados (E1) e redução e projeção de dados (E2) preparam os dados operacionais para o processamento analítico e a mineração de dados. O processo de preparação consiste na remoção de inconsistências, preenchimento de dados ausentes, agregação, redução da granularidade, entre outras tarefas inerentes ao pré-processamento dos dados. A atividade definir arquitetura (E3) especifica como os componentes e módulos do sistema serão integrados. Os sistemas desenvolvidos segundo o processo AgileKDD têm o DW estruturado de acordo com a Hub and Spoke Architecture (INMON, 1997; INMON, STRAUSS e NEUSHLOSS, 2008). O processamento analítico e a mineração dos dados serão realizados por aplicações conectadas aos DM. A forma de carregamento e a frequência de atualização dos dados das fontes de dados operacionais (que podem estar dispersas geograficamente) para o DW são especificadas no escopo da atividade definir arquitetura. Também é definido se o DW será centralizado ou se haverá instâncias distribuídas dele. A arquitetura especifica também a forma de acesso aos dados pelas ferramentas de exploração (OLAP e MD), bem como os mecanismos de autenticação e autorização para acesso ao sistema pelo usuário final. A saída produzida por esta atividade é a descrição da arquitetura do software. A atividade verificar qualidade dos dados (E4) tem como objetivo confirmar que os dados operacionais disponíveis têm a consistência e a integridade necessárias para o desenvolvimento do projeto. Esta é uma atividade crítica e essencial, uma vez que problemas na qualidade dos dados podem inviabilizar projetos de BI e DCBD. 3135

Na atividade modelar DW e DM (E5), o DW é modelado de acordo com a modelagem relacional normalizada. Já os DM, agrupados por assuntos ou processos de negócio, são modelados de acordo com o paradigma dimensional. A modelagem do DW é composta pelos diagramas Entidade-Relacionamento, pelos dicionários de dados, bem como pelos mapeamentos de origem dos dados. Primeiramente são criados modelos conceituais, representando as entidades, os fatos, as dimensões e os relacionamentos, numa perspectiva de alto nível. Os modelos conceituais são facilmente compreendidos e validados por todos os participantes do projeto. Após a validação, os modelos conceituais são transformados em modelos físicos, voltados para as tecnologias de implementação de banco de dados. A partir do projeto físico do DW, é elaborado um mapeamento dos dados disponíveis nas fontes de dados operacionais para o DW. 4.2.3 Construção A fase de Construção (C) traduz o modelo de projeto em produtos integrados de software implementados de acordo com arquitetura definida na fase de Elaboração. Desta fase resultam principalmente os incrementos de software validados e preparados para serem entregues aos clientes e usuários. A atividade ETL (C1) produz as rotinas responsáveis por extrair, transformar e carregar os dados das fontes de dados operacionais para o DW. Os processos ETL são programados para executarem periodicamente, mantendo o DW sincronizado com as fontes de dados operacionais. As tarefas de transformação dos processos ETL também realizam remoção de inconsistências, preenchimento de dados ausentes, agregação, redução da granularidade, entre outras tarefas inerentes ao pré-processamento dos dados. A atividade denominada mineração de dados (C2) consiste na aplicação de algoritmos para extrair modelos ou padrões dos dados. Nesta atividade, os métodos de MD capazes de fazer o reconhecimento de padrões (árvores de decisão, máquinas de vetores de suporte, métodos estatísticos, redes neurais, algoritmos genéticos, entre outros) são aplicados sobre os dados carregados no DW. Para isso, são utilizadas ferramentas que disponibilizam os diversos algoritmos já implementados, testados e otimizados, para uso em uma série de aplicações. A criação de consultas OLAP (C3) consiste no mapeamento do DW em uma ferramenta OLAP, criando uma representação lógico-conceitual compreensível pelos usuários. A partir desse mapeamento, são criados relatórios, gráficos e dashboards predefinidos e personalizáveis. Também é oferecida ao usuário uma interface para a construção de consultas personalizadas (ad-hoc) a partir dos mapeamentos do DW. A atividade integração de dados e aplicações (C4) trata da pesquisa pelos conceitos criados no DW em Data Marts já existentes. Esta atividade analisa também os impactos causados pelas mudanças que podem ser necessárias para modificação dos conceitos existentes. Os possíveis impactos incluem mudanças em aplicações que já acessam os conceitos que serão modificados. O objetivo da atividade verificação e validação (C5) é assegurar que o software cumpra as suas especificações e atenda às necessidades dos usuários e clientes. A verificação confere se o software está sendo desenvolvido de acordo com a sua especificação, respondendo à seguinte pergunta: Estamos construindo certo o produto?. Já a validação busca assegurar que o software atenda às necessidades dos usuários: Estamos construindo o produto certo?. As técnicas de verificação e validação incluem a inspeção de software e os testes de software. Nesta atividade do AgileKDD, os resultados da mineração de dados e das consultas OLAP são confrontados com as fontes de dados operacionais. Assim, verifica-se não apenas os métodos de exploração do DW como 3136

também os processos ETL que carregam os dados das fontes operacionais para o DW. A validação inclui também a homologação do software pelo cliente. 4.2.4 Transição A fase de Transição (T) tem o objetivo de entregar o software para o cliente explorar, interpretar e utilizar as informações e o conhecimento. Esta fase também contribui para a melhoria contínua do processo, por meio de uma retrospectiva que reflete sobre a adequação do processo ao projeto implementado. A atividade GCM e publicação (T1) tem o propósito de rotular os artefatos do projeto, implantar os objetos de banco de dados, os processos ETL e o software executável nos ambientes de desenvolvimento, homologação e produção. A publicação consiste da execução de scripts, da configuração e agendamento dos processos ETL e da instalação do software necessário para a entrega do software ao usuário. Trata-se de uma atividade de infraestrutura, realizada juntamente com a gerência de configuração do software. Cada versão publicada dos artefatos deve ser rotulada, a fim de identificar a versão do software que está sendo entregue para homologação ou produção. A interpretação (T2) é uma atividade relacionada essencialmente aos resultados da mineração de dados. O conhecimento descoberto é submetido à análise das pessoas detentoras do conhecimento tácito, capazes de discernir acerca da validade das regras e dos padrões reconhecidos a partir dos dados. Após a interpretação, o conhecimento refinado e validado é utilizado (T3) pela organização no suporte à tomada de decisão e na melhoria dos seus processos de negócio. A retrospectiva (T4) é uma atividade relacionada à melhoria contínua do processo e à sua melhor adequação ao projeto. Ao final de cada iteração, uma retrospectiva é realizada para que a equipe identifique as atividades e atitudes que contribuíram para o alcance dos objetivos e as que devem ser aperfeiçoadas ou ignoradas para a melhor adequação do processo ao projeto. 4.3 Papeis das pessoas no AgileKDD O AgileKDD define os seguintes papeis para as pessoas envolvidas nos projetos: Gerente de Projeto conduz o planejamento do projeto, coordena as interações com os clientes e mantêm o time focado em alcançar os objetivos do projeto. Arquiteto responsável por definir a arquitetura de software, incluindo a tomada das principais decisões técnicas que orientam todo o design e a implementação do projeto. Analista de Requisitos representa os interesses do cliente e do usuário final colhendo informações dos clientes para entender o problema a ser resolvido, capturando os requisitos e definindo suas prioridades. Administrador de dados responsável pelo entendimento e avaliação da qualidade das bases de dados OLTP, pela modelagem e documentação do Data Warehouse e dos Data Marts. Testador é responsável pelas principais atividades de verificação e validação. Estas atividades incluem identificar, definir, implementar e conduzir os testes necessários, bem como registrar e analisar os resultados dos testes. Desenvolvedor responsável por desenvolver as rotinas ETL, executar os algoritmos de mineração de dados, criar as consultas OLAP e implementar a integração de dados e soluções. 3137

Cliente representa grupos de interessados cujas necessidades devem ser satisfeitas pelo projeto. 4.4 Disciplinas do AgileKDD As disciplinas do processo AgileKDD são as mesmas do OpenUP: Requisitos, Arquitetura, Desenvolvimento, Teste, Gestão de Projeto e Gestão de Configuração e Mudança, como apresenta o Quadro 2. Durante um ciclo completo de projeto, a maior parte do esforço da disciplina de Requisitos é concentrada na fase de Concepção. A Arquitetura é a principal disciplina durante a fase de Elaboração. Nesta mesma fase, o Desenvolvimento é intensificado a partir da definição da arquitetura do sistema e continua como principal disciplina da fase de Construção. Os testes ocorrem principalmente na tarefa Verificação e Validação da fase de Construção. A disciplina de Gestão de Projeto está concentrada predominantemente na fase de Concepção. A Gestão de Configuração e Mudança tem maior destaque na fase de Transição. Cada disciplina pode ser relacionada a um conjunto de produtos de trabalho criados durante as fases do processo. Quadro 2 Produtos de trabalho em cada disciplina do AgileKDD. Disciplina Propósito Produtos de Trabalho Requisitos Elicitar, analisar, especificar, validar e gerenciar os requisitos para o sistema a ser desenvolvido. Documento de visão. Glossário inicial do projeto. Protótipos. Arquitetura Desenvolvimento Teste Gestão de Projeto Gestão de Configuração e Mudança Definir uma arquitetura para os componentes do sistema. Projetar e implementar uma solução técnica que seja aderente à arquitetura e atenda aos requisitos. Validar a maturidade do sistema através do projeto, implementação, execução e avaliação dos testes. Instruir, ajudar e suportar a equipe, ajudando-a a lidar com os riscos e obstáculos encontrados quando da construção de software. Controlar as mudanças nos artefatos, assegurando uma evolução sincronizada do conjunto de Produtos de Trabalho que compõem um sistema de software. Descrição da arquitetura do software. Modelos de DW e DM. Componentes de software. Incremento integrado de software. Plano e procedimento de teste. Registro de teste. Plano de projeto. Avaliação de viabilidade e riscos. Lista de itens de trabalho. Uma vez definido o processo, faz-se necessário verificar a sua aplicabilidade em projetos de Sistemas de DCBD reais e confirmar se os resultados esperados pela aplicação do processo são alcançados. Esta verificação foi realizada por meio de um estudo de caso no qual o processo foi aplicado e os seus efeitos sobre a execução do projeto foram registrados sob o ponto de vista da Engenharia de Software. O estudo de caso indicou melhorias que posteriormente foram aplicadas ao processo visando à sua melhor adequação a projetos de Sistemas de DCBD gerenciados de acordo com os valores e princípios do Manifesto para o Desenvolvimento Ágil de Software. 3138

V. ESTUDO DE CASO Após a definição do processo AgileKDD, foi necessário validar a sua aplicabilidade no desenvolvimento de Sistemas de DCBD. Para tanto, foi selecionado um projeto de Sistema de DCBD da área de Petróleo e Gás, executado em quatro iterações, como mostra a Figura 8. Estas iterações tiveram a finalidade de construir e entregar o produto de formas adaptativa, iterativa e incremental, verificando a aplicabilidade do processo AgileKDD a um projeto de Sistema de DCBD. A primeira iteração do projeto foi destinada exclusivamente à fase de Concepção (I). A segunda iteração teve como objetivo atender aos requisitos funcionais de mineração de dados. A terceira iteração teve como objetivo calcular e apresentar os indicadores de gestão da atividade atendida pelo estudo de caso. A quarta iteração contemplou os requisitos funcionais de processamento analítico (OLAP). Figura 8 Iterações realizadas na implementação do estudo de caso. O estudo de caso escolhido permitiu avaliar a aplicabilidade do processo em um projeto real, influenciado por restrições de prazo, escopo e qualidade comuns em projetos comerciais. As seguintes características do estudo de caso permitiram que ele confirmasse a aplicabilidade do AgileKDD: (i) Abrangência. O estudo de caso contemplou tanto requisitos de MD como de OLAP, além dos indicadores de gestão. As atividades definidas no processo AgileKDD foram suficientemente abrangentes para suportarem a implementação de todos os requisitos. (ii) Houve mudanças nos requisitos. A execução do estudo de caso foi influenciada por mudanças nos requisitos de negócio do cliente. O AgileKDD proporcionou a resposta rápida às mudanças dos requisitos, demonstrando a adaptabilidade esperada em um processo ágil. (iii) Houve problemas de qualidade de dados. O alcance dos objetivos do projeto também foi influenciado por problemas de qualidade nos dados operacionais submetidos à DCBD. Esses problemas, ocorridos na execução do estudo de caso, permitiram identificar pontos de melhoria no processo. (iv) Equipe multidisciplinar. O estudo de caso foi implementado por uma equipe multidisciplinar e distribuída geograficamente. Nesses cenários, a comunicação é um fator crítico para o sucesso do projeto de software. O 3139