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

Tamanho: px
Começar a partir da página:

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

Transcrição

1 AGILEKDD: AN AGILE PROCESS MODEL TO KNOWLEDGE DISCOVERY IN DATABASES AND BUSINESS INTELLIGENCE SYSTEMATIZATION Givanildo Santana do Nascimento (Petrobras, Sergipe, Brasil) - Adicinéia Aparecida de Oliveira (Universidade Federal de Sergipe, Sergipe, Brasil) - 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

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 software entregues sucessivamente ao cliente, até que todos os requisitos viáveis sejam contemplados 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

16 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 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

17 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 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

18 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 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

19 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

20 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

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Planejamento Estratégico de TI. Prof.: Fernando Ascani

Planejamento Estratégico de TI. Prof.: Fernando Ascani Planejamento Estratégico de TI Prof.: Fernando Ascani Data Warehouse - Conceitos Hoje em dia uma organização precisa utilizar toda informação disponível para criar e manter vantagem competitiva. Sai na

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

DATA WAREHOUSE. Introdução

DATA WAREHOUSE. Introdução DATA WAREHOUSE Introdução O grande crescimento do ambiente de negócios, médias e grandes empresas armazenam também um alto volume de informações, onde que juntamente com a tecnologia da informação, a correta

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI 1. PI06 TI 1.1. Processos a serem Atendidos pelos APLICATIVOS DESENVOLVIDOS Os seguintes processos do MACROPROCESSO

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Curso Data warehouse e Business Intelligence

Curso Data warehouse e Business Intelligence Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Apresentação Os projetos de Data Warehouse e Business Intelligence são dos mais interessantes e complexos de desenvolver

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com Sistemas de informação Disciplina: Introdução a SI Noções de sistemas de informação Turma: 01º semestre Prof. Esp. Marcos Morais

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Data Warehouse Processos e Arquitetura

Data Warehouse Processos e Arquitetura Data Warehouse - definições: Coleção de dados orientada a assunto, integrada, não volátil e variável em relação ao tempo, que tem por objetivo dar apoio aos processos de tomada de decisão (Inmon, 1997)

Leia mais

Resumo dos principais conceitos. Resumo dos principais conceitos. Business Intelligence. Business Intelligence

Resumo dos principais conceitos. Resumo dos principais conceitos. Business Intelligence. Business Intelligence É um conjunto de conceitos e metodologias que, fazem uso de acontecimentos e sistemas e apoiam a tomada de decisões. Utilização de várias fontes de informação para se definir estratégias de competividade

Leia mais

srbo@ufpa.br www.ufpa.br/srbo

srbo@ufpa.br www.ufpa.br/srbo CBSI Curso de Bacharelado em Sistemas de Informação BI Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Tópicos Especiais em Sistemas de Informação Faculdade de Computação Instituto

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI

Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI Janeiro de 2011 p2 Usuários comerciais e organizações precisam

Leia mais

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Francisco Xavier Freire Neto 1 ; Aristides Novelli Filho 2 Centro Estadual de Educação Tecnológica

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

Gerenciamento de Projetos Modulo III Grupo de Processos

Gerenciamento de Projetos Modulo III Grupo de Processos Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Processos de Gerenciamento de Projetos Para que um projeto seja bem-sucedido,

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Metodologia de Gerenciamento de Projetos da Justiça Federal

Metodologia de Gerenciamento de Projetos da Justiça Federal Metodologia de Gerenciamento de Projetos da Justiça Federal Histórico de Revisões Data Versão Descrição 30/04/2010 1.0 Versão Inicial 2 Sumário 1. Introdução... 5 2. Público-alvo... 5 3. Conceitos básicos...

Leia mais

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES Trabalho de Graduação Orientando: Vinicius Stein Dani vsdani@inf.ufsm.br Orientadora: Giliane

Leia mais

APLICAÇÃO DE MINERAÇÃO DE DADOS PARA O LEVANTAMENTO DE PERFIS: ESTUDO DE CASO EM UMA INSTITUIÇÃO DE ENSINO SUPERIOR PRIVADA

