Pontos de Função & Contagem de Sistemas Data Warehouses

Pontos de Função & Contagem de Sistemas Data Warehouses Versão 1.0 Observação: O NEC estabeleceu que White Papers¹ é um esforço de fornecer dicas rápidas de um determinado assunto à comunidade de contagem. Este documento se baseia nas práticas de contagem de pontos de função conforme descrito versão 4.2 do Manual de Práticas de Contagem (CPM) e demonstra a aplicabilidade de Pontos de Função neste domínio. Os conteúdos desse trabalho servem para ser usado exclusivamente como dicas na aplicação da contagem de ponto de função no domínio descrito. Tais dicas não constituem alteração de regras e não devem ser usados como regras. Esse documento foi revisado e aprovado pelo CPC, e não constitui os padrões das práticas de contagem IFPUG conforme contido no CPM. Página 1 de 19

Pontos de Função & Contagem de Sistemas Data Warehouses Versão 1.0 Contribuidores do White Paper Autores Daniel French GEICO Chris Kohnz Tammy Preuss AT&T (DWO White Paper Team Lead) Revisores Dawn Coley EDS Roger Heller Q/P Management Group, Inc. NEC Chairperson Deb Maschino EDS Steve Woodward Q/P Management Group, Inc. NEC Vice Chairperson Comitê de Práticas de Contagem IFPUG Contribuidores Extras Carol Dekkers Quality Plus Technologies, Inc. Lavanya Kaul NIIT Technologies Pam Morris Total Metrics Luca Santillo CFPS, Cnsultor de Métricas Ewa Wasylkowski Total Metrics Participantes tradução para Português Tradutor : Andre Rossano Teixeira Camargo TOTVS Revisores : Guilherme Siqueira Simões FATTO Consultoria e Sistemas Carlos Schuster TOTVS Página 2 de 19

Introdução Nos últimos anos tem-se visto um aumento considerável no desenvolvimento de sistemas de Data Warehouses no mundo todo. Dada a natureza primária dos Data Warehouses como repositórios de dados enviados de outras aplicações, a contagem de ponto de função de tais sistemas proporcionou desafios únicos à comunidade. O objetivo desse trabalho é proporcionar orientação para aplicar as regras de contagem do ponto de função conforme especificado na versão 4.2 do Manual de Práticas de Contagem (CPM), de janeiro de 2004. Este white paper não altera as regras de contagem oficiais do International Function Point Users Group (IFPUG) conforme especificado no CPM. Público Este trabalho destina-se a profissionais de contagem do ponto de função que têm um entendimento intermediário a avançado das regras do CPM do IFPUG e precisam aplicá-las enquanto contam um sistema do tipo Data Warehouse ou uma aplicação Data Mart. Esta informação também pode ser benéfica aos membros da comunidade Tecnologia da Informação em geral e os que necessitam de um entendimento de como um sistema Data Warehouse/Data Mart é visto da perspectiva do usuário quando a contagem e regras do IFPUG são aplicadas. Ambiente O enfoque principal de um Data Warehouse é guardar vários tipos de dados em um local consolidado. Por exemplo, dados pessoais e dados financeiros podem ser mantidos no mesmo Data Warehouse. Isso facilita a criação de relatórios complexos e visões ao eliminar a necessidade de acessar múltiplas aplicações ou arquivos. O analista de ponto de função pode encontrar várias ferramentas usadas para criar relatórios a partir dos dados armazenados no Data Warehouse, como o Crystal Reports ou outras aplicações caseiras/proprietárias. O enfoque, porém, está no movimento dos dados saindo e entrando no Data Warehouse, e não nas ferramentas que geram relatórios. Abordagem: Definindo a Fronteira da Aplicação Um aspecto crucial da contagem de Data Warehouses que apresentou desafios significativos dos contadores de ponto de função está em definir a fronteira da aplicação. Uma fronteira impropriamente definida, pode distorcer de forma considerável os resultados da análise de ponto de função. Página 3 de 19

