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

(1)

NEC White Paper

Copyright IFPUG 2007

NEC White Paper New Environments Committee

Página 1 de 19

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.

(2)

Página 2 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

(3)

NEC White Paper

Página 3 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.

(4)

Página 4 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ção1_.

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 contagem2_.

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.

(5)

NEC White Paper

Página 5 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.

(6)

Página 6 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

(7)

NEC White Paper

Página 7 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.

(8)

Página 8 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 esquema3_{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

(9)

NEC White Paper

Página 9 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.

(10)

Página 10 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ócio5

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

(11)

NEC White Paper

Página 11 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

(12)

Página 12 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.

(13)

NEC White Paper

Página 13 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.

(14)

Página 14 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).

(15)

NEC White Paper

Página 15 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.)

(16)

Página 16 de 19

Figura 8 mostra uma transação que origina do aplicativo fonte e cruza a fronteira, aStaging 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

(17)

NEC White Paper

Página 17 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.

(18)

Página 18 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.

(19)

NEC White Paper

Página 19 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