APLICAÇÃO DE MINERAÇÃO DE DADOS PARA O LEVANTAMENTO DE PERFIS: ESTUDO DE CASO EM UMA INSTITUIÇÃO DE ENSINO SUPERIOR PRIVADA APLICAÇÃO DE MINERAÇÃO DE DADOS PARA O LEVANTAMENTO DE PERFIS: ESTUDO DE CASO EM UMA INSTITUIÇÃO DE ENSINO SUPERIOR PRIVADA Lizianne Priscila Marques SOUTO 1 1 Faculdade de Ciências Sociais e Aplicadas

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC CURSO: Bacharelado em Ciência da Computação DISCIPLINA: ANPS Análise e Projeto de Sistemas AULA NÚMERO: 3 DATA: PROFESSOR: Murakami Sumário 1 APRESENTAÇÃO...1 2 DESENVOLVIMENTO...1 2.1 Revisão...1 2.1.1

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4.

SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4. SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4.1 Armazenamento... 5 4.2 Modelagem... 6 4.3 Metadado... 6 4.4

Leia mais

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

Leia mais

Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura

Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Apresentação Os projetos de Data Warehouse e Business Intelligence são dos mais interessantes e complexos de desenvolver

Leia mais

TECNOLOGIA DA INFORMAÇÃO. Prof. Leandro Schunk

TECNOLOGIA DA INFORMAÇÃO. Prof. Leandro Schunk TECNOLOGIA DA INFORMAÇÃO Módulo 4 Governança de TI Dinâmica 1 Discutir, em grupos: Por que então não usar as palavras ou termos Controle, Gestão ou Administração? Qual seria a diferença entre os termos:

Leia mais

Construção de um Sistema de Informações Estratégicas, Integrando Conhecimento, Inteligência e Estratégia.

Construção de um Sistema de Informações Estratégicas, Integrando Conhecimento, Inteligência e Estratégia. Construção de um Sistema de Informações Estratégicas, Integrando Conhecimento, Inteligência e Estratégia. Introdução Sávio Marcos Garbin Considerando-se que no contexto atual a turbulência é a normalidade,

Leia mais

CobiT 5. Como avaliar a maturidade dos processos de acordo com o novo modelo? Conhecimento em Tecnologia da Informação

CobiT 5. Como avaliar a maturidade dos processos de acordo com o novo modelo? Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação CobiT 5 Como avaliar a maturidade dos processos de acordo com o novo modelo? 2013 Bridge Consulting All rights reserved Apresentação Sabemos que a Tecnologia da

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

VISÃO SISTÊMICA EM GERENCIAMENTO DE PROJETOS PARA WEB

VISÃO SISTÊMICA EM GERENCIAMENTO DE PROJETOS PARA WEB VISÃO SISTÊMICA EM GERENCIAMENTO DE PROJETOS PARA WEB Rogério Fernandes da Costa Professor especialista Faculdade Sumaré rogerio.fernandes@sumare.edu.br Resumo: O presente estudo tem como objetivo abordar

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO

FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO @ribeirord FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO Rafael D. Ribeiro, M.Sc,PMP. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br Lembrando... Aula 4 1 Lembrando... Aula 4 Sistemas de apoio

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Processo de software I Ricardo de Sousa Britto rbritto@ufpi.edu.br + O que é Engenharia de Software n Definição dada pela IEEE [IEE93]: n Aplicação de uma abordagem sistemática,

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Gerenciamento de Projetos Modulo III Grupo de Processos

Gerenciamento de Projetos Modulo III Grupo de Processos Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

Leia mais

ADMINISTRAÇÃO DOS RECURSOS DE DADOS

ADMINISTRAÇÃO DOS RECURSOS DE DADOS Capítulo 7 ADMINISTRAÇÃO DOS RECURSOS DE DADOS 7.1 2003 by Prentice Hall OBJETIVOS Por que as empresas sentem dificuldades para descobrir que tipo de informação precisam ter em seus sistemas de informação?

Leia mais

ROBSON FUMIO FUJII GOVERNANÇA DE TIC: UM ESTUDO SOBRE OS FRAMEWORKS ITIL E COBIT