Definições da Fronteira da Aplicação A fronteira da aplicação Define o que é externo à aplicação É uma interface conceitual entre a aplicação interna e o mundo externo do usuário Funciona como uma membrana por meio da qual os dados processados por transações (EEs, SEs e CEs) passam para dentro e fora da aplicação Agrupa os arquivos lógicos mantidos pelo aplicativo (ALIs) Ajuda a identificar os dados lógicos referenciados, mas não mantidos dentro da fronteira do aplicativo (AIEs) É dependente da visão de negócios externa do usuário sobre aplicação. É independente de considerações técnicas e/ou de implementação 1. As seguintes regras devem se aplicar aos limites: A fronteira é determinada com base na visão do usuário. O enfoque é no que o usuário pode entender e descrever. A fronteira entre as aplicações relacionadas baseia-se em áreas funcionais separadas como visto pelo usuário, não em considerações técnicas. A fronteira inicial já estabelecida para a aplicação ou aplicações sendo modificadas não são influenciadas pelo escopo de contagem 2. Com base nessas regras de definição de fronteira, o que segue abaixo deve ser excluído dos limites da aplicação: Arquivos lógicos mantidos pelo(s) sistema(s) de origem, exceto se eles são referenciados durante o processamento dos arquivos de chegada com os dados. Tabelas Temporárias, Staging Areas, Tabelas de códigos Data Marts. Estes podem ser contados como fronteiras de aplicações separadas. Algumas considerações incluem: o O propósito da contagem, o Os usuários são um grupo distinto; ex.: um departamento específico como marketing, diferente grupo de usuários do Data Warehouse e; o A existência de dados externos além daquele disponível dentro do Data Warehouse. Figura 1 é uma representação gráfica de como a fronteira de um Data Warehouse pode ser definida. Página 4 de 19

1 IFPUG CPM Versão 4.2 página 5-4 2 IFPUG CPM Versão 4.2 página 5-5 Figura 1 Fronteiras do Data Warehouse A Figura 1esta mostrando um limite em volta das Staging Areas/Depósito de Dados Operacionais/Data Warehouses e limites em torno de Data Marts específicos. É uma representação gráfica de como as fronteiras podem ser definidas. Embora este diagrama mostre todos os três Data Marts fora da fronteira, esse nem sempre pode ser o caso. Acrônimos comuns: ETL = Extrair, Transformar & Carregar ODS = Depósito de Dados Operacionais EDW = Enterprise Data Warehouse BO = Business Objects Funcionalidade física Muitos sistemas de Data Warehouse contêm várias áreas físicas onde os dados são armazenados antes, durante e depois que os dados são recebidos do sistema de origem e são processados. Nesse contexto, é importante diferenciar a funcionalidade do negócio das funções físicas e técnicas. Página 5 de 19

Tecnologia Web Os Data Warehouses geralmente usam tecnologia da web para tornar as suas informações mais acessíveis aos usuários. Esses Wesites podem incorporar informações nos relatórios ou Consultas; informação de metadados; dicionários de dados; ferramentas de Consulta; treinamento; e membros de grupos de projetos em um local conveniente. Quando esses Websites existem, o Analista do Ponto de Função precisa determinar se a fronteira do Data Warehouse inclui ou exclui o Website que fornece acesso a ele. Segue algumas dicas para ajudar nessa decisão: Se um Website central é usado para acessar vários Data Warelouses dentro da empresa, e este é mantido por uma equipe específica e não pela equipe que mantém os Data Warehouses, essa é uma boa indicação que o Website é uma aplicação separada cuja função primária é fornecer acesso aos Data Warehouses. Se um cara web foi construído para fornecer capacidades de relatório para um Data Warehouse específico, e é mantido por esta equipe de Data Warehouse, provavelmente seria contado como parte do aplicativo de Data Warehouse. Observação: A fronteira do aplicativo não se baseia necessariamente em como a organização do software é gerenciada. Porém, conhecer quem desenvolveu o Website que fornece acesso a um Data Warehouse em particular pode ser útil quando se define a fronteira da aplicação. Anatomia Física de um Data Warehouse Tipicamente, existem três segmentos físicos dentro do Data Warehouse; Staging Areas, o depósito de dados operacionais e o Data Warehouse. Staging Areas Essa Staging Area é usada para armazenar uma versão atual do Data Warehouse que existe no sistema original. Esta cópia física é criada por várias razões, inclusive: Desempenho O sistema operacional pode reduzir a carga de processamento imposta pelas leituras requeridas antes que a transformação dos dados comece. Segurança Sistemas origem podem controlar o que os programas têm acesso em suas áreas. Ao fornecer uma exportação, o sistema de origem mantém controle sobre o que é enviado. Os dados armazenados nas Staging Areas são os mesmos ou muito similares aos do sistema original, em suas estruturas e valores de dados. A Staging Area raramente é vista ou descrita por um usuário do negócio ou um usuário administrador. Depósito de Dados Operacionais (ODS) O ODS contém dados transacionais detalhados que são (tipicamente), de alguma forma, modificados. A fonte original desses dados é o sistema de origem via a área de etapas. Considere como os dados podem ser modificados quando determinam se é um Página 6 de 19

