__________________________________________________________________________ UNIVERSIDADE CATÓLICA DE BRASÍLIA PROGRAMA DE PÓS-GRADUAÇÃO EM GESTÃO DO CONHECIMENTO E TECNOLOGIA DA INFORMAÇÃO Mestrado Medição de Tamanho para Sistemas de Data Mart Autora: Angélica Toffano Seidel Calazans Orientadores: Profa. Dra. Káthia Marçal de Oliveira Prof. Dr. Rildo Ribeiro dos Santos BRASÍLIA 2003 ANGÉLICA TOFFANO SEIDEL CALAZANS MEDIÇÃO DE TAMANHO PARA SISTEMAS DE DATA MART Dissertação submetida ao Programa de PósGraduação stricto sensu em Gestão do Conhecimento e Tecnologia da Informação da Universidade Católica de Brasília para obtenção do Grau de Mestre. Orientadores: Profa. Dra. Káthia Marçal de Oliveira Prof. Dr. Rildo Ribeiro dos Santos Brasília 2003 TERMO DE APROVAÇÃO ANGÉLICA TOFFANO SEIDEL CALAZANS MEDIÇÃO DE TAMANHO PARA SISTEMAS DE DATA MART Dissertação defendida e aprovada como requisito parcial para obtenção do grau de Mestre no Programa de Pós-Graduação stricto sensu em Gestão do Conhecimento e Tecnologia da Informação, em 4 de dezembro de 2003, pela banca examinadora constituída por: Profa. Dra. Káthia Marçal de Oliveira Orientadora - UCB Prof. Dr. Rildo Ribeiro dos Santos Orientador- UCB Prof. Dr. Ricardo de Almeida Falbo UFES Prof. Dr. Hércules Prado UCB Prof. Dr. Nicolas Anquetil UCB Brasília UCB i AGRADECIMENTOS À minha querida mãe Thereza pela ajuda nas revisões, apoio e incentivo durante todo este trabalho. À minha irmã Eloisa pela grande ajuda nas revisões e traduções. Ao meu marido Calazans e meus filhos Luiza e Bruno que souberam entender minhas ausências e sempre torceram por mim. A meu pai e meu irmão pelo incentivo durante este trabalho. À minha amiga Marília pela ajuda nas revisões e apoio durante o trabalho. À minha chefe Ana Maria pela grande compreensão durante todo este trabalho. Aos meus colegas da Caixa Econômica Federal, inclusive supervisores, técnicos e líderes que participaram com informações valiosas sobre os sistemas e os que também, apoiaram todo este trabalho. Aos colegas das instituições pesquisadas que contribuíram com informações valiosas sobre os sistemas pesquisados. Aos alunos do Mestrado em Gestão do Conhecimento e Tecnologia da Informação da Universidade Católica de Brasilia que estudaram comigo e apoiaram a elaboração deste trabalho, em especial Edmeia e Leão. Aos professores convidados Ricardo Falbo, Hércules Prado e Nicolas Anquetil que compuseram a banca formada para avaliar esta dissertação, garantindo mais credibilidade nessa avaliação. Ao Sr. César Travassos de Brito, estatístico consultado, pela ajuda nas análises estatísticas. À professora Káthia e ao professor Rildo meus orientadores pelo envolvimento, profissionalismo, companheirismo e grande contribuição para este trabalho. E a todos que colaboraram e ajudaram, de qualquer maneira, na elaboração deste trabalho. ii RESUMO ___________________________________________________________________________ Para melhor controlar tempo, custo e recursos em projetos de software as organizações necessitam uma forma adequada de estimar o tamanho dos projetos antes mesmo de eles realmente iniciarem. Nesse contexto, diferentes abordagens foram propostas para estimar o tamanho de um sistema, como por exemplo a reconhecida Análise por Pontos de Função, que é amplamente utilizada no desenvolvimento de projetos de software. A maioria dessas abordagens tem como objetivo medir o tamanho de qualquer tipo de sistema, não importando a tecnologia. Contudo, alguns autores argumentam que cada tecnologia tem particularidades específicas e que essas devem ser levadas em consideração. Sistemas de Data Mart, por exemplo, têm particularidades diferentes dos sistemas tradicionais (e.g. um Data Mart utiliza outros sistemas como fontes de dados e não cria novas informações, ele somente contempla consultas e não atualizações, entre outras). É importante, portanto, ter uma abordagem de estimativa que considere estas particularidades quando na medição de Data Mart. Este trabalho apresenta uma adaptação da abordagem de Análise por Pontos de Função para estimativa de tamanho de Data Mart. São apresentados, também, resultados da aplicação desta proposta em projetos reais da indústria. iii ABSTRACT __________________________________________________________________________ To better control the time, cost and resources assigned to software projects, organizations need a proper estimate of their size even before the projects actually start. Accordingly, several approaches were proposed to estimate the size of a software project, as the well-known Function Point Analysis, which is largely used in traditional software development projects. Most of these approaches aim at measuring the size of any type of software system, whatever the technology. However some authors argue that each technology has specific particularities, which must be taken into account. Data Mart systems, for instance, have particularities in their development that are different from the traditional software systems (e.g. a data mart uses other software systems as data sources and do not create new information, it only contemplates information queries and not information update and so on). It is important, therefore, to have an estimation approach that considers those particularities while measuring the Data Mart size. This work presents an adaptation of the Function Points Analysis approach for Data Mart size estimation. It also presents and discusses results on data mart projects developed in the industry. iv SUMÁRIO ___________________________________________________________________________ RESUMO……………………………………………………………………………......…..iii ABSTRACT……………………………………………………………………………........iv CAPÍTULO 1 - INTRODUÇÃO ............................................................................................. 1 1.1 MOTIVAÇÃO E RELEVÂNCIA DO ESTUDO................................................... 1 1.2 OBJETIVOS E METODOLOGIA ......................................................................... 3 1.2.1 Classificação da pesquisa.................................................................................... 3 1.2.2 Suposições........................................................................................................... 4 1.2.3 Coleta e análise de dados .................................................................................... 4 1.3 ESTRUTURA DA DISSERTAÇÃO ....................................................................... 5 CAPÍTULO 2 - SISTEMAS DE DATA WAREHOUSE/DATA MART ................................ 6 2.1 INTRODUÇÃO......................................................................................................... 6 2.2 SISTEMAS TRANSACIONAIS E SISTEMAS ANALÍTICOS .......................... 7 2.3 DATA WAREHOUSE E DATA MART.................................................................... 9 2.4 ARQUITETURA DO AMBIENTE....................................................................... 11 2.5 PROCESSO DE DATA WAREHOUSING............................................................ 14 2.6 METODOLOGIAS PARA O DESENVOLVIMENTO DE SISTEMAS DATA WAREHOUSE/DATA MART ............................................................................................. 18 2.6.1 Abordagem Inmon (2003)................................................................................. 19 2.6.2 Proposta de Kimball e Ross (2002) - Diagrama do ciclo de vida dimensional do negócio - Business development lifecycle (BDL) ............................................................. 22 2.6.3 Abordagem de Husemann, Lechtenborger e Vossen (2000) (Conceptual Data Warehouse design – CDWD)............................................................................................ 24 2.6.4 Abordagem de Golfarelli e Rizzi (1999) .......................................................... 25 2.7 ANÁLISE COMPARATIVA................................................................................. 27 2.8 CONSIDERAÇÕES DO CAPÍTULO .................................................................. 29 CAPÍTULO 3 - MEDIÇÃO DE TAMANHO DE SOFTWARE ......................................... 30 3.1 INTRODUÇÃO....................................................................................................... 30 3.2 MEDIÇÃO DE SOFTWARE ................................................................................. 31 3.3 MÉTRICAS DE TAMANHO ................................................................................ 32 3.3.1 Lines of code - LOC (1950 /1960) ................................................................... 33 3.3.2 Halstead (Maurice Halstead) (1972)................................................................ 33 3.3.3 Análise por Pontos de Função (1979)............................................................... 34 3.3.4 Mark II Function points (1991) ........................................................................ 40 3.3.5 Full functions points (1997) e COSMIC Full Functions Points (2001) ........... 42 3.4 PROPOSTA DE MEDIÇÃO DE DATA WAREHOUSE/DATA MART DE SANTILLO.......................................................................................................................... 45 3.5 CONSIDERAÇÕES DO CAPÍTULO .................................................................. 48 CAPÍTULO 4 - PROPOSTA DE MEDIÇÃO DE TAMANHO PARA DATA MART ..... 50 4.1 INTRODUÇÃO....................................................................................................... 50 4.2 SISTEMAS DE DATA MART E OS SISTEMAS TRANSACIONAIS .............. 51 4.3 ABORDAGENS DE MEDIÇÕES DE TAMANHO ANALISADAS ................. 53 4.3.1 APF ................................................................................................................... 53 4.3.2 COSMIC ........................................................................................................... 54 v 4.3.3 Santillo .............................................................................................................. 55 4.4 DISCUSSÃO PARA ESCOLHA DA MÉTRICA A SER ADAPTADA............ 57 4.5 APF PARA DATA MART....................................................................................... 59 4.5.1 Estabelecer o objeto da contagem..................................................................... 59 4.5.2 Determinar a fronteira de medição ................................................................... 59 4.5.3 Contar as funções de dados e suas complexidades ........................................... 60 4.5.4 Contar as funções transacionais e suas complexidades .................................... 61 4.5.5 Calcular os pontos de função não-ajustados ..................................................... 61 4.5.6 Determinar o fator de ajuste.............................................................................. 62 4.5.7 Determinar pontos de função ajustados ............................................................ 63 4.6 CARACTERÍSTICAS GERAIS PROPOSTAS PARA A TECNOLOGIA DE DATA MART ...................................................................................................................... 64 4.6.1 Características gerais aplicáveis ....................................................................... 64 4.6.2 Características não-aplicáveis........................................................................... 65 4.6.3 Características adaptadas .................................................................................. 67 4.6.4 Novas características gerais propostas para a tecnologia de Data Mart........... 70 4.7 PROPOSTA DE ADEQUAÇÃO NO PROCESSO DE DESENVOLVIMENTO DE DATA MART ................................................................................................................. 79 4.8 MEDIÇÃO DE TAMANHO EM PROJETOS REAIS ....................................... 81 4.8.1 Planejamento..................................................................................................... 81 4.8.1.1 Critérios adotados para a Instituição 1 (I1)....................................................... 82 4.8.1.2 Critérios adotados para as Instituições 2 e 3 (I2 e I3)....................................... 83 4.8.2 Aplicação .......................................................................................................... 85 4.8.3 Análise dos resultados....................................................................................... 89 4.8.3.1 Aplicação ANOVA, Teste de Tukey e análise ................................................. 92 4.9 CONSIDERAÇÕES DO CAPÍTULO .................................................................. 96 CAPÍTULO 5 - CONCLUSÕES E TRABALHOS FUTUROS.......................................... 98 REFERÊNCIAS BIBLIOGRÁFICAS................................................................................ 101 APÊNDICE A - ENTREVISTA ESTRUTURADA PARA LEVANTAMENTO DOS DADOS DOS SISTEMAS .................................................................................................... 109 APÊNDICE B - CARACTERÍSTICAS GERAIS ADEQUADAS A TECNOLOGIA DE DATA MART.......................................................................................................................... 110 APÊNDICE C - CARACTERÍSTICAS GERAIS APF.................................................... 116 APÊNDICE D - ARTIGO PUBLICADO NO II SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 2003................................................................................ 121 APÊNDICE E - ARTIGO PUBLICADO NA DEVELOPERS´MAGAZINE, 2003...... 134 vi LISTA DE FIGURAS ___________________________________________________________________________ Figura 2. 1 - Elementos básicos do Data Warehouse ............................................................... 12 Figura 2.2 - Arquitetura de Data Warehouse............................................................................ 13 Figura 2.3 - Modelo Multidimensional de dado – Fato Vendas ............................................... 16 Figura 2.4 - Exemplo de esquema estrela ................................................................................. 17 Figura 2.5 - Exemplo de esquema flocos de neve .................................................................... 17 Figura 2.6 - Metodologia de desenvolvimento de um Data Warehouse .................................. 20 Figura 2.7 - Diagrama do ciclo de vida dimensional do negócio ............................................. 22 Figura 2.8 - Modelo de Processo para o Projeto de Data Warehouse ...................................... 24 Figura 2.9 - Exemplo de um Modelo de Fato Dimensional...................................................... 26 Figura 3.1 - Proposta do processo de contagem incorporado ao processo de desenvolvimento ........................................................................................................................................... 39 Figura 3.2 - Processo de aplicação do método COSMIC-FFP ............................................... 43 Figura 4.1 - Dois ciclos de desenvolvimento (transacional e Data Warehouse) ...................... 53 Figura 4.2 - Comparação do tempo real com a estimativa de tempo da proposta de Santillo.. 57 Figura 4.3 - Proposta de contagem no ciclo de vida de Data Warehouse................................. 80 Figura 4.4 - Comparação Qtd PF da APF x PF da Proposta..................................................... 87 Figura 4.5 - Comparação tempo real, estimado APF e estimado Proposta............................... 87 Figura 4.6 - Contagem efetuada no ciclo de vida de um projeto de Data Warehouse ............. 88 Figura 4.7 - Comparação entre a contagem de PF da APF e da Proposta incluindo sistema em início de desenvolvimento I1S7........................................................................................ 89 vii LISTA DE QUADROS _________________________________________________________________ Quadro 2.1 - Dados e aplicações transacionais x Dados e aplicações analíticos........................ 8 Quadro 2.2 - Ciclos de vidas..................................................................................................... 18 Quadro 2.3 - Fases da metodologia propostas por Golfarelli e Rizzi ....................................... 25 Quadro 2.4 - Características diferenciais das abordagens metodológicas ................................ 27 Quadro 2.4 (cont.) - Características diferenciais das abordagens metodológicas..................... 28 Quadro 3.1 - Escalas de medição.............................................................................................. 31 Quadro 3.2 - Complexidade Arquivos Lógicos Internos e Arquivos Interface Externa........... 35 Quadro 3.3 - Complexidade de Entrada Externa ...................................................................... 36 Quadro 3.4 - Complexidade de Saída Externa ou Consulta Externa ........................................ 36 Quadro 3.5 - Número de pontos de função por função e complexidade.................................. 36 Quadro 3.6 - Aspectos funcionais e não-funcionais x Características gerais ........................... 37 Quadro 3.7 - Descrição dos movimentos de dados................................................................... 44 Quadro 3.8 - Tipos de função e correlação............................................................................... 47 Quadro 3.9 - Comparação entre as características das abordagens de métricas de software.... 49 Quadro 4.1 - Características gerais de sistema aplicáveis ao contexto de Data Mart .............. 64 Quadro 4.2 - Características gerais de sistema não-aplicáveis ao contexto de Data Mart....... 66 Quadro 4.3 - Exemplos dos itens de influência utilizados pela APF...................................... 71 Quadro 4.4 - Situação dos projetos analisados ......................................................................... 82 viii LISTA DE TABELAS _________________________________________________________________ Tabela 4.1 - Levantamento do esforço da etapa ETL no processo de construção de um Data Mart/Data Warehouse ...................................................................................................... 51 Tabela 4.2 - Levantamento da Proposta Santillo(2001)............................................................ 56 Tabela 4.3 - Comparação entre o tempo real e o tempo estimado da proposta de Santillo(2001) ........................................................................................................................................... 57 Tabela 4.4 - Levantamento das empresas que utilizam ferramenta ETL.................................. 84 Tabela 4.5 - Aplicação da APF e da proposta em 10 sistemas de Data Mart .......................... 85 Tabela 4.6 - Resultados com relação ao tempo real, estimado APF e estimado proposta........ 86 Tabela 4.7 - Levantamento PF de um sistema em início de desenvolvimento ......................... 89 Tabela 4.8 - Estatísticas descritivas .......................................................................................... 93 Tabela 4.9 - Aplicação da ANOVA.......................................................................................... 94 Tabela 4.10 - Testes de Tukey - Comparação Múltipla............................................................ 95 Tabela 4.11 - Subgrupos Homogêneos ..................................................................................... 96 ix 1 CAPÍTULO 1 - INTRODUÇÃO ____________________________________________________________________________ 1.1 MOTIVAÇÃO E RELEVÂNCIA DO ESTUDO A medição na engenharia de software é um dos fatores importantes para a geração de um produto com qualidade. Segundo Fenton e Pfleeger(1997, p.12-13), mensura-se para compreender, controlar e aperfeiçoar o processo de produção de software. Medidas permitem um melhor controle dos projetos, possibilitam mudanças, proporcionam o aperfeiçoamento contínuo do processo e do produto de software e o estabelecimento de bases de comparação para o desenvolvimento futuro. A mensuração do tamanho do software na gestão de projetos, além de proporcionar melhor entendimento, controle e aperfeiçoamento do processo de construção de software, está vinculada à necessidade de avaliar e medir resultados, conhecer melhor o patrimônio de software, gerar indicadores para tomada de decisão, avaliar o impacto da introdução de novas tecnologias, obter vários indicadores de desempenho (produtividade, qualidade) e obter e/ou melhorar estimativas de prazo, custo e recursos gerando expectativas mais realistas para o usuário (SIMÕES, 1999). Dessa forma, é essencial que a mensuração de tamanho seja o mais aproximada possível da realidade, pois ela é um fator de impacto nas demais variáveis (CALAZANS, OLIVEIRA e SANTOS, 2003)(Apêndice D). Várias abordagens têm sido propostas e aperfeiçoadas, desde a década de 1960, com o objetivo de definir o tamanho de um software, entre elas: Lines of code – LOC (1950/1960) (FENTON e NEIL, 2000), a abordagem Halstead (1972) (BATENBURG, RIDDER e KERF, 1998), Function Point Analysis (FPA) ou Análise por Pontos de Função (APF) (1979) (IFPUG, 2000), o MKII Function Point Analysis (1991) (LOKAN e ABRAN, 1999) e o Full Function Points/COSMIC Full Functions Points (1997) (ABRAN et al, 1999). A maior parte dessas propostas busca medir o tamanho de qualquer tipo de software, independente da tecnologia. Sistemas de Data Warehouse/Data Mart, no entanto, são um tipo especial de software, com características particulares como, por exemplo, o fato dos usuários utilizarem o software somente para consultas e não atualização dos dados; o desenvolvimento baseado em dados existentes em outros sistemas sem a geração de novos dados; o processo de desenvolvimento diferente de sistemas tradicionais (SANTILLO, 2001); a necessidade de um projeto de Extração, Transformação e Carga (ETL) e a utilização de uma modelagem multidimensional dos dados. 2 Data Warehouse e Data Mart são sistemas que utilizam depósitos multi dimensionais de dados e que servem como fundamento de informações para a tomada de decisão. Data Warehouse representa uma grande base de dados analítica capaz de integrar, de forma concisa e confiável, as informações de interesse para empresa (MACHADO, 2000, p.26) e (POE, 1996, p.6), possuindo uma arquitetura mais abrangente com foco mais amplo. Os Data Mart, em sua forma mais simples, representam dados de um único processo de negócio (KIMBALL E ROSS, 2002, p. 455) e possuem um escopo menor, tanto de arquitetura como de foco. Podem, contudo, estar coerentemente acoplados no framework maior do Data Warehouse corporativo, se utilizadas técnicas de interligação e quando suas dimensões estão em conformidade. Barbieri (2001, p.56) cita que atualmente os termos “Data Warehouse e Data Mart são praticamente (quase) intercambiáveis”. Uma parcela significativa do orçamento em Tecnologia da Informação (TI) de muitas organizações é dedicada ao desenvolvimento de aplicações de Data Warehouse (MOODY e KORTINK, 2000) e, segundo Stuzke (2000), as empresas necessitam estimar de forma acurada o tamanho dos produtos de software no início do processo de desenvolvimento para melhor planejar e prever a construção de produtos de software e, ainda, diminuir o risco e a tomada de decisões errôneas. Agarwal et al. (2001) concordam com esta questão, destacando que a utilização de estimativas de tamanho no início do estágio de um projeto de software é uma das necessidades do mercado para garantir o suporte eficaz à tomada de decisões. A estimativa em projetos de software envolve, na maioria das vezes, a previsão de quatro variáveis: tamanho (dimensão do software produzido ou a produzir), esforço (trabalho necessário para o desenvolvimento do software), prazo (tempo necessário para o desenvolvimento do software) e qualidade (envolvendo fatores como manutenabilidade, confiabilidade e outros)(AGUIAR, 2002). A primeira variável a ser determinada é sempre o tamanho do software, produzido ou a produzir, pois é a partir da definição da dimensão que é possível definir o esforço e o prazo necessários para o desenvolvimento do software. Isso demonstra a importância de uma mensuração de tamanho o mais próxima possível da realidade, pois ela é um fator que causa impacto nas demais variáveis. Torna-se necessário adequar as abordagens de medição de tamanho definidas para sistemas tradicionais para que considerem as características específicas de Data Warehouse/Data Mart e com isso gerem estimativas mais reais. Uma abordagem adequada de mensuração de tamanho ajudará a Gestão da TI a resolver uma das maiores dificuldades encontradas atualmente: conhecer a dimensão do que está sendo gerenciado. 3 O processo de mensurar o tamanho de um software ainda está muito pouco internalizado dentro das empresas brasileiras. A pesquisa da Secretaria de Política de Informática do Ministério da Ciência e Tecnologia (MCT) em 2002 demonstrou que no universo de 446 empresas do mercado de software pesquisadas, somente 30% das empresas utilizavam algum tipo de métrica de tamanho, sendo que dessas 18,2% utilizavam a abordagem da APF (MCT, 2002). A APF considera as funções que o software possui ou possuirá, segundo a visão do usuário final, para determinar o tamanho do sistema, mas Fenton e Pfleeger (1997, p.263) , Lokan e Abran (1999) e outros autores (ABRAN et al., 2001) identificam a não aplicabilidade dessa abordagem a todos os tipos de software. Considerando esses aspectos, torna-se necessária uma abordagem de mensuração de tamanho voltada para Projetos de Data Warehouse/Data Mart, de forma a obter estimativas mais adequadas. 1.2 OBJETIVOS E METODOLOGIA Esta dissertação tem por objetivo a definição de uma proposta de mensuração de tamanho para Projetos de Data Mart. São objetivos específicos: Estudar as características principais de sistemas de Data Mart/Data Warehouse, identificando aspectos diferenciados em relação aos sistemas transacionais; Estudar algumas abordagens de métricas de tamanho existentes, analisar sua aplicabilidade a esse contexto e identificar a melhor alternativa para adequação à tecnologia de Data Mart; Propor a adequação de uma das abordagens de métricas de tamanho para projetos de Data Mart; Utilizar e avaliar a nova adequação em projetos de Data Mart; Comparar os resultados da aplicação dessa proposta de adequação com os resultados da abordagem original escolhida como base para adequação. 1.2.1 Classificação da pesquisa O tipo de pesquisa utilizada classifica-se como pesquisa aplicada, uma vez que busca a resolução de problema concreto, que é a mensuração de projetos de Data Mart. Com relação aos meios de investigação, foram utilizados: a pesquisa bibliográfica baseada em material publicado em livros, revistas, jornais, redes eletrônicas, anais; estudo de 4 caso circunscrito aos projetos possíveis de serem mensurados em três instituições investigadas; investigação documental, apoiada em pesquisa documental dos sistemas a serem pontuados; e, pesquisa de campo por meio da aplicação de entrevistas estruturadas com os responsáveis pelos projetos de Data Mart nas três instituições pesquisadas, a fim de obter informações sobre os projetos. Foram analisadas, por meio de pesquisa bibliográfica, as características diferenciadas de um processo de desenvolvimento de um sistema de Data Mart, as deficiências que as métricas possuem quando aplicadas a sistemas de Data Mart e as críticas existentes a estas abordagens. Foi construída uma proposta de adequação de uma dessas métricas ao contexto de Data Mart, com base na pesquisa bibliográfica e aplicada nos projetos de Data Mart das três instituições investigadas. Foram comparados os resultados dessa proposta e da métrica aplicada escolhida. 1.2.2 Suposições As seguintes suposições foram elaboradas: As abordagens de métricas de tamanho de software existentes não são adequadas para o contexto dos projetos de Data Mart. O processo de concepção e construção de um Data Mart difere do processo de concepção e construção de um sistema tradicional operacional/transacional. O método de mensuração de software deve ser escolhido ou adequado às características particulares do tipo de sistema que se pretenda desenvolver. Somente com métricas apropriadas e adequadas consegue-se realizar estimativas com significativa precisão e confiabilidade. 1.2.3 Coleta e análise de dados Foram coletados dados em três instituições governamentais instaladas em Brasília, Distrito Federal. Duas delas são bancárias e uma delas é uma empresa de desenvolvimento de Sistemas. Foram realizadas entrevistas estruturadas com os responsáveis pelos sistemas de Data Mart dessas três instituições, visando obter informações sobre os sistemas a serem medidos, sobre o tempo e sobre a quantidade de recursos humanos utilizados para os projetos de Data Mart já implantados. Tal informação foi necessária para, a partir do cálculo inverso e considerando o fator de produtividade utilizado por uma instituição ou um fator de 5 produtividade de mercado, verificar qual dos tamanhos obtidos pelas aplicações das métricas mais se aproximou do tamanho real. Foram também consultados três especialistas em Data Mart, para adequação dos itens de influência das novas características geradas pela proposta de adequação. 1.3 ESTRUTURA DA DISSERTAÇÃO Além do capítulo introdutório, este trabalho consiste de mais cinco capítulos, que são descritos a seguir. No capítulo 2, é apresentada a tecnologia de Data Warehouse e os desafios que essa tecnologia acrescenta ao desenvolvimento de sistemas. É traçado um comparativo entre os sistemas transacionais e os sistemas de Data Warehouse e são conceituados Data Warehouse e Data Mart. É descrita a estrutura do ambiente de Data Warehouse e o processo de construção de um Data Warehouse. São apresentadas algumas das metodologias para desenvolvimento de sistemas de Data Warehouse. No capítulo 3, é apresentada uma visão geral sobre medição de software. Inicialmente são descritas algumas considerações sobre definição de medições e suas classificações. São apresentadas algumas abordagens de métricas de tamanho existentes: LOC, Halstead, APF, MKII e Full Function Points/COSMIC. É citada também uma proposta de medição de tamanho para o contexto de Data Warehouse/Data Mart (SANTILLO, 2001). Uma proposta de adequação é então apresentada no capítulo 4. Inicialmente, são descritas algumas considerações sobre as diferenças de Data Mart e um sistema transacional. São apresentadas sucintamente algumas abordagens de medição de tamanho existentes como APF, COSMIC e a proposta de Santillo (2001) e é justificada a escolha da APF para adequação. A proposta de adequação é detalhada e a aplicação da proposta é analisada em 11 sistemas de Data Mart das três instituições. O capítulo 5 apresenta as principais contribuições do trabalho para a melhoria da medição em sistemas de Data Warehouse e propõe os trabalhos futuros que poderão ser realizados a partir desta dissertação. 6 CAPÍTULO 2 - SISTEMAS DE DATA WAREHOUSE/DATA MART ____________________________________________________________________________ 2.1 INTRODUÇÃO Proposta no início dos anos 1990, a tecnologia de Data Warehouse surgiu como uma solução para satisfazer a necessidade de informações gerenciais da organização (MOODY e KORTINK, 2000). Um Data Warehouse é uma coleção de dados integrados, orientados a assunto, variantes no tempo e não voláteis utilizados pela organização para a tomada de decisões (INMON, 1999). Sistemas de Data Warehouse são criados para o processamento analítico das informações (On Line Analytical Processing - OLAP) e o seu objetivo é transformar o dado transacional, distribuído heterogeneamente pela organização, em informação estratégica para suporte a processos de tomada de decisão, de forma a garantir a competitividade necessária para o negócio (KIMBALL e ROSS, 2002, p. 3-5). O desenvolvimento de sistemas de Data Warehouse apresenta uma série de aspectos diferentes do desenvolvimento de sistemas transacionais ou On-Line Transaction Processing (OLTP). Sistemas transacionais são desenvolvidos com base nos requisitos operacionais (tecnologia OLTP) do modelo de negócio da organização (GARDNER, 1998). Estes sistemas possuem as características de serem utilizados no dia-a-dia da organização, apresentando os dados de natureza detalhada e uma estrutura relacional e normalizada (CHAUDHURI e DAYAL, 1997). Por outro lado, sistemas analíticos (tecnologia OLAP) são compostos de informações para departamentos ou unidades de negócio com a visão gerencial da empresa e permitem o cruzamento de informações funcionais para análises de negócios, de forma a garantir uma vantagem competitiva. São características desses sistemas de Data Warehouse: utilizar as informações para análise; possuir dados de natureza sumarizada e detalhada e ter uma estrutura multidimensional e desnormalizada (CHAUDHURI e DAYAL, 1997). O processo sistemático de construção de um sistema de Data Warehouse é chamado de Data Warehousing e é composto por uma coleção de tecnologias, algoritmos, ferramentas, técnicas e por uma arquitetura concebida para facilitar o armazenamento e o gerenciamento desses grandes volumes de dados e de várias origens, com o objetivo de proporcionar ao trabalhador do conhecimento (executivos, gerentes e analistas) a visão do todo ou de parte do negócio. (CHAUDHURI e DAYAL, 1997; GARDNER, 1998). 7 Para melhor entender a importância e a peculiaridade de sistemas de Data Warehouse, será apresentada uma visão geral da tecnologia de data warehousing. Inicialmente é traçado um comparativo entre os sistemas transacionais e os sistemas de Data Warehouse ou sistemas analíticos (seção 2.2) e a conceituação de Data Warehouse e Data Mart (seção 2.3). Na seção 2.4, se descreve a estrutura do ambiente de Data Warehouse e o processo de Data Warehousing é apresentado na seção 2.5. A seção 2.6 apresenta algumas das metodologias para desenvolvimento de sistemas de Data Warehouse. Ao final do capítulo, nas seções 2.7 e 2.8, são descritas algumas considerações sobre as diferenças e as peculiaridades desta tecnologia. 2.2 SISTEMAS TRANSACIONAIS E SISTEMAS ANALÍTICOS Um dos primeiros obstáculos para a construção de um Data Warehouse é a dificuldade de entender a diferença entre sistemas transacionais e analíticos (GARDNER, 1998). Sistemas transacionais automatizam o processamento de dados das operações de um ou mais negócios da organização. Essas operações são transações repetitivas, estruturadas, isoladas, detalhadas, com atualização ou leitura de dados e os registros são acessados normalmente por chaves primárias (CHAUDHURI e DAYAL, 1997). Há quantidade de transações pré-definidas e o tamanho dos arquivos é restrito a alguns gigabytes de informação (MOODY e KORTINK, 2000). Neste tipo de software são críticos a consistência e a recuperação dos dados e o banco de dados é construído refletindo a semântica da operação de negócio (CHAUDHURI e DAYAL, 1997). Em contraste, nos sistemas analíticos, ou Data Warehouse/Data Mart, dados sumarizados, agregados e consolidados são mais importantes que dados detalhados ou registros individuais. Um Data Warehouse contém dados consolidados de diferentes sistemas transacionais, armazenados por longos períodos de tempo, possibilitando a informação histórica, e é projetado para tamanhos de centenas de gigabytes até terabytes (CHAUDHURI e DAYAL, 1997). Um Data Warehouse é limitado somente à leitura, possibilita respostas rápidas e consistentes em consultas ad hoc a milhões de registros e é voltado para uma quantidade restrita de acessos (MOODY e KORTINK, 2000). Esses sistemas analíticos utilizam aplicações especiais para tratamento desses dados, como as Ferramentas de OLAP e mineração de dados que são consideradas uma extensão da sua arquitetura. Essas ferramentas possibilitam o trabalho do usuário final com os dados de 8 forma múltipla e combinada, permitindo inferência, busca de informações e reconhecimento de padrões (data mining)(BARBIERI, 2001, p. 49). O Quadro 2.1 relaciona comparações entre os dados e aplicações de natureza transacionais e analíticos, no que se refere às características de dados (conteúdo, organização, atualização, utilização e duplicação dos dados, formato das estruturas dos dados, dados derivados e agregados, etc) e das aplicações (número de usuários, tempo de resposta, complexidade, etc.). Quadro 2.1 - Dados e aplicações transacionais x Dados e aplicações analíticos Características Dados e aplicações transacionais Conteúdo dos dados Valores unitários Dados e aplicações analíticos Valores sumarizados, calculados, integrados de várias fontes Organização dos dados Por aplicação /sistema de informação Por assuntos /negócios Natureza dos dados Dinâmica Estática até a nova carga dos dados Formato das estruturas dos Relacional, dados transacional atividades analíticas Atualização dos dados Atualização campo a campo Atualização em lotes Uso dos dados Altamente próprio para estruturado, computação processamento Dimensional, simplificado, próprio para Desestruturado, com processamento repetitivo analítico/ heurístico Natureza dos dados Detalhada Detalhada e sumarizada Dados derivados e Raros Comuns Duplicação de dados Normalização Desnormalização Data Joins Muitos Alguns Data index Alguns Muitos Acesso aos dados SQL SQL, ferramentas avançadas de análise agregados (OLAP) Tamanho das fontes de Gigabyte Gigabyte-terabyte Atualidade dos dados Dados atuais Dados atuais e históricos Informação primária Detém o controle Controlada por fontes externas Número de usuários das Alto Baixo Tempo de resposta das Otimizado para um pequeno tempo de Análises mais complexas, com tempos de aplicações resposta respostas maiores Complexidade das Baixa e/ou alta Alta Registros individuais Milhões de registros dados aplicações aplicações Foco das aplicações Baseado em Barbieri (2001,p. 38-47), Santillo (2001) e Paim (2003) A utilização das informações analíticas de um Data Warehouse pode oferecer um grande potencial para as organizações, mas sua implementação é um processo complexo e diferente do processo transacional. A seguir, são apresentados os conceitos de Data warehouse e Data mart e as formas de implementação existentes para um processo de informações analíticas de suporte à decisão. 9 2.3 DATA WAREHOUSE E DATA MART As abordagens iniciais para projetos de Data Warehouse e Data Mart surgiram das propostas de Bill Inmon e Ralph Kimball em meados dos anos 1990 (BARBIERI, 2001, p.52). A abordagem de Bill Inmon baseou-se, inicialmente, no estilo mais tradicional de banco de dados e busca uma forte integração entre todos os dados da empresa gerando um único projeto integrado, coeso e monolítico, ou seja, um Data Warehouse da organização ou corporativo. Kimball propôs uma abordagem mais incremental. Criou a metodologia do esquema estrela que aponta para projetos de Data Mart separados que devem ser integrados na medida de sua evolução. Permite projetos menores, independentes, focando áreas ou assuntos específicos que terão sua conexão com o passar do tempo, desde que mantida a compatibilidade dimensional entre chaves e tabelas. Estas duas abordagens atualmente são compatíveis, havendo somente diferenças na nomeação das suas estruturas (GALLAS, 1999), conforme pode ser observado a seguir. Inmon (1999) define Data Warehouse como “uma coleção de dados orientada a assunto, integrada, não volátil e variante no tempo para suporte a decisões gerenciais”. Orientada a assuntos, porque, diferente das bases transacionais (que são organizadas em torno de transações), no Data Warehouse as informações giram em torno de um assunto definido pelo usuário. Integrada pois o Data Warehouse necessita manter a consistência e a uniformidade dos dados extraídos de fontes distintas. Não volátil, considerando que os dados em um Data Warehouse não são atualizáveis, são apenas carregados e disponibilizados para consultas e variável no tempo, pois cada registro se refere a um dado instante do objeto. Para Machado (2000, p.26) e Poe (1996, p.6), Data Warehouse representa uma grande base de dados analítica capaz de integrar, de forma concisa e confiável, as informações de interesse para a empresa. É um armazém de dados e históricos cuja finalidade é apresentar as informações que permitam identificar indicadores, evolução de valores, ou seja, servir de fundamento de informações para a tomada de decisão (KIMBALL e ROSS, 2002, p.3-5). Inmon (1999) define Data Mart como uma coleção de áreas de interesse (subjects) para suporte à decisão, baseada nas necessidades de um determinado departamento. O Data Mart é granular na medida em que representa somente as necessidades do departamento ou de determinada área. Data Mart são sistemas de suporte à decisão (DSS) departamentais. A estrutura e conteúdo de um Data Warehouse e de um Data Mart são significativamente 10 diferentes. No Data Mart as informações estão em maior nível de sumarização e normalmente não apresentam o nível histórico encontrado em um Data Warehouse. Para Kimball e Ross (2002, p. 455), Data Mart é um conjunto flexível de dados extraídos de uma ou mais fontes transacionais e apresentado de modo simétrico (dimensional). Em sua forma mais simples representa dados de um único processo de negócio. Esse modo simétrico é mais flexível para consultas ad-hoc. Os Data Mart podem ser vinculados utilizando-se técnicas de interligação quando suas dimensões estão em conformidade. Segundo Berson e Smith (1997) o conceito de Data Mart foi modificando com o passar do tempo. Surgiu como uma alternativa mais barata para o Data Warehouse com relação ao custo e ao tempo de construção, pois “desenvolver um Data Warehouse com a integração total da empresa é um processo muito complexo e interativo e necessita de dados de muitas unidades departamentais, de clareza de dados e de um modelo extenso de negócio” (BELLATRECHE e KARLAPALEM, 2000). Hoje os termos “Data Warehouse e Data Mart são praticamente (quase) intercambiáveis” (BARBIERE, 2001, p. 56). Bellatreche e Karlapalem (2000), Machado (2000, p. 38-40) e Hackney (1998) sugerem duas abordagens para implementar Data Mart: O Data Mart pode ser desenhado derivando de um Data Warehouse (abordagem top down, sugerida por Inmon (1999)); ou pode ser desenhado com a integração de dados de origem (abordagem bottom up). A abordagem top down ocorre quando um projeto de Data Warehouse necessita ser separado fisicamente para atender à necessidade de um grupo, para facilitar o uso de ferramentas OLAP (desnormalizando o esquema de estrela ou de cubos) ou mesmo extrair determinados conjuntos de dados para facilitar a mineração. Nesses casos são gerados Data Mart dependentes, pois possuem a origem no Data Warehouse. Esses Data Mart são implementados separadamente, mas estão integrados ou interconectados, provendo uma visão global dos dados e informações. Essa abordagem possui vantagens como herança de arquitetura, visão de empreendimento, repositório de metadados1 centralizado, controle e centralização das regras. Seriam desvantagens dessa abordagem a implementação muito longa, alta taxa de risco da empresa, alto nível de cruzamento funcional e o desafio de gerenciar expectativas de desenvolvimento (HACKNEY, 1998). A abordagem bottom up gera Data Mart independentes que representam soluções fragmentadas para os problemas de negócio da empresa. Estes Data Mart não utilizam o 1 Metadados – Segundo Inmon et al (2001, p.251), dados sobre dados, no caso de Data Warehouse a descrição da estrutura, conteúdo, chaves, índices, etc. 11 conceito de integração que é a base do Data Warehouse e possuem problemas de escalabilidade. Mas são soluções para urgência de respostas, ausência de verbas para uma estratégia de Data Warehouse, ausência de um patrocinador e descentralização das unidades de negócio. Tem como vantagem a rapidez na implementação e no retorno dos investimentos, a manutenção do enfoque da equipe e a herança incremental. Como desvantagens há o perigo de gerar futuramente legamarts2, a necessidade de possuir a visão global da empresa e a administração e coordenação de múltiplas equipes e iniciativas (HACKNEY, 1998). Para resolver o problema de integração, a abordagem de Kimball e Ross (2002, p.455) sugere a implementação de dimensões e frameworks comuns para garantir a equalidade dos dados e conseqüentemente a interação. Machado (2000, p.41) identifica também uma implementação combinada top down e bottom up, na qual é realizada a modelagem de dados do Data Warehouse em nível macro, define-se as áreas de interesse e se criam Data Marts. Cada Data Mart é integrado a partir do macro modelo de dados do Data Warehouse. Essa proposta possui similaridades com a proposta de Kimball (BARBIERE, 2001, p.54), como uma das formas de desenvolver projetos de Data Mart e de garantir a interação. Considerando esses autores, este trabalho utilizará a nomenclatura Data Warehouse/Data Mart indistintamente para designar esses sistemas que utilizam depósitos dimensionais de dados, atentando para o fato que Data Warehouse possui uma arquitetura mais abrangente de foco mais amplo e que Data Mart representa um escopo menor tanto de arquitetura como de foco, mas plenamente e coerentemente acoplado no Framework maior do Data Warehouse corporativo. 2.4 ARQUITETURA DO AMBIENTE Existem quatro componentes separados e distintos no ambiente de Data Warehouse (Figura 2.1) (KIMBALL et al, 1998, p.15): sistemas transacionais de origem - São os sistemas que capturam e processam as transações da empresa; data staging area - Área de armazenamento de dados e de conjunto de processos que preparam os dados de origem para serem utilizados. Nessa área os dados dos sistemas operacionais de origem são filtrados, combinados, limpos, etc; área de apresentação de dados - O local onde os dados ficam armazenados e disponíveis ao usuário final. Normalmente nessa área são armazenados os modelos 2 Legados de Data Marts. 12 de Data Mart, baseados em um processo de negócio e que futuramente, se tiverem fatos e dimensões em conformidade, poderão se tornar um Data Warehouse; e, ferramentas de acesso a dados - São as ferramentas OLAP que permitem aos usuários utilizar os dados de uma maneira rápida, interativa, de forma fácil para executar análises mensuráveis. Os Data Warehouse/Data Mart servem como fonte de dados para essas ferramentas e devem assegurar consistência, integração e precisão. Sistemas Área de Data operacionais de origem Extrair Extrair de acesso de dados area Extrair Ferramentas apresentação staging Serviços: Filtrar, combinar e padronizar dimensões em conformidade Carregar Acessar Ferramentas de consultas específicas Criadores de relatórios Armazenamento de dados: tabelas relacionais e arquivos simples Processamento: classificação e processamento seqüencial Data Mart número 1: Dados dimensionais atômicos e de resumo baseados em um único processo de negócio a dados Barramento do DW: fatos e dimensões em conformidade Carregar Data Mart número 2: (projetado da mesma Acessar forma) Modelagem: Previsão, pontuação e exploração de dados Figura 2. 1 - Elementos básicos do Data Warehouse Adaptado:KIMBALL et al (1998, p.15) Já Watterson (1998) é mais detalhista, e identifica conforme Figura 2.2, os seguintes elementos na arquitetura de Data Warehouse: Origem dos dados - que são as bases de dados dos sistemas transacionais e também dados de outras origens como Enterprise Resource Planning (ERP)3, dados de bases WEB, outros dados externos ou dispersos pela organização. Staging area – local de tratamento de todos esses dados que são transformados, limpos, agregados, etc. Esses dados tratados servem de base para o Data 3 Sistemas Integrados de gestão. 13 Warehouse, os Data Mart ou mesmo um ODS4, se a arquitetura proposta trabalha com essa solução. Data Warehouse - engloba o modelo de Data Warehouse, Data Marts ou ODS. Suporte à decisão - São as ferramentas de suporte a decisão, ferramentas OLAP, relatórios, ferramentas de análises estatísticas ou financeiras necessárias para a análise dos dados. Paralelos a esses elementos são identificados os metadados nos repositórios das aplicações de origem de dados e, a partir desses repositórios, criados os Metadados da empresa que servirão como referencial para um Metadados corporativo. O gerenciamento do Warehouse e dos sistemas e Banco de Dados deverá ser exercido durante todo o processo. Origem dos dados Staging area Data Warehouse ODS Suporte à decisão DM Bases de aplicações Extração, transferência, agregação, etc ERP Desktop data External data Web based data DW OLAP Relatórios Análises estatísticas Análises financeiras DM Repositórios ferramentas Repositório empresa Metadados Referência repositório da empresa Gerenciamento do Warehouse Gerenciamento dos sistemas e Banco de dados Figura 2.2 - Arquitetura de Data Warehouse Adaptado: Watterson(1998) Existem outras propostas de arquitetura como a abordagem de Moody e Kortink (2000), Vavouras, Gatziu e Dittrich (1999). Em comum, todas possuem a identificação do processo de Extração, Transformação e Carga (ETL). Apesar da abordagem de Watterson (1998) possuir uma visão mais global da arquitetura, a abordagem de Kimball et al (1998, 4 Operational Data Storage - Cópias integradas e freqüentemente atualizadas de dados transacionais. É um terceiro sistema físico de tabelas localizado entre os sistemas transacionais e o Data Warehouse, utilizado ou não conforme a arquitetura de solução adotada (KIMBALL e ROSS, 2002, p. 449). 14 p.18-19) está mais direcionada para construção de Data Marts integrados. Considerando a proximidade conceitual dessas propostas de arquitetura, será utilizada a abordagem do Kimball e Ross (2002) para demonstrar de forma mais detalhada o processo de construção de um Data Mart/Data Warehouse nessa arquitetura. 2.5 PROCESSO DE DATA WAREHOUSING Os processos básicos para se criar e atualizar um Data Warehouse/Data Mart incluem, entre outros: (i) extração, (ii) transformação e (iii) carga dos dados (Extraction, Transformation, Load - ETL) e (iv) garantia da qualidade (KIMBALL et al, 1998, p.23). O processo de (i) extração envolve a leitura e a compreensão dos dados de origem e a cópia desses dados na data staging area para serem manipulados posteriormente. Normalmente, cada sistema de origem é uma aplicação independente que possui pouco compartilhamento de dados comuns, como produto, cliente e geografia, com outros sistemas transacionais da empresa. A integração desses dados é uma das tarefas que gera maior esforço no projeto de um Data Warehouse. A quantidade de sistemas transacionais envolvidos, suas estruturas de dados5 e o nível de documentação (o Data Warehouse/Data Mart necessita apresentar todos os conceitos e as origens dos dados) interferem diretamente na dimensão do sistema de Data Mart. Na fase de (ii) transformação modifica-se a estrutura do armazenamento de dados. Nessa fase ocorrem ”transformações em potencial, como filtragem dos dados (correções de erros de digitação, solução de conflitos de domínio, tratamento de elementos ausentes ou a divisão em formatos padrão), cancelamento de dados duplicados e atribuições de chaves” (KIMBALL e ROSS, 2002, p. 10). Nessa fase de transformação também pode ocorrer: Integração – envolve a geração de chaves substitutas para cada registro, de modo a evitar a dependência de chaves definidas no sistema legado; Limpeza – correção de códigos e caracteres especiais, resolvendo problemas de domínios, tratando dados perdidos e corrigindo valores duplicados ou errados; Eliminação – eliminar campos e dados provenientes dos sistemas legados que não serão úteis ao Data Mart; Combinação – realizada quando fontes de dados possuem os mesmos valores de chaves representando registros iguais ou complementares ou atributos de chaves não iguais, incluindo equivalência textual de códigos de sistemas legados distintos; 5 Definição da estrutura em que estão os dados de origem: VSAM, Banco de Dados Relacional (DB2, Sybase, Oracle, etc), Banco de dados hierárquico (IDMS), etc. 15 Verificação de integridade referencial – significa verificar se os dados de uma tabela são iguais aos dados correspondentes em outra tabela; Desnormalização e renormalização – consiste em reunificar as hierarquias de dados, separadas pela normalização dentro de uma tabela desnormalizada; Conversão de tipo de dados – envolve transformação de baixo nível de forma a converter um tipo de dado em outro formato; Cálculos, derivação e alocação – são transformações a serem aplicadas sobre as regras de negócio identificadas durante o processo de levantamento de requisitos; Auditoria no conteúdo dos dados – o processo de transformação deve realizar constantes verificações de somas, contagem de linhas e testes. Também são definidas as agregações necessárias para melhorar o desempenho das consultas para o usuário final (considerando a previsão de volume de dados). Toda essa transformação ocorre na data staging area ou Operational data storage (ODS), se a arquitetura da solução envolver esse componente. ODS são cópias integradas e freqüentemente atualizadas de dados transacionais. É um terceiro sistema físico de tabelas localizado entre os sistemas transacionais e o Data Warehouse, utilizado ou não conforme a arquitetura de solução adotada (KIMBALL e ROSS, 2002, p. 449). O principal objetivo do ODS é fornecer informações imediatas dos resultados transacionais, em casos em que os sistemas transacionais e o Data Warehouse não conseguem atender. A fase de (iii) carga é um processo interativo, pois o Data Warehouse tem que ser povoado continuadamente e refletir de forma incremental as mudanças dos sistemas transacionais. Manutenções que possam ocorrer nas fontes de dados interferem diretamente na dimensão do projeto, pois, além das transformações precisarem ser re-definidas e aplicadas, a carga também é alterada a cada modificação das fontes de dados das origens. A carga é a última etapa do processo de ETL e é realizada no banco de dados do Data Warehouse, na área de apresentação de dados. O processo de (iv) garantia da qualidade visa a garantir que o dado foi carregado corretamente nesse banco de dados e que todo o tratamento elaborado sobre esse dado (limpeza, indexação, agregação, etc) está garantindo a veracidade, correção dos dados e qualidade ao usuário final. No banco de dados do Data Warehouse (que pode ser desenvolvido utilizando uma tecnologia de banco de dados multidimensional ou relacional) os dados são armazenados em cubos (Fig. 2.3). Um modelo multidimensional permite modelar logicamente os dados para 16 melhorar o desempenho de consultas, maximizando a eficiência do esforço computacional e minimizando a quantidade de tabelas no banco de dados, provendo, desta forma, facilidade de utilização. O modelo multidimensional é normalmente representado por meio de um cubo, mas pode ter mais de três dimensões. O modelo da Figura 2.3 mostra uma representação de um fato Vendas por meio de um cubo. A medida é o volume de vendas, o que é determinado pela combinação de três dimensões: Localização, Produto e Tempo. A dimensão Localização nesta figura teria as cidades Fortaleza e Natal. A dimensão Produto teria os produtos Refrigerante, Leite, Creme e Sopa. A dimensão Tempo teria os meses 1, 2, 3. 1 Meses 2 3 Produtos Refrigerante Leite Creme Sopa Localizaçãos Fortaleza Natal Figura 2.3 - Modelo Multidimensional de dado – Fato Vendas Este modelo multidimensional pode ser representado graficamente pelos esquemas estrela ou flocos de neve. O esquema estrela é a estrutura básica de um modelo de dados multidimensional. É composto por uma entidade central, denominada fato, e um conjunto de entidades menores, denominadas dimensões, arranjadas ao redor desta entidade central. Esta abordagem recomenda a não normalização das tabelas dimensão(CHAUDHURI e DAYAL,1997) e (BARBIERI, 2001, p. 85). A Figura 2.4 exemplifica o esquema estrela. 17 Tabela dimensão Produto Tabela dimensão Cliente Tabela fato Vendas Tabela dimensão Cidade Tabela dimensão Data Figura 2.4 - Exemplo de esquema estrela Adaptado Moody e Kortink(2000) Cada fato representa um item de negócio ou uma transação de negócio. As tabelas fatos armazenam medidas numéricas associadas a eventos do negócio. Contêm dados normalmente aditivos (manipulados por soma, média, etc) e relativamente estáticos (MACHADO, 2000, p. 80-81). Cada dimensão participa de um fato e determina o contexto de um assunto de negócio. As tabelas dimensão representam entidades de negócios e constituem as estruturas de entrada que servem para armazenar informações como tempo, geografia, produto, cliente, etc (MACHADO, 2000, p. 95). O esquema flocos de neve é o resultado da decomposição de uma ou mais dimensões que possuem hierarquias entre seus membros. Esta abordagem recomenda a normalização das tabelas dimensão (CHAUDHURI e DAYAL, 1997) e (BARBIERI, 2001, p.85). A Figura 2.5 mostra um exemplo do esquema flocos de neve. Tabela dimensão Região Tabela dimensão Produto Tabela dimensão Cliente Tabela fato Vendas Tabela dimensão Estado Tabela dimensão Cidade Tabela dimensão Data Figura 2.5 - Exemplo de esquema flocos de neve 18 Além dos quatro processos citados anteriormente, Kimball et al.(1998, p. 24-25) ainda identificam outros processos necessários para a construção de um Data Warehouse, como Publicação6, Atualização7, Consultas8, Auditoria9, Segurança10 e Cópia de Segurança e Recuperação11. Existem diferentes abordagens para o desenvolvimento de Data Warehouse/Data Mart, sendo importante considerar uma metodologia no início de sua construção. O subitem 2.6 descreve algumas metodologias existentes para esta tecnologia. 2.6 METODOLOGIAS PARA O DESENVOLVIMENTO DE SISTEMAS DATA WAREHOUSE/DATA MART A adoção de uma metodologia para o desenvolvimento de sistemas de Data Warehouse/Data Mart tem um papel importante no planejamento e construção de grandes e escaláveis Data Warehouse, e também impacta na construção do produto de forma mais rápida (WATTERSON, 1998). Como já foi mencionado anteriormente, o processo de desenvolvimento de um Data Warehouse ocorre partindo de um enfoque diferente do que é seguido nos sistemas transacionais. Além dos dados terem uma contextualização diferente, o ciclo de vida para um sistema transacional é diferente do ciclo de vida de um sistema de apoio à decisão. Para Inmon (2000), vide Quadro 2.2, tais diferenças estão relacionadas principalmente à ordem das atividades, entre o ciclo de vida de um sistema transacional e de um sistema de Data Warehouse. Quadro 2.2 - Ciclos de vidas Sistema transacional Data Warehouse Levantamento de requisitos Análise das áreas e de informações Análise, síntese de requisitos Integração dos dados identificando distorções Projeto Definição programas Programação Projeto do sistema Teste Análise, síntese de requisitos dos usuários finais Implementação Identificação, entendimento dos requisitos implementação do repositório de dados Adaptado de Inmon(2000) 6 Tem o objetivo de notificar que o Data Mart está carregado, atualizado, com qualidade garantida e pronto para utilização. 7 Visa atualizar o Data Mart frente a mudanças de hierarquias corporativas, status e etc . 8 Tem o objetivo de disponibilizar consultas para usuários finais. 9 Tem como objetivo auditar o sistema. 10 Visa criar mecanismos para garantir a segurança dos dados. 11 Visa garantir que os dados serão armazenados e poderão ser recuperados. 19 Para construção do sistema transacional são definidas as atividades do negócio e os processos necessários para cumpri-las. Para a construção de um sistema de apoio à tomada de decisão, são levantadas as áreas de maior interesse e as informações geradas por essas áreas. Esses dados são trabalhados e após a base de dados ser montada, parte-se para as definições dos processos exigidos nas análises dos dados. Esses fatores demonstram a necessidade de uma metodologia própria que atenda a esse ciclo de vida diferenciado. Existem várias propostas de metodologia para Data Warehouse, entre elas as abordagens Inmon (2003), Kimball e Ross (2002, p. 380-424), Husemann, Lechtenborger e Vossen (2000), Golfarelli e Rizzi (1999), Porter e Rome (1995). Esses autores concordam que a construção de um Data Warehouse é diferente de um sistema transacional (GOLFARELLI e RIZZI, 1999; INMON, 1999) e sugerem uma seqüência de fases para compor o ciclo completo de desenvolvimento nessa tecnologia. A seguir são descritas sucintamente algumas metodologias existentes. 2.6.1 Abordagem Inmon (2003) Inmon (2003) propõe uma série de fases para construção de um Data Warehouse (Figura 2.6). A abordagem de Inmon abrange também etapas de alto nível com aspectos do projeto, como por exemplo, desenvolvimento inicial da organização e infra-estrutura tecnológica . 20 Desenvolvimento inicial Infra-estrutura tecnológica Projeto preliminar Modelo de dados Data Mart Projeto físico do banco de dados Reespecificação Acesso usuário final , análise Sistema de registro Exploração data warehouse Carga no sistema Figura 2.6 - Metodologia de desenvolvimento de um Data Warehouse Adaptado Inmon(2003) Na etapa de Desenvolvimento inicial da organização são identificadas as motivações para iniciação do processo. É elaborada uma previsão inicial de gastos com desenvolvimento e infra-estrutura, é definida a ordem de desenvolvimento (identificação dos módulos prioritários), o tamanho e a expectativa de evolução. Essa fase possui as seguintes saídas: identificação dos patrocinadores, definição dos objetivos e identificação de uma arquitetura com o propósito de mapear as necessidades organizacionais com relação às informações existentes. Na etapa seguinte de Infra-estrutura tecnológica são identificadas as necessidades de hardware (armazenamento, armazenamento alternativo, processadores, comunicações), software (sistema operacional, DBMS), acesso do usuário final e softwares de análises e gerenciamento de sistemas (monitoração de atividades on line, monitoração da atividade histórica, capacity planning, extração/transformação e carga e gerenciamento de metadata). A seleção de uma infra-estrutura tecnológica gera impacto nos custos, performance e capacidade. Para definição dessa etapa é necessário identificar o volume de dados, o nível de dados que se deseja construir, a quantidade de usuários, o custo da tecnologia, etc. Na fase de Projeto preliminar, identifica-se a granularidade dos dados e a forma como as interações serão efetuadas. São definidas a ordem de cada diferente interação do 21 desenvolvimento (o projeto de Data Warehouse deve ser dividido em séries de entregas lentas ou rápidas), a origem dos dados e identificados quais os Data Mart poderão ser derivados desse processo. A fase de Modelo de dados consiste de três níveis: o modelo de nível alto ou do diagrama de Entidade e Relacionamento, o modelo de nível médio (lógico) e o modelo de nível baixo (físico). Nessa etapa são identificados o escopo, os modelos existentes, os requisitos do usuário e os níveis de modelos pretendidos. Na primeira interação, define-se a forma como os dados serão carregados (se por unidade de tempo, por áreas geográficas, linha de produto, classe de cliente, tipo de atividade, etc); quais áreas funcionais serão definidas como as iniciais na interação do Data Warehouse (finanças, vendas, marketing, etc); quais áreas de interesse serão as primeiras a serem trabalhadas (há a necessidade de escolher um subconjunto de cada área de interesse para iniciar os trabalhos ou implementar somente uma). Após as fases de definição de infra-estrutura tecnológica, projeto preliminar e modelo de dados, inicia-se o Projeto físico do banco de dados, onde são definidos layout, tabelas, chaves, alocação de espaço, características físicas, índices, atributos, redundâncias e compactação. No projeto físico é implementado o nível de granularidade definido anteriormente. A fase seguinte é o Registro do sistema e nesta fase é efetuado o mapeamento dos dados de origem do legado com relação ao modelo de Data Warehouse. São estudadas e definidas as interfaces necessárias para a carga do Data Warehouse. A fase de Registro do sistema é considerada a mais complexa atividade na construção de um Data Warehouse, pois se identificam as múltiplas origens dos dados, a falta de origens para alguns dados, a necessidade de sumarização, conversão e recálculo dos dados, reestruturação de atributos de dados, fusões condicionais de dados, etc. A Carga do sistema é a próxima fase onde são identificados o número de programas necessários, a complexidade da lógica desses programas, linguagem desses programas, desenvolvidos os programas e efetuada a carga do sistema. A fase de Acesso usuário final /análise e feedback permite a execução dos testes pelos usuários finais. Na fase de Re-especificação é definido o plano de construção da próxima interação para o desenvolvimento. 22 2.6.2 Proposta de Kimball e Ross (2002) - Diagrama do ciclo de vida dimensional do negócio - Business development lifecycle (BDL) A Figura 2.7 demonstra a abordagem de Kimball e Ross (2002, p. 381), que tem como base principal um framework conceitual descrevendo uma seqüência de etapas de alto nível requeridas para o projeto, desenvolvimento e implementação de um Data Warehouse. Planejamento do projeto Definição dos requisitos do negócio Projeto técnico de arquitetura Seleção e instalação do produto Modelagem dimensional Projeto físico Projeto e desenvolvimento da data staging Especificação da aplicação analítica Desenvolvimento da aplicação analítica Distribuição Manutenção e crescimento Gerenciamento do projeto Figura 2.7 - Diagrama do ciclo de vida dimensional do negócio Adaptado de Kimball e Ross (2002, p. 381) O ciclo de vida inicia-se com Planejamento do projeto, onde são identificados fatores como a motivação da empresa, patrocinador do projeto, cultura analítica da empresa, definidas a análise da viabilidade (técnica, de recursos e de dados) e o escopo do projeto (definido pela área de TI e de negócios). Na etapa seguinte, Definição dos requisitos do negócio ocorre a definição de prioridades (análise de prioridades), impacto no negócio (alta/baixa) e viabilidade de dados (alta/baixa) juntamente com os gestores e os analistas dos sistemas de origem. Na etapa do Projeto de arquitetura técnica se realiza a coleta de requisitos relacionados à arquitetura, requisitos de segurança, e são identificadas as necessidades de configuração e de infra-estrutura física com relação ao tamanho, escalabilidade, desempenho, flexibilidade. Kimball et al (1998) sugere uma fase de seleção e instalação dos produtos que possui o objetivo de após o entendimento dos processos corporativo de compras, avaliar os produtos, conduzir a pesquisa de mercado, conduzir um protótipo (se necessário), instalação e negociação. 23 Uma análise mais aprofundada dos dados gerados pelo processo, avaliação da granularidade, consistência histórica, valores válidos e disponibilidade de atributos são ocorrências da fase modelagem dimensional. Identificam-se também nesta fase os sistemas de origens específicos, campos e regras de transformação para derivar o mapeamento de origem para destino. É criado o esquema dimensional e são identificados os nomes de tabelas, colunas, definições e as regras de cálculo para fatos e regras de dimensões (se houver a especificação de um metadados esta irá consistir uma de suas primeiras entradas). As demais fases que integram este framework proposto tratam do Projeto físico onde são efetuadas atividades como ajuste de desempenho, particionamento, criação de índices, agregação de tabelas (que são alternativas para garantir um desempenho adequado). Nessa fase são definidas estratégias de agregação de forma pré-calculada e pré-armazenada (quais dados os gestores estão resumindo com maior freqüência), estabelecidas as estratégias iniciais de indexação e implementado um sistema de monitoramento para permitir o ajuste contínuo de desempenho. Na etapa subseqüente, Projeto de desenvolvimento da data staging area ocorre o ETL da tabela dimensão com a extração de dados dos sistemas transacionais de origem e limpeza de valores de atributo12. Também ocorrem as atribuições de chaves substitutas e a carga da tabela dimensão. Nessa etapa é realizado o ETL da tabela fato com a extração de dados dos sistemas transacionais de origem, recebimento das dimensões atualizadas, separação dos fatos por granularidade (sistemas transacionais de origem incluem dados em diferentes níveis de detalhe dentro de um mesmo arquivo), transformação dos fatos conforme necessário13, troca das chaves transacionais de origem por substitutas, adição de chaves para contexto conhecido de forma a garantir a qualidade dos dados das tabelas de fatos. São também construídas ou atualizadas as tabelas de fatos de agregação e criada a massa para carga de dados. Essa etapa é identificada por muitos autores como Allison (2001), Fiori (2002), Inmon (1997), Meyer (2001) e Mrazek (2003) como o processo de maior impacto na construção de um Data Mart. Kimball e Ross (2002) definem ainda as etapas de especificação de aplicação analítica e desenvolvimento de aplicação analítica nas quais ocorrem a especificação, desenvolvimento e revisão das estratégias para ajuste de desempenho das aplicações analíticas. 12 Tratamento de valores descritivos inconsistentes, decodificações ausentes, códigos sobrecarregados com vários significados, dados inválidos e dados ausentes. 13 Cálculos aritméticos, conversões de tempo, equivalência de moedas, unidades de medida, normalização de fatos e tratamento de nulos. 24 As etapas seguintes seriam a Distribuição e Manutenção e Crescimento, pois tanto Kimball e Ross (2002) como Inmon (2003) concordam que o processo de desenvolvimento de um Data Warehouse é um processo interativo que necessita estar em constante manutenção e crescimento. 2.6.3 Abordagem de Husemann, Lechtenborger e Vossen (2000) (Conceptual Data Warehouse design – CDWD) A abordagem de metodologia para Data Warehouse de Husemann, Lechtenborger e Vossen (2000), diferente de Inmon (2003) e Kimball e Ross (2002) foca somente no processo de desenvolvimento do Data Warehouse. Não identifica etapas de alto nível requeridas para o andamento do projeto. Desse modo, compreende 4 fases seqüenciais: Análise dos requisitos e especificação, Projeto conceitual, Projeto lógico e Projeto físico. Na Figura 2.8, podem ser visualizadas as entradas e saídas de cada fase. Análise dos requisitos e especificação Esquema operacional da base de dados Conceitos de negócio semiformal Projeto conceitual Esquema conceitual formal Projeto lógico Esquema formal lógico Projeto físico Esquema físico do banco de dados Figura 2.8 - Modelo de Processo para o Projeto de Data Warehouse Adaptado de Husemann, Lechtenborger e Vossen (2000) Na primeira fase de Análise dos requisitos e especificação são estudados os esquemas Entidade/Relacionamento transacionais, pois possuem a informação básica para determinar a análise multidimensional. Nessa fase os usuários finais selecionam os atributos relevantes estrategicamente e especificam o propósito de suas dimensões e medidas. O resultado da 25 especificação desses requisitos é uma lista dos atributos com seus propósitos multidimensionais. A fase Projeto conceitual consiste na transformação de requisitos semiformais de especificação para o esquema formalizado conceitual multidimensional, que compreende o esquema dos fatos com suas medidas e hierarquias. No Projeto lógico o esquema conceitual é convertido para o esquema lógico respeitando o destino dos dados (relacional ou multidimensional). O esquema lógico é gerado de acordo com as regras de transformação considerando os diagramas conceituais de desenvolvimento. Na fase seguinte Projeto físico o desenho de Data Warehouse é implementado fisicamente incluindo estratégias de índices, particionamento, pré-agregações, ajustes para desnormalização. 2.6.4 Abordagem de Golfarelli e Rizzi (1999) A abordagem de Golfarelli e Rizzi (1999) não identifica etapas de alto nível citadas nas abordagens de Kimball e Ross (2002) e Inmon (2003). Esses autores definem seis fases de metodologia para a construção de um Data Warehouse e as descrevem conforme o Quadro 2.3. Quadro 2.3 - Fases da metodologia propostas por Golfarelli e Rizzi Fases Entradas Saídas Participantes Análises dos Documentações existentes Esquema de data base Projetistas, gerentes de sistema sistemas de de informação informação Especificação de Esquema de database Fatos, requisitos trabalho de carga Projetistas e usuários finais preliminar Projeto Esquema conceitual trabalho de carga preliminar Refinamento do Esquema dimensional, trabalho trabalho de de carga preliminar database, fatos, Esquema dimensional Projetistas Trabalho de carga Projetistas e usuário final DW esquema lógico Projetistas DW esquema físico Projetistas carga, validação do esquema dimensional Projeto lógico Esquema dimensional, modelo lógico direcionado, trabalho de carga Projeto físico DW esquema lógico, Banco e trabalho de carga Adaptado de Golfarelli e Rizzi (1999) 26 Na fase de Análise dos sistemas de informação ocorre a coleta da documentação concernente aos sistemas de informação pré-existentes. É um novo aspecto com relação ao desenvolvimento de sistemas transacionais que não requerem a pré-existência de bases de dados de suas origens. Sua saída são os esquemas conceituais ou lógicos. Na etapa seguinte de Especificação de requisitos, são coletados e filtrados os requisitos do usuário. Envolve o analista e os usuários finais de Data Warehouse, e produz as especificações concernentes aos fatos e indicações sobre a carga de trabalho (workload). Os fatos são baseados na documentação e informação do sistema a ser produzido. Fatos são os conceitos de interesse primário para as decisões adotadas e correspondem aos eventos que ocorrem dinamicamente no mundo empresarial. A carga de trabalho preliminar é expressa em linguagem pseudonatural e ajuda o analista a identificar dimensões e medidas durante o projeto conceitual. Para cada fato são especificadas medidas e agregações de interesse. Na etapa de Projeto conceitual são iniciados os esquemas dos sistemas de informações transacionais considerando os fatos e a carga preliminar de trabalho definida no passo anterior. Nessa etapa são construídos os esquemas dimensionais estruturados de acordo com o DFM (Modelo de Fato Dimensional), que consiste no conjunto de esquemas de fatos (um para cada fato) cujos elementos básicos são fatos, dimensões e hierarquias. Para cada esquema de fato deve ser definida a construção e refinamento da árvore de atributos com identificação das dimensões, das medidas e das hierarquias. O DFM possibilita suporte eficiente ao projeto conceitual e permite ao analista e aos usuários refinar as especificações dos requisitos. Representa também uma sólida plataforma para a fase de projeto lógico, além de disponibilizar uma documentação expressiva e não ambígua. A Figura 2.9 apresenta um exemplo da representação DMF. Gerenciamento de vendas Fato: Vendas Hierarquia estoque cidade estado atributo não dimensional endereço Figura 2.9 - Exemplo de um Modelo de Fato Dimensional Adaptado de Golfarelli e Rizzi (1999) 27 A etapa seguinte de Refinamento da carga de trabalho e validação do esquema, consiste em detalhar o esquema dimensional e definir uma especificação para as consultas de acordo com o DFM. Nessa etapa também se analisa a expectativa de volume de dados. A próxima etapa é o Projeto lógico que recebe o esquema dimensional, a workload, e um conjunto de informações adicionais (freqüência de atualizações, espaço em disco) para produzir o esquema de Data Warehouse com a garantia de minimização de tempo de resposta das consultas. Nessa etapa há a definição de visões materializadas, transações entre tabelas e particionamento vertical e horizontal entre tabelas fatos. Na última etapa de Projeto físico há a implementação física do projeto lógico com seleção de índices, baseados no esquema lógico, workload, e nos requisitos de acesso que foram especificados. Nessa fase são selecionados cada tipo de índice e seu respectivo custo funcional. 2.7 ANÁLISE COMPARATIVA No Quadro 2.4 são apresentadas as características diferenciais das quatro abordagens analisadas de desenvolvimento do Data Warehouse. Quadro 2.4 - Características diferenciais das abordagens metodológicas Abordagem Etapas do desenvolvimento Características diferenciais Inmon (2003) Desenvolvimento inicial da organização Identificação Infra-estrutura tecnológica implementacionais) Projeto preliminar Processo iterativo de etapas de alto nível(aspectos Modelo de dados Projeto físico do banco de dados Registro do sistema Carga do sistema Acesso usuário final /análise e feedback Reespecificação Kimball e Planejamento Ross(2002) projeto implementacionais) Definição dos requisitos do negócio Processo iterativo Projeto de arquitetura técnica Técnicas de modelagem dimensional Seleção e instalação dos produtos Definição de etapa para trabalhar com aplicações analíticas. Modelagem dimensional Identificação da fase de gerenciamento durante todo o Projeto físico projeto de gerenciamento do Identificação Projeto de desenvolvimento da data staging área Especificação de aplicação analítica e desenvolvimento de aplicação analítica Distribuição Implantação Manutenção e crescimento de etapas de alto nível (aspectos 28 Quadro 2.4 (cont.) - Características diferenciais das abordagens metodológicas Abordagem Etapas do desenvolvimento Características diferenciais Husemann, Análise dos requisitos e especificação Visão simplificada do processo Lechtenborger e Projeto conceitual Vossen (2000) Projeto lógico Projeto físico Golfarelli e Rizzi Análise dos sistemas de informação (1999) Proposta de um Modelo de fato dimensional - DFM Especificação de requisitos Projeto conceitual Refinamento do trabalho de carga, validação do esquema dimensional Projeto lógico Projeto físico Nota-se que na maior parte das metodologias citadas são identificadas fases de análise de requisitos, modelagem de dados (INMON, 2003) ou modelagem multidimensional (KIMBALL e ROSS, 2002), com ênfase maior na modelagem de aspectos voltados ao domínio multidimensional e projeto físico. A abordagem de Husemann, Lechtenborger e Vossen (2000) tem como elemento central a construção do projeto físico e não identifica as etapas abordadas por Kimball e Ross (2002) e Inmon (2003) de mapeamento dos dados de origem para o destino, de extração e transformação e carga dos dados e do processo iterativo proposto. Dessa forma, a abordagem apresenta uma visão simplificada do processo considerando o processo ETL ser um dos processos de maior impacto na construção de um Data Mart, conforme já citado anteriormente. A proposta de Golfarelli e Rizzi (1999) descreve o modelo de DFM como facilitador da construção de um Data Warehouse. É uma proposta direcionada à criação de um modelo detalhado e aprimorado de forma a garantir o entendimento das necessidades do usuário, a representação destas por meio do modelo DFM. Golfarelli e Rizzi (1999) não identificam etapas de extração, transformação e carga no processo, nem de iteração, o que torna a abordagem restrita à utilização do modelo proposto. Tanto a proposta de Kimball e Ross (2002) como a de Inmon (2003) propõem um desenvolvimento iterativo, identificando etapas como especificação (INMON, 2003) e manutenção e crescimento (KIMBALL e ROSS, 2002), de forma a garantir uma evolução constante do modelo. Essas duas abordagens apresentam uma boa cobertura das fases de desenvolvimento para esse tipo de tecnologia, detalhando, inclusive, o processo de ETL, que é um dos processos que demanda maior esforço na construção de um Data Mart, e as fases de alto nível com relação a aspectos iniciais do projeto. 29 2.8 CONSIDERAÇÕES DO CAPÍTULO O processo de desenvolvimento de sistemas de Data Warehouse apresenta diferenças com relação ao processo de desenvolvimento de sistemas transacionais. A transformação do dado operacional em informação para suporte à decisão é complexa e requer arquiteturas e metodologias próprias que garantam produtividade, agilidade e qualidade. Além de características como volume de dados, modelo multidimensional e tratamento de dados, a construção de um Data Mart é um processo oneroso e que necessita de acompanhamento constante, de forma a garantir o atendimento das necessidades de informações estratégicas para o usuário final. Uma abordagem adequada em termos de estimativas de tamanho de sistema para este tipo de software poderá agregar valor ao resultado final, ajudando também a identificar formas de melhorar a qualidade do produto e do processo. Com base nestas considerações, foi julgado importante elaborar uma proposta alternativa de medição de tamanho para a tecnologia de Data Mart. No próximo capitulo serão apresentadas diferentes abordagens para medição de tamanho na engenharia de software. 30 CAPÍTULO 3 - MEDIÇÃO DE TAMANHO DE SOFTWARE ____________________________________________________________________________ 3.1 INTRODUÇÃO Medição aplicada à área de engenharia de software é conceituada como a avaliação quantitativa de algum aspecto da engenharia de software, processo ou produto e tem como objetivos facilitar a análise, a estimativa e o controle do processo de desenvolvimento de um produto de software e estabelecer baselines para ajudar o desenvolvimento futuro (FENTON e PFLEEGER, 1997, p. 5), (PFLEEGER, 2000). Medições provêm também de informações quantitativas para suportar a tomada de decisões, minimizar os riscos e aperfeiçoar continuamente a produção e o produto (FENTON e NEIL, 2000). As principais medições voltadas para o desenvolvimento de software podem ser classificadas em medições de processos, medições de produto e medições de recursos (FENTON e PFLEEGER, 1997, p. 74). A medição de um produto de software, além de proporcionar um melhor entendimento, controle e aperfeiçoamento do processo de construção de software, também está vinculada à necessidade de gerar expectativas mais realistas para o usuário, avaliar e medir resultados, conhecer melhor o patrimônio de software, avaliar o impacto da introdução de novas tecnologias, obter indicadores de desempenho (produtividade, qualidade do código) e obter e/ou melhorar estimativas de prazo, custo e recursos (SIMÕES, 1999). Desde a década de 1960, várias abordagens têm sido propostas e aperfeiçoadas com o objetivo de definir o tamanho de um produto de software, entre elas: Lines of code – LOC (FENTON e NEIL, 2000), a abordagem Halstead (BATENBURG, RIDDER e KERF, 1998), Function Point Analysis – FPA ou Análise por Pontos de Função – APF (IFPUG, 2000), o MKII Function Point Analysis (LOKAN e ABRAN, 1999) e o Full Function Points, COSMIC Full Functions Points (ABRAN et al, 1999). O presente capítulo apresenta na seção 3.2 uma breve descrição sobre medição, no que se refere à sua definição e classificações. Na seção 3.3 são apresentadas algumas abordagens de métricas de tamanho existentes: LOC, Halstead, APF, MK II e Full Function Points/COSMIC. Na seção 3.4, será apresentada uma proposta de medição de tamanho para o contexto de Data Warehouse/Data Mart de Santillo (2001). A seção 3.5 faz uma breve comparação entre as abordagens estudadas. 31 3.2 MEDIÇÃO DE SOFTWARE Medição é o processo por meio do qual números ou símbolos são atribuídos a entidades do mundo real de forma a tornar possível caracterizar cada entidade por meio de regras claramente definidas (PFLEEGER et al, 1997), ou seja, é o processo de obtenção de uma medida para uma entidade do mundo real. Uma medida fornece uma indicação de quantidade, dimensão, capacidade ou tamanho de algum produto de software ou de um processo. Em outras palavras uma medida refere-se a um valor de uma métrica. Segundo a norma ISO 9126 (ISO/IEC 9126-1, 2001), métrica é a composição de métodos para medição e escalas de medição. Essas escalas de medição são formas de mapeamento para que, por meio da manipulação de dados numéricos, seja possível entender o comportamento das entidades. Existem vários tipos de mapeamentos para expressar os dados coletados para mensuração de software e as principais escalas de medição são determinadas pelos tipos de mapeamentos demonstrados no Quadro 3.1 baseado em Fenton e Pfleeger (1997, p.46), Pfleeger et al (1997) e Kitchenham, Hughes e Linkman (2001). Quadro 3.1 - Escalas de medição Tipo Descrição Nominal O valor do atributo é representado por um nome ou Exemplo Cor rótulo. Não possuem nenhuma relação de ordem entre os Possível intervalo Vermelho, amarelo, azul, verde diferentes tipos e qualquer representação simbólica ou numérica pode ser utilizada. As classes podem ser numeradas de 1 a n para identificação, mas de forma não Condições Igual, não igual Complexidade da Baixa, média e alta ordenada. Ordinal Acrescenta a noção de ordem à escala nominal. aplicação Ordinal não Acrescentaa noção de ordem à escala não-nominal. restrita Intervalo Rank ordenado de 1 a 20 clubes de futebol Intervalo – possui a informação do tamanho dos Graus de Temperatura 273 a 373 intervalos que separam as classes. Preserva a ordem da Kelvin escala ordinal, preserva diferenças mas não médias. Racional Racional – Escala com mais informações e flexibilidade. Medidas geométricas Medidas de linhas de Incorpora zero absoluto e permite análises sofisticadas. Coeficiente de código ou de números Possui ordem e tamanho dos intervalos entre as classes e variação de defeitos acrescenta a noção de razão entre as magnitudes. Todas as funções aritméticas podem ser utilizadas aplicadas em cada intervalo do mapeamento, gerando resultados significativos. Somente o entendimento das características de cada escala torna possível determinar se a conclusão obtida a partir da análise de dados numéricos possui significado para as medições efetuadas. 32 Fenton e Pfleeger (1997, p.74) identificam 3 principais classificações de medições voltadas para o desenvolvimento de software: medições de processos – mensuram as atividades realizadas durante todo o desenvolvimento de software, sendo necessário bom entendimento do processo para que essas métricas sejam bem aplicadas e utilizadas; medições de produto – mensuram os artefatos, produtos e documentos resultantes da atividade do processo; e, medições de recursos – mensuram as entidades requeridas para a execução do processo. Para cada uma dessas classificações é possível identificar atributos internos (tamanho, modularidade, redundância, funções, etc) e externos (qualidade, custo efetivo, estabilidade, compreensibilidade, etc) que podem ser também mensurados. De acordo com Fenton e Pfleeger (1997, p.246), o tamanho do produto de software pode ser utilizado para definir uma estimativa da quantidade de trabalho a ser executada no desenvolvimento do projeto. A definição de tamanho do produto também é utilizada para gerar outras estimativas como esforço, cronograma e qualidade (GARMUS e HERRON, 2000, p.5). As empresas necessitam estimar de forma acurada o tamanho dos produtos de software no início do processo de desenvolvimento para melhor planejar e prever a construção de produtos de software, diminuir o risco e a tomada de decisões errôneas (STUZKE, 2000). Agarwal et al (2001) concordam com essa questão destacando que a utilização de estimativas de tamanho no início do estágio de um projeto de software é uma das necessidades do mercado para garantir o suporte eficaz à tomada de decisões. Existem várias técnicas que avaliam as variáveis de tamanho. Segundo Simões(1999), essas técnicas podem ser classificadas basicamente em: Analógicas - baseada na experiência de quem faz estimativas; Modelos Algorítmicos - modelos baseados em cálculos matemáticos, por exemplo, o LOC que pontua o número de instruções fontes e a proposta Halstead; e, Análise de Funcionalidade - modelos baseados nas funções do software, por exemplo, a APF, Mark II, COSMIC FFP. 3.3 MÉTRICAS DE TAMANHO A seguir são apresentadas algumas abordagens de medição de tamanho, em ordem cronológica de seu surgimento. 33 3.3.1 Lines of code - LOC (1950 /1960) LOC ou Source Lines of Code - SLOC foi uma das primeiras métricas utilizada pelas empresas. A partir de 1960, LOC foi aplicada como base de medida para programas de qualidade (normalmente medindo indiretamente os defeitos por SLOC) e para definir produtividade por programador (LOC por programador mês) (FENTON e NEIL, 2000). LOC foi amplamente utilizada até meados de 1970 e com o aparecimento de uma diversidade de linguagens de programação houve a necessidade de outras formas de mensurar. LOC possui alguns pontos negativos como o fato da abordagem aplicada em um tipo de linguagem não poder ser comparada com a aplicação em outro tipo de linguagem (ex.: a linguagem assembler não é comparável em complexidade com outra linguagem; em orientação a objeto, a flexibilidade da ferramenta na utilização de mecanismos de herança dilui o resultado final da contagem das linhas, etc). Além disso, as contagens de linhas de código são uma medida de tamanho do que foi feito e não uma medida a ser utilizada no início do estágio de um projeto de software. A partir da década de 1970, interessantes mensurações de tamanho, baseadas na complexidade de software (Halstead) e de medidas de tamanho funcional (APF, MKII, COSMIC FFP), foram lançadas com a intenção de serem independentes da linguagem de programação. 3.3.2 Halstead (Maurice Halstead) (1972) Desenvolvido em 1972, como uma abordagem formal para definir o tamanho de um software e derivar várias estimativas, esse método é baseado no conceito de que o tamanho e a complexidade do software são definidos em função da quantidade de operadores e operandos do programa (BATENBURG et al., 1998), no qual: operadores são os comandos da linguagem utilizados; e, operandos os itens de dados que o programa irá tratar. Os operandos e os operadores são analisados e quantificados, e quatro medidas são definidas: n1 = número de operadores distintos presentes em um programa n2 = número de operandos distintos presentes em um programa N1 = total de ocorrências de operadores em um programa N2 = total de ocorrências de operandos em um programa. 34 Quantifica-se os vocábulos, a extensão do algorítmo e a dimensão total do programa em análise por meio das fórmulas: quantidade de vocábulos: n=n1+n2; e, comprimento do algorítmo: N=N1+N2. A dimensão total do programa é calculada por meio da fórmula: Comprimento do programa N = n1.log2 n1 + n2.log2 n2; e, Volume do programa V= N.log2 n. Essa abordagem não utiliza números puros ou absolutos, mas números relativos sem considerar algumas impurezas, tais como: cancelamento de operadores, operandos ambíguos (um mesmo operando representando duas ou mais variáveis), operandos sinônimos, etc. Com essa contagem, um sistema de equações é utilizado para derivar valores para nível de programa (complexidade de programa), dificuldades do programa, potencial mínimo de volume de um algorítmo e outras medidas (MICHAEL, BOSSUYT e SNYDER, 2002) . 3.3.3 Análise por Pontos de Função (1979) A Análise por Pontos de Função (APF) é uma das abordagens mais utilizadas e estudadas atualmente (Garmus e Herron, 2000, p. xvi). A APF foi proposta, inicialmente, em 1979 por Allan J. Albretch, da IBM, como um método para calcular o tamanho funcional de um software (LOKAN e ABRAN, 1999). Para o cálculo do tamanho funcional, a abordagem AFP propõe (IFPUG, 2000): medir o tamanho do software pela quantificação de suas funções, baseadas no projeto lógico ou a partir do modelo de dados segundo a visão e os requisitos do usuário final; medir independente da tecnologia; ser aplicável desde o início do software; apoiar a análise de produtividade e qualidade; e, estimar o tamanho do software com uma unidade de medida padrão. Os seguintes passos devem ser observados para mensuração de tamanho do software utilizando essa abordagem (IFPUG, 2000): i) Estabelecer o objeto da contagem - a abordagem se propõe a medir projetos de desenvolvimento, projetos de manutenção ou tamanho de uma aplicação existente. ii) Determinar a fronteira de medição - a fronteira de medição deve ser sempre determinada sob o ponto de vista do usuário. É bastante comum a comunicação 35 entre softwares e a fronteira de medição separa os componentes de um software de outros softwares; iii) Contar as funções de dados e suas complexidades - que são as funções relacionadas aos dados utilizados pelo software e que englobam Arquivos Lógicos Internos – ALI (grupo lógico de dados relacionados, identificável pelo usuário, que reside dentro da fronteira do aplicativo) e Arquivos de Interface Externa - AIE (grupo lógico de dados relacionados, identificável pelo usuário, ou informações de controle, referenciados pelo aplicativo, porém mantidos dentro da fronteira de um outro aplicativo). O processo de definição de complexidade de um ALI ou AIE é baseado em Registros Lógicos Referenciados - RLR (subgrupo de dados que são enxergados como um elemento único pelos usuários) e Dados Elementares Referenciados - DER (são os campos de dados não recursivos identificáveis pelos usuários), conforme Quadro 3.2 . Quadro 3.2 - Complexidade Arquivos Lógicos Internos e Arquivos Interface Externa 1 a 19 DER 20 a 50 DER 51 DER em diante 1 RLR Simples Simples Média 2 a 5 RLR Simples Média Complexa 6 RLR em diante Média Complexa Complexa Fonte: IFPUG (2000) iv) Contar as funções transacionais e suas complexidades - que são as funções básicas que o software deve conter e que incluem as Entradas Externas - EE (processo elementar que processa dados ou informações de controle procedentes de fora da fronteira do aplicativo), Saídas Externas – SE (processo elementar que gera dados ou informações de controle e/ou derivados14, enviados para fora da fronteira do aplicativo) e Consultas Externas – CE (processo elementar com componentes de entrada e saída que resulta na recuperação de dados). O processo de definição de complexidade de uma EE é baseado em ALR – Arquivos Lógicos Referenciados (são os ALI ou AIE referenciados pelo processo) e DER – Dados Elementares Referenciados (são todos os campos de dados não recursivos utilizados pelo processo, inclui-se também mensagens de erro, mensagens de confirmação, habilidade do processo de executar ações diferentes, etc), conforme Quadro 3.3 14 Resultado de um ou mais elementos combinados com uma fórmula, de modo a gerar ou derivar um ou mais dados adicionais. 36 Quadro 3.3 - Complexidade de Entrada Externa 1 a 4 DER 5 a 15 DER 0 ou 1 ALR Simples Simples Média 2 ALR Simples Média Complexa Média Complexa Complexa 3 ALR em diante 16 DER em diante Fonte: IFPUG (2000) O processo de complexidade de uma Saída Externa ou Consulta Externa é demonstrado por meio do Quadro 3.4. Quadro 3.4 - Complexidade de Saída Externa ou Consulta Externa 1 a 5 DER 6 a 19 DER 0 ou 1 ALR Simples Simples 20 DER em diante Média 2 ou 3 ALR Simples Média Complexa 4 ALR em diante Média Complexa Complexa Fonte: IFPUG (2000) v) Calcular os pontos de função não ajustados – Neste passo a quantidade de funções de dados e transações com seus respectivos níveis de complexidade são multiplicados pelos números de pontos de função definidos no Quadro 3.5. De acordo com a complexidade, cada uma das funções de dados e transacionais contribui com um determinado número de pontos de função. O total desses pontos de função computados é chamado de pontos de função não-ajustados (NoPFnão ajustado). Quadro 3.5 - Número de pontos de função por função e complexidade Tipo de função Simples Media Complexa ALI 7 10 15 AIE 5 7 10 EE 3 4 6 SE 4 5 7 CE 3 4 6 Fonte: IFPUG (2000) vi) Determinar o Fator de Ajuste – Neste passo, 14 características gerais do software são avaliadas segundo uma escala de 0 (nenhuma influência) a 5 (grande influência). Segundo Lokan e Abran (1999), as características gerais do software identificam vários aspectos funcionais e não-funcionais do software que são utilizados na mensuração de tamanho funcional. Esses aspectos envolvem Complexidade, Suporte ao usuário, Arquitetura, Interação, Fatores limitantes, Operação, Reusabilidade e Qualidade. O Quadro 3.6 apresenta as características gerais considerando estes aspectos. 37 Quadro 3.6 - Aspectos funcionais e não-funcionais x Características gerais Aspectos funcionais e não- Características gerais Definição da característica do software funcionais Complexidade Processamento complexo Aspectos relacionados com a complexidade do processamento. Detalhes específicos devem ser considerados para a pontuação como processamento lógico extensivo, processamento matemático extensivo, etc; Suporte ao Eficiência usuário final usuário Aspectos relacionados com a eficiência do aplicativo na interação com o usuário. A pontuação é decidida quanto aos recursos implementados para tornar o aplicativo amigável; Facilidade de mudanças Aspectos relacionados com o grau de flexibilidade do aplicativo com relação a mudanças de requisitos do usuário. Arquitetura Comunicação de dados Aspectos relacionados aos recursos utilizados na comunicação de dados do aplicativo. É importante determinar que protocolos são utilizados pelo aplicativo para o recebimento ou o envio de informações; Múltiplos locais Aspectos relacionados com a arquitetura do aplicativo e a necessidade de instalação em vários lugares; Processamento Aspectos relacionados com processamento e funções distribuídas; distribuído Interação Entrada de dados on line Aspectos relacionados com a quantidade de entrada de dados on-line do aplicativo; Atualização on line Aspectos relacionados com o modo de atualização dos arquivos lógicos internos do aplicativo; Fatores Desempenho Aspectos relacionados com parâmetros estabelecidos pelo usuário limitantes quanto ao tempo de resposta; Volume de transações Aspectos relacionados com a capacidade do software em relação ao volume de transações esperado; Operação Facilidade de implantação Aspectos relacionados com o grau de dificuldade de implementação do aplicativo. Verifica planos de conversão e de implementação; Facilidade operacional Aspectos relacionados com a facilidade de operação do aplicativo. Avalia procedimentos operacionais automáticos e mecanismos de iniciação, salvamento e recuperação de dados; Utilização de Aspectos relacionados com o nível de utilização dos equipamentos equipamento necessários à execução do aplicativo. A avaliação visa identificar a carga de trabalho exigida pelo aplicativo quando em produção; Reusabilidade Reutilização do código Qualidade Reutilização do código Aspectos relacionados com a reutilização do código do aplicativo; Definido anteriormente. Facilidade de mudanças Definido anteriormente. Fonte: Baseado IFPUG (2000) e Lokan e Abran(1999) Essas características influenciarão a complexidade do software e conseqüentemente seu tamanho. As características gerais do software variam para mais ou menos 35% o tamanho do software e há um fator entre 0,65 e 1,35 a ser utilizado nesse ajuste. 38 O ajuste na mensuração é efetuado através do Fator de Ajuste (FA) baseado na equação: FA = 0,65 + (0,01 x Soma dos graus de influência das características gerais). vii) Determinar pontos de função ajustados – são considerados as funções de dados, transacionais, seu grau de complexidade, as características gerais do software e o tipo de projeto. O resultado da contagem de funções de dados e transacionais é uma medida chamada de pontos de função não-ajustados (NoPFnão ajustado), pois não considera os aspectos citados no Quadro 3.6 que afetam o produto e a sua construção. Para determinar o Ponto de função ajustado - NoPFajustado (tamanho do projeto) consideram-se fórmulas específicas, como por exemplo, para medir aplicação ou projetos de desenvolvimento, a seguinte: NoPFajustado = NoPFnão ajustado x FA. Inicialmente, o modelo APF proposto em 1979 possuía quatro tipos de funções de dados e transações e um conjunto de pesos para pontuar a complexidade. As características gerais do software, que eram 10, possuíam uma variação de mais ou menos 25% (WITTIG et al, 1997) (LOKAN e ABRAN, 1999). Em 1984, a APF foi revista e o modelo expandido para cinco tipos de funções de dados e transações e cada função passou a ter um conjunto de três pesos (simples, média e complexa) para pontuar a complexidade. Algumas características gerais do software foram mantidas, outras modificadas e sete novas características foram adicionadas (LOKAN e ABRAN, 1999). O número das características foi estendido de dez para quatorze e, conseqüentemente, a faixa potencial de variação para mais ou menos 35%. Em 1986, uma comunidade de usuários criou o International Function Point Users Group (IFPUG) para servir como referência ao modelo APF. O modelo permanece desde aquela data sem incrementações substanciais. 3.3.3.1 Medições durante o ciclo de vida do projeto A abordagem APF propõe que a organização para obter habilidade e maior acurácia na estimava de projetos necessita incorporar o processo de estimação ao seu processo de desenvolvimento/manutenção, de forma a poder calibrar constantemente os resultados de sua 39 contagem. A Figura 3.1 mostra os momentos em que é sugerida, pela abordagem APF, a contagem. Inicialmente a contagem é realizada na etapa de requisitos de forma a possibilitar a contagem estimativa. Essa contagem possibilitará uma estimativa do prazo, custo e recursos necessários para o desenvolvimento do produto. Posteriormente será realizada a contagem na etapa de Projeto detalhado, na qual há um maior detalhamento dos requisitos e há a possibilidade de se ajustar a estimativa elaborada na etapa de requisitos. Na etapa de teste, em que todo o escopo do produto já está definido e está sendo validado, será realizada uma nova contagem de forma a verificar a evolução das contagens com relação ao escopo do software. Na etapa de implementação realizar-se-á a contagem final do produto. Nessa etapa é possível visualizar a evolução das contagens e o tamanho final do software. A contagem deve ser contínua em todo o processo de manutenção. Requisitos Contagem Projeto inicial Projeto detalhado Codificação Contagem Teste Contagem Implementação Contagem Manutenção Contagem Figura 3.1 - Proposta do processo de contagem incorporado ao processo de desenvolvimento Fonte: Garmus e Herron(2000, p.88) Vários são os pontos positivos identificados na abordagem APF: Agarwal et al (2001) citam que diferentes pessoas podem contar em tempos diferentes e obter uma mesma medida com uma razoável margem de erro, pontos de função podem ser entendidos pelo usuário não-técnico e a abordagem ajuda a comunicar o tamanho do produto para o usuário final; a abordagem é aceita como Padrão Internacional (ISO/IEC 20926:2003); Garmus e Herron, (2000, p.191) afirmam que o uso da abordagem facilita a comparação de softwares, utilizando uma mesma unidade de medida, possibilita a estimativa de custo, de valor, de recursos e de tempo de desenvolvimento do software. Possibilita a estimativa de tamanho no início do processo de desenvolvimento. É uma abordagem independente da tecnologia utilizada para o desenvolvimento ou manutenção; e, na última década, 15 livros e mais de 100 artigos publicados sobre APF (GARMUS e HERRON, 2000, p.xvi), o que mostra sua maturidade e a torna uma das abordagens funcionais mais utilizadas pelo mercado atualmente. 40 Outros autores criticam e questionam a abordagem APF com relação a: problemas com diferentes tecnologias (pontos de função não são independente do software ou do método utilizado), com diferentes domínios de aplicação (existem questionamentos sobre a aplicabilidade da abordagem em softwares real time e em aplicações cientificas) e com a mudança de requisitos (FENTON e PFLEEGER, 1997, p.264) e (ABRAN et al, 2001); problemas com a subjetividade das características gerais do software, que podem diminuir ou incrementar em até 35% (valor muito significante) o tamanho do software (FENTON e PFLEEGER, 1997, p.262); problemas de dupla contagem com relação às características gerais. Existem questionamentos se estas características estão medindo o tamanho ou a produtividade do modelo e nesse caso, pode ocorrer dupla contagem (por ex. Desempenho e Processamento Complexo podem ser computadas abordagem e, posteriormente, também computadas para nessa estimar produtividade/custo (utilizando outras abordagens como COCOMO) (FENTON e PFLEEGER, 1997, p.263) e (LOKAN e ABRAN, 1999). Com relação à aplicação da APF para a tecnologia de Data Mart, Santana (2001) aplicou a APF a um Sistema de Data Mart, mas seu trabalho não é conclusivo uma vez que ele somente aplicou a abordagem APF e pontuou um sistema de Data Mart. Santana não tece nenhum comentário sobre as características gerais aplicáveis ao sistema pontuado e nem identifica a quantidade de Pontos de Função total do sistema. Santana (2001) também não efetua análises para concluir se o tamanho obtido foi realmente condizente com o tamanho do aplicativo. 3.3.4 Mark II Function points (1991) Em 1991, a abordagem Mark II Function points (MK II) foi proposta por Symons, como uma alternativa à APF e como uma abordagem independente do modelo de processo de desenvolvimento utilizado e das técnicas de desenvolvimento empregadas. A abordagem Mark II se propõe a mensurar os requisitos de negócios independente da maneira como foram implementados (MK II FPA , 1998). Nessa abordagem, as principais características são os requisitos funcionais e técnicos do software e as transações lógicas que são os processos de negócio suportados pela aplicação. Cada transação lógica possui entradas, processamento e saídas, tudo considerando a fronteira de medição. 41 Para a contagem são seguidas as seguintes etapas: determinar o propósito e tipo da mensuração; determinar a fronteira de contagem; identificar as transações lógicas e categorias de tipos de elementos15; contar os processos (tipos de elementos de dados de entrada , tipos de dados de entidades referenciadas e tipos de elementos de dados de saída); cálcular o tamanho funcional - é obtido pela da soma de todas as transações lógicas, incluindo tipos de elementos de dados de entrada (Ni), tipos de dados de entidade referenciadas (Ne) e tipos de elementos de dados de saída (No). O Function Point Index (FPI) é a unidade medida do MK II obtida através da aplicação da fórmula: FPI = Wi * ∑Ni +We * ∑Ne + Wo * ∑No Onde ∑ é a soma de todas as transações lógicas e Wi (tipos de elementos de dados de entrada), We (tipos de dados de entidade referenciadas) e Wo (tipos de elementos de dados de saída) são médias definidas para cada ambiente (por exemplo: a indústria sugere o tamanho médio de: Wi = 0,58, We = 1,66 e Wo = 0,26) ; determinar o esforço do projeto; cálcular a produtividade e outros parâmetros de desempenho; cálcular os fatores de ajuste ou fatores técnicos de complexidade; calcular os Pontos de função de tamanho e parâmetros de desempenho ajustados. Com Mark II Function points, Symons explicitou o relacionamento entre pontos de função e esforço dentro da mesma abordagem. Sua proposta previa que a mudança de tecnologia modificaria o cálculo dos pontos de função. Symons alterou também características gerais inicialmente propostas para APF. Ele adicionou mais 5 características gerais (interação com outros softwares, segurança, acesso por terceiros, documentação e necessidades especiais de treinamento). Ele propôs que essas características fossem calibradas para refletir apropriadamente os valores referentes a cada tecnologia. A abordagem de Symons ganha mais valor para estimativa, enquanto reduz o valor e aplicabilidade para comparação de software com diferentes desenvolvimentos e com diferentes tecnologias. (LOKAN e ABRAN, 1999). 15 Identificação da categoria de tipos de elementos com base na manipulação do armazenamento de dados (create, update, delete ou read) 42 Essa abordagem permite determinar o esforço do projeto, calcular a produtividade e outros parâmetros de desempenho e é aceita como Padrão Internacional (ISO/IEC 20968:2002) 3.3.5 Full functions points (1997) e COSMIC Full Functions Points (2001) A abordagem Full Function Points V.1 foi proposta inicialmente, em 1997, como uma adaptação da métrica APF para softwares real time. Em 1999, o grupo Common Software Measurement International Consortium – COSMIC propôs a evolução desta abordagem para COSMIC – FFP – V.2.1 (Cosmic Ponto de função cheio – Versão 2.1) como uma métrica totalmente independente de outras métricas. Atualmente o COSMIC está na Versão 2.2. O COSMIC surgiu como uma alternativa de mensuração mais exata (de forma a não gerar dúvidas, não sendo ambígua), com independência de domínio e tecnologia e propondo diferentes medidas para diferentes propósitos (considerando a visão do usuário e do desenvolvedor). Essa métrica foi desenvolvida para trabalhar com o tamanho funcional de diversos tipos de software e mensura o tamanho do software baseado nas funções entregues para o usuário, possuindo uma visão de usuário mais abrangente que as outras métricas (CALAZANS, 2003)(Apêndice E). O método, como a APF, também pode ser utilizado para mensurar estimativa de esforço de desenvolvimento, evolução de qualidade de software, gerenciamento de contratos de outsorcing, comparação de softwares especificados em diferentes linguagens, em termos de produtividade, qualidade e manutenção de custos. A versão 2.2 do COSMIC foi aprovada em 2003 como Padrão Internacional (ISO/IEC 19761:2003). Na abordagem COSMIC FFP são consideradas as seguintes características: Requisitos funcionais dos usuários – São os requisitos correspondentes aos componentes do software e que descrevem as funções requeridas pelo usuário para o software. São designados Functional User Requeriments (FUR16). Usuários do software – Usuários podem ser considerados os seres humanos (engenheiros de software, usuários finais, etc), um serviço ou mesmo outro software. Componentes de software podem também ser considerados como usuários quando interagem com outros componentes. É possível identificar um ou mais usuários para a função de um componente de software em cada camada. 16 Requisitos funcionais do usuário 43 Camadas – O software pode ser mensurado de forma particionada em um ou mais componentes ou pedaços. Esses componentes ou pedaços reunidos para a execução de uma função17 ou processo formam uma camada. Fronteiras – Em cada camada, o componente de software pode ser mensurado conforme sua fronteira. Uma implícita fronteira existe entre cada camada identificada. Na Figura 3.2 pode ser observado o processo de aplicação do método. Requisitos funcionais do usuário Necessita definir tamanho subconjunto requisitos? Definir propósito, escopo e ponto de vista de mensuração Identificar a fronteira do software Identificar camada de softwares Identificar processos funcionais Identificar grupo de dados FUR no modelo COSMIC Identificar atributo de dados Figura 3.2 - Processo de aplicação do método COSMIC-FFP Fonte: Adaptado Abran et al (2001) Neste mapeamento, são identificadas as seguintes etapas: Definir propósito, escopo e ponto de vista da mensuração - Na definição do propósito define-se o objetivo da mensuração. O escopo é determinado baseado no propósito da mensuração. O escopo pode ser uma camada, um objeto reutilizável, um pacote de software, uma aplicação, etc. A definição do ponto de vista é necessária para definir o grau de detalhamento em que será pontuado o software. Para maior consistência da mensuração é necessário definir um limitado 17 A abordagem citada utiliza o termo functionality, mas quando consultado Houaiss (2001) foi verificado que o termo correspondente “funcionalidade” não está incorporado na língua portuguesa. 44 número de visões de mensuração. As duas principais visões de mensuração são a do usuário final e a do desenvolvedor. Identificar as camadas de software - A identificação das camadas de software é um processo interativo. Todas as camadas de software devem fornecer funções para seus usuários. Existe uma série de princípios para definir a camada descrita no Measurement Manual Cosmic - FFP. Identificar a fronteira do software - A fronteira de um componente de software é a fronteira conceitual entre esse componente, o trabalho que deve realizar e a percepção externa na perspectiva dos usuários. Identificar processos funcionais - Um processo funcional é um componente elementar de um FUR18, sendo composto de um conjunto de movimentos de dados (Entradas, Saídas, Leituras e Gravações), citados no Quadro 3.7. Esse processo pode ser subdividido em outros sub-processos. Quadro 3.7 - Descrição dos movimentos de dados Descrição Movimento de dados Entradas Entradas são o movimento de atributos de dados, pertencentes a um grupo de dados, do ambiente externo à fronteira do software para o ambiente interno ao software. Entradas não realizam update nos dados que movimentam. Podem ser associadas a manipulação (validação de dados) nos processos ou sub-processos identificados. Entradas incluem todas as formatações e manipulações requeridas pelos usuários. Saídas Saídas são o movimento dos atributos de dados pertencentes a um grupo de dados de dentro da fronteira do software para o lado do usuário do software. Saídas não lêem os dados que movimentam. Incluem toda a formatação e apresentação de manipulações requeridas pelos usuários, todo processamento para formatar e preparar para impressão alguns atributos de dados. Leituras Inclui todo processamento para ler o dado armazenado. Gravações Inclui todo processamento para criar e armazenar atributos de dados. Fonte: Abran et al (2001) Identificar grupos de dados – Um grupo de dados é um distinto, não vazio, não ordenado e não redundante conjunto de atributos de dados onde cada atributo de dado descreve um aspecto complementar do objeto de interesse. Um grupo de dados pode ser definido como um conjunto de atributos de dados que estão logicamente relatados e baseados na perspectiva funcional. Identificar atributos de dados – Atributos de dados são os atributos identificados como parte dos grupos de dados. Essa técnica define uma unidade de medida chamada de Cfsu (Cosmic Functional Size Unit). 18 Requisito funcional do usuário 45 A técnica COSMIC-FFP é uma função matemática que atribui um valor para cada um dos movimentos de dados citados anteriormente. Cada movimento (entrada, saída, leitura ou gravação) do processo (ou sub-processo) identificado recebe o tamanho de 1 Cfsu. Após a identificação dos processos e a contagem de todos os movimentos aplica-se a fórmula, ou seja, após a identificação da camada a ser medida, cada movimento de dados identificado nos processos a serem medidos é contado como 1 Cfsu, conforme fórmula a seguir: Size Cfsu (layer) = ∑ tamanho (entradas)+ ∑ tamanho (saídas)+ ∑ tamanho (leituras)+ ∑ tamanho (gravações) São pontos positivos identificados nessa abordagem: a habilidade de mensurar os requisitos de software de maneira fácil e com acurácia (BOOTSMA, 2000) e a medição mais implícita do objeto, por permitir pontuar subprocessos de objetos. Ou seja, a abordagem COSMIC oferece mais habilidade para derivar o tamanho funcional para controle de processo e em casos que requerem a mensuração de pequenas peças de software, essa abordagem oferece uma granularidade por conta de sua identificação e medidas de subprocessos (OLIGNY e ABRAN, 1999). Por ser uma métrica recente alguns autores identificaram a necessidade de aplicar a abordagem em outros tipos de softwares para melhor avaliar sua adequação e re-avaliação das definições da abordagem de forma a não gerar dúvidas na aplicabilidade da métrica (BEVO, LEVESQUE e ABRAN, 1999). Todas estas métricas mencionadas neste subitem 3.3, não propõem uma abordagem específica para o contexto de Data Mart e a seguir é apresentada uma abordagem de medição de tamanho para este contexto proposta por Santillo(2001). 3.4 PROPOSTA DE MEDIÇÃO DE DATA WAREHOUSE/DATA MART DE SANTILLO Santillo (2001) propõe uma abordagem, para medição de tamanho para a tecnologia de Data Warehouse , utilizando duas métricas a APF (IFPUG, 2000) e a COSMIC FFP (ABRAN et al, 1999). Santillo (2001) sugere a adequação da métrica de APF com a utilização da visão de usuário da métrica COSMIC-FFP, onde cada etapa do processo pode ser mensurada de acordo com a visão dos usuários daquela etapa. Dessa forma, se estaria pontuando as etapas não visualizadas pelo usuário final. 46 Santillo (2001) propõe os mesmos passos da APF para mensurar o tamanho do Data Warehouse/Data Mart com algumas adaptações: Com relação a (i) estabelecer o objeto da contagem, Santillo (2001) não sugere nenhuma adequação, pois identificar o objeto da contagem segue os mesmos padrões de um desenvolvimento de um software transacional. Para (ii) Determinar a fronteira de medição do aplicativo, Santillo (2001) identifica, utilizando a abordagem COSMIC-FPP, uma série de usuários de um Data Warehouse: administrador de procedures de ETL; administrador de Banco de Dados; administrador de OLAP (on line analytical processing); usuário final; e, algum software que provê e/ou receba dados para/do Data Warehouse. Considerando essas visões diferentes da tecnologia de Data Warehouse, Santillo (2001) identifica três camadas ETL19, Administração e Acesso que seriam as subfronteiras do projeto. Essas fronteiras variam conforme o tipo de produto a ser gerado, se Data Warehouse, Data Mart independente ou Data Mart dependente. As contagens também variam conforme o produto a ser mensurado. No que se refere a (iii) contar as funções de dados e suas complexidades, Santillo (2001) cita que a tabela fato não é visualizada pelo usuário de Data Warehouse e sugere que cada estrela lógica (fatos e dimensões associados) seja pontuada como um ALI – Arquivo lógico interno. Cada fato e tabela dimensional seria considerado um RLR - Registro Lógico Referenciado daquele ALI. Pela visão do administrador, Metadados técnicos, como por exemplo freqüência de updates, controle de versão do software, mapeamento físico lógico dos arquivos, seriam computados como ALI. Metadados de negócio (dicionário de dados, dados com aspectos históricos) também seriam computados como ALI. Para a definição de complexidade não é proposta nenhuma alteração, e a complexidade seria medida de acordo com a abordagem da APF (Quadro 3.2, p. 34). Para (iv) contar as funções transacionais e suas complexidades, Santillo (2001) sugere para cada ALI considerar uma EE – Entrada externa, pois eles são atualizados a partir dos dados de softwares operacionais que funcionam como uma EE. Na fronteira de Administração seriam computadas quantas EE fossem necessárias para pontuar o 19 Extraction, Transformation and Load (Processo de extrair, transformar e carregar os dados transacionais no Data Warehouse), conforme citado no capitulo 2 . 47 gerenciamento das transações para criar, atualizar e excluir metadados. Na fronteira de Acesso é sugerida a existência de pelo menos uma SE – Saída externa para cada estrela lógica. Para a definição de complexidade não é proposta nenhuma alteração, e a complexidade seria medida de acordo com a abordagem da APF (Quadro 3.3 e 3.4, p. 35). No que se refere à etapa (v) Calcular os pontos de função não ajustados não é sugerida nenhuma alteração, ou seja seria utilizada a proposta da APF, descrita no Quadro 3.8 a seguir. Quadro 3.8 - Tipos de função e correlação Tipo Fronteira Produto Exemplos ALI ETL DW, DM Arquivos lógicos ALI Admin DW, DM Metadados, arquivos Log , estatisticos AIE ETL DW, DM Arquivos lógicos operacionais AIE DW DM Dep DW ALI quando acessado por ETL AIE ADM DW, DM Arquivos de suporte EE ETL DW, DM 1 EE para cada ALI identificado EE Admin DW, DM Criar, atualizar e apagar metadados CE Admin DW Visão de Metadados SE Acesso DM 1 SE para cada ALI identificado no ETL CE Acesso DM 1 CE para cada identificada ALI no ETL CE List Box DM Drill down triggers, outras listas Fonte: Adaptado SANTILLO (2001) Santillo (2001) sugere neste quadro, exemplos a serem adotados considerando o tipo de função (dado ou transacional) a ser computada, cada uma das fronteiras identificadas e o produto mensurado (DW – Data Warehouse, DM – Data Mart dependente20 e independente21 e DM Dep – Data Mart dependente). No passo referente a (vi) determinar os Fatores de ajuste, Santillo (2001) propõe que as 14 características sejam desconsideradas, e que o percentual de ajuste fique em 1,0, não acrescentando nem diminuindo nenhum percentual de ajuste à pontuação bruta obtida. Finalmente para (vii) calcular pontos de função ajustados Santillo (2001) utiliza as fórmulas propostas na APF. A proposta de Santillo (2001) apresenta alternativas interessantes como: a sugestão de pontuação das EE, na qual sugere computar uma EE para cada ALI; e, 20 a pontuação dos processos de log e estatísticos. Data Mart dependente é considerado o Data Mart que apesar de ser implementado separadamente por grupos de trabalho ou departamentos, é integrado ou interconectado a outros Data Mart, provendo uma visão corporativa dos dados (MACHADO, 2000). 21 Segundo Machado (2000) Data Mart independente é um Data Mart isolado, controlado por um grupo específico de usuários e que atende a necessidades específicas, sem foco no corporativo. 48 Com relação à proposta de utilização da técnica COSMIC FFP em conjunto com APF não foram encontradas na literatura pesquisada restrições mas, depois da análise desta proposta foram identificadas as seguintes: a utilização de duas métricas diferentes, com visões fundamentais diferentes em relação à visão do usuário e unidades de medidas diferentes não parece adequada; a não utilização de fatores de ajuste poderá gerar distorções com relação ao tamanho; a sugestão da pontuação de cada estrela (tabela fato e suas dimensões) como um único ALI. A tabela dimensão pode ser utilizada em mais de uma estrela, e é comum essa utilização, dessa forma se pontuaria várias vezes as mesmas tabelas dimensões. Isso com certeza geraria uma distorção na mensuração. Um fator importante a ser destacado é que Santillo (2001) não chegou a aplicar sua proposta em nenhum software de Data Mart, nem Data Warehouse. 3.5 CONSIDERAÇÕES DO CAPÍTULO Existem muitas abordagens para mensurar o tamanho de um software e não existe uma abordagem que seja melhor que outra, sob todos os aspectos, em qualquer situação. A abordagem de mensuração de tamanho deve ser escolhida e/ou adequada dependendo das características particulares do software que se pretenda desenvolver. Na Quadro 3.9 é apresentada a comparação entre algumas características das métricas abordadas, considerando: se o modelo que é apresentado é baseado em algoritmo ou função (funcional); se a abordagem possibilita a estimativa de tamanho no início do processo de desenvolvimento do software; que visão é utilizada na aplicação da abordagem (se a aplicação considera o código ou a visão das necessidades do usuário final); o nível de maturidade da abordagem (considerando a utilização e a quantidade de artigos envolvendo a abordagem); a possibilidade de aplicação em todos os tipos de tecnologias de software; e, a existência de proposta específica dentro de cada abordagem para a tecnologia de Data Warehouse/Data Mart. 49 Quadro 3.9 - Comparação entre as características das abordagens de métricas de software Abordagem/ LOC Halstead Mark II APF COSMIC Santillo Modelo Algorítmo Algorítmo Funcional Funcional Funcional Funcional Possibilidade Não Não Sim Sim Sim Sim Visão da abordagem Código Código Usuário Usuário Usuário Usuário Nível de Maturidade Alto Médio Alto Alto Baixo Baixo Não Não Características estimativa no inicio do projeto da abordagem Possibilidade Segundo a Segundo a Segundo a aplicação em todas métrica sim, mas métrica sim, mas métrica as tecnologias existem existem mas questionamentos questionamentos questionamentos Não Não Não Proposta para especifica adequação Não Não Não sim, existem Sim à tecnologia de Data Warehouse Este trabalho analisou inicialmente, no capítulo 2, a tecnologia de Data Mart/Data Warehouse, todas as suas características diferenciadas de um sistema transacional, seus objetivos, peculiaridades e metodologias para construção. Foram apresentadas também, no capítulo 3, algumas abordagens de métricas de tamanho existentes, seus pontos positivos e negativos e identificadas críticas com relação à adequação de cada abordagem para outras tecnologias. Com base nestas análises, foi identificada como importante a elaboração de uma proposta alternativa de medição de tamanho para o contexto de Data Mart/Data Warehouse, que será apresentada no capítulo 4. No capítulo 4 também será descrita e analisada a aplicação desta proposta em 11 projetos reais de três instituições federais localizadas no Distrito Federal. 50 CAPÍTULO 4 - PROPOSTA DE MEDIÇÃO DE TAMANHO PARA DATA MART ____________________________________________________________________________ 4.1 INTRODUÇÃO Sistemas de Data Mart são sistemas voltados à execução de análises estratégicas com o objetivo de propiciar às organizações suporte ao processo de tomada de decisões. O desenvolvimento dessas aplicações é bastante diferente do desenvolvimento aplicado aos sistemas transacionais. Como visto no capítulo 2, as diferenças vão desde o objetivo geral dos sistemas até características como a organização, a natureza e a atualização dos dados, a quantidade de usuários e outras. Devido ao crescimento substancial de sistemas de Data Mart, nos últimos tempos, torna-se necessário o estudo de métricas de tamanho para esta tecnologia. No capítulo 3, foi apresentada a importância das medições de tamanho nos projetos de tecnologia, destacando a sua utilização como forma de previsão, efetuada no início do ciclo de vida do sistema, de modo a subsidiar a estimativa de custos, cronograma e recursos. Todas as propostas de medição de tamanho apresentadas, com exceção da de Santillo (2001), não apresentam nenhuma adequação para Data Mart. Dessa forma, este estudo aborda as características e peculiaridades de sistemas de Data Mart e propõe uma adequação de métrica de tamanho para essa tecnologia. A abordagem proposta define uma adequação da métrica APF para Data Mart. É descrito um conjunto de alterações a serem aplicadas em uma métrica já existente para que ela se torne mais adequada e dimensione de forma mais eficaz o tamanho de um software de Data Mart. Esta abordagem foi aplicada em 11 projetos de Data Mart de três instituições governamentais federais localizadas no Distrito Federal. Estas instituições, denominadas I1, I2 e I3, subsidiaram o processo de coleta e análise dos dados, fornecendo informações através de entrevistas estruturadas e documentos dos sistemas que foram pontuados. A proposta original da APF também foi aplicada nestes projetos de Data Mart. Os resultados das pontuações da abordagem proposta e da APF foram comparados e analisados. Inicialmente, na seção 4.2, são descritas algumas considerações sobre as diferenças de Data Mart e um sistema transacional e, na seção 4.3, algumas abordagens de medição de tamanho existentes como APF, COSMIC e a proposta de Santillo (2001). Na seção 4.4, se justifica a escolha da APF para adequação. Na seção 4.5 e 4.6 é descrita a proposta de 51 adequação. A seção 4.7 apresenta a análise dessa proposta de adequação no ciclo de vida de um sistema de Data Warehouse. Na seção 4.8, é demonstrada a aplicação da proposta em sistemas de Data Mart de três instituições públicas federais e se analisa a adequabilidade da proposta. A seção 4.9 resume algumas considerações sobre a proposta de abordagem de tamanho de sistemas de Data Mart descrita neste capítulo. 4.2 SISTEMAS DE DATA MART E OS SISTEMAS TRANSACIONAIS Conhecer as particularidades da tecnologia de Data Mart é essencial para identificar as diferenças entre esse tipo de software e os sistemas transacionais. Os objetivos, a construção, o tratamento dos dados, a visão do usuário possuem características muito diferentes nesse tipo de software quando comparados a um sistema transacional. Enquanto os Data Mart são voltados para a análise e tomada de decisões, os sistemas transacionais têm como meta o atendimento a determinada necessidade organizacional com relação a operacionalização de algum produto. Existem, no caso do sistema de Data Mart, funções que não são visualizadas pelo usuário final e que impactam no tamanho do sistema que está sendo mensurado (SANTILLO, 2001). Dentre estas funções encontram-se as geradas para tratar os dados na data staging area22, o fato dos usuários utilizarem o software somente para consultas e não atualização dos dados, o desenvolvimento baseado em dados existentes de outros sistemas sem gerar nova informação, além do processo de ETL23 que, segundo Allison (2001), Fiori (2002), Inmon (1997), Meyer (2001) e Mrazek (2003), é o processo de maior impacto e que demanda maior esforço na construção de um Data Mart (Tabela 4.1). Tabela 4.1 - Levantamento do esforço da etapa ETL no processo de construção de um Data Mart/Data Warehouse Autores Esforço do ETL dentro do processo de construção de um Data Mart/Data Warehouse 22 Allison (2001) 40 a 70% (foi considerado 55%) Fiori (2002) Alta percentagem de esforço Imnon (1997) 55% Meyer (2001) Até 70% Mrazek (2003) Mais de 50% Média 57% Conforme citado no capítulo 2, data staging area é a área de armazenamento de dados e de conjunto de processos que preparam os dados de origem para serem utilizados (KIMBALL, 1998). 23 Processo de extração, transformação e carga dos dados no ambiente de Data Warehouse. 52 Outras diferenças entre a construção de um Data Warehouse e um sistema transacional foram citadas no capítulo 2 e podem ser melhor visualizadas pela comparação na Figura 4.1 dos dois ciclos de desenvolvimento. Para compor esta figura foi escolhido a abordagem de Kimball et al (1998), pois, conforme já abordado no capítulo 2, é uma das abordagens mais abrangentes do processo de construção de um Data Warehouse . O processo de construção de um Data Warehouse é iniciado com a definição de prioridades (etapa de Planejamento do projeto) e análise das áreas de negócio e dos dados que são realizadas na etapa de Definição dos requisitos do negócio. No processo de construção de um sistema transacional o levantamento dos requisitos funcionais do usuário é a primeira etapa a ser executada, podendo ter inclusive atividades relacionadas ao planejamento do projeto. No Data Warehouse, na etapa de Modelagem física, são analisados os dados e implementado o esquema dimensional. No sistema transacional na etapa de Projeto inicial são definidas as funções gerais que atendam aos requisitos definidos na etapa de análise de requisitos. No Data Warehouse, nas etapas de Projeto Físico e Projeto Desenvolvimento da data staging area são integrados os dados, definidas as estratégias de agregação e definidas e realizadas as atividades de ETL. No sistema transacional, nas etapas de Projeto detalhado e Codificação são definidos o modelo de dados, especificadas e codificadas as funções. No Data Warehouse, os requisitos dos usuários finais são analisados e sintetizados nas etapas de Especificação e Desenvolvimento de aplicações analíticas e é nessa etapa que são efetuados os testes, enquanto no sistema transacional os requisitos dos usuários finais definidos na primeira etapa são testados (fase de Teste) e implementados (fase de Implementação). Ambos os tipos de sistemas possuem uma etapa de manutenção, sendo que no caso de um Data Warehouse a etapa de manutenção inclui um crescimento inerente a esse tipo de tecnologia. 53 Projeto inicial Requisitos Planejamento do projeto Definição dos requisitos do negócio Projeto detalhado Codificação Teste Projeto técnico de arquitetura Seleção e instalação do produto Modelagem dimensional Projeto físico Projeto e desenvolvimento da data staging Especificação da aplicação analítica Desenvolvimento da aplicação analítica Implementação Distribuição Manutenção Manutenção e crescimento Gerenciamento do projeto Figura 4.1 - Dois ciclos de desenvolvimento (transacional e Data Warehouse) Baseado: Kimball et al (1998) e Garmus e Herron (2000) Para entender melhor a diferença entre Sistemas de Data Mart e transacionais é necessário compreender a natureza dos dados nesses dois contextos. Enquanto nos sistemas transacionais os dados são dinâmicos, detalhados, normalizados em uma estrutura relacional, nos Data Mart são estáticos, sumarizados, agregados, desnormalizados em uma estrutura multidimensional. Os dados do Data Mart são extraídos dos sistemas transacionais, tratados e carregados nessa estrutura multidimensional, de forma a garantir sua utilização para suporte à tomada de decisão. 4.3 ABORDAGENS DE MEDIÇÕES DE TAMANHO ANALISADAS Conforme já apresentado no capítulo 3, existem várias abordagens de medição de tamanho de um software, entre elas APF, COSMIC e a proposta de Santillo (2001). Essas abordagens permitem a medição durante todo o processo de construção do software, incluindo o processo inicial de forma a possibilitar a elaboração de estimativas. 4.3.1 APF A Análise por pontos de função - APF é uma das abordagens funcionais mais estudadas atualmente. Essta métrica, conforme descrita no capítulo 3, se propõe a medir o tamanho do software considerando as funções de dados e transações do software e aplicando 14 características gerais de sistemas para mensurar aspectos especiais referentes à operação, 54 qualidade, infra-estrutura, etc. A quantidade de pontos de função é obtida após a aplicação das fórmulas definidas nas quais são computadas todas as funções de dados e transações com suas complexidades e calculadas as características gerais de sistema. Existem muitos pontos positivos nessa abordagem entre elas, a possibilidade de estimar o tamanho de um software no início e durante todo o processo de desenvolvimento do produto e de utilizar uma base histórica de produtividade da organização ou de dados do mercado (possibilitando a derivação de custo e tempo) (GARMUS e HERRON, 2000, p.68, 88). Por ser uma das métricas mais antigas, a APF possui um diferencial em relação a abordagens mais novas, pois existem dados de produtividade da indústria com relação a APF computados por vários órgãos entre eles o International Software Benchmarking Standards Group - ISBSG, que possibilitam estudo ou mesmo a utilização desses índices por organizações que não possuem um histórico de contagens. Existe também um grupo de usuários (International Function Point Users Group IFPUG) para suporte e atualização da métrica (GARMUS e HERRON, 2000, p.xxvii). Apesar de ser a métrica de tamanho mais utilizada pelo mercado, existem muitos autores que criticam sua adequação à mensuração de projetos atuais, pois foi criada na década de 1980, quando a construção de software era feita de forma estruturada (SYMONS, 2001). Symons (2001) identifica a necessidade de uma mensuração que trabalhe com todos os domínios de tecnologia. Fenton e Pfleeger (1997, p.262-264) concordam com esta crítica e identificam problemas na abordagem APF com relação a aplicação da métrica em diferentes tecnologias e domínios de aplicação, conforme já citado no capítulo 3. Outros autores identificam dificuldades de aplicar a APF nos diferentes domínios de sistemas de informação (ABRAN et al, 2001) e a necessidade de adequar ou criar novos modelos de mensuração para atender a diversos tipos de tecnologias existentes (LOKAN e ABRAN, 1999). Com relação à aplicação desta abordagem à tecnologia de Data Mart ou Data Warehouse só foi encontrado o trabalho de Santana (2001), citado no item 3.3.3.1, e que não foi conclusivo. 4.3.2 COSMIC A abordagem COSMIC FFP, citada no capítulo 3, é uma das abordagens mais atuais com relação à medição de tamanho de software. Foi criada pelo grupo COSMIC e tem como 55 principal diferenciação de outras métricas a possibilidade de se pontuar camadas, subprocessos sob diversos pontos de vista (do usuário, do desenvolvedor, etc). No COSMIC FFP pontua-se a movimentação dos dados (entradas, saídas, leituras e gravações) no subprocesso de menor nível do software. O cálculo do tamanho do software é obtido por meio da soma de todas as pontuações de movimento dos dados nos processos e subprocessos do produto. Diab (2001) cita como vantagens dessa métrica a formalidade e clareza das definições no manual COSMIC, pois facilita a contagem de uma maneira uniforme, a maior acurácia na estimativa de custo, a evolução da produtividade e a qualidade da medida. Por ser uma métrica proposta no ano de 1997 existem ainda algumas dúvidas para mensurar situações especificas como, por exemplo, sua aplicabilidade na notação UML24. Bevo et al (1999) apresentam algumas dúvidas sobre como aplicar a COSMIC para a notação UML. Diab (2001) reconhece também que os documentos de UML nem sempre contêm os detalhes necessários para utilizar o COSMIC. Esse autor cita que durante o desenvolvimento da aplicação da métrica apareceram algumas interpretações diferentes das regras, e é necessário que o grupo COSMIC analise essas definições de forma a não gerar dúvidas. Diab (2001) sente a necessidade de utilizar as regras em muitos sistemas para melhor avaliar a sua aplicabilidade. Na literatura não foi encontra nenhuma menção de aplicação desta abordagem à tecnologia de Data Mart ou Data Warehouse. Também não foi identificada nenhuma base de dados histórica com os fatores de produtividade da indústria, por tipo de linguagem, semelhante à base do ISBSG para APF e esta seria a principal dificuldade de se comprovar a adequabilidade da métrica com relação ao tempo real dos projetos que se pretende analisar. 4.3.3 Santillo A proposta de Santillo (2001), como citado no capítulo 3, é uma adequação da abordagem APF com a abordagem COSMIC FFP. Ele propõe a utilização da métrica APF com a visão de desenvolvedor da COSMIC. Como foi citado no capitulo 3, a abordagem COSMIC FFP possibilita a mensuração considerando diversos pontos de vista, do usuário final, do desenvolvedor, etc. A proposta de Santillo (2001) não foi aplicada em nenhum projeto de Data Warehouse/Data Mart, segundo informações do autor. 24 UML – Unified Modeling Language 56 Algumas críticas identificadas com relação a esta proposta se referem à utilização de duas métricas que possuem unidades de medidas diferentes, o que a princípio não parece ser adequado; a pontuação das tabelas dimensões ser feita de maneira duplicada; e, a nãoutilização das características gerais de sistema. Esses aspectos poderiam causar distorções e sendo assim foi resolvido aplicar esta abordagem em um número reduzido de projetos de Data Mart de uma instituição (I1), primeira instituição pesquisada, de forma a averiguar a sua adequação. Na Tabela 4.2 estão relacionados os resultados da pontuação dos ALI – arquivos lógicos internos, AIE – arquivos de interface externa, EE – entradas externas, CE – consultas externas, SE – saídas externas, IF – itens dos fatores, PFN- pontos de função não ajustados, FA – fator de ajuste e PFA – pontos de função ajustados. Tabela 4.2 - Levantamento da Proposta Santillo(2001) Siste mas Proposta Santillo ALI AIE EE I1S1 I1S2 I1S3 120 240 195 SE CE 48 96 78 IF PFN 168,00 336,00 273,00 FA 1 1 1 PFA 168,00 336,00 273,00 Para analisar a contagem de pontos de função da proposta de Santillo(2001) foi definida a estimativa de tempo considerando: Quantidade de recursos (tamanho da equipe) que participou do desenvolvimento e, um fator de produtividade por pontos de função. A Instituição I1 utiliza uma tabela de produtividade (horas gastas por ponto de função) para seus contratos de outsourcing. Esta produtividade é variável para cada tipo de linguagem e também para cada fase de desenvolvimento. Para obtenção do fator de produtividade (horas por ponto de função) foi calculada a média ponderada de todas as produtividades por fases de desenvolvimento, considerando a linguagem C++ utilizada pela empresa para esse tipo de projeto. Este cálculo definiu uma média de esforço (horas/pf) de 16,00. Para todos os projetos foi considerada a quantidade de 22 dias por mês, com a carga horária de 8 horas diárias. A Tabela 4.3 demonstra a comparação entre o tempo real em meses e o tempo estimado pela proposta de Santillo, considerando a mesma quantidade de recursos. 57 Tabela 4.3 - Comparação entre o tempo real e o tempo estimado da proposta de Santillo(2001) Sistemas Tempo real Qtd recursos em meses I1S1 I1S2 I1S3 10 8 /9 19 6 7 5 Qtd PF (Proposta Tempo Santillo) estimado em meses (Proposta Santillo) 168,00 336,00 273,00 2,54 4,36 4,96 Analisando as tabelas comparativas e os resultados obtidos (Figura 4.2) verifica-se a proposta de Santillo(2001) está bem abaixo do tempo real. Na proposta de Santillo(2001) a variação entre o tempo real e o tempo estimado foi de 48% a 74%. Esses percentuais podem ser considerados como um indicador de que os resultados obtidos pela proposta de Santillo(2001) com relação a estimativa de dimensão de tamanho dos softwares de Data Mart não parece ser adequado. Comparação tempo real e tempo da proposta de Santillo 20 15 Tempo em 10 meses Tempo real Tempo estimado Santillo 5 0 I1S1 I1S2 I1S3 Sistemas Figura 4.2 - Comparação do tempo real com a estimativa de tempo da proposta de Santillo 4.4 DISCUSSÃO PARA ESCOLHA DA MÉTRICA A SER ADAPTADA Embora o principal objetivo de todos os sistemas de software seja o atendimento às metas negociais, existem sistemas sob as mais diversas formas e tamanhos e várias abordagens de métricas para mensurá-los. A medição de um projeto de Data Mart com a abordagem APF fica prejudicada, considerando que esse processo na visão do usuário, recebe dados já armazenados por outros sistemas e disponibiliza-os de forma que ferramentas adquiridas possam ser utilizadas para 58 minerar ou consultar historicamente esses dados. A métrica APF examinada não trata exemplos específicos para contagem de tamanho de sistemas de Data Mart. A COSMIC FFP, apesar de ser uma proposta inovadora, não possui atualmente dados históricos que possam ser aplicados para um estudo comparativo, além de autores terem identificado dificuldades na aplicação da métrica e necessidade de melhor detalhamento. Não foi encontrada nenhuma aplicação da COSMIC para a tecnologia de Data Mart/Data Warehouse. A proposta de Santillo, apesar de ser uma proposta voltada para esse contexto, não demonstrou ser muito adequada à mensuração de tamanho e conseqüente estimativa de tempo. Além disso, o fato de nunca ter sido utilizada pelos próprios autores da métrica indica a necessidade de melhor validação. Conforme já enfatizado anteriormente, a mescla de duas abordagens (APF e COSMIC) com unidades de medida diferentes não parece adequada e a não aplicação das características gerais de sistema pode causar distorções. Das métricas estudadas, a que possui maior maturidade tanto no meio acadêmico como na indústria é a APF. Essa métrica, apesar das críticas quanto à sua adequabilidade a diversos tipos de software, possui bases históricas de mercado, um instituto para garantir a sua evolução e oferece certificação. A atividade de estimativa de tamanho voltada para sistemas de Data Mart é uma atividade difícil e ainda muito deficiente. As definições da APF necessitam de modificações para que possam ser utilizadas no mundo de hoje para as diversas tecnologias existentes. As diretrizes para contagem (IFPUG Counting Guidelines) não têm sofrido modificações nos últimos oito anos. Nesse período, a tecnologia tem evoluído com novas propostas, metodologias e arquiteturas, enquanto a APF permanece sem grandes modificações. A tecnologia de Data Mart/Data Warehouse, como citado no capítulo 2, surgiu no início dos anos 1990. Muitos autores reconhecem ser difícil aplicar as definições da APF às novas tecnologias, e segundo este trabalho, essa dificuldade acontece também no contexto de Data Mart. Baseados nessas observações, optou-se por elaborar uma proposta de adequação da APF para o contexto de Data Mart. É importante adaptar as Regras de contagem da APF (mantendo a conformidade com os padrões do passado) ao mundo de hoje, as tecnologias novas e emergentes. A proposta elaborada causa impacto na contagem de pontos de função, melhora o entendimento e aplicabilidade da métrica. Para um bom resultado na estimativa de tamanho é de suma importância a utilização de modelo adequado, com métricas bem definidas e coletadas. 59 4.5 APF PARA DATA MART Nesta seção será apresentada como a APF foi adaptada para o contexto de Data Mart considerando os sete passos de medição apresentados no capítulo 3: (i) estabelecer objeto de contagem, (ii) determinar fronteira de medição, (ii) contar funções de dados e suas complexidades, (iii) contar funções de transações e suas complexidades, (iv) calcular os pontos de função não-ajustados, (v) obter o fator de ajuste e (vi) determinar os pontos de função ajustados. 4.5.1 Estabelecer o objeto da contagem No que se refere a estabelecer o objeto da contagem não é necessário nenhuma adequação, pois identificar o objeto da contagem segue os mesmos padrões de um sistema transacional. É necessário identificar se a contagem é voltada para um projeto de desenvolvimento, visando à criação de um novo sistema; para um projeto de manutenção, onde são modificadas ou adicionadas funções a um sistema já existente; ou, para contagem de um aplicativo existente em um sistema já desenvolvido. 4.5.2 Determinar a fronteira de medição A fronteira de medição, como visto no capítulo 3, refere-se às funções de dados e transações mantidas pelo sistema a ser pontuado. Nessa etapa, considerando a medição de um sistema de Data Mart, é necessário analisar quem irá extrair os dados dos sistemas transacionais de origem. Se os dados de origem são fornecidos pelos sistemas transacionais, a fronteira de medição do Data Mart fica restrita aos dados e funções internas do projeto de Data Mart. Neste caso, não são computadas funções de dados para os arquivos dos sistemas transacionais de origem. Quando o processo de extração dos dados dos sistemas transacionais é realizado pela equipe responsável pelo sistema de Data Mart, os arquivos produzidos serão pontuados como AIE dentro da fronteira de medição, o que a torna mais ampla. No caso da utilização de uma ferramenta de ETL, que automatiza todo o processo de extração, sugere-se que a fronteira da medição fique restrita às tabelas internas do projeto de Data Mart. 60 4.5.3 Contar as funções de dados e suas complexidades Como discutido no capítulo 3, as funções de dados englobam os dados utilizados pelo software e estão divididas em ALI e AIE25. Como descrito no capítulo 2, o modelo multidimensional de um Data Warehouse pode ser representado graficamente pelos esquemas star 26(estrela) ou snow flake27 (flocos de neve). Se o esquema estrela for adotado, deve ser considerado que o usuário possui a visão das dimensões que necessitará para suas pesquisas, e que essas visões estão relacionadas aos fatos. Sugere-se que todos os fatos e dimensões sejam pontuados como ALIs. O usuário também possui a visão de que esses dados deverão ser tratados, limpos, agregados, sumarizados em uma área, antes de serem disponibilizados para consulta. Com base nessa visão e considerando, também, a necessidade de se computar os dados da data staging area, sugere-se que todo ALI computado inicialmente sejam também computado como ALI para a data staging area. Os dados da data staging area são dados que permanecem e que são utilizados constantemente para as novas cargas e atualizações. Normalmente, podem ser criados mais de um arquivo na data staging area para cada dimensão e fato, mas inicialmente será inferido somente a existência de um para cada ALI. Se o modelo utilizado é flocos de neve, sugere-se que todos os fatos sejam pontuados como ALIs. Cada dimensão principal deve ser considerada um ALI e cada floco de neve vinculado direta ou indiretamente a esta dimensão é considerado um RLR28, isto porque, na visão do usuário final, o dado visualizado é o da dimensão principal, independente da quantidade de flocos existentes. Por exemplo, considerando a tabela fato vendas e as dimensões flocadas por região, estado e cidade, o usuário final possui a visão que o dado que ele necessita é a dimensão de vendas por local. As dimensões estado e cidade são consideradas RLR – registros lógicos referenciados do ALI região. São pontuados como AIE os grupos lógicos de dados relacionados, identificáveis pelo usuário, ou informações de controle, referenciadas pelo aplicativo, porém mantidos dentro da fronteira de um outro aplicativo. Para identificar a complexidade de cada função de dados (ALI e AIE) é utilizada a proposta da APF, que é citada no capítulo 3 e apresentada no Quadro 3.2. 25 Como descrito no capítulo 3, ALI são os Arquivos Lógicos Internos e AIE os Arquivos de Interface Externa. É composto por uma entidade central, denominada fato, e um conjunto de entidades menores, denominadas dimensões, arranjadas ao redor desta entidade central, conforme discutido no capítulo 2. 27 É composto por uma entidade central, denominada fato, e um conjunto de entidades menores, denominadas dimensões, arranjadas ao redor desta entidade central.Estas dimensões são decompostas em uma ou mais dimensões que possuem hierarquias entre seus membros, conforme descrito no capítulo 2. 28 Registro lógico referenciado - subgrupo de dados que são enxergados como um elemento único pelos usuários. 26 61 4.5.4 Contar as funções transacionais e suas complexidades Como citado no capítulo 3, as funções transacionais são as funções básicas que o software deve conter e que incluem as Entradas Externas - EE29, Saídas Externas – SE30 e Consultas Externas – CE 31. Com relação às Entradas Externas, considera-se uma EE para cada ALI, pois eles são atualizados a partir dos dados de sistemas transacionais de origem. Na realidade, o processo de carga é muito mais complexo e gera muito mais funções de transações do que apenas uma, como está sendo sugerido, mas, considerando a visão do usuário e a dificuldade de se mapear separadamente todas as funções de entrada e tratamento dos dados na data staging area sugere-se a definição de uma EE para cada ALI. Relatórios e consultas pré-formatadas são computados como SE ou CE. Será computada como SE quando gerar dados ou informações de controle e/ou derivados enviados para fora da fronteira do aplicativo e como CE se possuir componentes de entrada e saída que resultem na recuperação de dados. Para identificar a complexidade de cada função de transação (EE, SE e CE) deve ser utilizada a proposta da APF, que é citada no capítulo 3 e apresentada nos Quadros 3.3 e 3.4. 4.5.5 Calcular os pontos de função não-ajustados Neste passo, a quantidade de funções de dados e transações com seus respectivos níveis de complexidade são multiplicados pelo número de pontos de função definidos no Quadro 3.5 do capítulo 3. O resultado deste cálculo considera-se o ponto de função nãoajustado. Para manter o padrão adotado pela APF foram preservados os valores usados por essa métrica para definir a quantidade de pontos de função para cada nível de complexidade obtido para cada função. 29 Processo elementar que processa dados ou informações de controle procedentes de fora da fronteira do aplicativo. 30 Processo elementar que gera dados ou informações de controle e/ou derivados, enviados para fora da fronteira do aplicativo. 31 Processo elementar com componentes de entrada e saída que resulta na recuperação de dados. 62 4.5.6 Determinar o fator de ajuste Neste passo, 14 características gerais do software são avaliadas segundo uma escala de 0 (nenhuma influência) a 5 (grande influência). Essas características influenciarão a complexidade do software e conseqüentemente o seu tamanho. Para obter o fator de ajuste mais adequado à tecnologia de Data Mart, foi necessária análise dessas características gerais para estes sistemas. Muitos autores reconhecem que as características gerais de sistema devem ser redefinidas. Lokan (2000) cita que estas características foram definidas entre 1979 e 1984 considerando aspectos importantes naquela época e que atualmente estes aspectos possuem menor significância. Jones (1996) identifica 100 características que seriam relevantes. Por outro lado, outros autores acham alto o número de 14 características gerais de sistema. Kitchenham (1992) encontrou variações comuns nas características gerais de sistema. Em seus estudos somente 5 a 6 características do total de 14 seriam suficientes. Garmus e Heron (1996) e Lokan (2000) identificaram padrões que podem ser observados nas características gerais de sistema para diferentes tipos de software, ou seja, dependendo do tipo de software somente algumas características gerais de sistema são utilizadas. Considerando a quantidade de propostas existentes para adequação das características gerais de sistema e após uma análise cuidadosa das 14 características propostas pela APF no que se refere ao contexto de Data Mart percebe-se que: quatro características são aplicáveis para esse tipo de software: Processamento distribuído, Desempenho, Reusabilidade de código e Facilidade operacional; duas cararacterísticas podem ser adaptadas para Data Mart: Eficiência do usuário final e Processamento complexo; oito características estão muito vinculadas a sistemas transacionais, o que implica que, quando aplicadas ao contexto de Data Mart recebem valor 0 (nenhuma influência). Por exemplo, as características Entrada de dados on-line e Atualização on-line, uma vez que sistemas de Data Mart não possuem entradas nem atualizações on-line. Outro exemplo seria a característica Múltiplos locais pois, Data Mart não são instalados em locais específicos. Na seção 4.6 serão descritos detalhadamente os critérios adotados para definição das características gerais de sistema para o contexto de sistemas de Data Mart. Foram mantidas as quatro características da abordagem APF aplicáveis, foram adaptadas duas características e criadas mais sete características para o contexto de Data Mart. Desta forma, a proposta ficou com um total de 13 características e não 14 características como a proposta original da APF. 63 Como foi reduzido o número de características gerais proposto pela APF, foi necessário adaptar a fórmula de fator de ajuste apresentada na seção 3.3.3, que é: FA = 0,65 + (0,01 x Soma dos graus de influência das características gerais). Como destacado no capítulo 3, as características gerais do software definidas na proposta inicial da APF eram 10 e possuíam uma variação de mais ou menos 25% (WITTIG et al, 1997; LOKAN e ABRAN, 1999). Analisando a abordagem inicial e atual das características gerais, identifica-se que para cada característica geral de sistema foi atribuído o valor de 2,5, considerando que as 14 características incrementam ou diminuem em até 35% do valor de pontos brutos computados. Com a proposta voltada para o contexto de Data Mart, as características gerais de sistema foram reduzidas de 14 para 13. Foi necessário então adequar o valor da fórmula para um ajuste de mais ou menos 32,5 %. Para isto foi utilizada uma regra de três simples com relação à proposta atual. E a fórmula de cálculo foi adequada para: FA = 0,67 + (0,01 x Soma dos graus de influência das características gerais). Com esta alteração manteve-se o percentual relativo as Características Gerais de sistemas definidas anteriormente. E o fator de ajuste, no contexto de Data Mart ficou variável de mais ou menos 32,5 % sobre o Ponto de função não ajustado. 4.5.7 Determinar pontos de função ajustados Finalmente, para determinar o tamanho do projeto, foram utilizadas as fórmulas propostas pela abordagem APF. Nesta etapa são considerados as funções de dados e transacionais, seu grau de complexidade, as características gerais do software e tipo de projeto. O resultado da contagem de funções de dados e transacionais é uma medida chamada de pontos de função não ajustados (NoPFnão ajustado), pois não considera as características gerais que afetam o produto e sua construção. Para determinar o tamanho do projeto ou os Pontos de função ajustados (NoPFajustado) consideram-se fórmulas específicas como por exemplo, para medir aplicação ou projetos de desenvolvimento, a seguinte: NoPFajustado = NoPFnão ajustado x FA. A seção seguinte apresenta os critérios utilizados para definição das características gerais de sistema para o contexto de Data Mart. 64 4.6 CARACTERÍSTICAS GERAIS PROPOSTAS PARA A TECNOLOGIA DE DATA MART Conforme descrito anteriormente, foram analisadas todas as Características gerais propostas pela APF e identificadas quatro características gerais de sistema aplicáveis, substituídas duas características possíveis de adequar por nomes mais pertinentes, e foram propostas novas características gerais de sistema que representam o contexto de Data Mart. A seguir são descritas as características aplicáveis, as características não aplicáveis, as características adaptadas e as criadas para o contexto de Data Mart. 4.6.1 Características gerais aplicáveis Quatro características gerais da abordagem APF foram identificadas como aplicáveis ao contexto de Data Mart. O Quadro 4.1 define cada uma destas características, seus itens de influência e justifica sua aplicabilidade à tecnologia de Data Mart. Quadro 4.1 - Características gerais de sistema aplicáveis ao contexto de Data Mart Característica Definição Processamento Aspectos distribuído relacionados com processamento e funções distribuídas. Itens de Influência 0. O aplicativo não auxilia na transferência de dados ou funções entre os processadores envolvidos. Justificativa O processo de Data Mart prepara dados para leitura 1. O aplicativo prepara dados para que o usuário final os utilize do usuário final em outra em outro processador (planilhas de cálculo, por exemplo). ferramenta, no caso uma 2. O aplicativo prepara dados e os transfere para que outros ferramenta OLAP ou na equipamentos os utilizem. intranet. 3. O processamento é distribuído e a transferência de dados acontece de forma on-line apenas em uma direção. 4. O processamento é distribuído e a transferência de dados acontece de forma on-line em ambas as direções. 5. As funções de processamento são dinamicamente executadas no equipamento mais apropriado. Desempenho Aspectos relacionados a parâmetros estabelecidos pelo usuário 0. Nenhum requisito especial de performance foi solicitado pelo usuário. 1. Requisitos de desempenho foram estabelecidos e revistos mas nenhuma ação especial foi requerida. 2. Tempo de resposta e volume de processamento são itens quanto a críticos durante horários de pico de processamento. Porém , tempos de nenhuma determinação especial foi estabelecida quanto à resposta. utilização do processador. A data limite para a disponibilidade do processamento é sempre o próximo dia útil. 3. Tempo de resposta e volume de processamento são itens críticos durante todo o horário comercial. Não há determinação especial para utilização do processador. A data limite para a comunicação com outros aplicativos é um item importante e deve ser considerada. 4. Os requisitos de desempenho estabelecidos requerem tarefas de análise de performance na fase de análise e desenho do É aplicável ao projeto de Data Mart que trabalha com volumes altos de transações, mesmo que transações efetuadas ferramentas OLAP. sejam por 65 Característica Definição Itens de Influência Justificativa aplicativo. 5. Os requisitos de desempenho estabelecidos requerem tarefas de análise de desempenho na fase de análise e desenho do aplicativo. Além disso, ferramentas de análise de desempenho precisam ser usadas nas fases de implementação para que os requisitos do usuário sejam atendidos plenamente. Reusabilidade Aspectos 0. Nenhuma preocupação com a reutilização do código. A reusabilidade pode ser de código relacionados à 1. Reutilização de código apenas no aplicativo. aplicada reutilização do 2. Menos de 10% do código do aplicativo foi projetado para ser contexto de software. código do aplicativo. em qualquer utilizado em outros aplicativos. 3. 10% ou mais do código do aplicativo foi escrito para ser utilizado em outros aplicativos. 4. O código do aplicativo foi projetado para ser utilizado em outros aplicativos. A customização deve ser realizada em nível de código-fonte. 5. O código do aplicativo pode ser reutilizado em outros aplicativos com alto grau de parametrização. É apenas necessário que o usuário altere determinados parâmetros. Facilidade Aspectos 0 – Nenhuma consideração especial de operação além do processo Aplicável Operacional relacionados normal de salvamento de dados. direcionado com a 1 a 4 - determinado de acordo com os itens abaixo: procedimentos facilidade de operação do aplicativo. aos batch de extração e carga. recuperação, mas a intervenção do operador é necessária. Avalia Foram desenvolvidos procedimentos de iniciação, salvamento e recuperação, sem necessidade de intervenção do operador (vale procedimentos operacionais Foram desenvolvidos procedimentos de iniciação, salvamento e quando dois itens). automáticos e O aplicativo minimiza a necessidade de montar fitas magnéticas. mecanismos de iniciação, 5 – O aplicativo foi desenhado para trabalhar sem operador. salvamento e Nenhuma intervenção do operador é necessária além de iniciar e recuperação de encerrar o aplicativo, porque esse já contém rotinas automáticas de dados. recuperação de erros. O aplicativo minimiza a necessidade de manuseio de papel. Fonte: Baseado IFPUG (2000) 4.6.2 Características não-aplicáveis Outras características gerais da abordagem APF citadas no Quadro 4.2, estão intrinsecamente relacionadas a sistemas transacionais o que implica que, quando analisadas no contexto da Data Mart, sempre receberiam o valor 0 (nenhuma influência). Estas características foram classificadas como não aplicáveis ao contexto de Data Mart. 66 Quadro 4.2 - Características gerais de sistema não-aplicáveis ao contexto de Data Mart Características não-aplicáveis Justificativa Comunicação de dados - aspectos relacionados aos recursos No contexto de Data Mart não há essa preocupação com a utilizados na comunicação de dados do aplicativo. É comunicação de dados. Os dados são disponibilizados nos bancos importante determinar que protocolos são utilizados pelo multidimensionais e os usuários finais os acessam utilizando aplicativo para o recebimento ou o envio de informações ferramentas OLAP de mercado. Utilização de equipamento - aspectos relacionados com o Essa característica está vinculada a aplicativos transacionais e à nível de utilização dos equipamentos necessários à execução necessidade de equipamento para produção, principalmente em do aplicativo. A avaliação visa identificar a carga de trabalho aplicações cliente-servidor. No caso do Data Mart não há essa exigida pelo aplicativo quando em produção preocupação, uma vez que o usuário final utiliza o sistema através o de ferramentas OLAP que acessam banco multidimensional. Volume de transações – Aspectos relacionados com a Como foi visto no capítulo 2, a quantidade de transações é uma capacidade do sistema em relação ao volume de transações característica dos sistemas transacionais (OLTP) que utilizam esperado. esse recurso para automatizar os processos de negócio das organizações. No contexto de Data Mart não são criadas transações para operacionalizar o negócio. Entrada de dados on-line - Aspectos relacionados com a No contexto de Data Mart não existem entradas de dados on line quantidade de entrada de dados on-line do aplicativo Atualização on-line - Aspectos relacionados com a No contexto de Data Mart não existem atualizações on line quantidade de atualização on-line dos arquivos lógicos internos Facilidade de implantação – Aspectos relacionados com o No Data Mart não são definidos planos de conversão de bases grau de dificuldade de implementação do aplicativo. Verifica anteriores e nem de implementação dessas bases. Por ser um planos de conversão e de implementação. processo totalmente batch de extração e transformação dos dados já existentes em sistemas transacionais são definidos planos de extração, transformação e carga desses dados no modelo multidimensional. Múltiplos locais - Aspectos relacionados à arquitetura do Data Warehouse/Data Mart não é instalado em nenhum local, o aplicativo e à necessidade de instalação em vários lugares acesso é realizado através de ferramentas OLAP. Facilidade de mudanças – Aspectos relacionados com o Essa característica refere-se à existência de facilidades como grau de flexibilidade do aplicativo com relação a mudanças consultas e relatórios flexíveis, dados de controle armazenados nos requisitos de usuário. em tabelas, etc. Todas as consultas de um Data Mart são feitas por meio de ferramentas OLAP que já possuem essa facilidade de disponibilizar consultas e relatórios flexíveis. Fonte: Baseado IFPUG (2000) Baseados na análise dos itens citados, considerou-se as quatro características gerais da abordagem APF realmente aplicáveis e não foram consideradas as características gerais não aplicáveis. Na análise efetuada foram identificadas também, duas características que poderiam ser adaptadas para o contexto de Data Mart e substituiu-se estas duas características possíveis de adequar por nomes e critérios mais pertinentes para o contexto de Data Mart. Para cada uma destas características, foram definidos os níveis de influência numa escala de 0-5 conforme proposto na APF. Essas acaracterísticas serão apresentadas na seção seguinte. 67 4.6.3 Características adaptadas Duas características podem ser adaptadas para Data Mart, são elas: Eficiência do usuário final e Processamento complexo. Eficiência do usuário final identifica os aspectos relacionados com a eficiência do aplicativo na interação com o usuário e pontua com relação à quantidade de recursos implementados de maneira a tornar o aplicativo mais amigável. Estes recursos são identificados pela abordagem APF como: auxílio à navegação (teclas de função, acesso direto, menus dinâmicos), menus, documentação e ajuda on-line, movimento automático de cursor, movimento horizontal e vertical da tela, etc). Os sistemas de Data Mart não constróem consultas nem atualizações on line e essa característica, da forma como está definida pela APF, não tem como ser aplicada, mas segundo Barbiere (2001, p.110), a definição de agregação facilita o acesso aos dados pelo usuário final e agiliza os processos decisórios. A definição dos níveis de agregação necessários no contexto de Data Mart tem como objetivo proporcionar eficiência para o usuário final e desta forma decidiu-se adequar a característica Eficiência do usuário final para Quantidade de agregação, considerando que a definição dos níveis de agregação necessários visa melhorar o desempenho das consultas e aumentar a eficiência para o usuário final. Processamento complexo é definida pela abordagem APF como um conjunto de aspectos do sistema que necessitam ser analisados, tais como: a existência de processamento lógico extensivo, processamento matemático, processamento complexo, processamentos especiais de auditoria e etc. No processo de Data Warehouse estes aspectos definidos pela APF, não tem aplicação, mas a quantidade de tratamento, tais como: integração, limpeza, eliminação, combinação, verificação de integridade referencial , desnormalização e renormalização, conversão de tipo de dados, cálculos, derivação e alocação, etc podem ser considerados como um nível de complexidade do processo. Desta forma, a característica Complexidade do processamento foi adequada para Qualidade dos dados. A seguir são descritos os critérios definidos para essas duas características gerais adaptadas. 68 4.6.3.1 Quantidade de agregação Segundo Barbiere (2001, p.110), os valores agregados são representados por meio de tabelas prontas, trabalhadas e sumarizadas em várias dimensões, visando facilitar os acessos aos dados e agilizar os processos decisórios. São armazenadas utilizando mais espaço, pois são dedicadas a dados num estado pré-processado. Esse autor também considera que, na definição das agregações é importante analisar e definir a estratégia de carga total x atualização incremental. Essa definição passa por aspectos como tempo de processamento e complexidade dos programas. Kimball et al (1998, p.543, 544) citam que as agregações interferem muito na performance, proporcionando um benefício direto para os usuários que terão suas informações acessadas de forma mais rápida. Lokan e Abran (1999) identificam a performance como um dos requisitos nãofuncionais e a quantidade de agregação visa preliminarmente, garantir performance para o usuário final. Na proposta APF existe a característica Eficiência para o usuário final cujo objetivo é identificar o nível de eficiência do produto de software. Nesta proposta optou-se por substituíla pela quantidade de agregações utilizadas no projeto e a quantidade de definições necessárias para implementá-las. A escala escolhida, em conjunto com especialistas, identificou o número máximo de agregações que receberiam o nível de influência 5 (Oito ou mais quantidades de agregação identificadas) e se definiu as faixas e os respectivos níveis de influência abaixo desse item. 0. nenhum nível de agregação identificado; 1. Um nível de agregação identificado; 2. De dois a três quantidades de agregação identificadas; 3. De quatro a cinco quantidades de agregação identificadas; 4. Seis a sete quantidades de agregação identificadas; 5. Oito ou mais quantidades de agregação identificadas. 4.6.3.2 Qualidade de dados Barbiere (2001, p. 74, 75) identifica alguns processos de transformação como filtro, integração, condensação, conversão e derivação. Kimball et al (1998, p.23, 24, 25) identificam uma série de tipos de transformações que poderiam ser utilizadas na etapa de transformação do dado no processo de ETL do Data 69 Warehouse, entre eles: integração, desnormalização e renormalização, limpeza, merge, conversão de tipo de dados, cálculos, derivação e alocação, agregação, valores nulos, etc. Todos esses tipos de transformação visam garantir o valor do dado (KIMBALL et al, p.24, 1998), ou seja, garantir a qualidade do dado a ser consultado e segundo Lokan e Abran (1999) qualidade é requisito não-funcional que deve ser considerado. Para essa nova característica foi definida uma escala considerando o grau de influência de 0 a 5 para a quantidade de tratamento utilizado para garantia da qualidade do dado. Foi efetuada uma pesquisa bibliográfica visando identificar os tipos de transformações mais marcantes. A abordagem APF possui algumas características (Características Interface com o usuário, Facilidade de mudança) que também utilizam esse mesmo conceito de pontuar o grau de influência com relação à quantidade de itens implementados dentro do intervalo de 0 a 5 (ver Quadro 4.4). Para a nova característica Qualidade de dados é sugerido que se verifique a necessidade de aplicabilidade dos seguintes itens no software (apresentados no capítulo 2): Integração – envolve a geração de chaves substitutas para cada registro, de modo a evitar a dependência de chaves definidas no sistema legado; Limpeza – correção de códigos e caracteres especiais, resolvendo problemas de domínios, tratando dados perdidos e corrigindo valores duplicados ou errados; Eliminação – eliminação de campos e dados provenientes dos sistemas legados que não serão úteis ao Data Warehouse; Combinação – realizada quando fontes de dados possuem os mesmos valores de chaves representando registros iguais ou complementares ou atributos de chaves não iguais, incluindo equivalência textual de códigos de sistemas legados distintos; Verificação de integridade referencial – checagem dos dados de uma tabela em relação aos dados correspondentes de outra tabela; Desnormalização e renormalização – reunificação das hierarquias de dados, separadas pela normalização dentro de uma tabela desnormalizada; Conversão de tipo de dados – transformação de baixo nível de forma a converter um tipo de dado em outro formato; Cálculos, derivação e alocação – transformações a serem aplicadas sobre as regras de negócio identificadas durante o processo de levantamento de requisitos; Auditoria no conteúdo dos dados – verificações (através de somas, contagem de linhas e testes) das transformações realizadas. 70 Será utilizada a seguinte definição para pontuação dos itens de influência: 0. quando não ocorrer nenhuma das características descritas; 1. quando ocorrer uma ou duas das características descritas; 2. quando ocorrer três ou quatro das características descritas; 3. quando ocorrer cinco ou seis das características descritas; 4. quando ocorrer sete ou oito das características descritas; 5. quando ocorrerem todas as características descritas. Na seção 4.6.4 serão descritas detalhadamente os critérios adotados para definição das novas características gerais propostas para o contexto de Data Mart 4.6.4 Novas características gerais propostas para a tecnologia de Data Mart Para cada uma das características, foram definidos os níveis de influência numa escala de 0-5 conforme proposto na APF. Para a definição das novas características foram considerados os estudos a seguir relacionados. Como citado anteriormente, vários autores, entre eles Allison (2001), Fiori (2002), Inmon (1997), Meyer (2001) e Mrazek (2003) identificam o processo de ETL como o processo de maior impacto e que demanda maior esforço dentro do processo de construção de um Data Mart, representando de 40 a 70% do projeto. Segundo Lokan e Abran (1999) as características gerais de sistema identificam vários aspectos funcionais e não-funcionais do software que são utilizados na mensuração de tamanho funcional, entre eles: Complexidade, representada pela característica geral da APF Processamento complexo; suporte ao usuário, representado pelas características da APF Eficiência usuário final e Facilidade de mudanças; qualidade: características de Reutilização do código e Facilidade de mudanças; arquitetura: características da APF como Comunicação de dados, Múltiplos locais e Processamento distribuído; interação, representada pelas características de Entrada de dados on line e Atualização on line; 71 fatores limitantes: características da APF de Desempenho e Volume de transações; operação: características de Facilidade de implantação, Facilidade operacional e Utilização de equipamento; reusabilidade: Reutilização de código. Lokan e Abran (1999) também identificam outros aspectos como documentação, manutenção, padrões de código que podem ser considerados. Considerando estas afirmativas, foram identificadas dentro do processo de ETL características que poderiam influênciar na definição de tamanho de um Data Mart e que identificassem esses aspectos funcionais e não-funcionais citados por Lokan e Abran (1999). Para definição dos itens de influência relacionados com cada característica foi considerada que na proposta APF as escalas utilizadas para as características gerais de sistema variam de um intervalo de 0 (representando pouca influência) a 5 (representando muita influência). Para cada característica e para definição do intervalo (de 0 a 5), a APF define várias formas de itens de influência, conforme exemplo do Quadro 4.3: Quadro 4.3 - Exemplos dos itens de influência utilizados pela APF Forma do item Exemplo da Itens de Influência Característica Faixas de Entrada de dados 0- todas as transações previstas no aplicativo são processadas de modo batch, intervalo on-line 1- 1% a 7% das transações são entradas de dados on-line. (percentual ou 2- 8% a 15% das transações são entradas de dados on-line. numérica) 3- 16% a 23% das transações são entradas de dados on-line. dentro do 4- 24% a 30% das transações são entradas de dados on-line. intervalo de 0 5- Acima de 30% das transações são processadas em modo on-line. a 5. Atualização on- 0. Nenhuma atualização on-line. line 1. Atualização on-line de 1 a 3 arquivos lógicos internos. O volume de atualizações é baixo e a recuperação de dados é realizada de forma simples. 2. Atualização on-line de mais de 3 arquivos lógicos internos. O volume de atualizações é baixo e a recuperação de dados é realizada facilmente. 3. Atualização on-line de todos (ou da maioria) dos arquivos lógicos internos. 4. Atualização on-line de todos os arquivos lógicos internos, com implementação de proteção contra a perda de dados. 5. Atualização on-line de todos os arquivos lógicos internos, com implementação de proteção contra perda de dados. Existem processos automáticos de recuperação de dados com interferência mínima do operador. Quantidade de Interface com o Recursos utilizados: itens usuário Auxílio à navegação. implementados Menus. dentro do Documentação e ajuda on-line. intervalo de 0 Movimento automático do cursor. a 5. Movimento horizontal e vertical da tela. Impressão remota. Teclas de função pré-estabelecidas. 72 Forma do item Exemplo da Itens de Influência Característica Processos batch submetidos a partir de transações on-line. Seleção de cursor em campos de tela. Utilização adequada de atributos de campos. Impressão da documentação das transações on-line por meio de hard copy. Utilização de mouse. Menus pop-up. Pequeno número de telas para realizar funções de negócio. Suporte bilíngüe (conte quatro itens). Suporte multilingüe (conte cinco itens). O item de influência é decidido pela quantidade de recursos utilizados: 0. Nenhum item contado. 1. De 1 a 3 itens contados. 2. De 4 a 5 itens contados. 3. Mais de 5 itens contados, embora não existam requisitos de amigabilidade expressos pelo usuário. 4. Mais de 5 itens contados, existindo requisitos do usuário que impliquem, por exemplo, minimização de digitação ou persistência de valores mais utilizados. 5. Mais de 5 itens contados, havendo requisitos do usuário que somente podem ser atendidos com a utilização de ferramentas e processos especiais. Quantidade de Facilidade itens mudanças de Estão disponíveis facilidades como consultas e relatórios flexíveis para atender a necessidade simples. implementados Estão disponíveis facilidades como consultas e relatórios flexíveis para atender a dentro do necessidade média (conte dois itens). intervalo de 0 Estão disponíveis facilidades como consultas e relatórios flexíveis para atender a a 5, necessidade complexas (conte três itens). considerando Dados de controle são armazenados em tabelas que são mantidas pelo usuário por meio também uma de processos on-line, com mudanças se refletindo nos dias seguintes. escala ordinal Dados de controle são armazenados em tabelas que são mantidas pelo usuário por meio interna de processos on-line, com mudanças se refletindo imediatamente. (simples, Pontuação: média, 0. Nenhum item contado. complexa). 1. Um item contado. 2. Dois itens contados. 3. Três itens contados. 4. Quatro itens contados. 5. Cinco ou mais itens contados. Intervalo de 0 Comunicação de 0. Aplicativo batch ou stand-alone. a 5 com outra dados 1. Aplicativo batch com entrada ou saída de dados remota. 2. Aplicativo batch com entrada e saída de dados remota. 3. Aplicativo com entrada de dados on-line para alimentar processamento batch. 4. Aplicativo com entrada de dados on-line, suportando apenas um tipo de protocolo graduação de complexidade de comunicação. 5. Aplicativo com entrada de dados on-line, suportando vários tipos de protocolo. Fonte: Baseado IFPUG (2000) Na proposta de adequação foi utilizada a mesma escala (0 a 5) e na definição dos itens de influência foram seguidos os padrões adotados pela APF. 73 As características e os itens de influência definidos foram identificados por meio de pesquisa bibliográfica e de consulta a especialistas, da primeira instituição pesquisada, que identificaram principalmente as quantidades ou volumes a serem utilizados como referencial. As características a seguir foram propostas considerando as peculiaridades do contexto de Data Mart e os aspectos funcionais e não-funcionais das características gerais de sistema propostos por Lokan e Abran (1999). 4.6.4.1 Utilização de ferramenta apropriada para extração e carga Segundo Barbiere (2001, p.72) a escolha e utilização de uma ferramenta de ETL aliada à integridade dos dados é de fundamental importância para manter a qualidade de dados em um Data Warehouse. Decidiu-se então considerar essa característica analisando o impacto da mesma no processo de construção e também relacionamento dessa com os aspectos citados por Lokan e Abran (1999): qualidade (manutenibilidade) e de operação (facilidade de operação) e complexidade do processo de ETL. A existência de uma ferramenta de ETL proporciona uma melhor manutenibilidade e operacionalização do processo. A utilização de uma ferramenta que automatiza o processo de construção de um Data Mart reduz também a complexidade do processo, que passa a ter menos controles manuais. O processo de ETL nas empresas pode ser totalmente automatizado ou não, dependendo da plataforma adotada pela empresa. Por esse motivo optou-se pela determinação do grau de utilização da ferramenta ETL. Como a proposta de APF considera 5 níveis de influência, foi utilizada a escala a seguir e definiu-se em conjunto com especialistas dessa tecnologia o percentual que seria indicado para cada item de influência. Nesse caso, se estabeleceu uma faixa de 20% para cada item de influência partindo de 0 (quando é utilizada ferramenta para 100% do processo de extração/transformação/carga), chegando até 5 (quando não é utilizada ferramenta para todo processo de extração/transformação/carga): 0. quando é utilizada ferramenta para 100% do processo de extração/transformação/ carga; 1. quando é utilizada ferramenta para até 80% do processo de para até 60% do processo de extração/transformação/ carga; 2. quando é utilizada ferramenta extração/transformação/ carga; 74 3. quando é utilizada ferramenta para até 40% do processo de para até 20% do processo de extração/transformação/ carga; 4. quando é utilizada ferramenta extração/transformação/ carga; 5. quando nenhuma ferramenta é utilizada para extração e carga dos dados transacionais 4.6.4.2 Quantidade de sistemas transacionais envolvidos no projeto Kimball et al (1998, p. 296, 298, 304) demonstram que a utilização de várias origens de dados causa impacto no escopo do projeto, pois todo o trabalho de análise e extração dos dados deve ser realizado considerando suas origens. Segundo esses autores, é importante entender a dificuldade das origens dos dados no projeto de Data Warehouse. Para Machado (2000, p.24), a extração de dados de fontes heterogêneas ou externas é uma atividade complexa. Considerando essas afirmativas, vinculando essa característica aos aspectos citados por Lokan e Abran (1999) de complexidade e operação e analisando o processo de extração de dados do Data Mart, foi definido considerar a quantidade de sistemas transacionais envolvidos no projeto como uma característica geral de sistema para o contexto de Data Mart. Quanto maior a quantidade de sistemas transacionais envolvidos no processo maior será a complexidade do Data Mart. Maior será a quantidade de extrações, de tratamentos e de cargas. E maior será, também, o nível de operacionalização necessário para controlar todo este processo. Considerando os 5 níveis de influência definidos pela APF, decidiu-se em conjunto com especialistas que um sistema de Data Mart que envolvesse dados de mais de 8 sistemas transacionais poderia ser considerado de alta complexidade e seria classificado com o item de influência 5. Foi, também, definido que os demais itens de influência teriam faixas de forma a chegar ao sistema menos complexo, que somente trataria dados de um sistema transacional (item de influência 1). Neste caso não tem sentido o item de influência 0, pois o Sistema de Data Mart é construído sempre com dados de pelo menos um sistema transacional. 0. Não aplicado. 1. quando o projeto envolve 1 sistema transacional; 2. quando o projeto envolve de 2 a 3 sistemas transacionais; 3. quando o projeto envolve de 4 a 5 sistemas transacionais; 4. quando o projeto envolve de 6 a 7 sistemas transacionais; 5. quando o projeto envolve mais de 8 sistemas transacionais. 75 4.6.4.3 Documentação dos sistemas transacionais de origem (existência de metadados dos sistemas de transacionais) Segundo Barbiere (2001, p. 114), os metadados32 representam um dos mais importantes pontos na documentação dos Data Warehouse/Data Mart. Os metadados permitem que a empresa conheça os cubos de dados disponíveis, suas dimensões e métricas, além das informações sobre os dados que lhe deram origem. Para Inmon et al (2001, p.184-185 ) os metadados exigem uma boa quantidade de recursos para criar e mantê-los atuais. Os metadados atuam como um mapa para informar onde os dados estão, como chegaram lá, qual a sua fonte e qual o seu significado. Lokan e Abran (1999) identificam a característica de documentação como um requisito importante. Considerando estes posicionamentos e, conseqüentemente, o impacto da não-existência de documentação ou metadados nos sistemas transacionais de origem, optou-se por criar essa característica para o contexto de Data Mart. O nível de documentação do sistema transacional de origem tem grande impacto em um sistema de Data Mars, pois sua não existência gera a necessidade de um conhecimento maior tanto por parte do desenvolvedor como por parte do usuário final que necessitam conhecer a informação do dado para detectar necesidades de tratamento, formatação de consultas, etc. Uma vez que um projeto de Data Mart pode extrair dados de um ou mais sistemas transacionais decidiu-se identificar o percentual de sistemas de transacionais tratados que possuía ou não informações de metadados. Como a proposta da APF considera 5 níveis de influência, definiu-se faixas de intervalo, juntamente com especialistas, para definir o percentual de existência de documentação dentro do processo e seu conseqüente impacto. Foi identificado que o nível de influência 5 seria determinado para o sistema de Data Mart que trabalhasse com um percentual inferior a 30% de metadados existentes nos sistemas transacionais de origem. 0. quando todos os sistemas transacionais de origem possuem metadados; 1. quando acima de 90% dos sistemas transacionais de origem possuem metadados; 32 Metadados – Segundo Inmon et al(2001, p.251), dados sobre dados, no caso de Data Warehouse a descrição da estrutura, conteúdo, chaves, índices e etc. 76 2. quando acima de 70% dos sistemas transacionais de origem possuem metadados; 3. quando acima de 50% dos sistemas transacionais de origem possuem metadados; 4. quando acima de 30% dos sistemas transacionais de origem possuem metadados; 5. quando nenhum dos sistemas transacionais de origem possui metadados. 4.6.4.4 Freqüência de atualização das fontes de dados Tanto os Data Warehouse, como os Data Mart evoluem acompanhando a evolução dos sistemas transacionais. A freqüência de atualização dos sistemas transacionais tem conseqüência imediata no tamanho do sistema, através do acréscimo de funções de dados ou mesmo de grupos de dados, atualizações no processo de extração, transformação e carga no modelo. A freqüência de atualização das fontes de dados está diretamente ligada ao aspecto de complexidade, citados por Lokan e Abran (1999), pois o nível de complexidade do sistema aumenta quando novos fatos e dimensões são gerados a partir da nova atualização. Considerando isto, decidiu-se considerar essa característica e utilizar a escala a seguir para classificar o nível de influência de 0 a 5. O percentual de atualizações dos arquivos de extração/carga foi definido por consulta aos especialistas que identificaram o percentual máximo que receberia o nível de influência 5. A partir dessa definição foram determinadas as outras faixas até o nível de influência 0. 0. quando houver previsão de 0% a 10% de atualizações dos arquivos de extração /carga; 1. quando houver previsão de 10% a 20% de atualizações dos arquivos de extração /carga; 2. quando houver previsão de 20% a 30% de atualizações dos arquivos de extração /carga; 3. quando houver previsão de 30% a 40% de atualizações arquivos de extração /carga; 4. quando houver previsão de 40% a 50% de atualizações dos arquivos de extração /carga; 77 5. quando houver previsão de mais de 50% de atualizações dos arquivos de extração /carga. 4.6.4.5 Estrutura dos dados de origem Segundo Inmon et al (2001, p.7), o ambiente transacional é muito complexo. Existem muitos aplicativos legados e muitas interfaces entre esses aplicativos. Os dados necessários ao Data Warehouse deverão ser garimpados desse ambiente altamente complexo. Para Machado (2000, p.13), uma das características que distingue o Data Warehouse de outros sistemas transacionais é a extração de dados de fontes heterogêneas internas (várias plataformas de hardware e software) ou externas. Além disso uma das características que devem ser analisadas nessa tecnologia é a possibilidade de trabalhar com dados de diferentes estruturas de organização tais como: VSAM, Relacional (DB2, Oracle, Sybase, SQL Server) e Hierárquico (IDMS). Lokan e Abran (1999) citam o aspecto de operação como um requisito funcional e a partir das observações anteriores, foi definida a estrutura dos dados de origem como uma das características gerais de sistema para o contexto de Data Mart. Nesse caso foi utilizada uma escala com a quantidade de estruturas dos dados de origem com critérios de 1 a 5. Foi definida, com especialistas, a maior quantidade de estruturas que poderia receber o nível de influência de 5 e o valor para as demais escalas. Neste caso não tem sentido o item de influência 0, pois o Sistema de Data Mart é construído sempre com dados de pelo menos um sistema transacional que terá no mínimo uma única estrutura de dados de origem. 0. Não se aplica; 1. quando existir uma única estrutura dos dados de origem; 2. quando existirem duas estruturas dos dados de origem; 3. quando existirem três estruturas dos dados de origem; 4. quando existirem quatro estruturas dos dados de origem; 5. quando existirem mais de quatro estruturas. 4.6.4.6 Volume dos dados Segundo Barbiere (2001, p.153, 165) o volume de dados em um processo de Data Warehouse refere-se a tabelas com milhões de registros, com muitos gigas e até alguns teras. 78 Segundo McKendrick (2002), as bases dos sistemas de suporte a decisão devem triplicar de tamanho nos próximos dois anos, o que mostra o impacto desta característica no processo de Data Mart. Optou-se então por utilizar uma escala ordinal de forma a identificar o volume de carga a ser tratado tanto na etapa de extração como na etapa de carga dos dados e, também, pontuar os níveis de influência de 0 a 5. É importante lembrar que a métrica APF possui uma característica (Facilidade de mudança) que também utiliza esse mesmo conceito de pontuar o grau de influência (0 a 5) com relação a uma escala ordinal interna (simples, média, complexa). Foram consultados os especialistas para definir o tamanho com relação a cada escala ordinal definida. Nesse caso não tem sentido o item de influência 0, pois alto volume de dados é uma característica dos Sistemas de Data Mart (conforme apresentado no capítulo 2). Decidiu-se também considerar somente 3 níveis de influência (1, 3, 5) para facilitar a identificação da quantidade de volume a ser tratado. Neste caso acordou-se que a nova característica volume de dados receberia os seguintes níveis de influência: 1 Baixo (até 500 gigabytes33) 3. Médio (de 500 gigabytes a 1 terabyte34) 5. Alto (acima de 1 terabyte) 4.6.4.7 Nível de conhecimento exigido pela equipe de Data Mart da base de dados /regras de negócio dos sistemas transacionais de origem. O nível de conhecimento exigido pela equipe de Data Mart da base e regras de negócio dos sistemas transacionais de origem depende da estratégia adotada pela organização para extração desses dados. Se a organização optar pela extração realizada pela equipe de Data Mart, essa equipe necessitará conhecer os requisitos básicos do sistema transacional de origem para operacionalizar este processo. A extração nesse caso, considerando o escopo do projeto de Data Mart será mais complexa. Se a extração é realizada pela equipe do sistema transacional de origem, um grau de conhecimento médio/baixo é necessário pela equipe do Data Mart. Foram consultados especialistas para definir o nível de conhecimento exigido com relação ao grau de influência (0 a 5) definido pela métrica APF. Neste caso definiu-se 33 34 Medida de capacidade de armazenamento do computador, representando aproximadamente um bilhão de bytes. Medida de capacidade de armazenamento do computador, representando aproximadamente mil gigabytes. 79 considerar somente 3 níveis de influência (1, 3, 5) para facilitar a identificação do conhecimento da equipe de Data Mart necessário. Não foram definidos níveis de influência para 0, 2 e 4 devido ao grau de subjetividade da questão. Foi considerado que para a característica nível de conhecimento da equipe a definição de somente 3 itens facilitaria a aplicação. 1 Pouco conhecimento da equipe de Data Mart das regras de negócio dos sistemas transacionais. 3 Médio conhecimento da equipe de Data Mart das regras de negócio dos sistemas transacionais. 5 Alto conhecimento da equipe de Data Mart das regras de negócio dos sistemas transacionais. Conforme já foi descrito no capítulo 3, a APF propõe a contagem de tamanho em diversas etapas no processo de desenvolvimento de sistemas. A seguir será apresentada como a proposta de medição de tamanho seria aplicada no processo de desenvolvimento de um sistema de Data Mart. 4.7 PROPOSTA DE ADEQUAÇÃO NO PROCESSO DE DESENVOLVIMENTO DE DATA MART A APF é uma métrica que se propõe a estimar o tamanho do software desde o início do projeto. Na proposta APF são identificadas etapas do desenvolvimento do produto, em que a contagem deve ser realizada com o objetivo de obter dados históricos da evolução e mesmo da adequação dos fatores de produtividade, custo e prazo utilizados, conforme citado no capítulo 3 (Figura 3.1). São sugeridos na abordagem da APF cinco momentos em que a contagem será realizada. Conforme mencionado no capítulo 2, e destacado na seção 4.2, o processo de desenvolvimento de um projeto de Data Mart se diferencia do processo de desenvolvimento de um sistema transacional. Como a proposta de adequação de APF visa à tecnologia de Data Mart /Data Warehouse, definiu-se dentro do processo de desenvolvimento proposto por Kimball et al (1998, p.41) as etapas em que deveriam ser realizadas as contagens respeitando os mesmos objetivos propostos pela APF de acompanhamento e adequação do processo, discutido na seção 3.3.3.1. 80 Foi escolhido o Diagrama do ciclo de vida dimensional do negócio proposto por Kinball et al ( 1998, p.41) por ser, conforme citado no capitulo 2, uma das abordagens mais abrangentes, com boa cobertura das fases de desenvolvimento para esse tipo de tecnologia, inclusive do processo de ETL. Foram também definidos cinco momentos para realização da contagem no contexto de Data Warehouse (Figura 4.3). Essa definição é importante, pois tem como objetivo garantir o padrão da métrica adaptada, mesmo que no contexto de Data Mart. Planejamento do projeto Definição dos requisitos do negócio Projeto técnico de arquitetura Seleção e instalação do produto Modelagem dimensional Projeto físico Projeto e desenvolvimento da data staging Especificação da aplicação analítica Desenvolvimento da aplicação analítica Distribuição Manutenção e crescimento Contagem Contagem Gerenciamento do projeto Contagem Contagem Contagem Figura 4.3 - Proposta de contagem no ciclo de vida de Data Warehouse Na etapa definição de requisitos de negócio seria efetuada a primeira contagem, pois nesta etapa são realizadas análises das áreas de negócio e dos dados. Para esta contagem considera-se as macro funções de dados identificadas. Nesse momento tem-se uma contagem estimativa de tamanho do sistema. A segunda contagem é realizada na etapa de Modelagem física, onde são analisados os dados e implementado o esquema dimensional. Nesse momento, com o esquema dimensional definido, as funções de dados poderão ser pontuadas com maior precisão. Nessa etapa estão sendo levantados os dados disponíveis pelos sistemas legados e as características gerais do sistema serão aplicadas com maior pertinência. Na etapa de Projeto Desenvolvimento da data staging area são integrados os dados, definidas estratégias de agregação e definidos e criados os programas de ETL. A contagem nesse terceiro momento viria para ratificar e/ou retificar a contagem anterior, pois com as 81 estratégias de agregação e ETL definidas já se tem o conhecimento profundo de todas as funções necessárias do sistema. As características gerais também serão aplicadas com maior precisão, pois já se definiram todos os procedimentos de transformação, o volume dos dados, a existência de metadados, entre outros. Na etapa de distribuição, na qual se tem o sistema totalmente construído, se inicia a implantação e realizar-se-ia a última contagem de modo a obter a pontuação final do tamanho do sistema e os dados históricos com relação à evolução das medidas. As contagens tem prosseguimento, nas etapas de manutenção e crescimento de forma a garantir a atualização do tamanho do sistema. 4.8 MEDIÇÃO DE TAMANHO EM PROJETOS REAIS Nesta seção será apresentada a aplicação dessa proposta em projetos reais da indústria, iniciando com o planejamento do estudo, a efetiva aplicação e concluindo com a análise dos resultados. 4.8.1 Planejamento Visando utilizar e validar a proposta de adequação da APF para a tecnologia de Data Mart, esta foi aplicada em projetos de três instituições federais. Duas instituições do setor financeiro e a terceira voltada ao desenvolvimento de sistemas. A proposta foi aplicada em 7 projetos da primeira instituição, em 1 projeto da segunda e em 3 projetos da terceira instituição. Dessa forma foram avaliados ao todo 11 projetos de Data Mart objetivando efetuar uma comparação entre as duas abordagens (a APF tradicional e a proposta de adequação). Para isso será considerado, o tempo estimado obtido de cada uma das propostas e o tempo real gasto para o desenvolvimento, verificando qual das duas abordagens se aproxima mais do tempo real. No Quadro 4.4 pode ser visualizada a situação de cada projeto analisado. Os dados dos sistemas em produção, que possuem informações com relação ao tempo de construção e quantidade de recursos envolvidos, foram utilizados para validar a proposta e a APF tradicional. O dado do sistema em desenvolvimento foi utilizado para verificar a adequabilidade da proposta quando aplicada na etapa de definição de requisitos de negócio, conforme Figura 4.3. 82 Quadro 4.4 - Situação dos projetos analisados Instituição Projeto analisado Situação 1 I1S1 Em produção 1 I1S2 Em produção 1 I1S3 Em produção 1 I1S4 Em produção 1 I1S5 Em produção 1 I1S6 Em produção 1 I1S7 Em desenvolvimento 2 I2S1 Em produção 3 I3S1 Em produção 3 I3S2 Em produção 3 I3S3 Em produção Para cada instituição foram definidos os seguintes critérios para permitir a análise dos dados: quantidade de dias por mês, carga horária diária, quantidade de recursos alocados para construção do sistema e um fator de produtividade por pontos de função a ser utilizado. Para todos os projetos foi considerada a quantidade de 22 dias por mês, com a carga horária de 8 horas diárias. A quantidade de recursos alocados para cada sistema de todas as instituições pesquisadas foi obtida por meio de entrevistas dirigidas com os líderes dos projetos de Data Mart. A seguir estão descritos os critérios adotados para cada instituição com relação ao fator de produtividade. 4.8.1.1 Critérios adotados para a Instituição 1 (I1) Com relação ao fator de produtividade por pontos de função, é interessante ressaltar que essa instituição já utiliza a métrica APF para pontuar os sistemas tradicionais. A Instituição 1 utiliza uma tabela de produtividade (horas gastas por ponto de função) para seus contratos de outsourcing. Essa produtividade é variável para cada tipo de linguagem e também para cada fase de desenvolvimento. Para obtenção do fator de produtividade (horas por ponto de função) foi calculada a média ponderada de todas as produtividades por fases de desenvolvimento considerando a linguagem C++ utilizada pela empresa para esse tipo de projeto. Esse cálculo definiu uma média de esforço de 16 horas por ponto de função. 83 4.8.1.2 Critérios adotados para as Instituições 2 e 3 (I2 e I3) As Instituições 2 e 3 não utilizam métricas para mensurar o tamanho de seus sistemas e não possuem fatores de produtividade com relação à quantidade de horas por ponto de função. Nesse caso, para analisar a contagem de pontos de função definiu-se a estimativa de tempo com relação a APF e com relação à Proposta considerando o fator de produtividade descrito a seguir: 4.8.1.2.1 Para Instituição 2 Foi considerado um fator de produtividade de mercado, já que a empresa não possuía um fator de produtividade próprio. A produtividade adotada foi baseada na análise dos dados do banco de dados do International Software Benchmarking Standards Group (ISBG, 2002). O foco desse grupo é coletar, validar e publicar um repositório histórico de produtividade em projetos de softwares. Esse banco de dados é utilizado para análise e levantamento de produtividade do mercado e possui uma grande base de dados de produtividade por pontos de função e linguagens de programação de várias indústrias e companhias. Esses dados já foram utilizados para análise por autores como Garmus e Herron (2000) e Oligny, Bourque, Abran e Fournier (2002). A linguagem adotada pela Instituição 2 é VB (Microsoft Visual Basic) e foi calculada a média da produtividade encontrada para essa linguagem neste banco de dados. Chegou-se a uma média de esforço de 8,0 horas por ponto de função. 4.8.1.2.2 Para Instituição 3 Para a Instituição 3, foi também considerado um fator de produtividade de mercado, já que a empresa não possuía um fator de produtividade próprio. A produtividade adotada foi baseada na análise dos dados do banco de dados do International Software Benchmarking Standards Group(ISBG, 2002). A média da produtividade encontrada nesse banco de dados para a linguagem adotada por essa instituição (Natural) foi de 9,0 horas por ponto de função. Além disto, essa instituição utiliza uma ferramenta que automatiza o processo de ETL. Considerando que esta média de produtividade é vinculada ao esforço humano de 84 desenvolvimento com a linguagem, e que um processo automatizado de ETL reduz parte deste esforço, foi necessário investigar e definir uma adequação para esta média de produtividade obtida. O processo de ETL na construção de um Data Mart, como citado no início deste capítulo, é identificado por autores como Allison (2001), Fiori (2002), Imnon (1997), Meyer (2001) e Mrazek (2003) como o processo de maior impacto e que demanda maior esforço, conforme pode ser visualizado na Tabela 4.1. Empresas como Áquila (BROKAW, 2003), Enbridge Inc. (MACMILLAN, 2003) Principal Financial Group(HOUSE, 2003) Towers Perrin (BOYER, 2003) que utilizam uma ferramenta de ETL relataram em estudos de casos ganhos de produtividade de até 50% (Tabela 4.4) Tabela 4.4 - Levantamento das empresas que utilizam ferramenta ETL Empresas Ambiente, Linguagem ou sistema Ganho de produtividade operacional Áquila Grande porte/Unix 43% Enbridge Inc. Grande porte/Unix 50% Principal Financial Group Cobol 30% Towers Perrin Sun solaris 50% Média 43% Analisando esses dados, ficou claro que a utilização de uma ferramenta proporciona ganho de produtividade, decidiu-se recalcular a quantidade de horas necessárias para a produção de um ponto de função da Instituição 3. Para isto, a produtividade por ponto de função definida anteriormente (9,0 horas por ponto de função) foi recalculada considerando: que a etapa de ETL é a etapa de maior impacto na construção de um Data Mart (segundo o Tabela 4.1 pode chegar até a 70% do processo total de construção), e decidiu-se considerar que o processo de ETL consome 57% (média obtida por meio da bibliografia consultada) do esforço de construir um Data Mart; a utilização de uma ferramenta de ETL pode proporcionar um ganho de produtividade de até 50% e, nesse caso, foi decidido considerar uma média de ganho de produtividade de 43% (considerando a bibliografia consultada). Foi então aplicada a redução de 43% em 57% da produtividade de mercado de 9,0 horas por ponto de função e obtido o novo fator de produtividade de 6,8 horas por ponto de função. 85 4.8.2 Aplicação Foram aplicadas a APF e a Proposta nos 10 projetos de Data Mart que estão em fase de produção. Na Tabela 4.5 estão relacionados os resultados da pontuação dos ALI – arquivos lógicos internos, AIE – arquivos de interface externa, EE – entradas externas, CE – consultas externas, SE – saídas externas, IF – itens dos fatores, PFN – pontos de função não-ajustados, FA – fator de ajuste e PFA – pontos de função ajustados. Tabela 4.5 - Aplicação da APF e da proposta em 10 sistemas de Data Mart Sistema I1S1 I1S2 I1S3 I1S4 I1S5 I1S6 I2S1 I3S1 I3S2 I3S3 APF Proposta ALI AIE EE SE CE IF PFN FA PFA ALI AIE EE SE CE IF PFN FA PFA 252 5 110 13 367 0,78 286,26 504 5 110 40 619 1,07 662,33 252 24 116 13 392 0,78 305,76 504 24 116 39 644 1,06 682,64 507 7 234 14 748 0,79 590,92 1014 7 234 43 1255 1,1 1380,50 87 7 41 15 135 0,80 108,00 167 7 41 40 215 1,07 230,05 112 7 50 11 169 0,76 128,44 224 7 50 41 281 1,08 303,48 91 14 40 10 145 0,75 108,75 182 14 40 23 236 0,9 212,40 0 0 80 8 80 0,73 58,40 151 80 21 231 0,88 203,28 105 65 48 6 218 0,71 154,78 210 65 48 17 323 0,84 271,32 175 132 78 143 8 528 0,73 385,44 350 132 78 143 28 703 0,95 667,85 0 0 60 6 60 0,71 42,60 129 60 22 189 0,89 168,21 Para aplicação da APF e da Proposta foram utilizadas entrevistas estruturadas (Apêndice A) junto às equipes para levantar o tempo real, quantidade de recursos, forma de trabalho (utilização ou não de ferramenta) e as características gerais definidas pela abordagem tradicional da APF (Apêndice B) e pela Proposta (Apêndice C). Foram analisados os modelos de dados juntamente com as equipes e levantadas as demais funções existentes. Para aplicação da APF foi considerada e interpretada para este contexto a proposta tradicional, onde cada fato e dimensão do modelo dimensional foi computado como um ALI ou AIE. Para as funções de transações foram computados como EE toda a carga necessária aos ALI definidos e como SE e CE as consultas disponibilizadas ao usuário final. Para aplicação da Proposta foi considerada a definição das seções 4.5 e 4.6. Como pode ser observado, na Tabela 4.5, na maior parte dos projetos não foi computada nenhuma SE nem CE, pois todas as empresas possuíam ferramentas OLAP de mercado e na maior parte dos sistemas cabia ao usuário final a elaboração de suas SE e CE, exceto o projeto I3S2 que definiu alguns saídas externas de forma a proporcionar ao usuário final algumas das consultas já elaboradas. Nesse caso foram computadas as consultas seguindo o padrão definido pela APF. Pode-se destacar ainda que os projetos I2S1 e I3S3 eram projetos já existentes. Tinham sido criados anteriormente e não trabalhavam com uma data staging area. 86 Devido a problemas, como falta de tratamento dos dados, necessidade de limpezas, e etc foram reconstruídos totalmente com a estrutura de data staging área. A base anteriormente definida foi mantida. O que foi considerado neste estudo, foi a construção do Data Mart sobre essas bases já criadas, pois as informações obtidas, para análise da proposta real, consideraram somente essa nova versão da construção. Neste caso não foram pontuados os ALI que já existiam antes do início dessa nova construção dos projetos. Após a aplicação da métrica APF e da proposta foi necessário efetuar as comparações entre os resultados obtidos com relação ao tempo real dos projetos. Para isto foram utilizados os fatores de produtividade definidos nos itens 4.8.1, 4.8.2. Foi utilizada a quantidade de recursos efetivamente alocada nas equipes durante o tempo real de desenvolvimento. É interessante ressaltar que a definição da quantidade de recursos (com casas decimais) utilizadas pelos sistemas I1S5 e I3S3 se refere a alocação parcial de recursos durante o tempo do projeto. Na tabela 4.6 são apresentados os resultados. Tabela 4.6 - Resultados com relação ao tempo real, estimado APF e estimado proposta Sistema Tempo real Qtd recursos PF estimados Tempo PF estimados em meses utilizados APF estimado APF Proposta em meses I1S1 I1S2 I1S3 I1S4 I1S5 I1S6 I2S1 I3S1 I3S2 I3S3 10 8,5 19 10,5 5,5 8 1,5 3,0 6 4 6 7 5 2 4,2 2 5 3 4 1,3 286,26 305,76 590,92 108,00 128,44 108,75 58,4 154,78 385,44 42,60 4,33 3,97 10,74 4,9 2,78 4,94 0,53 1,99 3,72 1,26 662,33 682,64 1380,5 230,05 303,48 212,40 203,28 271,32 667,85 168,21 Tempo estimado Proposta em meses 10,03 8,86 25,1 10,45 6,56 9,65 1,84 3,49 6,44 4,99 A Figura 4.4 demonstra, de forma gráfica, a comparação entre a quantidade de pontos de função obtidos com a aplicação das duas abordagens: APF e proposta. Conforme pode ser observado, a proposta de medição voltada para esse contexto está definindo tamanhos maiores que a APF em todos os sistemas de Data Mart mensurados. Na Figura 4.4, pode ser analisada a comparação entre o tempo real de desenvolvimento, o tempo estimado da APF e da proposta elaborada. 87 Qtd PF - APF X Proposta 1400 1200 1000 800 Qtd PF 600 APF 400 Proposta 200 0 I1S1 I1S2 I1S3 I1S4 I1S5 I1S6 I2S1 I3S1 I3S2 I3S3 Sistemas Figura 4.4 - Comparação Qtd PF da APF x PF da Proposta Comparação Tempo real x Estimado APF x Estimado proposta 30 25 20 Tem po em m eses 15 Tempo real em meses Tempo estimado APF 10 Tempo estimado proposta 5 0 I1S1 I1S2 I1S3 I1S4 I1S5 I1S6 I2S1 I3S1 I3S2 I3S3 Sistem as Figura 4.5 - Comparação tempo real, estimado APF e estimado Proposta Conforme pode ser observado na Tabela 4.6 e na Figura 4.5 a estimativa de tempo entre a abordagem proposta e o tempo real de desenvolvimento dos projetos de Data Mart ficou bem aproximada. Em contraste todas as estimativas efetuadas pela métrica APF para Data Mart ficaram abaixo do tempo real do sistema, o que demonstra, nesse escopo, uma mensuração não totalmente adequada de tamanho. 88 O único sistema que ficou com um tempo estimado da Proposta de adequação menos aproximado ao real foi o I1S3. Quando consultada, a equipe informou que esse sistema foi construído por uma equipe altamente especializada de consultores e foi inferido que, talvez, nesse caso, o fator de produtividade tenha sido subestimado. Conforme já citado, a abordagem APF propõe a mensuração durante todo o ciclo de vida do sistema. As medições acima elaboradas consideraram sistemas já concluídos, de forma a conseguir dados com relação a tempo inicial e final e quantidade de recursos alocados, ou seja, no processo de desenvolvimento do produto de Data Mart as métricas foram aplicadas nos projetos de Data Mart na penúltima etapa da contagem, conforme demonstrado na Figura 4.6. Planejamento do projeto Definição dos requisitos do negócio Projeto técnico de arquitetura Seleção e instalação do produto Modelagem dimensional Projeto físico Projeto e desenvolvimento da data staging Especificação da aplicação analítica Desenvolvimento da aplicação analítica Distribuição Manutenção e crescimento Contagem Contagem Gerenciamento do projeto Contagem Contagem Contagem Figura 4.6 - Contagem efetuada no ciclo de vida de um projeto de Data Warehouse A APF, como já demonstrado no capítulo 2, tem como uma de suas vantagens a possibilidade de pontuação no início do ciclo de desenvolvimento de forma a possibilitar a aplicação de estimativas de custo, prazo e recursos. Visando avaliar se a proposta também se adequava à mensuração no início do processo de desenvolvimento, foi pontuado o sistema I1S7 no início da fase de desenvolvimento, visando verificar se a diferença entre os tamanhos definidos pela APF e proposta no início do desenvolvimento e os obtidos no final do desenvolvimento permaneceriam semelhantes. A pontuação pode ser visualizada na Tabela 4.7. 89 Tabela 4.7 - Levantamento PF de um sistema em início de desenvolvimento Empresa Sistema PF APF Tempo APF I1 I1S7 153,30 2,78 estimado PF Proposta 357,00 Tempo estimado proposta 6,5 A comparação entre as medições de PF dos sistemas já concluídos e o I1S7 em início de desenvolvimento pode ser visualizada na Figura 4.7 Comparação APF x Proposta 1400 1200 1000 PF 800 600 APF 400 Proposta 200 0 I1S1 I1S2 I1S3 I1S4 I1S5 I1S6 I2S1 I3S1 I3S2 I3S3 I1S7 Sistemas Figura 4.7 - Comparação entre a contagem de PF da APF e da Proposta incluindo sistema em início de desenvolvimento I1S7. Conforme pode ser observado, a diferença de tamanho entre APF e a proposta permanece constante também na medição de um projeto no início de desenvolvimento. A diferença entre a APF e a Proposta em Pontos de função seria de 57% e considerando que a diferença entre a APF e a Proposta em Pontos de função dos outros projetos ficou entre 42% e 74% , isto seria um indicador da aplicabilidade da proposta também no início do projeto. 4.8.3 Análise dos resultados Como destacado no início da seção 4.8.1, o objetivo da aplicação prática em projetos reais era verificar se a proposta deste trabalho estaria mais adequada que a proposta tradicional de APF. Para isso foram considerados, o tempo estimado obtido de cada uma das propostas e o tempo real gasto para o desenvolvimento, verificando qual das duas abordagens se aproxima mais do tempo real. Dessa forma, para realizar a análise dos resultados foi necessário verificar 90 os tempos estimados (com a APF e com a Proposta) com o propósito de verificar o tempo mais aproximado ao tempo real no contexto de Sistemas de Data Mart. A análise estatística foi realizada considerando a Tabela 4.6 – Resultados com relação ao tempo real, estimado APF e estimado proposta, gerados a partir: do tempo real utilizado para construção de Data Mart; do tempo estimado após a aplicação da APF; e, do tempo estimado após a aplicação da Proposta. Esta análise foi efetuada considerando os dados de 10 sistemas de Data Mart de três instituições governamentais. Como o objetivo principal da análise estatística foi verificar o tempo estimado (da APF ou da Proposta) mais aproximado com relação ao tempo real, foram definidos os seguintes testes estatísticos a serem aplicados: Análise de Variância - ANOVA (Analysis Of Variance) Como são considerados três tratamentos (tempo real, tempo estimado APF e tempo estimado proposta) com o mesmo objetivo, mas obtidos de maneira diferente, pode se aplicar a ANOVA - Análise de Variância35 para verificar se as amostras, que têm variâncias homogêneas, têm médias iguais ou diferentes, claro que, observadas as premissas estatísticas da normalidade e independência entre populações que participarão do teste. ANOVA é conhecida como a técnica estatística mais empregada para interpretação de dados experimentais. Em geral, a finalidade da ANOVA é testar diferentes significâncias entre médias (PHADKE, 1989). Wohlin et al. (2000, p.57) também sugerem o uso de ANOVA quando existe três tratamentos a serem analisados para verificar uma hipótese. Uma ANOVA permite estabelecer se as médias das populações em estudo são, ou não são estatisticamente iguais. No entanto esse tipo de análise não permite detectar quais são as médias estatisticamente diferentes das demais. O objetivo de usar a ANOVA é, portanto, garantir que, considerando os três tratamentos, pelo menos uma das médias é diferente. Dessa forma, foram formuladas as seguintes hipóteses: Hipótese Inicial 35 Variância é uma média aritmética calculada a partir dos quadrados dos desvios obtidos entre os elementos da série e a sua média. 91 Hipótese nula36: Ho: M1=M2=M3 , onde M1 = média do tempo real; M2 = média do tempo estimado após a aplicação da APF;e, M3 = média do tempo estimado após a aplicação da proposta. Contra a possibilidade da existência de pelo menos uma diferença: Hipótese alternativa37: H1: Mi ≠ Mj para algum i≠j, onde M = média i e j podendo assumir os valores de 1 a 3 (inclusive) A hipótese inicial prevê a igualdade das médias dos três tratamentos (tempo real, tempo estimado APF e tempo estimado proposta), enquanto que a hipótese alternativa afirma que pelo menos uma das médias dos três tratamentos é diferente. Testar as hipóteses envolve diferentes tipos de riscos. Alguns testes avaliam a rejeição à hipótese verdadeira, enquanto outros testes avaliam a não rejeição à hipótese alternativa. Neste estudo para identificar o risco, foi escolhido utilizar o Nível de significância. Nível de significância é definido como a probabilidade de rejeitar a hipótese nula (Ho), quando ela(Ho) é verdadeira (conhecido como erro de tipo I). Ou seja, nível de significância identifica a probabilidade de se ter observado uma amostra38 que apresenta uma diferença entre as médias que não existia na população39. Teste Tukey HSD (Honestly Significant difference) Como destacado anteriormente, a ANOVA permite estabelecer se as médias das populações em estudo são, ou não são, estatisticamente iguais, mas não permite detectar quais são as médias estatisticamente diferentes das demais. Para verificar quais médias diferem entre si foi utilizado o teste Tukey HSD. O teste de Tukey permite estabelecer a diferença mínima significante, ou seja, a menor diferença de médias de amostras que deve ser tomada como estatisticamente significante, em determinado nível. 36 A hipótese nula é a negação da hipótese alternativa. É uma hipótese de uma pesquisa e normalmente é a negação da hipótese nula. 38 Amostra é qualquer subconjunto de elementos retirado da população.Os testes estatísticos sempre são realizados com amostras. 39 População é definida como o conjunto de elementos sobre os quais se deseja informação. 37 92 Para realizar a análise estatística foi utilizado o pacote estatístico SPSS40 para realizar as análises. Neste pacote é possível realizar tanto a ANOVA como o teste de Tukey. 4.8.3.1 Aplicação ANOVA, Teste de Tukey e análise Como destacado anteriormente, para esta análise foram considerados os 10 sistemas Data Mart em que se tem todos os tratamentos (tempo com APF, com a proposta e tempo real). Esta análise foi efetuada considerando os dados de 10 sistemas de Data Mart de três instituições governamentais. Deve-se salientar que nas observações do Sistema I1S3, as estimativas tanto do APF como do Proposta ficaram longe do Real. Este fato foi explicado anteriormente no item 4.8.2, onde foi identificado que o sistema foi construído por uma equipe altamente especializada de consultores e foi inferido que, talvez neste caso, o fator de produtividade tenha sido subestimado. Para este caso foi utilizado um procedimento de substituição para pontos atípicos a fim de não se perder a observação e que também não interferisse nos resultados, ou seja, substituiu-se os pontos pela média de cada tratamento respectivamente. Na tabela 4.8 são demonstrados os cálculos estatísticos ou estatística descritiva. Estes cálculos têm como objetivo descrever a amostra e embasar os cálculos necessários para posterior análise da variância (ANOVA) e teste de Tukey. Na tabela são apresentados os seguintes valores: N - considerado o tamanho da amostra. Média - definida como a soma de todos os valores da população dividido pelo número do tamanho da amostra. Desvio padrão – que é a raiz quadrada da variância. Mostra quanto, em média, os valores estão afastados da média da série estatística. Erro padrão – que é o desvio padrão da população de médias amostrais Intervalo de confiança - intervalo centrado na estimava pontual, cuja probabilidade de conter o verdadeiro valor do parâmetro é igual ao nível de confiança. Em pesquisas eleitorais, trabalha-se, via de regra, com um intervalo da ordem de 95%. A amplitude do Intervalo de confiança está relacionado com a precisão desejada. 40 Valores mínimos e máximos da amostra estudada. Software comercial que possui um conjunto de ferramentas estatísticas 93 Tabela 4.8 - Estatísticas descritivas Estatísticas Descritivas Tratamentos N Média Desvio Padrão Erro Padrão 95% Intervalo de confiança para a média Limite Inferior Limite Superior Mínimo Máximo Tempo Real 10 7,6000 4,9822 1,5755 4,0360 11,1640 1,50 19,00 Tempo Apf 10 3,2336 1,5309 0,4841 2,1385 4,3287 0,53 4,94 Tempo Proposta 10 7,1051 2,9435 0,9308 4,9994 9,2108 1,84 10,45 Total 30 5,9796 3,8810 0,7086 4,5304 7,4288 0,53 19,00 Aplicação da ANÁLISE DE VARIÂNCIA – ANOVA Para efetuar o teste da hipótese citado anteriormente, foi efetuada a análise utilizando a ANOVA. Conforme já descrito, uma ANOVA permite estabelecer se as médias das populações em estudo são, ou não são, estatisticamente iguais. Primeiro foi definido o nível de significância41 a ser aplicado. Segundo Vieira (1999, p.38) a escolha do nível de significância é arbitrária e quando se escolhe o nível de significância 5%, é usual afirmar que o resultado é significante. Foi definido, então, nesta análise, o nível de significância de 5%. Foi necessário estudar as causas de variação. Existem duas explicações para os dados variarem. Uma explicação é o fato das amostras provirem de populações diferentes (tempo real, tempo estimado APF e tempo estimado Proposta). Outra explicação é o acaso, porque mesmos dados, provenientes da mesma população, também variam. Além de definir as causas de variação, para se comparar mais de duas médias é necessário aplicar o p-valor42. Nesta análise foi utilizado o cálculo do p-valor para rejeitar a Hipótese nula em favor da Hipótese alternativa. O teste p-valor é fornecido por programas estatísticos de computador e neste teste se oferece a possibilidade do valor do teste t43 ser, na distribuição teórica, maior que o valor 41 Nível de significância é definido como a probabilidade de cometer o erro de tipo I, ou seja, rejeitar a hipótese nula (Ho), quando ela é verdadeira. 42 A estatística de p-valor avalia dados com relação a média de cada grupo, variância de cada grupo e variância ponderada, isto tudo implementado com uma distribuição teórica. 94 obtido. Então, toda a vez que o p-valor for menor que o nível de significância estabelecido (neste estudo 0,05), rejeita-se a hipótese de que as médias são iguais. Segundo Vieira (1999, p.40) é muito complicado calcular o p-valor manualmente, sem auxílio de uma ferramenta. A aplicação da ANOVA é apresentada na Tabela 4.9, onde são listados: Tratamento - representa a variação considerando fatores controlados, neste caso o tempo real, tempo estimado APF e o tempo estimado proposta. Resíduos (ou acaso) - representam a variação considerando uma série de fatores não controlados. Soma dos quadrados - representa a soma dos quadrados da amostra menos um valor de correção44. Graus de liberdade - É um conceito ligado ao número de dados disponíveis (livres) para o cálculo da estatística. No caso da Tabela de ANOVA, os graus de liberdade do grupo será igual ao número de grupos menos 1, o grau de liberdade total será igual a n-1 e o grau de liberdade do resíduo, a diferença entre esses dois. Quadrado médio - Razão da soma dos quadrados divididos pelo grau de liberdade. P-valor - avalia dados com relação à média de cada grupo, variância de cada grupo e variância ponderada, isto tudo implementado com uma distribuição teórica Todos os dados calculados servem para cálculo do p-valor e também serão utilizados na aplicação do teste de Tukey. Tabela 4.9 - Aplicação da ANOVA Soma de Quadrados Graus de Liberdade Quadrado Médio p-valor Tratamentos 114,330 2 57,165 ,017 Resíduos 322,471 27 11,943 Total 436,801 29 Pode ser observado na Tabela 4.9 que o p-valor = 0,017 é bem pequeno. Quanto menor o p-valor, maior a evidência contra H0, o que leva a rejeitar a Hipótese nula em favor da Hipótese alternativa. Além disto, o p-valor é menor que o nível de significância determinado para a análise (0,05). Logo, existe pelo menos uma média estatisticamente diferente. Uma ANOVA permite estabelecer se as médias das populações em estudo são, ou não são, estatisticamente iguais. No entanto, esse tipo de análise não permite detectar quais são as 43 Teste t – teste mais utilizado para comparar médias. É baseado no nível de significância, na média de cada grupo, na variância de cada grupo e na variância ponderada. 44 Valor de correção é dado pelo total geral da amostra elevado ao quadrado dividido pelo número de observações. 95 médias estatisticamente diferentes das demais. Por exemplo, a ANOVA apresentada na Tabela 4.9 mostrou que as médias das populações não são iguais, mas não permite concluir qual é, ou quais são as médias diferentes das demais. Aplicação do Teste Tukey HSD Para verificar quais médias diferem entre si foi utilizado o teste Tukey HSD, apresentado na Tabela 4.10. Conforme citado anteriormente o teste de Tukey permite estabelecer a diferença mínima significante, ou seja, a menor diferença de médias de amostras que deve ser tomada como estatisticamente significante, em determinado nível. O teste de Tukey é realizado considerando: o quadrado médio do resíduo da análise da variância, o número de repetições de cada tratamento e um valor dado em tabela. O valor de Tukey foi calculado pelo programa estatístico utilizado e foi obtido o valor da menor diferença significante(Tukey) de 3,2325. De acordo com o teste de Tukey, duas médias são estatisticamente diferentes toda a vez que o valor absoluto da diferença entre elas for igual ou maior ao valor da menor diferença significante (Tukey). Conforme pode ser observado na Tabela 4.10, os valores absolutos das diferenças entre as médias estão apresentados na coluna Diferença entre as medias (I-J). E é fácil verificar que a diferença absoluta entre o Tempo real e Tempo APF (4,3664) e o Tempo Proposta e Tempo APF (3,8715) são superiores ao valor de Tukey (3,2325), ou seja, são estatisticamente diferentes, considerando o nível de significância de 0,05. Tabela 4.10 - Testes de Tukey - Comparação Múltipla Teste de Tukey HSD - Comparação Múltipla Variáveis (I)Tratamento Tempo Real Tempo Proposta (J)Tratamento Diferença Entre as Médias (I-J) Erro Padrão Tempo Apf 4,3664(*) 1,5455 Tempo proposta 0,4949 Tempo Apf 3,8715(*) 95% Intervalo de confiança Sigcalc. Limite Inferior Limite Superior 0,023 0,5344 8,1984 1,5455 0,945 -3,3371 4,3269 1,5455 0,047 3,947E-02 7,7035 (*) A diferença entre estas médias é significante (superior ao Tuckey) ao nível de significância de 0.05. Na Tabela 4.11, para melhor visualização, foram definidos dois subgrupos homogêneos com os respectivos tamanhos das amostras e médias. Conforme pode ser 96 observado, o primeiro subgrupo possui somente o tratamento Tempo de APF, que conforme a Tabela 4.10 foi identificado como estatisticamente diferente. No segundo subgrupo estão os tratamentos Tempo proposta e Tempo real, subgrupos identificados na Tabela 4.10 como estatisticamente semelhantes. As medidas homogêneas estão no mesmo subgrupo e, neste caso, possuem valor bem aproximado. Tabela 4.11 - Subgrupos Homogêneos Tukey ª Tratamentos N Subgrupos para α45 = 0.05 Médias Médias Tempo Apf 10 Tempo proposta 10 7,1051 Tempo Real 10 7,6000 3,2336 Médias homogêneas estão no mesmo subgrupo. ª Média Harmônica para amostra N = 10. Com base no que foi analisado e nas Tabelas 4.10 e 4.11, pode-se concluir que a média da estimativa de Tempo APF difere das outras duas. Em contrapartida, a média da estimativa de Tempo proposta é igual estatisticamente ao Tempo real, o que leva a concluir que a melhor ferramenta de medição para Sistemas de Data Mart é o Tempo Proposta calculado com base na proposta elaborada neste trabalho. 4.9 CONSIDERAÇÕES DO CAPÍTULO Esse capítulo apresentou a proposta de medição para sistemas de Data Mart. Inicialmente foram analisadas as peculiaridades desse contexto, identificando diferenças, com relação a sistemas transacionais, tanto nos objetivos do sistema como no processo de construção e tratamento de dados. A partir da observação de que a construção de sistemas de Data Mart possui diferenças substanciais da construção de um software transacional foi iniciada uma investigação de medição de tamanho para este contexto. Foi elaborada uma breve descrição das métricas estudadas APF, COSMIC e Santillo e suas vantagens e desvantagens em relação ao contexto de Data Mart. 45 Nível de significância 97 No que diz respeito a APF, as principais desvantagens para aplicabilidade da métrica ao contexto de Data Mart seriam a não-visualização por parte do usuário final de processos como o ETL e a inadequação das características gerais de sistema. As principais desvantagens da abordagem COSMIC são uma necessidade de um maior amadurecimento da métrica, aplicação em projetos de Data Mart para verificar sua adequabilidade e a criação de repositórios de produtividade com relação a essa nova unidade de medida. A proposta de Santillo gera alguns questionamentos como a mescla de duas métricas diferentes, a não utilização das características gerais de sistema e, o fato de sua aplicação em 3 projetos de Data Mart, o que a caracterizou como não adequada. Foi justificada a escolha da APF como métrica a ser adequada para Data Mart, por ser uma métrica mais madura e, também, por possuir um repositório de dados sobre fatores de produtividade, o que facilita a sua aplicabilidade em organizações que não utilizam métrica e nem possuem uma base histórica de produtividade. Foi apresentada detalhadamente uma proposta de adequação para Data Mart seguindo cada fase de contagem definida pela abordagem APF. Para a fase inicial (Estabelecer o objeto da contagem) e final (Calcular pontos de função não-ajustados e Determinar pontos de função ajustados) não foram sugeridas alterações. Para as demais fases (Determinar fronteira de medição, Contar funções de dados e suas complexidades, Contar funções de transações e suas complexidades e Determinar os fatores de ajuste) foram sugeridas adaptações à métrica de forma a torná-la mais aderente ao contexto de Data Mart. A proposta de adequação e a métrica da APF foram aplicadas em 11 projetos reais de 3 instituições públicas federais. Foram analisados os resultados e identificados padrões. O resultado dessa investigação gerou indicativos de que as propostas existentes não são adequadas e que uma adequação da abordagem APF é necessária para uma mensuração de tamanho de software mais adequada e confiável para Data Mart. A adequação e a medição de 11 projetos reais mostrou resultados promissores. Sabe-se que são necessárias mais aplicações da abordagem proposta para confirmar a sua melhor adequabilidade para projetos de Data Mart, mas esse pode ser o ponto de partida para a solução do problema de mensurar tamanho de software para sistemas de Data Mart. 98 CAPÍTULO 5 - CONCLUSÕES E TRABALHOS FUTUROS ____________________________________________________________________________ Uma das maiores dificuldades encontradas pela gestão de projetos é estimar o porte do que está sendo construído. Existem muitas abordagens para mensurar o tamanho de um software e não existe uma abordagem que seja melhor que outra, sob todos os aspectos, em qualquer situação. A abordagem de mensuração de tamanho deve ser escolhida e/ou adequada dependendo das características particulares do sistema que se pretenda desenvolver ou do problema que se pretenda solucionar (CALAZANS, OLIVEIRA e SANTOS, 2003) (Apêndice D). Sistemas de Data Warehouse/Data Mart propõem uma nova visão no processo de desenvolvimento. Diferentemente dos sistemas transacionais, o processo de construção é mais complexo, especializado e com características específicas desse tipo de software. Isso requer que outros processos, como os processos de medição (atualmente voltados para sistemas transacionais), que interagem com o processo de construção de forma a viabilizar um melhor gerenciamento do processo de construção de um software, sejam adaptados de forma a garantir o gerenciamento adequado de recursos, custos e tempo. Com essa motivação em mente, esta dissertação teve por objetivo a definição de uma proposta de mensuração de tamanho para Projetos de Data Mart e os seguintes objetivos específicos foram elaborados: (i) Estudar as características principais de sistemas de Data Mart/Data Warehouse, identificando aspectos diferenciados em relação aos sistemas transacionais; (ii) Estudar algumas abordagens de métricas de tamanho existentes, analisar sua aplicabilidade a este contexto e identificar a melhor alternativa para adequação à tecnologia de Data Mart; (iii) Propor a adequação de uma das abordagens de métricas de tamanho para projetos de Data Mart; (iv) Utilizar e avaliar a nova adequação em projetos de Data Mart; (v) Comparar os resultados da aplicação desta proposta de adequação com os resultados da abordagem escolhida. Para atender a esses objetivos foram estudadas as principais características da tecnologia Data Mart/Data Warehouse e identificadas as principais diferenças com relação aos sistemas transacionais. Foram estudadas algumas abordagens de métricas de tamanho existentes, seus pontos fortes e as críticas existentes. Dessa forma atende-se aos objetivos (i) e (ii). 99 Para o objetivo (iii), foi definido um modelo de proposta de adequação de métrica de tamanho para Data Mart e como premissas essenciais desse modelo de medição proposto colocamos: (1) adequação ao contexto de Data Mart e (2) a possibilidade de ser utilizado em todas as etapas do processo de construção de um Data Mart. As abordagens de métricas de tamanho foram estudadas e foi definida a APF como a mais indicada a ser adequada para o contexto de Data Mart. A abordagem APF possui maior maturidade tanto no meio acadêmico como na indústria, pois é uma das abordagens mais utilizadas e estudadas atualmente (Garmus e Herron, 2000, p. xvi). Apesar das críticas quanto à sua adequabilidade a diversos tipos de software, existem bases de produtividade histórica de mercado, o que facilita a sua aplicabilidade em organizações que não utilizam métrica e nem possuem uma base histórica de produtividade. Na proposta de adequação, que manteve conformidade com os padrões da APF, os mesmos passos de contagem foram mantidos, foram indicadas novas formas de pontuar as funções de dados e transações e foram criadas novas características gerais de sistemas. A proposta de adequação elaborada causa impacto na contagem de pontos de função, melhora o entendimento e aplicabilidade da métrica. Para atender aos objetivos (iv) e (v), a proposta de adequação foi aplicada em alguns projetos de três instituições públicas federais. Foram efetuadas análises para verificar a adequabilidade da proposta a esse contexto. Ao longo do estudo de casos reais, foi demonstrado que nossa proposta aplicada a projetos de Data Mart garantiu uma melhor representação do tamanho do sistema, o que mostra evidências ou dá indícios de sua melhor adequação para este contexto. Além desse benefício, foram identificadas outras contribuições desta dissertação: a adequação de uma métrica existente para o contexto de Data Mart; a aplicação e avaliação de uma métrica existente (APF) considerando o contexto de Data Mart em projetos reais em três instituições estudadas; e, a aplicação e avaliação de uma proposta de adequação já existente (Santillo, 2001) também nesse contexto, em projetos reais de uma das instituições analisadas. Contudo, a utilização prática no contexto dessas três instituições em que os projetos de Data Mart foram avaliados, permitiu identificar alguns pontos que requerem melhorias e que poderão ser alvos de trabalhos futuros: A abordagem foi utilizada somente para projetos de desenvolvimento de Data Mart. Contudo sua adequação a projetos de manutenção necessita ser verificada 100 por meio de aplicação em outros projetos, de forma a enriquecer ou mesmo validar a adequação; A experiência com o sistema S2I1 (único modelo que utiliza o esquema flocos de neve) mostrou a necessidade de aplicação em outros projetos, de forma a enriquecer ou mesmo validar a adequação; A experiência com o sistema S1I7 (único modelo pontuado no início do processo de desenvolvimento), demonstrou a necessidade de aplicação em outros projetos no início do processo de desenvolvimento de forma a enriquecer ou mesmo validar a adequação; A abordagem proposta não possui nenhum ferramental de apoio à mensuração de projetos nessa tecnologia e a construção desse é importante, como forma de registrar uma base histórica de produtividade para essa tecnologia. Alguns temas interessantes para pesquisa também podem ser derivados a partir de dessa proposta: Investigar outras tecnologias e domínios que necessitam ser mensurados e verificar a adequabilidade das métricas existentes para esses domínios e tecnologias; Aplicar esta abordagem em um número maior de projetos de Data Mart; e, Expandir a aplicação das métricas para as demais categorias de projetos envolvendo a área de BI (Bussiness Intelligence) como um todo, ou seja, abordar os aspectos da construção de Data Warehouse corporativo, analisando as diversas estratégias para a sua arquitetura, ambientes de integração e as variações no conceito do datawarehouse, como Active Data Warehouse, Real-time Data Warehouse, entre outros. Desenvolver uma metodologia para criação de métricas mais adequadas visando possíveis mudanças de tecnologia e domínio. 101 REFERÊNCIAS BIBLIOGRÁFICAS ____________________________________________________________________________ ABRAN A., SYMONS C., OLIGNY S. An Overview of COSMIC –FFP field trial results. In: ESCOM-SCOPE. Londres, 2001. ABRAN, A., DESHARNAIS, J., OLIGNY, S., ST-PIERRE, D., SYMONS C. Cosmic FFP Measurement Manual. v. 2.2, Ed. S.Oligny, Software Engineering Management Research Laboratory. Université du Quebec a Montreal. Canada, 1999. AGARWAL, R., KUMAR, M., YOGESH, MALLICK, S., BHARADWAJ, R. , ANANTWAR, D. Estimating software projects. ACM SIGSOFT. p.60-67, Jul, 2001. AGUIAR, Maurício. Estimando os projetos com Cocomo II no RUP. Developers Magazine. Set/2002. ALLISON, Bryan. Targeting ETL Success. DM Review, Mai 2001. BARBIERI, C. BI-Business Intelligence – Modelagem & tecnologia. Rio de Janeiro: Axcel Books do Brasil Editora, 2001. BATENBURG, F., RIDDER, E., KERF, J. APL Extended compared with other languages according to Halstead´s theory. ACM Sigplan Notices. 33(6), p. 54-60, 1998. BELLATRECHE, L., KARLAPALEM, K. What can partitioning do for your Data warehouses and Data Marts? In: International Database Engineering and applications symposium (IDEAS’00). IEEE, 2000. BERSON, A., SMITH, S. Data Warehousing, data mining, and OLAP. EUA: McGrawHill, 1997. BEVO, V., LEVESQUE, G., ABRAN, Alain. Application de la methode FFP a partir d’une specification selon la notation UML: Compte rendu des premiers essais d’apllication et questions. In: International Workshop on Software Measurement. Canada, 1999. 102 BEVO, V., LEVESQUE, G., ABRAN, Alain. Application de la methode FFP a partir d’une specification selon la notation UML: Compte rendu des premiers essais d’apllication et questions. In: International Workshop on Software Measurement(IWSM’99). Canadá, p.230-242, 1999. BOOTSMA, F. How to obtain accurate estimates in a real-time environment using full functions points. In: 3rd IEEE Symposium on Application-Specific Systems and Software Engineering Technology (ASSET'00). Estados Unidos, 2000. BOYER, Michael. Towers Perrin. Disponível no site <http://www.ascentialsoftware.com/cgibin/litlib.cgi?URL=TowersPerrin.pdf>. Acesso em 08/08/2003. BROKAW, Erik. Aquila. Disponível no site < http://www.ascentialsoftware.com/cgibin/litlib.cgi?URL=Aquila.pdf>. Acesso em 08/08/2003. CALAZANS, A. Cosmic full function points: Calculando o tamanho de software. Developers’ Magazine. Brasil, 2003. CALAZANS, A., OLIVEIRA, K., SANTOS, R. Dimensionando Data Marts :Uma adequação de uma métrica funcional. In: II Simpósio Brasileiro de Qualidade de Software, 2003. Fortaleza. Anais SBQS 2003. Fortaleza, Unifor, 2003. CHAUDHURI , S., DAYAL, U. An overview of data warehousing and OLAP technology. ACM Sigmod Record. Mar, 1997. DIAB, H., FRAPPIER, M., ST-DENIS, R. A formal definition of COSMIC-FFP for automated measurement of room specifications. Departement de Mathematiques and D’Informatique, Université de Sherbrooke. Canada, 2001. FENTON, N., NEIL, M. Software Metrics: Roadmap. Future of Software Engineering Limerick Ireland ACM. p. 359-370, 2000. FENTON, N., PFLEEGER, S. Software metrics a rigorous & practical approach. 2nd. Ed., PWS Publishing Company, 1997. 103 FIORI, Rich. Evaluating ETL Tools. BI Report, Jul, 2002. GALLAS, S. Kimball Vs. Inmon. EUA: The Thompson Corporation and DM Review. Set, 1999. GARDNER, S. Building the Data Warehouse. Communications of the ACM. Vol.41, n. 9., p. 52 – 60, Set, 1998. GARMUS, D., HERRON, D. Function point analysis – measurement practices for successful software projects. Addison-Wesley Information Technology Series, 2000. GARMUS, D., HERRON, D. Measurement the software process: a practical guide to functional measurements. Prentice-Hall, Upper Saddles River NJ, 1996. GOLFARELLI, M., RIZZI, S. Design the Data Warehouse: key steps and crucial issues. Journal of Computer Science and Information Management. vol. 2, N. 3, 1999. HACKNEY, D. Data Warehouse delivery:Who are you? DM Review. Fev, 1998. HOUAISS, A. Dicionário Houaiss da lingua portuguesa. Rio de Janeiro: Objetiva, 2001. HOUSE, Rose. The Principal Financial Group. Disponível no site <http://www.informatica.com/customers/customer+success/principal.html>. Acesso em: 08/08/2003. HUSEMANN, B., LECHTENBORGER, J., VOSSEN, G. Conceptual Data Warehouse Design. In: Proceedings of the International Workshop on Design and Management of Data Warehouse (DMDW’2000). Suécia, Jun, 2000. IFPUG. International Function Point Users Group. Function Point Counting Practices Manual: Release 4.1. Ohio: IFPUG. 2000. 1 v. INMON, Bill. The Data Warehouse Budget: Special Feature from January 1997. Portal Feature, Jan, 1997. 104 INMON, W.H., A Data warehouse development methodology. 2003. Disponível em: <www.billinmon.com/library/methods/dwmeth_frame.asp>. Acesso em 05 Mai 2003. INMON, W.H., Definition of a Data Warehouse. 1999. Disponível em: <www.billinmon.com/library/articles/dwedef.asp>. Acesso em 05 Mai 2003. INMON, W.H., Separating operational from DSS: Some criteria. 2000. Disponível em: <www.billinmon.com//library/whiteprs/earlywp/ttoperdw.pdf>. Acesso em 05 Mai 2003. INMON, W.H.., TERDEMAN, R.H., IMHOFF, C. Data Warehousing – como transformar informações em oportunidades de negócios. São Paulo: Berkeley, 2001. ISBSG. Benchmarking Repository, Release 6. ISBSG. Abr, 2002. ISO/IEC 9126-1. Software engineering – Product quality. 2001. ISO/IEC 20926. Software engineering – IFPUG 4.1 Unadjusted functional size measurement method – Counting practices manual.2003. ISO/IEC 19761. Software engineering – COSMIC-FFP -- A functional size measurement method. 2003. ISO/ IEC 20968. Software engineering – Mk II Function Point Analysis -- Counting Practices Manual. 2002. JONES, C. Applied Software Mesurement (2nd edition). McGraw-Hill, New York, 1996. KIMBALL, R., ROSS, M. Data Warehouse toolkit: o guia completo para modelagem multidimensional. Rio de Janeiro: Campus, 2002. 105 KIMBALL, R., THORNTHWAITE, W., REEVES, L.. ROSS, M., The Data Warehouse lifecycle toolkit: experts methods for designing, developing and deploying Data Warehouses. New York: John Wiley & Sons, 1998. KITCHENHAM, B., HUGHES, R., LINKMAN, S. Modeling software measurement data. IEEE Transactions on software engineering, vol. 27, no. 9, p.788-805, 2001. KITCHENHAM, B.A. Empirical studies of assumptions the underlie software cost-estimation models. Information and Software Technology, 34(4): 211-218, Abr, 1992. LOKAN, C. An empirical analysis of function point adjustment factors. Information and software Technology, Fev, 2000. LOKAN, C., ABRAN, A. Multiple viewpoints in functional size measurement. In: International Workshop on Software measurement - IWSM’99. Canada. p. 121132, 1999. MACHADO, F. Projeto de Data Warehouse – uma visão multidimensional. São Paulo: Erica, 2000. McKENDRICK, J. Make Room for the Monster Data bases. Database Trends and Applications, vol. 15, n. 12, Dez, 2002. MACMILLAN, Hugh. Enbridge Inc., Distribution and services division. Disponível no site <http://www.ascentialsoftware.com/cgi-bin/litlib.cgi?URL=enbridge-profile.pdf>. Acesso em: 08/08/2003. MCT, Ministério da Ciência e Tecnologia .Qualidade e produtividade no setor de software brasileiro. 2002. MENDES, E., MOSLEY, N., COUNSELL, S. Web metrics – estimating design and authoring effort. Web Engineering, IEEE, 2001. MEYER, Steven. Which ETL Tool is Right for You. DM Review. Mar 2001. 106 MICHAEL, J., BOSSUYT, B., SNYDER, B. Metrics for measuring the effectiveness of software-testing tools. In: Proceedings of the 13 th International Symposium on Software Reliability Engeneering (ISSRE’02). IEEE Computer Society, 2002. MK II FPA. United Kingdom Software Metrics Association UKSMA. MKII Function Point Analysis Counting Practices Manual: Version 1.3.1. Reino Unido, 1998. MOODY, D., KORTINK, M. From Enterprise Models to Dimensional Models: A Methodology for Data Warehouse anda Data Mart Design. In: Proceedings of the International Workshop on Design and Management of Data Warehouses (DMDW), Suécia, p. 5-1/5-12, Jun, 2000. MRAZEK, Jan. ETL: The best-Kept Secret of Success in Data Warehousing. DM Review, Jun 2003. OLIGNY, S., ABRAN, A. On the compatibility between full function points and IFPUG function points. In: Proceedings of the 10th European Software Control and Metric Conference – ESCOM, Inglaterra, 1999. OLIGNY, S., BOURQUE, P., ABRAN, A., FOURNIER, B. Devoloping project duration models in software engineering. The journal of systems and Software, 2002. PAIM, F. Uma metodologia para definição de requisitos em sistemas de Data Warehouse. Dissertação de Mestrado. Universidade Federal de Pernambuco. Recife, 2003. PFLEEGER, S. Use realistic, effective software measurement. Software quality institute series. USA , p. 210-235, 2000. PFLEEGER, S., JEFFERY, R., CURTIS, B., KITCHENHAM, B. Status report on software measurement. IEEE Software, p.33-38, Mar, 1997. PHADKE, M.S., Quality Engineering Using Robust Design. Prentice Hall, Englewood Cliffs New Jersey, 1989. 107 POE, V. Building a Data Warehouse for decision support. New Jersey: Prentice Hall PTR, 1996. PORTER, J., ROME, J. Lessons from a Successful Data Warehouse Implamentation. Arizona: Cause/Effect, p. 43-50, 1995. SANTANA, S. Desenvolvendo Data Mart utilizando a Análise por pontos de função: uma proposta para integração entre sistemas transacionais e sistemas de apoio à decisão. 2001. Dissertação (Mestrado Engenharia da Produção) – Programa de PósGraduação em Engenharia de Produção, UFSC, Florianópolis. SANTILLO, L. Size & estimation of data warehouse systems. In: The European Software Measurement Conference – FESMA/DASMA. Alemanha , 2001. SIMÕES, C. Sistemática de Métricas, qualidade e produtividade. Developers’ Magazine, Brasil, 1999. STUTZKE, R. Predicting Estimation Accuracy. In: The European software control and metrics conference – ESCOM, Alemanha, p. 211 – 220, 2000. SYMONS, Charles. Come back function point analysis (modernised) – all is forgiven!. In: The 4th European Conference on Software Measurement and ICT Control FESMA – DASMA. Alemanha, p. 1-12, 2001. VAVOURAS, A., GATZIU, S., DITTRICH, K. Modeling and executing the Data Warehouse refreshment process. In: International Symposium on Database Applications in Non traditional Environments. IEEE, 1999. VIEIRA, S. Estatistica Experimental. 2.ed, São Paulo: Atlas. 1999. WATTERSON, K. Second-Generation Data Warehouse. SunExpert Magazine, EUA, p. 5865, 1998. 108 WITTIG, G., MORRIS, P., FINNIE, G., RUDOLPH, E. Formal methodology to establish function points coefficientes. School of Information Technology. Australia, [1997?]. WOHLIN,C., RUNESON,P., HOST,M.,OHLSSON, M.,REGNELL, B., WESSLEN, A. Experimentation in Software Engineering An Introduction. Kluwer Academic Publishers. Londres, 2000. 109 APÊNDICE A - ENTREVISTA ESTRUTURADA PARA LEVANTAMENTO DOS DADOS DOS SISTEMAS ___________________________________________________________________________ Esse apêndice lista as questões da entrevista estruturada realizada com todos os responsáveis por projetos de Data Mart das empresas pesquisadas ___________________________________________________________________________ Empresa: Nome do responsável: Data: ___________________________________________________________________________ Qual o nome do sistema que será mensurado? Descrever objetivos gerais. Será um módulo? Descrever. Como funciona a arquitetura de Data Warehouse/Data Mart na empresa? Qual a linguagem utilizada e qual o banco de dados? A empresa já utiliza algum processo de medição? A empresa utiliza alguma ferramenta de ETL? Quantas pessoas o projeto envolveu? Tempo integral ou parcial? Durante quanto tempo? Quantas tabelas fatos e dimensões? Qual a quantidade de atributos de cada uma? Existem funções de consultas e relatórios? Aplicar as características gerais do sistema. Utilizar formulário anexo. 110 APÊNDICE B - CARACTERÍSTICAS GERAIS ADEQUADAS A TECNOLOGIA DE DATA MART ___________________________________________________________________________ Esse apêndice lista as Características Gerais do Sistema adequadas a tecnologia de Data Mart. Este dados foram coletados junto aos responsáveis por projetos de Data Mart das empresas pesquisadas ___________________________________________________________________________ Características gerais 1 0. Influência O aplicativo não auxilia na transferência de dados ou funções entre os processadores Processamento distribuído de dados Aspectos relacionados com processamento e funções distribuídas. Item de Níveis de influência envolvidos; 1. O aplicativo prepara dados para que o usuário Comentários: final os utilize em outro processador (planilhas Leitura via client ou via Internet ou de cálculo, por exemplo); Intranet pode receber o valor 2 a 4. 2. O aplicativo prepara dados e os transfere para que outros equipamentos os utilizem; 3. O processamento é distribuído e a transferência de dados acontece de forma on-line apenas em uma direção; 4. O processamento é distribuído e a transferência de dados acontece de forma on-line em ambas as direções; 5. As funções de processamento são dinamicamente executadas no equipamento mais apropriado. 2 0. requerimento especial de performance foi solicitado pelo usuário; Desempenho/Performance Aspectos relacionados a parâmetros Nenhum 1. Requerimentos de foram performance estabelecidos pelo usuário quanto a estabelecidos e revistos, mas nenhuma ação tempos de resposta. especial foi requerida; 2. Tempo de resposta e volume de processamento são itens críticos durante horários de pico de processamento. Porém, nenhuma determinação especial foi estabelecida quanto à utilização do processador. A data limite para a disponibilidade do processamento é sempre o próximo dia útil; 3. Tempo de resposta e volume de processamento são itens críticos durante todo o horário comercial. Não há determinação 111 Características gerais Item de Níveis de influência Influência especial para a utilização do processador. A data limite para a comunicação com outros aplicativos é um item importante e deve ser considerado. 4. quando, além do descrito no item 3, os requisitos de performance estabelecidos requerem tarefas de análise de performance na fase de análise e desenho do aplicativo. 5. quando, além ferramentas de do descrito análise de no item 4, performance precisam ser usadas nas fases de desenho, desenvolvimento ou mesmo na fase de implementação para que os requisitos do usuário sejam atendidos plenamente. 0. 3 Utilização de ferramenta Indica o nível de processo de extração/transformação/carga; apropriada 1. para extração e carga automatização e complexidade do processo de Data Mart quando é utilizada ferramenta para 100% do quando é utilizada ferramenta para até 80% do processo de extração/transformação/carga 2. quando é utilizada ferramenta para até 60% do processo de extração/transformação/carga; 3. quando é utilizada ferramenta para até 40% do processo de extração/transformação/carga; 4. quando é utilizada ferramenta para até 20% do processo de extração/transformação/carga; 5. quando nenhuma ferramenta é utilizada para extração/transformação/carga dos dados 1 sistema transacionais 4 0. Não se aplica Quantidade de sistemas transacionais 1. quando Descreve o grau em que a quantidade de influenciará com o projeto envolve transacional; envolvidos no projeto interfaces o outros sistemas desenvolvimento da aplicação. Quando a quantidade de sistemas transacionais é alto, influencia o projeto, desenvolvimento, implantação e suporte 2. quando o projeto envolve de 2 a 3 sistemas transacionais; 3. quando o projeto envolve de 4 a 5 sistemas transacionais 4. quando o projeto envolve de 6 a 7 sistemas transacionais; 5. quando o projeto envolve mais de 8 sistemas da aplicação. transacionais. 5 0. quando todos os sistemas de origem possuem 112 Características gerais Documentação Item de Níveis de influência dos Influência metadados; sistemas 1. transacionais de origem (Existência de Metadados dos sistemas de origem) quando acima de 90% dos sistemas de origem possuem meta dados; Nível de documentação dos sistemas de 2. origem, de forma a identificar a existência quando acima de 70% dos sistemas de origem possuem metadados; de metadados dos dados de origem. 3. quando acima de 50% dos sistemas de origem possuem metadados; 4. quando acima de 30% dos sistemas de origem possuem metadados; 5. quando nenhum dos sistemas de origem possui metadados; 6 0. nenhum nível de agregação identificado; Quantidade de agregação substituindo 1. Um nível de agregação identificado; Eficiência do usuário final 2. De dois a três quantidades de agregação Definição dos níveis de agregação identificadas; necessários de forma a melhorar o 3. desempenho das consultas do usuário De quatro a cinco quantidades de agregação identificadas; final 4. Seis ou sete quantidades de agregação identificadas; 5. Oito ou mais quantidades de agregação identificadas. 0. 7 atualizações dos arquivos de extração /carga; Freqüência de atualização das fontes de dados 1. Descreve o grau em que os sistemas quando houver atualizações de 10% a 20% dos arquivos de extração /carga; transacionais são alterados implicando em constantes alterações nas aplicações quando houver previsão de 0% a 10% de 2. de quando houver atualizações de 20% a 30% dos arquivos de extração /carga; extração e carga. 3. quando houver atualizações de 30% a 40% arquivos de extração /carga; 4. quando houver atualizações de 40% a 50% dos arquivos de extração /carga; 5. quando houver atualizações de mais de 50% arquivos de extração /carga. 8 Ao considerar as características da aplicação verificar a Qualidade dos dados em substituição ao necessidade de aplicabilidade dos seguintes itens: Processamento complexo - Integração – envolve a geração de chaves Descreve o grau previsto para tratamento substitutas para cada registro, de modo a evitar a de exceções identificadas inicialmente dependência de chaves definidas no sistema legado; com relação à qualidade de dados, dados - Limpeza – correção de códigos e caracteres 113 Características gerais Item de Níveis de influência rejeitados, erro de conteúdo, etc. Influência especiais, resolvendo problemas de domínios, tratando dados perdidos e corrigindo valores duplicados ou errados; - Eliminação – eliminar campos e dados provenientes dos sistemas legados que não serão úteis ao Data Mart. - Combinação – realizada quando fontes de dados possuem os mesmos valores de chaves representando registros iguais ou complementares ou atributos de chaves não iguais, incluindo equivalência textual de códigos de sistemas legados distintos; - Verificação de integridade referencial – significa verificar se os dados de uma tabela são iguais aos dados correspondentes em outra tabela - Desnormalização e renormalização – consiste em reunificar as hierarquias de dados, separadas pela normalização dentro de uma tabela desnormalizada; - Conversão de tipo de dados – envolve transformação de baixo nível de forma a converter um tipo de dado em outro formato - Cálculos, derivação e alocação - são transformações a serem aplicadas sobre as regras de negócio identificadas durante o processo de levantamento de requisitos; - Auditoria no conteúdo dos dados – o processo de transformação deve realizar constantes verificações de somas, contagem de linhas e testes. Tem-se: 0. quando não ocorrer nenhuma das características acima; 1. quando ocorrer de uma a duas das características acima; 2. quando ocorrer de três a quatro das características acima; 3. quando ocorrer cinco a seis das características acima; 4. quando ocorrer sete a oito das características acima; 5. quando ocorrer todas as características acima; 114 Características gerais 0. 9 Item de Níveis de influência Influência Nenhuma preocupação com reutilização de código. Reusabilidade de código Aspectos relacionados à reutilização do 1. Reutilização de código apenas no aplicativo. código do aplicativo. 2. Menos de 10% do código do aplicativo foi projetado para ser utilizado em outros aplicativos. 3. 10% ou mais do código do aplicativo foi escrito para ser utilizado em outros aplicativos. 4. O código do aplicativo foi projetado para ser utilizado em outros aplicativos. A customização deve ser realizada em nível de código-fonte. 5. O código do aplicativo pode ser reutilizado em outros aplicativos com alto grau de parametrização. É apenas necessário que o usuário altere determinados parâmetros. 10 Estrutura dos dados de origem Definição da estrutura em que estão os 0. Não se aplica; 1. quando existir uma única estrutura dos dados dados de origem, VSAM, Relacional(DB2, de origem; Sybase, Oracle), Hierárquico – IDMS). 2. quando existir duas estruturas dos dados de origem; 3. quando existir três estruturas dos dados de origem; 4. quando existir quatro estruturas dos dados de origem; 5. 11 Facilidade operacional 0 quando existir mais de quatro estruturas. Nenhuma consideração especial de operação além do processo normal de salvamento de dados; Aspectos relacionados com a facilidade de 1 a 4: quando um ou todos os itens seguintes se operação do aplicativo. Avalia procedimentos aplicarem (selecionar todos os que se aplicam; cada operacionais automáticos e mecanismos de item soma um ponto): iniciação, salvamento e recuperação de dados. Foram desenvolvidos procedimentos de iniciação, salvamento e recuperação, mas a intervenção do operador é necessária; Foram desenvolvidos procedimentos de iniciação, salvamento e recuperação, sem a necessidade de intervenção do operador (vale dois 115 Características gerais Item de Níveis de influência Influência itens); O aplicativo minimiza a necessidade de a necessidade de montagem de fita magnética; O aplicativo minimiza manuseio de papel; 5 O aplicativo foi desenhado para trabalhar sem operador. Nenhuma intervenção do operador é necessária além de iniciar e encerrar o aplicativo porque este já contém rotinas automáticas de recuperação de erros. 12 Volume de dados 1 Baixo (até 500 gigabytes) Previsão do volume de dados do projeto 3. Médio (de 500 gigabytes a 1 terabyte) O volume de dados interfere no tamanho e 5. Alto (acima de 1 terabyte) deve ser previsto visando garantir performance 13. Nível de conhecimento exigido pela equipe de Data Mart da base de 1 Pouco conhecimento da equipe de Data Mart das dados/regras de negócio dos sistemas regras de negócio dos sistemas transacionais transacionais de origem 3 Médio conhecimento da equipe de Data Mart (Vinculada à existência de ferramenta ETL, das regras de negócio dos sistemas transacionais pois a existência obriga a equipe de Data 5 Alto conhecimento da equipe de Data Mart das Mart a conhecer todas as regras de negócio regras de negócio dos sistemas transacionais transacional e definir outras formas de extração). 116 APÊNDICE C - CARACTERÍSTICAS GERAIS APF ___________________________________________________________________________ Esse apêndice lista as Características Gerais do Sistema da abordagem APF. Este dados foram coletados junto aos responsáveis por projetos de Data Mart das empresas pesquisadas. ___________________________________________________________________________ Características gerais 1 Comunicação de dados Aspectos relacionados aos Níveis de influência recursos utilizados na comunicação de dados do aplicativo. É importante determinar que protocolos são utilizados pelo aplicativo para o recebimento ou envio de informações. 2 Processamento distribuído de dados Aspectos relacionados com processamento e funções distribuídas. Comentários: Leitura via client ou via Internet ou Intranet pode receber o valor 2 a 4. 3 Desempenho/Performance Aspectos relacionados a parâmetros estabelecidos pelo usuário quanto a tempos de resposta. 0 Aplicativo batch ou stand alone; 1 Aplicativo batch com entrada ou saída de dados remota; 2 Aplicativo batch com entrada de dados e saída de dados remotas; 3 Aplicativo com entrada de dados on-line para alimentar processamento batch; 4 Aplicativo com entrada de dados on-line, suportando apenas um tipo de protocolo de comunicação; 5 Aplicativo com entrada de dados on-line, suportando vários tipos de protocolo. 0 Aplicativo não auxilia na transferência de dados ou funções entre os processadores envolvidos; 1 Aplicativo prepara dados para que o usuário final os utilize em outro processador (planilhas de cálculo, por exemplo); 2 Aplicativo prepara dados e os transfere para que outros equipamentos os utilizem; 3 Processamento é distribuído e a transferência de dados acontece de forma on-line apenas em uma direção; 4 Processamento é distribuído e a transferência de dados acontece de forma on-line em ambas as direções; 5 As funções de processamento são dinamicamente executadas no equipamento mais apropriado. 0 Nenhum requerimento especial de performance foi solicitado pelo usuário; 1 Requerimentos de performance foram estabelecidos e revistos, mas nenhuma ação especial foi requerida; 2 Tempo de resposta e volume de processamento são itens críticos durante horários de pico de processamento. Porém, nenhuma determinação especial foi estabelecida quanto à utilização do processador. A data limite para a disponibilidade do processamento é sempre o próximo dia útil; 3 Tempo de resposta e volume de processamento são itens críticos durante todo o horário comercial. Não há determinação especial para a utilização do processador. A data limite para a comunicação com outros aplicativos é um item importante e deve ser considerado. 4 quando, além do descrito no item 3, os requisitos de performance estabelecidos requerem tarefas de análise de performance na fase de análise e desenho do aplicativo. 5 quando, além do descrito no item 4, ferramentas de análise de performance precisam ser usadas nas fases de desenho, desenvolvimento ou mesmo na fase de implementação para que os requisitos do usuário sejam atendidos plenamente. Item de Influência 117 Características gerais Níveis de influência 4 Utilização do equipamento Aspectos relacionados com o nível 0 Não há restrições operacionais 1 Existem poucas restrições de caráter operacional; não há necessidade de esforço adicional para implementar o aplicativo. 2 Algumas considerações de ajuste de performance e de segurança precisam estar implementadas 3 Existem especificações especiais que precisam ser observadas para módulos específicos do aplicativo. 4 O aplicativo requer cuidados especiais no processador central ou dedicado 5 O aplicativo requer cuidados especiais no processador central ou dedicado. Existem considerações que exigem a utilização de ferramentas de análise de performance para que o aplicativo e os seus componentes sejam implementados nas unidades processadoras. 0 Não há previsão de períodos com grande volume de transações; 1 Estão previstos grandes volumes de transações mensais, trimestrais, anuais ou em determinado período do ano. 2 Há grande volume de transações por semana; 3 Há grande volume de transações por dia. 4 Face ao grande volume de transações, análises de performance devem ser realizadas para que o tempo de resposta do aplicativo esteja de acordo com as especificações do usuário. 5 O grande volume de transações exige análise de performance com ferramentas adequadas. 0 Todas as transações previstas no aplicativo são processadas em modo batch. 1 1% a 7% das transações são entradas de dados on-line 2 8% a 15% das transações são entradas de dados online. 3 16% a 23% das transações são entradas de dados online. 4 24%a 30% das transações são entradas de dados online. 5 Acima de 30% das transações são processadas em modo on-line. de utilização dos equipamentos necessários à execução do aplicativo. A Avaliação visa identificar a carga de trabalho exigida pelo aplicativo quando em produção 5 Volume de transações Aspectos relacionados com a capacidade do sistema em relação ao volume de transações esperado 6 Entrada de dados on-line Aspectos relacionados com a quantidade de entrada de dados on-line do aplicativo. 7 Interface com o usuário Aspectos relacionados com a eficiência do aplicativo na interação com o usuário. A pontuação é decidida quantos aos recursos implementados para tornar o aplicativo amigável. • • • • • • • • • • • Auxílio de navegação (teclas de função, acesso direto e menus dinâmicos); Menus; Documentação e ajuda on-line; Movimento automático de cursor; Movimento horizontal e vertical da tela; Impressão remota (via transações on-line); Processos batch submetidos a partir de transações on-line. Seleção de cursos em campos de tela; Utilização adequada de atributos de campos (vídeo reverso (por exemplo)); Impressão da documentação das transações online através de hard copy; Utilização de mouse; Menus pop up; Item de Influência 118 Características gerais Níveis de influência Pontuação: 0 1 2 3 Nenhum item contado; De um a três itens contados; De quatro a cinco itens contados; Mais de 5 itens contados, embora não existam requerimentos de amigabilidade expressos pelo usuário; 4 Mais de 5 itens contados, existindo requisitos do usuário que impliquem, por exemplo, minimização de digitação ou persistência de valores mais utilizados; 5 Mais de 5 itens contados, havendo requisitos do usuário que somente podem ser atendidos com a utilização de ferramentas e processos especiais. 0 Nenhuma atualização on line; 8 1 Atualização on-line de 1 a 3 arquivos lógicos Atualização on-line internos.O volume de atualizações é baixo e a Aspectos relacionados com o modo de recuperação de dados é realizada de forma simples; atualização dos arquivos lógicos internos do 2 Atualização on-line de mais de 3 arquivos lógicos aplicativo. internos. O volume de atualizações é baixo e a recuperação de dados é realizada facilmente; 3 Atualização on-line de todos (ou da maioria) os arquivos lógicos internos; 4 Atualização on-line de todos os arquivos lógicos internos, com implementação de proteção contra a perda de dados; 5 Atualização on-line de todos os arquivos internos, com implementação de proteção contra a perda de dados. Existem processos automáticos de recuperação de dados com interferência mínima do operador. 9 • Processamentos especiais de auditoria ou de Processamento complexo segurança foram considerados no desenho do Aspectos relacionados com a complexidade aplicativo. • O aplicativo trabalha com processamento lógico do processamento. Detalhes específicos extensivo; devem ser considerados para a pontuação. • O aplicativo trabalha com processamento matemático extensivo; • O processamento dos dados pode gerar exceções que resultam em transações incompletas que devem ser novamente processadas; • O aplicativo trabalha com processamento complexo para gerenciar múltiplas possibilidades de entrada e saída de dados. Pontuação: 0 Nenhum item assinalado 1 Apenas um item assinalado 2 Dois itens assinalados 3 Três itens assinalados 4 Quatro itens assinalados 5 Todos os itens assinalados. 0 Nenhuma preocupação com reutilização de código. 10 1 Reutilização de código apenas no aplicativo. Reusabilidade de código 2 Menos de 10% do código do aplicativo foi Aspectos relacionados à reutilização do projetado para ser utilizado em outros aplicativos. 3 10% ou mais do código do aplicativo foi escrito para código do aplicativo. ser utilizado em outros aplicativos. 4 O código do aplicativo foi projetado para ser utilizado em outros aplicativos. A customização deve ser realizada em nível de código-fonte. Item de Influência 119 Características gerais Níveis de influência 5 O código do aplicativo pode ser reutilizado em outros aplicativos com alto grau de parametrização. É apenas necessário que o usuário altere determinados parâmetros. 0 Nenhuma consideração especial estabelecida pelo 11 usuário. Não há procedimentos especiais requeridos Facilidade de Implantação na implantação do aplicativo. Aspectos relacionados com o grau de 1 Nenhuma consideração especial estabelecida pelo usuário, embora sejam necessários alguns dificuldade de implementação do aplicativo. procedimentos especiais na implantação do Verifica planos de conversão e de aplicativo. 2 Existem requisitos de conversão e de implementação implementação. através de roteiros estabelecidos e testados pelo usuário. O impacto da conversão do aplicativo não é relevante. 3 Existem requisitos de conversão e de implementação através de roteiros estabelecidos e testados pelo usuário. O impacto da conversão do aplicativo é de vital importância. 4 Existem requisitos de conversão e de implementação através de roteiros estabelecidos e testados pelo usuário. O impacto da conversão do aplicativo não é relevante. Conversão automática e ferramentas de implantação foram providas e testadas. 5 Existem requisitos de conversão e de implementação através de roteiros estabelecidos e testados pelo usuário. O impacto da conversão do aplicativo é de vital importância. Conversão automática e ferramentas de implantação foram providas e testadas. 0 Nenhuma consideração especial de operação além do 12 processo normal de salvamento de dados; Facilidade operacional 1 a 4: quando um ou todos os itens seguintes se aplicarem (selecionar todos os que se aplicam; cada item soma um ponto): Aspectos relacionados com a facilidade de • Foram desenvolvidos procedimentos de iniciação, operação do aplicativo. Avalia procedimentos salvamento e recuperação, mas a intervenção do operador é necessária; operacionais automáticos e mecanismos de • Foram desenvolvidos procedimentos de iniciação, iniciação, salvamento e recuperação de dados. salvamento e recuperação, sem a necessidade de intervenção do operador (vale dois itens); • O aplicativo minimiza a necessidade de montagem de fita magnética; • O aplicativo minimiza a necessidade de manuseio de papel; 5 O aplicativo foi desenhado para trabalhar sem operador. Nenhuma intervenção do operador é necessária além de iniciar e encerrar o aplicativo porque este já contém rotinas automáticas de recuperação de erros. 0 Os requerimentos do usuário não consideram a 13 possibilidade de instalação do aplicativo em mais de Múltiplas instalações (locais) Aspectos relacionados com a arquitetura um local. do aplicativo e a instalação em vários lugares. 1 A necessidade de instalar o aplicativo em vários locais foi considerada no projeto, não obstante o aplicativo ter sido desenhado para trabalhar em ambientes idênticos em hardware e software. 2 A necessidade de instalar o aplicativo em vários locais foi considerada no projeto, não obstante o aplicativo ter sido desenhado para trabalhar em Item de Influência 120 Características gerais Níveis de influência ambientes similares em hardware e software. 3 A necessidade de instalar o aplicativo em vários locais foi considerada no projeto, estando o aplicativo apto a operar em diferentes ambientes de hardware e software. 4 A necessidade de instalar o aplicativo em vários locais foi considerada no projeto, apesar do aplicativo ter sido desenhado para trabalhar em ambientes similares de hardware e software. Planos de documentação e manutenção foram providos e testados. 5 A necessidade de instalar o aplicativo em vários locais foi considerada no projeto, estando o aplicativo apto a operar em diferentes ambientes de hardware e software. Planos de documentação e manutenção foram providos e testados. 14 Facilidade de mudança Aspectos relacionados com o grau de flexibilidade do aplicativo com relação a mudanças nos requisitos do usuário. • • • Estão disponíveis facilidades como consultas e relatórios flexíveis para atender a necessidades simples; Estão disponíveis facilidades como consultas e relatórios flexíveis para atender a necessidades de média complexidade (conte dois itens); Estão disponíveis facilidades como consultas e relatórios flexíveis para atender a necessidades complexas (conte 3 itens); Dados de controle são armazenados em tabelas que são mantidas pelo usuário através de processos on-line, com mudanças se refletindo nos dias seguintes; • Dados de controle são armazenados em tabelas que são mantidas pelo usuário através de processos on-line, com mudanças se refletindo imediatamente (conte dois itens). Pontuação: 0. Nenhum item contado. 1. Um item contado 2. Dois itens contados 3. Três itens contados 4. Quatro itens contados 5. Cinco ou mais itens contados. • Item de Influência 121 APÊNDICE D - Artigo publicado no II Simpósio Brasileiro de Qualidade de Software, 2003 ___________________________________________________________________________ Esse apêndice apresenta o artigo publicado no II Simpósio Brasileiro de Qualidade de Software - Fortaleza, Unifor - 2003. ___________________________________________________________________________ Dimensionando Data Marts: Uma Adequação de uma Métrica Funcional AngélicaToffano S. Calazans Káthia Marçal de Oliveira, Caixa Econômica Federal Univ. Católica de Brasília [email protected] [email protected], Rildo Ribeiro dos Santos Univ. Católica de Brasília [email protected] Resumo Estimar o tamanho de um projeto para permitir definir prazos, custos e recursos é uma necessidade contínua das empresas. Nesse sentido, várias abordagens surgiram com o objetivo de estimar o tamanho do software, destacando-se entre elas, a Análise por Pontos de Função como uma das abordagens mais utilizadas pelo mercado atualmente. Com o surgimento da tecnologia de Data Mart e o aumento da demanda de desenvolvimento desses sistemas, as empresas passaram a exigir também estimar o tamanho desses produtos para permitir uma melhor gerência na produção dos mesmos. Sistemas de Data Mart, no entanto, possuem características próprias e particularidades no desenvolvimento diferentes dos sistemas tradicionais. Dessa forma, se faz necessário a adequação de uma das abordagens de medição de sistemas tradicionais para sistemas de Data Mart. Neste artigo, propomos uma adequação da Análise por Pontos de Função e apresentamos os resultados da aplicação desta proposta em projetos reais da Caixa Econômica Federal. Palavras Chaves: Métricas funcionais, Data Mart, estimativa de tamanho, Análise por pontos de Função. Abstract Estimate the size of a project to define time, cost and resources is a continuous necessity of the companies. In this direction, several boardings had appeared with the objective of estimate the size of software, like the Analysis for Points of Function - one of boardings more used by the market currently. With the appearing of Data Mart technology and the increase of the demand of development of these systems, the companies had started to also demand estimate of these products to allow a better management in the production of them. Data Mart systems, however, have proper characteristics and particularitities in the development different of the traditional systems. So, it makes necessary the adequacy of one of the boardings of measurement of traditional systems for Data Mart systems. In this article, we consider one adequacy of the Analysis for Points of Function and present results of application of this proposal in real projects of Caixa Econômica Federal. Key words: Functional measurement, Data Mart, Analysis. size estimation, Function Point Introdução A medição na engenharia de software é um dos fatores importantes para a geração de um produto com qualidade. Segundo [3] mensura-se para entender, controlar e aperfeiçoar o processo de produção de software. Medidas ajudam a visualizar o processo de desenvolvimento e manutenção de software e proporcionam o estabelecimento de baselines 122 para ajudar o desenvolvimento futuro. Permitem um melhor controle dos projetos, possibilitam a incrementação de mudanças e proporcionam o aperfeiçoamento continuo deste processo e do produto de software . A mensuração do tamanho do software na gestão de projetos, além de proporcionar um melhor entendimento, controle e aperfeiçoamento do processo de construção de software, também está vinculada à necessidade de gerar expectativas mais realistas para o usuário, avaliar e medir resultados, conhecer melhor o patrimônio de software, obter e/ou melhorar estimativas de prazo, custo e recursos, gerar indicadores para tomada de decisão, avaliar o impacto da introdução de novas tecnologias e obter vários indicadores de desempenho (produtividade, qualidade do código) [12]. Dessa forma, é essencial que a mensuração de tamanho seja o mais aproximada possível da realidade, pois ela é um fator de impacto nas demais variáveis. Desde a década de 80, várias abordagens têm sido propostas e aperfeiçoadas com o objetivo de estimar funcionalmente o tamanho de um software, entre elas destacam-se: a Análise por Pontos de Função(APF), proposta em 1979 e já na versão 4.1 [6]; o MKII FPA, abordagem proposta em 1984 com base na APF e atualmente na versão 1.3.1 como uma visão totalmente independente da APF [13]; o Feature Points(1986), método experimental voltado para mensurar features de tipos especiais de software (sistemas de tempo real, com grande complexidade, CAD), o Full Function Points, abordagem proposta em 1997 como uma adequação da APF [1] e que evoluiu para o COSMIC Full Functions Points (1999) uma abordagem totalmente independente da APF que se propõe a mensurar qualquer tipo de software [1]. A maior parte destas propostas se propõe a medir o tamanho de qualquer tipo de software, independente da tecnologia. Sistemas de Data Warehouse/Data Mart, no entanto, são um tipo especial de software, com características particulares como, por exemplo, o fato dos usuários utilizarem o software somente para consultas e não atualização dos dados, o desenvolvimento baseado em dados existentes de outros sistemas sem gerar nova informação, e um processo de desenvolvimento diferente de sistemas tradicionais [11]. É necessário, portanto, adequar as abordagens definidas para sistemas tradicionais para que considerem as características específicas de Data Warehouse/Data Mart e com isso gerem estimativas mais reais. Neste artigo analisamos o processo de mensuração para sistemas de Data Mart com relação à proposta de APF. A escolha dessa abordagem se deve ao fato da APF ser uma das abordagens funcionais mais utilizadas pelo mercado atualmente, tendo na última década 15 livros e mais de 100 artigos publicados [4] o que mostra sua maturidade. Nas seções seguintes apresentamos, inicialmente, uma breve descrição sobre Data Warehouse/Data Mart, no que se refere a sua definição e processo de construção (seção 2); e sobre medição e análise por pontos de função, no que se refere a sua forma de medição (seção 3). Na seção 4, será apresentada a adequação da APF para Data Mart. Na seção 5 mostramos os resultados da aplicação desta adequação em alguns projetos da Caixa Econômica Federal. Finalmente, na seção 6, apresentamos as conclusões deste trabalho. Características de Data Warehouse/Data Mart Definição Segundo [5], um “Data Warehouse é uma coleção de dados orientada por assuntos, integrada, variante no tempo, e não volátil, que tem por objetivo dar suporte aos processos de tomada de decisão”. A tecnologia utilizada tanto no Data Warehouse como no Data Mart é a mesma, sendo que as variações que ocorrem são mínimas, mais voltadas para o volume de dados, abrangência da arquitetura e o foco [2]. Os Data Marts são voltados somente para uma determinada área referenciando um escopo menor, a uma unidade de negócio, a um departamento, ou a um 123 conjunto especifico dos usuários, já o Data Warehouse é voltado para os assuntos de toda empresa. As principais características de um Data Warehouse/Data Mart são [8]: informações facilmente acessadas e consistentes, adaptabilidade e flexibilidade às mudanças, proteção destas informações e utilização das informações como base para tomada de decisões. Existem quatro componentes separados e distintos no ambiente de Data Warehouse (Figura 1) [8]: sistemas operacionais de origem - sistemas que capturam as transações da empresa; data stanging area - área de armazenamento de dados e de conjunto de processos que preparam os dados de origem para serem utilizados; área de apresentação de dados - local onde os dados ficam armazenados e disponíveis ao usuário final; e ferramentas de acesso a dados - ferramentas OLAP e de mineração de dados que permitem aos usuários utilizar os dados de uma maneira rápida, interativa, de forma fácil para executar análises mensuráveis. Os Data Mart servem como fonte de dados para estas ferramentas e devem assegurar consistência, integração e precisão. Sistemas Operacionais De origem Data Área de Apresentação de dados Staging Área Extrair Serviços: Filtrar, combinar e padronizar dimensões de conformidade Extrair Armazenamento de dados: tabelas relacionais e arquivos simples Extrair Carregar Data Mart número 1: Dados dimensionais atômicos e de resumo baseados em um único processo de negócio Ferramentas de acesso a dados Acessar Ferramentas de consultas específicas Criadores de relatórios Modelagem: Previsão, pontuaç ao e exploração de dados Barramento do DW: fatos e decisões em conformidade Processamento: classificação e processamento sequencial Carregar Data Mart número 2: (projetado da mesma forma) Figura 1 – Elementos básicos do Data Warehouse [8] Acessar 124 Processo de Construção As fases básicas para se criar e atualizar um Data Warehouse são [8]: (i) extração, (ii) transformação e (iii) carga dos dados (ETL – Extraction, Transformation, Load). O processo de extração (i) envolve a leitura e compreensão dos dados de origem e cópia destes dados na staging area para serem manipulados posteriormente. Normalmente, cada sistema de origem é uma aplicação independente e que possui pouco compartilhamento de dados comuns como produto, cliente e geografia com outros sistemas operacionais da empresa. A integração destes dados é uma das tarefas que geram mais esforço no projeto de um Data Warehouse. A quantidade de sistemas transacionais envolvidos, suas estruturas de dados46 e o nível de documentação (o Data Mart necessita apresentar todos os conceitos e as origens dos dados) interferem diretamente na dimensão do sistema de Data Mart. O processo de extração pode ser realizado de forma automatizada através de ferramenta de ETL. A existência ou não desta ferramenta também impacta o tamanho do produto seja na geração de um maior número de funcionalidades para a extração destes dados ou na exigência de conhecimento profundo, por parte dos desenvolvedores do Data Mart, das regras de negócio dos sistemas transacionais e definição de formas de extração. Na fase de transformação (ii) modifica-se a estrutura do armazenamento de dados. Nesta fase ocorrem ”transformações em potencial, como filtragem dos dados (correções de erros de digitação, solução de conflitos de domínio, tratamento de elementos ausentes ou a divisão em formatos padrão), combinação de dados de várias origens, cancelamento de dados duplicados e atribuições de chaves” [8]. Nesta fase também podem ser aplicados níveis de desnormalização e renormalização47, combinação48, auditoria no conteúdo de dados49 e agregações necessárias para melhorar o desempenho das consultas para o usuário final (considerando a previsão de volume de dados). Toda esta transformação ocorre na staging area ou Operational data storage (ODS) (se a arquitetura da solução envolver este componente) e também impacta no tamanho de um projeto de Data Mart. A fase de carga (iii) é um processo interativo, pois o Data Warehouse tem que ser povoado continuadamente e refletir de forma incremental as mudanças do sistemas operacionais. Manutenções que possam ocorrer nas fontes de dados interferem diretamente na dimensão do projeto, pois além das transformações precisarem ser re-definidas e aplicadas, a carga também é alterada a cada modificação das fontes de dados das origens. A carga é a última etapa do processo de ETL e é realizada no banco de dados do DW, na área de apresentação de dados. Neste banco de dados (que pode ser desenvolvido em uma tecnologia de banco de dados multidimensional ou relacional) os dados são armazenados em cubos. Um modelo multidimensional possui três elementos básicos: fatos, que são definidos como a coleção de itens de dados, composta de dados de medidas e de contexto, representando um item de negócio, uma transação de negócio ou um evento de negócio; dimensões que são os elementos que participam de um fato e determinam o contexto de um assunto de negócios e medidas que são atributos numéricos que representam um fato [9]. Medição de Software 46 Definição da estrutura em que estão os dados de origem: VSAM, Banco de Dados Relacional (DB2, Sybase, Oracle, etc), Banco de dados hierárquico (IDMS), etc. 47 Reunificação das hierarquias de dados, separadas pela normalização dentro de uma tabela desnormalizada. 48 Realizada quando fontes de dados possuem os mesmos valores de chaves representando registros iguais ou complementares ou atributos de chaves não iguais, incluindo equivalência textual de códigos de sistemas de legados distintos. 49 O processo de transformação deve realizar constantes verificações de somas, contagens de linhas e testes. 125 Medição é o processo através do qual números ou símbolos são atribuídos a características das entidades do mundo real de forma a tornar possível caracterizar cada entidade através de regras claramente definidas [3], ou seja, é o processo de obtenção de uma medida para uma entidade do mundo real. Uma medida fornece uma indicação de quantidade, dimensão, capacidade ou tamanho de algum produto de software ou de um processo. Em outras palavras uma medida refere-se a um valor de uma métrica. Segundo [7], métrica é a composição de métodos para medição e escalas de medição. Para se chegar a uma medida de software, existem técnicas de estimativas que avaliam as variáveis de tamanho, esforço e prazo. Estas técnicas podem ser classificadas basicamente em Analógicas (baseada na experiência de quem faz estimativas), Modelos Algoritmos (que considera modelos matemáticos, por exemplo, o COCOMO que pontua o número de instruções fontes (número de linhas de código), regressão linear, Halstead) e Análise de Funcionalidade (baseada nas funcionalidades do software, por exemplo, a APF) [12]. Algumas das principais abordagens utilizadas para análise de funcionalidade são a Análise por Pontos de Função, definida desde 1979 e que vem continuamente sendo utilizada e melhorada desde então, e a COSMIC-FFP [1] proposta em 1999, tornou-se um padrão em 2003, mas ainda sem grande experimentação prática. A seguir serão descritas as principais características da APF por ser essa a métrica adequada nesse trabalho. Análise por Pontos de Função A Análise por Pontos de Função (APF) mede o tamanho do software pela quantificação de suas funcionalidades, baseadas no projeto lógico ou a partir do modelo de dados segundo a visão e os requisitos do usuário final [6]. Suas principais características são: medir o que foi requisitado e recebido do usuário, medir independente da tecnologia, ser aplicável desde o início do sistema, apoiar a análise de produtividade e qualidade e estimar o tamanho do software com uma unidade de medida padrão. Os seguintes passos devem ser observados para mensuração de tamanho do software utilizando esta abordagem [6]: Estabelecer o objeto da contagem (projetos de desenvolvimento, projetos de manutenção ou contagem de uma aplicação); Determinar a fronteira de medição (a fronteira de medição deve ser sempre determinada sob o ponto de vista do usuário); Contar as funções de dados, divididos em Arquivos Lógicos Internos (ALIs - que são grupos lógicos de dados mantidos dentro da fronteira da aplicação) e Arquivos de Interface Externa (AIEs – arquivos somente referenciados pela aplicação); Contar as funções transacionais, divididos em Entradas Externas (EEs), Saídas Externas (SEs) e Consultas Externas (Ces); Determinar o Fator de Ajuste (conjunto de 14 características que influenciarão a complexidade do software. São elas: comunicação de dados, processamento distribuído, performance, utilização de equipamento, volume de transações, entrada de dados on-line, eficiência do usuário final, atualização on-line, processamento complexo, reutilização de código, facilidade de implantação, facilidade operacional, múltiplos locais, facilidade de mudanças); e, Determinar o tamanho do projeto (considera as funções de dados, transacionais, fatores de ajuste e tipo de projeto). Cada função de dado ou transacional terá um peso diferente dependente de sua complexidade. Diversas tabelas baseadas na quantidade de elementos de dados, de registros e de arquivos 126 referenciados são utilizadas para determinar a complexidade de cada função em Baixa, Média ou Alta. A Tabela 1 mostra o número de pontos de função atribuídos a cada tipo de função conforme o grau de complexidade. Tipo de função EE SE CE ALI AIE Baixa 3 4 3 7 5 Média 4 5 4 10 7 Alta 6 7 6 15 10 Tabela 1 – Quantidade de pontos de função x Tipo de função x complexidade [6] O resultado da contagem de funções de dados e transacionais é uma medida chamada de contagem não ajustada (NoPFnão ajustado), pois não considera ambiente ou plataforma tecnológica que, entre outros, são detalhes que afetam o produto e sua construção. O ajuste na mensuração é efetuado através do Fator de Ajuste determinado. A determinação do Fator de Ajuste considera a avaliação de cada característica numa escala de 0 (nenhuma influência) a 5 (grande influência). A determinação deste fator de ajuste (FA) é baseada na equação: FA = 0,65 + (0,01 x Soma das características gerais do sistema). Para determinar o tamanho do projeto consideram-se fórmulas específicas como por exemplo, para medir aplicação ou projetos de desenvolvimento, a seguinte: NoPFajustado = NoPFnão ajustado x FA. Medição de Tamanho de Data Marts Existem diferenças substanciais entre a construção de um software transacional e a construção de um produto de Data Warehouse/Data Mart. Além do processo ser bastante diferenciado, o resultado, o tratamento dos dados, a visão do usuário possuem características muito diferentes quando comparados a um sistema tradicional. Existem, no caso deste domínio, funcionalidades que não são visualizadas pelo usuário final e que impactam no tamanho do sistema que esta sendo mensurado, como por exemplo todas as funcionalidades geradas para tratar os dados na staging area. A mensuração de um projeto de Data Warehouse com a abordagem APF fica prejudicada considerando que este processo, na visão do usuário, recebe dados já armazenados por outros sistemas e disponibiliza-os de forma que ferramentas adquiridas possam ser utilizadas para minerar ou consultar historicamente estes dados. A métrica APF examinada não trata exemplos específicos para contagem de tamanho de sistemas de Data Warehouse/Data Mart. Dessa forma é necessário analisar cada um dos itens que são considerados na APF e adequálos às características de Data Mart apresentadas na seção 3. Apresentaremos, a seguir como adaptamos a APF considerando os seis (6) passos de medição apresentados na seção anterior. No que se refere a (i) estabelecer o objeto da contagem não é necessário nenhuma adequação, pois identificar o objeto da contagem segue os mesmos padrões de um desenvolvimento de um sistema transacional. Com relação a (ii) Determinar a fronteira de medição do aplicativo é necessário verificar se o sistema de Data Mart para ser construído utilizará alguma ferramenta de ETL ou se os dados de origem são fornecidos pelos sistemas de origem, nestes casos a fronteira do aplicativo fica restrita as tabelas internas do projeto de Data Mart. Não serão computadas funções de dados para os arquivos dos sistemas de origens. Se os dados de origem não são fornecidos pelos sistemas de origem e nem obtidos através de uma ferramenta de ETL, sugerimos que estes dados sejam pontuados como AIE. 127 No que se refere a (iii) contar as funções de dados deve ser considerado que o usuário possui a visão das dimensões que necessitará para suas pesquisas, e que estas visões estão muito interelacionadas aos fatos, todos os fatos e dimensões devem ser pontuados como ALIs. Como AIE serão pontuados os dados corporativos utilizados no projeto. O usuário também possui a visão de que estes dados deverão ser tratados, limpos, agregados, sumarizados em uma área antes de serem disponibilizados para consulta. Com base nesta visão e considerando também a necessidade de se computar os dados da staging área, sugerimos que para todos os ALI computados inicialmente sejam também computados ALI para a staging área. Os dados da staging área são dados que permanecem e que são utilizados constantemente para as novas cargas e atualizações. Normalmente, podem ser criados mais de um arquivo na staging area para cada dimensão e fato, mas inicialmente será inferido somente a existência de um para cada ALI. A definição da complexidade para cada função de dado será aplicada conforme a proposta da APF. Para (iii) contar as funções transacionais deve-se para cada ALI considerar uma EE, pois eles são atualizados a partir dos dados de sistemas operacionais que funcionam como uma EE. Na realidade o processo de carga é muito mais complexo e gera muito mais processos do que apenas um como esta sendo sugerido, mas considerando a visão do usuário sugerimos a definição de uma EE para cada ALI. Com relação a SE ou CE sugere-se que sejam computadas qualquer solicitação de relatórios/consultas/view pré formatadas para facilitar a consulta do usuário final, respeitando-se a distinção entre SE e CE da proposta APF. A definição da complexidade para cada função transacional será aplicada conforme a proposta da APF. O passo referente a (iv) Determinar os Fatores de ajuste implicou numa análise cuidadosa dos fatores de ajuste propostos na APF no que se refere à Data Marts. Como resultado dessa análise percebemos que dos 14 fatores de ajuste: 4 fatores são aplicáveis a este tipo de software: Processamento distribuído de dados, Desempenho, Reusabilidade de Código e Facilidade Operacional. 2 fatores poderiam ser adaptados para Data Warehouse/Data Mart, são eles: Eficiência do usuário final50 que poderia ser adequado para considerando a Quantidade de agregação51 onde a definição dos níveis de agregação necessários tem como objetivo proporcionar eficiência para o usuário final. Processamento complexo52 que poderia ser adequado para Qualidade dos dados53 onde a quantidade de tratamento (de dados e das exceções) necessário ao projeto pode ser comparada como um nível de complexidade do processo. Os demais fatores (no total de 8) estão intrinsecamente relacionados a sistemas transacionais o que implica em quando analisados no contexto da Data Warehouse/ Data Mart sempre receberiam o valor 0 (nenhuma influência). Por exemplo, entrada de dados on-line54 e atualização on-line55 pois no contexto de Data Warehouse/Data Mart não existem entradas nem atualizações on-line; e ainda múltiplos locais56 considerando que o Data Warehouse/Data Mart não é instalado em nenhum local. Baseados nessa análise resolvemos considerar os 4 fatores realmente aplicáveis, substituir os 2 fatores possíveis de adequar por nomes mais pertinentes, e propor novos fatores de ajustes que 50 Aspectos relacionados com a eficiência do aplicativo na interação com o usuário. 51 Definição dos níveis de agregação necessários de forma a melhorar o desempenho das consultas do usuário final. 52 Aspectos relacionados com a complexidade do processamento. 53 Descreve o grau previsto para tratamento de exceções identificados inicialmente com relação à qualidade de dados, dados rejeitados, erro de conteúdo, etc. 54 Aspectos relacionados com a quantidade de entrada de dados on-line do aplicativo 55 Aspectos relacionados com a quantidade de atualização on-line dos arquivos lógicos internos. 56 Aspectos relacionados à arquitetura do aplicativo e a necessidade de instalação em vários lugares. 128 representem as características de Data Mart. Para cada um dos fatores, foram definidos os níveis de influência numa escala de 0-5 conforme proposto na APF. A proposta final de adequação dos fatores de ajuste para Data Mart pode ser visualizada na Tabela 2. Finalmente para (vi) determinar o tamanho do projeto utilizamos as fórmulas propostas na APF. Fatores de Ajuste e comentários sobre Níveis de influência aplicabilidade O aplicativo não auxilia na transferência de dados ou funções 1 entre os processadores envolvidos; Processamento distribuído de dados Aspectos relacionados com processamento O aplicativo prepara dados para que o usuário final os utilize em e funções distribuídas. outro processador (planilhas de calculo, por exemplo); Comentários: O aplicativo prepara dados e os transfere para que outros Leitura via client ou via Internet ou Intranet equipamentos os utilizem; pode receber o valor 2 a 4. O processamento é distribuído e a transferência de dados acontece de forma on-line apenas em uma direção; Aplicável. O processo de Data Mart prepara O processamento é distribuído e a transferência de dados acontece dados para leitura do usuário final em outra de forma on-line em ambas as direções; ferramenta, no caso uma ferramenta OLAP, As funções de processamento são dinamicamente executadas no na intranet. equipamento mais apropriado. Nenhum requerimento especial de performance foi solicitado pelo 2 usuário; Desempenho/Performance Aspectos relacionados a parâmetros Requerimentos de performance foram estabelecidos e revistos, estabelecidos pelo usuário quanto a tempos de mas nenhuma ação especial foi requerida; resposta. Tempo de resposta e volume de processamento são itens críticos durante horários de pico de processamento. Porém, nenhuma É aplicável ao projeto de Data Mart que determinação especial foi estabelecida quanto à utilização do trabalha com volumes altos de transações, processador. A data limite para a disponibilidade do mesmo que sejam transações efetuadas por processamento é sempre o próximo dia útil; ferramentas OLAP. Tempo de resposta e volume de processamento são itens críticos Dependendo do projeto seriam indicados os durante todo o horário comercial. Não há determinação especial níveis 4 ou 5. para a utilização do processador. A data limite para a comunicação com outros aplicativos é um item importante e deve ser considerado. quando, além do descrito no item 3, os requisitos de performance estabelecidos requerem tarefas de análise de performance na fase de análise e desenho do aplicativo. quando, além do descrito no item 4, ferramentas de análise de performance precisam ser usadas nas fases de desenho, desenvolvimento ou mesmo na fase de implementação para que os requisitos do usuário sejam atendidos plenamente. quando é utilizada ferramenta para 100% do processo de extração 3 Utilização de ferramenta apropriada para e/ou carga; quando é utilizada ferramenta para 80% do processo de extração extração e carga Indica o nível de automatização do processo e/ou carga; de Data Mart quando é utilizada ferramenta para 60% do processo de extração e/ou carga; quando é utilizada ferramenta para 40% do processo de extração e/ou carga; quando é utilizada ferramenta para 20% do processo de extração e/ou carga; quando nenhuma ferramenta é utilizada para extração e carga dos dados transacionais 4 Quantidade de sistemas transacionais quando o projeto envolve 1 sistema transacional envolvidos no projeto Descreve o grau em quando o projeto envolve de 2 a 3 sistemas transacionais; que a quantidade de interfaces com outros quando o projeto envolve de 4 a 5 sistemas transacionais sistemas influenciará o desenvolvimento da quando o projeto envolve de 6 a 7 sistemas transacionais; aplicação. quando o projeto envolve mais de 8 sistemas transacionais. Quando a quantidade de sistemas 129 Fatores de Ajuste e comentários sobre Níveis de influência aplicabilidade transacionais é alto, influencia o projeto, desenvolvimento, implantação e suporte da aplicação. quando todos os sistemas de origem possuem metadados; 5 Documentação dos sistemas transacionais quando 90% dos sistemas de origem possuem meta dados; de origem (Existência de Metadados dos quando 70% dos sistemas de origem possuem metadados; quando 50% dos sistemas de origem possuem metadados; sistemas de origem) Nível de documentação dos sistemas de quando 30% dos sistemas de origem possuem metadados; origem, de forma a identificar a existência de quando nenhum dos sistemas de origem possui metadados; metadados dos dados de origem. nenhum nível de agregação identificado; 6 Quantidade de agregação substituindo Um nível de agregação identificado; De dois a três quantidades de agregação identificadas; Eficiência do usuário final Definição dos níveis de agregação necessários De quatro a cinco quantidades de agregação identificadas; de forma a melhorar o desempenho das Seis ou sete quantidades de agregação identificadas; consultas do usuário final Oito ou mais quantidades de agregação identificadas quando não houver previsão; 7 Freqüência de atualização das fontes de quando houver atualizações de 10% a 20% dos arquivos de extração /carga; dados Descreve o grau em que os sistemas quando houver atualizações de 20% a 30% dos arquivos de transacionais são alterados implicando em extração /carga; constantes alterações nas aplicações de quando houver atualizações de 30% a 40% arquivos de extração extração e carga. /carga; quando houver atualizações de 40% a 50% dos arquivos de extração /carga; quando houver atualizações de mais de 50% arquivos de extração /carga. Ao considerar as características da aplicação verificar a 8 Qualidade dos dados em substituição ao necessidade de aplicabilidade dos seguintes itens: Integração – envolve a geração de chaves substitutas para cada Processamento complexo Descreve o grau previsto para tratamento de registro, de modo a evitar a dependência de chaves definidas no exceções identificadas inicialmente com sistema legado; relação à qualidade de dados, dados Limpeza – correção de códigos e caracteres especiais, resolvendo rejeitados, erro de conteúdo, etc. problemas de domínios, tratando dados perdidos e corrigindo valores duplicados ou errados; Eliminação – eliminar campos e dados provenientes dos sistemas legados que não serão úteis ao DW. Combinação – realizada quando fontes de dados possuem os mesmos valores de chaves representando registros iguais ou complementares ou atributos de chaves não iguais, incluindo equivalência textual de códigos de sistemas legados distintos; Verificação de integridade referencial – significa verificar se os dados de uma tabela são iguais aos dados correspondentes em outra tabela Desnormalização e renormalização – consiste em reunificar as hierarquias de dados, separadas pela normalização dentro de uma tabela desnormalizada; Conversão de tipo de dados – envolve transformação de baixo nível de forma a converter um tipo de dado em outro formato Cálculos, derivação e alocação - são transformações a serem aplicadas sobre as regras de negócio identificadas durante o processo de levantamento de requisitos; Auditoria no conteúdo dos dados – o processo de transformação deve realizar constantes verificações de somas, contagem de linhas e testes. Tem-se: quando não ocorrer nenhuma das características acima; quando ocorrer de uma a duas das características acima; quando ocorrer de três a quatro das características acima; 130 Fatores de Ajuste e comentários sobre Níveis de influência aplicabilidade quando ocorrer cinco a seis das características acima; quando ocorrer sete a oito das características acima; quando ocorrer todas as características acima; Nenhuma preocupação com reutilização de código. 9 Reutilização de código apenas no aplicativo. Reusabilidade de código Aspectos relacionados à reutilização do Menos de 10% do código do aplicativo foi projetado para ser código do aplicativo. utilizado em outros aplicativos. 10% ou mais do código do aplicativo foi escrito para ser utilizado Aplicável em outros aplicativos. O código do aplicativo foi projetado para ser utilizado em outros aplicativos. A customização deve ser realizada em nível de código-fonte. O código do aplicativo pode ser reutilizado em outros aplicativos com alto grau de parametrização. É apenas necessário que o usuário altere determinados parâmetros. 10 quando existir uma única estrutura dos dados de origem; Estrutura dos dados de origem Definição da estrutura em que estão os quando existir duas estruturas dos dados de origem; dados de origem, VSAM, Relacional(DB2, quando existir três estruturas dos dados de origem; Sybase, Oracle), Hierárquico – IDMS). quando existir quatro estruturas dos dados de origem; quando existir mais de quatro estruturas. 0 Nenhuma consideração especial de operação além do processo 11 normal de salvamento de dados; Facilidade operacional 1 a 4: quando um ou todos os itens seguintes se aplicarem Aspectos relacionados com a facilidade de (selecionar todos os que se aplicam; cada item soma um ponto): operação do aplicativo. Avalia procedimentos Foram desenvolvidos procedimentos de iniciação, salvamento e operacionais automáticos e mecanismos de recuperação, mas a intervenção do operador é necessária; iniciação, salvamento e recuperação de dados. Foram desenvolvidos procedimentos de iniciação, salvamento e recuperação, sem a necessidade de intervenção do operador (vale Aplicável quando direcionado aos dois itens); procedimentos batch de extração e carga. O aplicativo minimiza a necessidade de montagem de fita magnética; O aplicativo minimiza a necessidade de manuseio de papel; 5 O aplicativo foi desenhado para trabalhar sem operador. Nenhuma intervenção do operador é necessária além de iniciar e encerrar o aplicativo porque este já contém rotinas automáticas de recuperação de erros. 12 1 Baixo Volume de dados Previsão do volume de dados do projeto 3. Médio O volume de dados interfere no tamanho e 5. Alto deve ser previsto visando garantir performance 13. Nível de conhecimento exigido pela equipe de Data Mart da base de 1 Pouco conhecimento da equipe de Data Mart das regras de negócio dos sistemas transacionais dados/regras de negócio dos sistemas 3 Médio conhecimento da equipe de Data Mart das regras de transacionais de origem negócio dos sistemas transacionais (Vinculada à existência de ferramenta ETL, 5 Alto conhecimento da equipe de Data Mart das regras de pois a existência obriga a equipe de Data negócio dos sistemas transacionais Mart a conhecer todas as regras de negócio transacional e definir formas de extração). Tabela 2 - Fatores propostos para sistemas de Data Mart Aplicação da proposta de adequação e da APF Nos últimos anos a Caixa Econômica Federal tem utilizado a Análise de Ponto de Função para mensurar o tamanho de seus sistemas. Esta métrica tem características próprias, conforme 131 poderá ser verificado no escopo deste trabalho, e tem sido utilizada na medição de Sistemas de Informações operacionais, Data Mart, Workflows. Foram escolhidos três projetos de Data Mart que já estão em produção e possuem dados com relação ao tempo de construção e quantidade de recursos envolvidos, de forma a poder se efetuar uma comparação entre as duas abordagens: a APF como ela é proposta, e a adequação da APF apresentada na seção 5. Foram pontuados os seguintes sistemas: SIST. 1, sistema de informações gerenciais dos negócios da empresa; SIST. 2, um sistema de informações gerenciais de determinada área negocial da empresa; e, SIST. 3, um sistema de informações gerenciais de Recursos Humanos. Não foi contada nenhuma SE nem CE para os projetos em questão, pois, a empresa utiliza ferramentas OLAP para geração de relatórios e consultas. Estas ferramentas são utilizadas pelo usuário final que define suas próprias consultas dinamicamente. Os resultados são apresentados na Tabela 3. Sistemas APF Proposta de Adequação ALI AIE EE SE CE IF PFN FA PFA ALI AIE EE CE CE IF PFN FA PFA SIST. 1 507 7 234 14 748 0,79 590,92 1014 7 234 43 1255 1,08 1355,40 SIST. 2 252 24 116 13 392 0,78 305,76 504 24 116 39 644 1,04 669,76 SIST. 3 252 5 110 13 367 0,78 286,26 504 5 110 40 619 1,05 649,95 Legenda: IF – Itens de influencia PFN – Pontos de função não ajustados FA – Fator de ajuste PFA – Pontos de função ajustados Tabela 3 – Contagem dos sistemas de Data Mart Para analisar a contagem de pontos de função decidimos definir a estimativa de tempo considerando o número de recursos (tamanho da equipe) que participou do desenvolvimento. Para isso, foi considerado um fator de produtividade que é utilizado pela empresa, ou seja, o esforço (horas/pf) de 16,00 com a quantidade de 22 dias por mês, com a carga horária de 8 horas. Na tabela 4 são apresentados os resultados da aplicação da APF e da proposta de adequação com relação ao tempo real de construção e à quantidade de recursos alocados para cada um dos sistemas. APF Ponto Função Tempo estimado 19 meses 590,92 10,74 meses 8 a 9305,76 3,97 meses meses Proposta de Adequação Ponto Função Tempo estimado 1355,40 24,64 meses 669,76 8,69 meses 10 meses 286,26 649,95 Sistema Qtd Tempo recurso real SIST. 1 SIST. 2 5 7 SIST. 3 6 4,33 meses 9,84 meses Tabela 4 – Comparação da abordagem APF e da proposta de adequação com relação ao tempo real Como pode ser observada na Tabela 4, a proposta de adequação se aproxima mais ao tempo real do projeto do que a abordagem APF. O único sistema que ficou com um tempo estimado da Proposta de adequação menos aproximado ao real foi o Sist. 1. Quando consultada, a equipe informou que este sistema foi construído por uma equipe altamente especializada de consultores, e inferimos que, talvez neste caso, o fator de esforço tenha sido superestimado. 132 Conclusões Uma das maiores dificuldades encontradas pela gestão de projetos é estimar o porte do que está sendo construído. Existem muitas abordagens para mensurar o tamanho de um software e não existe uma abordagem que seja melhor que outra, sob todos os aspectos, em qualquer situação. A abordagem de mensuração de tamanho deve ser escolhida e/ou adequada dependendo das características particulares do sistema que se pretenda desenvolver ou do problema que se pretenda solucionar. A partir da observação de que os sistemas de Data Warehouse/Data Mart possuem diferenças substanciais da construção de um software transacional iniciamos uma pesquisa de como adaptar uma abordagem de medição de tamanho (a análise por pontos de função) para esse contexto. O resultado desta investigação demonstrou que uma adequação da abordagem APF é necessária para uma mensuração de tamanho de software mais adequada e confiável para este domínio. A adequação e a medição de três projetos reais nos mostrou resultados promissores. Sabemos que são necessárias mais aplicações da abordagem proposta para confirmar a sua melhor adequabilidade para projetos de Data Warehouse e Data Mart, mas este pode ser o caminho inicial para a solução do problema de mensurar tamanho de softwares para domínios de Data warehouse/Data Mart. REFERÊNCIAS BIBLIOGRÁFICAS [1] ABRAN, A., DESHARNAIS, J., OLIGNY, S., ST-PIERRE, D., SYMONS C. Cosmic FFP Measurement Manual, version 2.2, Ed. S.Oligny, Software Engineering Management Research Laboratory, Université du Quebec a Montreal, Canada, 1999. 81 p. [2] BARBIERI, C. BI-Business Intelligence – Modelagem & tecnologia. Rio de Janeiro: Axcel Books do Brasil Editora, 2001. [3] FENTON,N., PFLEEGER, S. Software Metrics A Rigorous & Practical Approach. Boston: PWS Publishing Company, 1997. 638 p. [4] GARMUS,D. Function Points Analysis – Measurement Practices for Successful Software Projects. Estados Unidos: Addison Wesley,2001.363 p. [5] INMON, W.H. , Definition of a Data Warehouse. 1999. Disponível em: <www.billinmon.com/library/articles/dwedef.asp. Acesso em 05 Mai 2003. [6] IFPUG. International Function Point Users Group. Function Point Counting Practices Manual: Release 4.1. Ohio: IFPUG. 2000. 1 v. [7] ISO/IEC 9126:2001.Software engineering – Product quality.2001. [8] KIMBALL, R., ROSS, M. Data warehouse toolkit: o guia completo para modelagem multidimensional.Rio de Janeiro: Campus, 2002. 494 p. [9] MACHADO, F. Projeto de Data Warehouse – uma visão multidimensional. São Paulo: Erica, 2000. [10] OLIGNY, S., ABRAN, A. On the compatibility between full function points and IFPUG function points. In: PROCEEDINGS OF THE 10TH EUROPEAN SOFTWARE 133 CONTROL AND METRIC CONFERENCE – ESCOM, 1999. Herstmonceux Castle, Inglaterra. p.1-9. [11] SANTILLO, L. Size & estimation of data warehouse systems. In: THE EUROPEAN SOFTWARE MEASUREMENT CONFERENCE – FESMA – DASMA, 2001. Heidelberg, Alemanha .p.12. [12] SIMÕES, C. Sistemática de Métricas, qualidade e produtividade.Developers’ Magazine, Brasil, 1999. 7p. [13] UK. UKSMA Metrics Practices Committee. MKII Function Point Analysis Counting Practices Manual. Version 1.3.1. UK, 1998. 100 p. 134 APÊNDICE E - Artigo publicado na Developers´Magazine, 2003 ___________________________________________________________________________ Esse apêndice apresenta o artigo publicado na Developers´Magazine, em Outubro/2003. ___________________________________________________________________________ Cosmic Full Function Points: Calculando o Tamanho de Softwares Uma das maiores dificuldades encontradas no gerenciamento de projetos da TI é estimar o porte do que está sendo construído. O software e o seu custo de produção possuem características como complexidade implícita e alto grau de subjetividade que impactam sua concepção e produção. Estas características dificultam muito uma mensuração precisa e absoluta. Orçar produto e produção é bem mais difícil nesta área que em outras. Desde a década de 80, vários métodos têm sido propostos e aperfeiçoados com o objetivo de estimar o tamanho funcional de um software. Entre eles a proposta inicial de Allan Albrecht, Feature Points, MkII FPA, Function Points Analysis – FPA/IFPUG v.4.0, Function Points Analysis – FPA/IFPUG 4.1, MKII FPA 1.3, Full Function Points - FFP V. 1 e Cosmic Full Function Points - FFP v. 2.1 e 2.2. O método Cosmic Full Function Points é uma das abordagens mais atuais com relação à mensuração de tamanho de software. Foi proposto em 1997 com o nome de Full Function Points V.1, como uma adaptação da métrica FPA/IFPUG para sistemas real time. Em 1999, o grupo Common Software Measurement International Consortium – COSMIC – propôs a abordagem Cosmic – FFP – V.2.1 (Cosmic Ponto de Função Cheio – V.2.1) como uma métrica totalmente independente de outras. Atualmente o Cosmic está na V. 2.2. O Cosmic surgiu como uma alternativa de mensuração mais exata (de forma a não gerar dúvidas, não sendo ambígua), com independência de domínio e propondo diferentes medidas para diferentes propósitos (considerando a visão do usuário e do desenvolvedor). Esta métrica foi desenvolvida para trabalhar com o tamanho funcional de diversos tipos de software e mensura o tamanho baseada nas funcionalidades entregues para o usuário, possuindo uma visão de usuário mais abrangente que as outras métricas. O método pode ser utilizado para mensurar estimativa de esforço de desenvolvimento, evolução de qualidade de software, gerenciamento de contratos de outsorcing, comparação de sistemas especificados em diferentes linguagens, em termos de produtividade, qualidade e manutenção de custos. A versão 2.2 do Cosmic foi aprovada em 2003 pelo Modelo Internacional (ISO/IEC 19761:2003). Três outros métodos (IFPUG, MkII FPA e NESMA) foram também aprovados pela ISO, mas o Cosmic, por ser uma abordagem mais flexível e atual, possui características que valem a pena serem 135 conhecidas e analisadas. Características do Cosmic FPP Na abordagem Cosmic FFP, são consideradas as seguintes características: Requisitos funcionais dos usuários – São os requisitos correspondentes aos componentes do software e que descrevem as funções requeridas pelo usuário para o software. São designados Functional User Requeriments (FUR). Usuários do software – Usuários podem ser humanos (engenheiros de software, usuários finais, etc.), um serviço ou mesmo outro software. Componentes de software podem também ser considerados como usuários quando interagem com outros componentes. É possível identificar um ou mais usuários para a funcionalidade de um componente de software em cada camada. Camadas – O software pode ser mensurado de forma particionada em um ou mais componentes ou pedaços. Estes componentes ou pedaços reunidos para a execução de uma funcionalidade ou processo formam uma camada. Fronteiras – Em cada camada, o componente de software pode ser mensurado conforme sua fronteira. Uma implícita fronteira existe também entre cada camada identificada. Método de cálculo utilizando Cosmic FFP O método Cosmic consiste na aplicação de uma série de regras e rotinas para que, a partir de determinado pedaço de software, seja possível conseguir medir o tamanho deste software. Neste mapeamento, são identificadas as seguintes etapas: Definição do propósito, escopo e ponto de vista da mensuração - Na definição do propósito define-se o objetivo da mensuração. O escopo é determinado baseado no propósito da mensuração e consiste em um conjunto de FUR incluídos em uma específica mensuração de tamanho funcional. O escopo pode ser uma camada, um objeto reutilizável, um pacote de software, uma aplicação, etc. A definição do ponto de vista é necessária para definir o grau de detalhamento em que será pontuado o software. Para maior consistência da mensuração, é necessário definir um limitado número de visões. As duas principais visões de mensuração são do usuário final e do desenvolvedor. Identificação das camadas de software - A identificação das camadas de software é um processo interativo. Todas as camadas de software devem fornecer funcionalidades para seus usuários. Existem uma série de princípios para definir a camada descritos no Measurement Manual Cosmic FFP. Identificação da fronteira do software - A fronteira de um componente de software é a fronteira conceitual entre este componente, o trabalho que deve realizar e a percepção externa na perspectiva dos usuários. Identificação dos processos funcionais – Um processo funcional é um componente elementar de um FUR, sendo composto de um conjunto de movimentos de dados (entrada, saída, leitura e gravação). Este processo 136 pode ser subdividido em outros sub processos. Identificação grupos de dados – Um grupo de dado é um distinto, não vazio, não ordenado e não redundante conjunto de atributos de dados onde cada atributo de dado descreve um aspecto complementar do objeto de interesse. Um grupo de dados pode ser definido como um conjunto de atributos de dados que estão logicamente relatados e baseados na perspectiva funcional. Movimento de dados – Entradas: São o movimento de atributos de dados, pertencentes a um grupo de dados, do ambiente externo à fronteira do software para o ambiente interno ao software. Não realizam “update” nos dados que movimentam e podem ser associadas à manipulação (validação de dados) nos processos ou sub processos identificados. Entradas incluem todas formatações e manipulações requeridas pelos usuários. Saídas: São o movimento dos atributos de dados pertencentes a um grupo de dados de dentro da fronteira do software para o lado do usuário do software. Não lêem os dados que movimentam e incluem toda a formatação e apresentação de manipulações requeridas pelos usuários e todo processamento para formatar e preparar para impressão alguns atributos de dados. Leituras: Inclui todo processamento para ler o dado armazenado. Gravação: Inclui todo processamento para criar e armazenar atributos de dados. Após a identificação de todos os componentes, aplica-se a fórmula. A técnica Cosmic-FFP é uma função matemática que atribui um valor para cada um dos movimentos de dados citados anteriormente. Esta técnica define um Cfsu (Cosmic Functional Size Unit) como uma pontuação de dado elementar. A mensuração é baseada no processo ou subprocesso. Cada instância do processo (ou subprocesso) identificado (entrada, saída, leitura ou gravação) recebe o tamanho de 1 Cfsu. Para cada camada identificada, o tamanho funcional é aplicado para todos os processos (ou subprocessos) identificados, conforme fórmula a seguir: Size Cfsu (layer) = tamanho (entradas) + tamanho (saídas) + tamanho (leituras) + tamanho (gravações) No caso de manutenção, utiliza-se a seguinte fórmula: Size Cfsu (mudança(proceso funcional) = size (movimento de dados adicionados) + size (movimento de dados alterados) + size (movimento de dados excluídos) Calculando o tamanho de um processo estruturado Considerando um processo simples de manutenção de cliente (onde teríamos somente dois campos a serem atualizados: nome e endereço), poderíamos visualizar a aplicação da métrica para este processo e os subprocessos com a identificação dos tipos de movimentos: Size Cfsu (camada) = tamanho (entradas) + tamanho (saídas) + tamanho (leituras) + tamanho (gravações) Size = 14 Considerando a reusabilidade de certos subprocessos, teríamos Size = 14 3 = 11 137 Conclusões Independente do software a ser construído, cada uma de suas partes, etapas e subdivisões podem ser mensuradas. Somente com a aplicação de métricas apropriadas será possível realizar estimativas com precisão, confiabilidade e qualidade. O método a ser utilizado para a estimativa de tamanho de software deve ser escolhido dependendo das características particulares do sistema que se pretende desenvolver e de circunstâncias especiais que envolvam o problema a solucionar. Segundo a publicação do Ministério da Ciência e Tecnologia, Qualidade e Produtividade no Setor de Software Brasileiro (2002, p.58), somente 30% das empresas de produção de software (foram consultadas 446 empresas no Brasil) utilizam algum tipo de métrica de tamanho. Isto demonstra que o processo de estimar o tamanho de software ainda está muito pouco internalizado dentro das empresas brasileiras. A métrica Cosmic possui várias características que a diferenciam das métricas já existentes, tais como: A possibilidade de aplicar a visão do usuário final e do desenvolvedor (todas as métricas desconsideram a visão do desenvolvedor e em muitos processos a visão do desenvolvedor é responsável por uma mensuração mais acurada do produto). A identificação de camadas (considerando que a maioria das tecnologias existentes trabalha com este paradigma). A flexibilidade (utilizando a abordagem FPA, uma EE – entrada externa – pode ter no máximo de 3 a 6 pontos; no Cosmic depende de quantos movimento efetua). A aplicabilidade de forma mais simples e menos ambígua. Isto tudo torna a abordagem Cosmic uma técnica interessante para equipes e empresas que querem iniciar o processo de mensuração como forma de incrementar a qualidade, produtividade e controle de seus produtos; para equipes que não conseguiram bons resultados utilizando-se de outros mecanismos de estimativa; e também para empresas que necessitam de um método de mensuração simples e de fácil aplicabilidade em diversos tipos/projetos de desenvolvimento e/ou manutenção (OO, Data Warehouse, Workflow, etc.). Referências ABRAN A.; SYMONS C.; OLIGNY S. An Overview of Cosmic – FFP field trial results. In: The 12nd European Software Control and Metrics Conference ESCOM. 2001. Londres. Inglaterra. p. 1-10. Disponível em http://www.lrgl.uqam.ca/cosmic-ffp/publications/ ABRAN, A.; OLIGNY, S.; SYMONS, C.; ST-PIERRE, D.; DESHARNAIS, J. Functional Size Measurement Methods – Cosmic – FFP: Design and Fiel Trials. In: The 3rd, European Software Measurement Conference – FESMA – AEMES. 2000. Madri, p. 13. Disponível em http://www.lrgl.uqam.ca/publications/pdf/587.pdf. ABRAN, A.; DESHARNAIS, J.; OLIGNY, S.; ST-PIERRE, D.; SYMONS C. 138 Cosmic FFP Measurement Manual, version 2.2. Ed. S. Oligny. Software Engineering Management Research Laboratory - Université du Quebec a Montreal. Canada. 1999. p. 81. Disponível em http://www.çrgç.uqam.ca/ffp.html. DIAB, H.; FRAPPIER, M.; ST-DENIS, R. A formal definition of Cosmic – FFP for automated measurement of room specifications. Canada. Departement de Mathematiques and d’Informatique – Université de Sherbrooke. 2001. p 12. Disponível em http://www.lrgl.uqam.ca/publications/pdf. HO, V.; ABRAN, A.; OLIGNY, S; Using Cosmic – FFP to quantify functional Reuse in Software Development. In: THE European Software Control and Metrics Conference – ESCOM. 2000. Munique. p.1-8. Disponível em http://www.lrgl.uqam.ca/cosmic-ffp/casestudies/. MELI, R.; SANTILLO, L. Function point estimation methods: a comparative overview. In: The 2nd European Software Measurement Conference – FESMA. 1999. Amsteram. p. 1-14. Disponível em http://www.dpo.it/resources/papers/1999-fesma-fpestmet-en.pdf. MELI, R. Functional and technical software measurement: conflict or integration? In: The 3rd European Software Measurement Conference – FESMA – AEMES – 2000. Madri. p 15. Disponível em http://www.dpo.it/resources/papers/2000-fesma-functechmeas-en.pdf. Qualidade e Produtividade no Setor de Software Brasileiro n. 4 (2002). Brasília. Ministério da Ciência e Tecnologia. Secretaria de Política de Informática. 2002. p 258. RULE, P. The importance of the Size of Software requirements. In: NASSCOM Conference. Hotel Oberoi Towers. Mumbai, India. 2001. p 19. Disponivel em http://www.gifpa.co.uk/library/papers/rule/the_import_of_size/v1c.html. STUTZKE, R. Predicting Estimation Accuracy. In: The European Software Control and Metrics Conference – ESCOM. 2000. Alemanha. p 211 – 220. Disponível em: http://dialspace.dial.pipex.com/town/drive/gcd54/conference2000/stutzke.pdf. Autor: Angélica Calazans Biografia: Angélica Calazans é especialista em TI da Caixa Econômica Federal. Participa do grupo de métricas da instituição e é mestranda em Gestão do Conhecimento e Tecnologia da Informação da Universidade Católica de Brasilia.