ROBSON FUMIO FUJII GOVERNANÇA DE TIC: UM ESTUDO SOBRE OS FRAMEWORKS ITIL E COBIT ROBSON FUMIO FUJII GOVERNANÇA DE TIC: UM ESTUDO SOBRE OS FRAMEWORKS ITIL E COBIT LONDRINA - PR 2015 ROBSON FUMIO FUJII GOVERNANÇA DE TIC: UM ESTUDO SOBRE OS FRAMEWORKS ITIL E COBIT Trabalho de Conclusão

Leia mais

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos.

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos. A GESTÃO DE PROJETOS EXISTENTE NA NORMA DO-178B Matheus da Silva Souza, matheusdasilvasouza@gmail.com Prof. Dr. Luiz Alberto Vieira Dias, vdias@ita.br Instituto Tecnológico de Aeronáutica Praça Marechal

Leia mais

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004 Introdução ao RUP Rational Unified Process por Denize Terra Pimenta Outubro/2004 1 Contexto Não é suficiente apenas a presença de desenvolvedores altamente treinados: Precisamos de uma linguagem para a

Leia mais

Processos de gerenciamento de projetos em um projeto

Processos de gerenciamento de projetos em um projeto Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

4. PMBOK - Project Management Body Of Knowledge

4. PMBOK - Project Management Body Of Knowledge 58 4. PMBOK - Project Management Body Of Knowledge No Brasil, as metodologias mais difundidas são, além do QL, o método Zopp, o Marco Lógico do Banco Interamericano de Desenvolvimento (BID) e o Mapp da

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit)

PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit) PMBOK e Cobit - Uma Experiência na Reformulação de Sistemas em Angola Marcelo Etcheverry Torres,PMP,Cobit) Agenda A palestra Angola Cliente O projeto Usando o PMBOK Usando o Cobit Lições Aprendidas Conclusão

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Interatividade aliada a Análise de Negócios

Interatividade aliada a Análise de Negócios Interatividade aliada a Análise de Negócios Na era digital, a quase totalidade das organizações necessita da análise de seus negócios de forma ágil e segura - relatórios interativos, análise de gráficos,

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Engenharia de Software Parte I Introdução Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Mitos do Desenvolvimento de Software A declaração de objetivos é suficiente para se construir um software.

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Autor(es) BARBARA STEFANI RANIERI. Orientador(es) LUIZ EDUARDO GALVÃO MARTINS, ANDERSON BELGAMO. Apoio Financeiro PIBIC/CNPQ. 1.

Autor(es) BARBARA STEFANI RANIERI. Orientador(es) LUIZ EDUARDO GALVÃO MARTINS, ANDERSON BELGAMO. Apoio Financeiro PIBIC/CNPQ. 1. 19 Congresso de Iniciação Científica ESPECIFICAÇÃO E IMPLEMENTAÇÃO DE UMA FERRAMENTA AUTOMATIZADA DE APOIO AO GERSE: GUIA DE ELICITAÇÃO DE REQUISITOS PARA SISTEMAS EMBARCADOS Autor(es) BARBARA STEFANI

Leia mais

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

PROJETO DE FÁBRICA DE SOFTWARE

PROJETO DE FÁBRICA DE SOFTWARE FACULDADE SETE DE SETEMBRO FASETE Departamento de Sistemas de Informação PROJETO DE FÁBRICA DE SOFTWARE Denise Xavier Fortes Paulo Afonso BA Agosto/2015 Sumário 1. INTRODUÇÃO... 3 2. PERFIS FUNCIONAIS...

Leia mais

PODER JUDICIÁRIO TRIBUNAL REGIONAL DO TRABALHO DA 3ª REGIÃO

PODER JUDICIÁRIO TRIBUNAL REGIONAL DO TRABALHO DA 3ª REGIÃO Controle de Versões Autor da Solicitação: Subseção de Governança de TIC Email:dtic.governanca@trt3.jus.br Ramal: 7966 Versão Data Notas da Revisão 1 03.02.2015 Versão atualizada de acordo com os novos