armazenamento de dados e o tipo de função de dados (ALI ou AIE). Os dados nesse segmento do Data Warehouse podem ser descritos como: Integrados Validados Freqüentemente atualizados Detalhados Voláteis O segmento ODS suporta a habilidade para, via data mining, buscar informações sumarizadas para as informações de nível transacional, detalhadas e atuais. Data Warehouse O Data Warehouse é a última área de acomodação (dentro do limite do aplicativo de Data Warehouse) para os dados transformados. Quando dados são armazenados aqui, eles passaram por um processamento via ETL (Extrair, Transformar e Carregar). Exemplos desse processamento incluem: Validação Integração Limpeza Verificações de qualidade Sumarização Diagramas de Modelo de Dados Projetos de Data Warehouse contêm muitos documentos que o Analista do Ponto de Função pode usar para auxiliar na contagem do ponto de função. Alguns dos documentos mais úteis são os diagramas de modelo de dados, que ajudar a determinar dados e funções transacionais para a contagem. Os diagramas de modelo de dados incluem: Tabelas Fato Tabelas Agregadas Tabelas de existência Dimensões Tabelas de Visualização Metadados Tabelas Fato A tabela fato é a principal tabela de interesse em um modelo dimensional. Uma tabela fato contém medidas relacionadas a negócios e cada tabela fato pode ser conectada a tabelas dimensionais ou a outras tabelas fato.os dados da fato no Data Warehouse se parecem tipicamente com aqueles contidos no sistema de origem ou ODS, mas foram submetidas ao processo ETL e portanto seu significado pode ter sido mudado drasticamente. Página 7 de 19

A estrutura de chave estrangeira na tabela fato permite que os campos definidos em entidades dimensionais acessem informações adicionais. Uma contagem de DET (TDs) tipicamente incluirá campos da entidade da tabela fato e da entidade dimensional. Dependendo da abordagem de modelagem usada pela equipe do projeto, o esquema 3 de estrela representado pode incluir só os campos que são requeridos para definir a informação da entidade da fato ou pode incluir todos os campos que são definidos para a entidade dimensional, mas são requeridos para uso em outras entidades do fato. Em resumo, tabelas fato contêm agrupamentos identificáveis do usuário de dados e são geralmente mantidos por um ou mais processos de ETL (processos elementares). Como tais, eles são contados como Arquivos Lógicos Internos. Uma palavra final de advertência sobre contagem dos tipos de dados (DETs ou TDs) certifique-se de contar somente os requeridos para a entidade fato em análise. Figura 2 Diagrama de Relacionamento da Entidade Figura 2 mostra um diagrama de relacionamento de entidades do Data Warehouse Mercearia. Página 8 de 19

3 http://en.wikipedia.org/wiki/star_schema Figura 3 Tabela de Fatos Figura 3 mostra uma tabela fato em um exemplo usando uma transação de Mercearia. 4 Tabelas Agregadas Tabelas Agregadas é um tipo especial de tabela fato. Tabelas Agregadas deveriam ser contadas? Depende da razão para a existência da tabela agregada, que pode existir por razões de desempenho ou negócios. Razões de Desempenho Um conjunto de medidas pode ser criado à medida que os dados são carregados, pois do tempo requerido para que tais cálculos sejam feitos nos relatórios é muito grande. Nesse caso, estas tabelas agregadas não devem ser contadas como ALIs ou AIEs. Propósitos de Negócio Os usuários podem requerer que as tabelas agregadas sejam construídas para satisfazer um propósito funcional de negócios. Por exemplo, informações da fato nem sempre podem ser expressáveis no mesmo nível de detalhe; ou custos de remessa podem ser disponíveis ao nível de cliente da fatura de envio, mas não no nível da linha da fatura ou o nível do produto. Uma boa referência para mais exemplos é o The Data Warehouse Lifecycle Toolkit: Expert Methods for Desingning Developing and Deploying Data Warehouses por Ralph Kimball. Página 9 de 19

4 Pontos de Função e Data Warehouses de Empresas de Contagem - FP-380, Quality Plus Technologies, Inc. Figura 4 Depósito de Dados de Vendas Agrupados Figura 4 continua o exemplo da Mercearia com as Vendas do Estabelecimento Agrega armazenagem de dados que existe para o propósito do negócio 5 Tabelas Agregadas Esse tipo especial de tabela fato não contém medidas numéricas de negócio, mas ela documenta a existência de um evento. Para determinar se deve ser incluído na contagem de pontos de função, faça a análise funcional conforme esboçado nas regras do Manual de Práticas de Contagem Página 10 de 19

5 Pontos de função e Data Warehouses de Empresas de Contagem - FP-380, Quality Plus Technologies, Inc Figura 5 Armazenagem de Dados Existência/fato sem fatos Figura 5 mostra a tabela Transação da Mercearia um exemplo de uma armazenagem de dados Existência/fato sem fatos. 6 Essa tabela fato é usada para definir quais produtos serão oferecidos a quais estabelecimentos durante quais promoções. Essa tabela ajudará o analista na avaliação da eficácia de promoções ao identificar os estabelecimentos e produtos participantes. Similar a tabelas associativas encontradas no modelo relacional normalizado, tabelas de existência gerenciam exceções onde certos exemplos de uma tabela se relacionam a um ou mais outras tabelas. 7 Nesse exemplo, a entidade Promotion Products é uma tabela contável. A exigência em permitir rastrear promoções fica satisfeita com essa entidade. Isso define que produtos serão oferecidos ou foram oferecidos em quais estabelecimentos durante as promoções. A contagem resultante é um arquivo de baixa complexidade geralmente um ALI. A categorização do arquivo deve ser feito depois que as funções transacionais foram contadas. - Um Arquivo com um RET (Produtos de Promoção) - < 51 DETS Página 11 de 19

6 Pontos de função e Data Warehouses de Empresas de Contagem - FP-380, Quality Plus Technologies, Inc 7 Dimensional Data Modeling por Thomas J. Kelly, Principal Consultant, Data Warehouse Practice, Sybase Professional Services Tabelas dimensionais Tabelas dimensionais contêm as informações descritivas necessárias para permitir uma análise da informação relacionada a fato e contêm informações para permitir a verificação do carregamento dos dados. Tipicamente, uma tabela fato só conterá DETs que permitam uma medição em particular (na tabela fato) para ser considerada pelos campos nas tabelas dimensionais. Figura 6 Diagrama de Relacionamento da Entidade com várias dimensões Figura 6 mostra diagrama de relacionamento da entidade com várias dimensões Dimensões e Fatos Como eles Coexistem? Fisicamente, tabelas fato contêm só os DETs requeridos para representar alguma medida de negócios e são rodeadas pela mesma tabela física por DETs do tipo chave estrangeiras que conectam a dimensões de forma a permitir mais descrição de qualquer evento em particular. Ao contar os elementos dos dados para a inclusão da tabela fato todos os elementos de dados identificáveis do usuário na tabela de fato e os dados elementares das tabelas dimensionais que são requeridos para definir o registro da tabela de fatos. Página 12 de 19