Leia mais

A importância da. nas Organizações de Saúde

A importância da. nas Organizações de Saúde A importância da Gestão por Informações nas Organizações de Saúde Jorge Antônio Pinheiro Machado Filho Consultor de Negócios www.bmpro.com.br jorge@bmpro.com.br 1. Situação nas Empresas 2. A Importância

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

O Valor da TI. Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação. Conhecimento em Tecnologia da Informação

O Valor da TI. Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação O Valor da TI Introduzindo os conceitos do Val IT para mensuração do valor de Tecnologia da Informação 2010 Bridge Consulting

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

Métodos qualitativos: Pesquisa-Ação

Métodos qualitativos: Pesquisa-Ação Métodos AULA 12 qualitativos: Pesquisa-Ação O que é a pesquisa-ação? É uma abordagem da pesquisa social aplicada na qual o pesquisador e o cliente colaboram no desenvolvimento de um diagnóstico e para

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

3. Fase de Planejamento dos Ciclos de Construção do Software

3. Fase de Planejamento dos Ciclos de Construção do Software 3. Fase de Planejamento dos Ciclos de Construção do Software A tarefa de planejar os ciclos de construção do software pode partir de diretrizes básicas. Estas diretrizes visam orientar que os ciclos de

Leia mais

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado)

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) SISTEMA INTERNO INTEGRADO PARA CONTROLE DE TAREFAS INTERNAS DE UMA EMPRESA DE DESENVOLVIMENTO

Leia mais

EXPERIÊNCIA DE USO DE ARQUITETURA CORPORATIVA NO PROJETO DE RES

EXPERIÊNCIA DE USO DE ARQUITETURA CORPORATIVA NO PROJETO DE RES EXPERIÊNCIA DE USO DE ARQUITETURA CORPORATIVA NO PROJETO DE RES Rigoleta Dutra Mediano Dias 1, Lívia Aparecida de Oliveira Souza 2 1, 2 CASNAV, MARINHA DO BRASIL, MINISTÉRIO DA DEFESA, BRASIL Resumo: Este

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 VANT-EC-SAME Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 Histórico da Revisão Data Versão Descrição Autor 17/0/07 1.0 Versão Inicial Douglas Moura Confidencial VANT-EC-SAME, 2007

Leia mais

Business Process Management [BPM] Get Control. Empower People.

Business Process Management [BPM] Get Control. Empower People. Business Process Management [BPM] Get Control. Empower People. O SoftExpert BPM Suite é uma suíte abrangente de módulos e componentes perfeitamente integrados, projetados para gerenciar todo o ciclo de

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás

Leia mais

Project and Portfolio Management [PPM] Sustainable value creation.

Project and Portfolio Management [PPM] Sustainable value creation. Project and Portfolio Management [PPM] Sustainable value creation. O SoftExpert PPM Suite é a solução mais robusta, funcional e fácil para priorizar, planejar, gerenciar e executar projetos, portfólios

Leia mais

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP RUP Rational Unified Process ( Unificado de Desenvolvimento da Rational) Conjunto de passos que tem como objetivo atingir uma meta de software na ES, processo que visa a produzir o software - de modo eficiente

Leia mais

Boas Práticas em Gerenciamento de Projetos Material utilizado nas aulas de Pós-graduação do Centro de Informática 2010.2

Boas Práticas em Gerenciamento de Projetos Material utilizado nas aulas de Pós-graduação do Centro de Informática 2010.2 O que é um? s: Tradicional e/ou Ágil? Cristine Gusmão, PhD Tem início e fim bem determinados Things are not always what they seem. Phaedrus, Escritor e fabulista Romano O projeto é uma sequência única,

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento

Leia mais

O Valor estratégico da sustentabilidade: resultados do Relatório Global da McKinsey

O Valor estratégico da sustentabilidade: resultados do Relatório Global da McKinsey O Valor estratégico da sustentabilidade: resultados do Relatório Global da McKinsey Executivos em todos os níveis consideram que a sustentabilidade tem um papel comercial importante. Porém, quando se trata

Leia mais