Figura 7 Dimensões e Fatos Figura 7 mostra a combinação das dimensões e os dados da fato. 8 Tabelas de visualização Como as tabelas de visualização podem ser contadas? Basicamente, existem duas formas em que as tabelas de visualização podem ser contadas durante a análise do ponto de função. Processos elementares Se uma tabela de visualização é criada e enviada para fora do Data Warehouse para consumo de outro aplicativo (fronteira diferente de aplicativo) assim a transação pode ser contada como uma saída externa ou consulta externa para o aplicativo do Data Warehouse. Parte de um ou mais processos elementares Se a tabela de visualização é criada para uso do Data Warehouse então ela não deve ser contada como uma única função (processo elementar). A tabela de visualização deve ser analisada para determinar a fonte desses dados. As funções de dados usados para criar a tabela de visualização devem ser consideradas como um FTRs em potencial para determinar a complexidade das funções transacionais, que acessam aqueles dados em particular. Página 13 de 19

8 Pontos de função e Data Warehouses de Empresas de Contagem - FP-380, Quality Plus Technologies, Inc Metadados A forma mais simples, talvez não a mais clara, de descrever metadados é: Dados sobre dados. Os metadados proporcionam mais informação sobre o objeto que está sendo analisado. Os metadados são usados por dois grupos de pessoas em uma organização: usuários que desempenham análise relacionada a negócios e aqueles que desempenham análises relacionadas à técnica. Cada conjunto de usuários tem diferentes necessidades desde a configuração da aplicação até a definição de campos usados em um relatório específico. Metadados técnicos incluem: Descrição de tabelas Descrição de atributos Relações da entidade Regras de processamento de dados Relacionamento de chaves Categorias de metadados de negócios incluem: Dicionário de dados Proprietários de dados Informação assuntos da área Um dos elementos-chave, para ter em mente ao analisar os tipos de metadados para incluir em sua análise é quem foi definido como os usuários do aplicativo. Isso afeta a quantidade de arquivos que poderão existir. Funções de Transação Existem quatro categorias de transações/funções que são usados num Data Warehouse típico. São eles: Extrair, Transformar e Carregar dados Relatórios Funções Administrativas Funções de Metadados. ETL, ou Extrair Transformar e Carregar (ETL) é o conjunto de transações de banco de dados usado para extrair informações de um banco de dados, transformá-los e carregá-los em um segundo banco de dados. As fontes de dados para o Data Warehouse estão em aplicativos ou sistemas que são externos ao Data Warehouse (fora da fronteira). Dados de orgiem são extraídos ou recuperados de bancos de dados externos por processos no Data Warehouse. Uma vez que os dados são buscados da origem, são transformados usando regras de negócios fornecidas pelo usuário bem como pelo administrador do armazém de dados (Transform). Depois que os dados são transformados, eles são então carregados no Data Warehouse (Carrega ou Transporta). Página 14 de 19

Conta-se uma EE para cada Carregamento/Transporte de dados de aplicativo de origem que mantém um ou mais ALIs no Data Warehouse. Lembre-se que a intenção primeira dessas transações é manter dados lógicos no Data Warehouse ou alterar o comportamento do sistema. A lógica especial de processamento se aplica na transformação e carregamento de dados. Não conte três EEs separadas para cada passo do processo (ex.: uma EE de Extração, uma EE de Transformação, e uma EE de Carregamento), uma vez que todos os três são requeridos para completar o processo elementar. Conta um Arquivo referenciado (FTR) para cada ALI mantido. Conte um Arquivo referenciado (FTR) para cada leitura de ALI ou AIE durante o processamento da entrada externa. Conte só um Arquivo referenciado (FTR) para cada ALI que é mantido e lido. Conte um AIE para cada grupo lógico de dados que é copiado de um sistema de origem para o Data Warehouse sem nenhuma lógica especial de processamento. Nesse caso, também não conte uma EE para a extração de dados. (A exigência lógica é referenciar os dados. Os dados existem no Data Warehouse devido ao desempenho ou outras considerações de design/arquitetura do que uma necessidade do usuário de negócios.) Figura 8 Transação do armazém de dados Página 15 de 19

Figura 8 mostra uma transação que origina do aplicativo fonte e cruza a fronteira, a Staging Area, o ODS e finaliza no Data Warehouse. Relatório / Consulta Consultar e fazer relatórios sobre os dados contidos no Data Warehouse são importantes funções de negócios. O analista do ponto de função, precisa determinar quais funções de relatório ou consulta fazem parte do Data Warehouse e quais são considerados fora da fronteira. Existem pelo menos duas categorias de relatórios: relatórios adhoc e programados. Relatórios adhoc representam uma solicitação a cada vez com parâmetros diferentes selecionados pelo usuário, enquanto relatórios programados são criados periodicamente (diariamente, semanalmente, mensalmente) e, tipicamente, não podem ser modificados pelos usuários. Relatórios programados geralmente requerem uma análise formalizada e um ciclo de vida de desenvolvimento. Como tal, relatórios programados são geralmente contados pelo contador do ponto de função enquanto relatórios adhoc, criados por um usuário final, não podem ser contados. Uma exceção a essa orientação seria contar a funcionalidade oferecida ao usuário para criar seus próprios relatórios adhoc. Os dois exemplos seguintes de ferramentas de relatório podem ser usados para criar relatórios adhoc e padrão. 1. Ferramenta de Relatório internamente desenvolvida: Essa ferramenta é criada por desenvolvedores para suportar usuários do Data Warehouse. A fronteira de contagem determina se a ferramenta de relatório desenvolvida é contada como um componente do Data Warehouse ou um aplicativo separado. Se os usuários vêem a ferramenta como parte do Data Warehouse, deve ser considerada estando dentro da fronteira do Data Warehouse. Outras áreas que podem influenciar a decisão de incluir a ferramenta como componente do Data Warehouse são a lógica de processamento e localização/manutenção dos dados lógicos que suportam os relatórios. Supondo que a ferramenta de relatório desenvolvida se estabelece dentro dos limites do Data Warehouse, conte pelo menos uma SE (EO) ou CE (EQ) para cada relatório ou consulta desenvolvida e/ou suportada para satisfazer as necessidades do usuário. Siga as orientações CPM para determinar se o relatório ou consulta é um processo elementar único. 2. Software Comercial de prateleira (COTS)/Ferramenta de Relatório Comprada (ex.:. Relatórios Crystal, Cognos, Business Objects, etc): Para contagens de desenvolvimento e melhoria, um contador do ponto de função deve contar só as funções que foram personalizadas ou feitas para o usuário de negócios ou administrativo. Se há uma necessidade ou solicitação de negócios para contar todo o portfólio de funções do software, (por exemplo, para avaliar as características ou funções Página 16 de 19

proporcionadas pelo COTS), COTS e as funções personalizadas podem ser contados, mas o portfólio deve ser considerado um limite de aplicativo separado do Data Warehouse, contado como um aplicativo separado, e categorizado de acordo. Conte um SE (EO) ou CE (EQ) para cada relatório ou consulta desenvolvida e/ou suportada para satisfazer as necessidades do usuário. Siga as orientações CPM para determinar se o relatório ou consulta é um processo elementar único. Funções Administrativas Data Warehouses possuem inúmeras funções administrativas. Enquanto muitas são técnicas por natureza e requeridas para manter o Data Warehouse ativo e operante; algumas são de natureza de negócios e podem ser contadas. Perguntas que o contador pode fazer para ajudar a determinar se uma função administrativa é de lógica técnica ou de negócios incluem: As funções foram desenvolvidas para suportar um usuário do aplicativo (ex.: administrador do sistema, arquiteto de dados)? Existem exigências únicas de segurança (ex.: logins, segmentação de acesso por permissões, senhas)? Supondo que o contador possa responder as questões acima afirmativamente: Conte um EE (EI) para cada função única administrativa (ex.: segurança, questões do usuário) que mantém um ALI ou modifica o comportamento do sistema Conte uma SE (EO) ou CE (EQ) para relatórios produzidos para suportar essas funções. Use regras de CPM para determinar os tipos de transação Metadados Metadados são geralmente definidos como dados sobre dados. Em um Data Warehouse pode haver pelo menos dois tipos: Informação que suporta as características, funções e dados de negócios (ex.: dicionário de dados) Informação que suporta as funções técnicas do Data Warehouse (ex.: programações para backups ou ajustes de desempenho). É importante revisar e entender o propósito e objetivos da Contagem do Ponto de Função, na medida em que isso irá clarear quem são os usuários e que funcionalidade de usuário pode ser considerada. Ambos os tipos de metadados exigem a assistência de um administrador. A partir de uma perspectiva de dados de negócios, pode-se incluir um arquiteto de dados. A partir de uma perspectiva técnica que poderia incluir um administrador do sistema. Ao tentar analisar quais características e funções desempenhadas nessas capacidades administrativas são contadas, é útil fazer as seguintes questões: 1. As funções de metadados foram desenvolvidas para apoiar um usuário do aplicativo? Se a resposta é sim, conte um EE (EI) para cada função única mantendo os metadados, e conte uma SE (EO) ou CE (EQ) para os relatórios de metadados produzidos. Página 17 de 19

2. As funções metadados foram desenvolvidas para suportar funções ou características técnicas opostas à lógica de negócios? Se a resposta é sim, essas funções não são contadas. Elas foram criadas por propósitos técnicos. Conclusão Data Warehouses não são uma tecnologia nova; muitas empresas grandes e pequenas as usam. Porém, muitas empresas acham difícil gerenciá-las por conta própria, particularmente em épocas de angústia por crescimento rápido. A medida que mais e mais empresas dependem de seus Data Warehouses para proporcionar a real visão de seus negócios, esse gerenciamento se torna um elemento crítico para seu sucesso contínuo, e mesmo a sobrevivência contínua. A única natureza dos Data Warehouses apresenta o Analista do Ponto de Função com um número de desafios a fornecer essas empresas dados de tamanhos precisos e métricas relacionadas que podem ser usados para tomar as melhores decisões possíveis. O analista pode aplicar as dicas dadas neste white paper com às regras de contagem no CPM para ajudálo a desenvolver uma contagem mais precisa do ponto de função. Página 18 de 19

Gostaríamos de agradecer os seguintes membros do IFPUG que contribuíram com materiais que foram usados na preparação desse documento. 1. Guidelines for Counting Data Warehouses Ewa Wasylkowski, CFPS & Pam Morris, CFPS; January 2005 Ewa Wasylkowski, Senior Metrics Consultant, Total Metrics ewa.wasylkowski@totalmetrics.com; Pam Morris, Managing Director, Total Metrics pam.morris@totalmetrics.com www.totalmetrics.com 2. Size & Estimation of Data Warehouses Luca Santillo, CFPS, Metrics Consultant presented at FESMA-DASMA Conference in 2001 luca.santillo@gmail.com 3. Guidelines followed for Estimating Data Warehouse Projects Lavanya Kaul, CFPS; January 2005 NIIT Technologies, Ltd., New Delhi, India PLavanya@NIIT.com 4. Function Points & Counting Enterprise Data Warehouses FP-380 4.2 Workshop Materials and Case Studies Carol Dekkers; CFPS, January 2005 Carol Dekkers, CMC, CFPS; President, Quality Plus Technologies, Inc. www.qualityplustech.com 5. Defining Application Boundaries: Data Warehouses and Data Marts Chris Kohnz CFPS, September 2004 Personal White Paper Chris@Kohnz.com 6. Data Warehouses and Function Points Chris Kohnz, CFPS presented at IFPUG Annual Conference in 2004 Chris@Kohnz.com Página 19 de 19