Medição de Tamanho para Sistemas de Data Mart

__________________________________________________________________________
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ós-

Graduaçã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

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

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
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
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 Dados e aplicações analíticos
Conteúdo dos dados Valores unitários 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, próprio para computação Dimensional, simplificado, próprio para
dados transacional atividades analíticas
Atualização dos dados Atualização campo a campo Atualização em lotes
Uso dos dados Altamente estruturado, processamento Desestruturado, com processamento
repetitivo analítico/ heurístico
Natureza dos dados Detalhada Detalhada e sumarizada
Dados derivados e Raros Comuns
agregados
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
(OLAP)
Tamanho das fontes de Gigabyte Gigabyte-terabyte
dados
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
aplicações
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
aplicações
Foco das aplicações Registros individuais Milhões de registros
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 Data Área de Ferramentas

operacionais staging apresentação de acesso
de origem area de dados a dados
Data Mart número 1:

Serviços:
Dados dimensionais Ferramentas de
Filtrar, combinar e
Extrair atômicos e de resumo consultas
padronizar
baseados em um único Acessar específicas
dimensões em Carregar
conformidade processo de negócio
Criadores de
Extrair Armazenamento de relatórios
dados: tabelas
relacionais e Barramento do
arquivos simples DW: fatos e
dimensões em Modelagem:
conformidade Previsão,
Processamento: pontuação e
classificação e exploração de
Extrair processamento Data Mart número 2: dados
seqüencial (projetado da mesma
Carregar forma) Acessar
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 Suporte à decisão
ODS DM
Bases de aplicações
Extração,
DW OLAP
transferência,
agregação, Relatórios
ERP etc Análises estatísticas
Desktop data Análises financeiras
External data
DM
Web based data
Referência repositório da
Repositórios ferramentas Repositório empresa Metadados 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.
Meses
1 2 3
Produtos
Refrigerante
Leite
Creme
Sopa
Fortaleza
Localizaçãos
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 Tabela fato Tabela

dimensão Vendas dimensão
Cliente 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
Tabela
dimensão
dimensão
Produto
Estado
Tabela Tabela Tabela

dimensão fato dimensão
Cliente Vendas 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
implementação do repositório de dados
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
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 Projeto Modelo de

tecnológica preliminar dados
Data Mart
Projeto físico
do banco de
dados
Exploração
data
Re- Sistema de
warehouse
especificação registro
Acesso
Carga no
usuário final ,
sistema
análise
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.
Projeto Seleção e
técnico de instalação do
arquitetura produto
Projeto e
Modelagem Manutenção e
Definição dos Projeto físico desenvolvimento Distribuição
Planejamento dimensional da data staging crescimento
requisitos do
do projeto
negócio
Especificação Desenvolvimento
da aplicação da aplicação
analítica
analítica
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 Esquema operacional

especificação da base de dados
Conceitos de negócio
semiformal
Projeto conceitual
Esquema conceitual formal
Projeto lógico
Esquema formal lógico
Esquema físico do banco de

Projeto físico
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, trabalho de carga Projetistas e usuários finais
requisitos preliminar
Projeto Esquema database, fatos, Esquema dimensional Projetistas
conceitual trabalho de carga preliminar
Refinamento do Esquema dimensional, trabalho Trabalho de carga Projetistas e usuário final
trabalho de de carga preliminar
carga, validação
do esquema
dimensional
Projeto lógico Esquema dimensional, modelo DW esquema lógico Projetistas
lógico direcionado, trabalho de
carga
Projeto físico DW esquema lógico, Banco e DW esquema físico Projetistas
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 Hierarquia
Fato: Vendas cidade

estoque 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 de etapas de alto nível(aspectos
Infra-estrutura tecnológica implementacionais)
Projeto preliminar Processo iterativo
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 de gerenciamento do Identificação de etapas de alto nível (aspectos
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
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
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 Proposta de um Modelo de fato dimensional - DFM
(1999) 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 Exemplo Possível intervalo
Nominal O valor do atributo é representado por um nome ou Cor Vermelho, amarelo,
rótulo. Não possuem nenhuma relação de ordem entre os 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
ordenada.
Ordinal Acrescenta a noção de ordem à escala nominal. Complexidade da Baixa, média e alta
aplicação
Ordinal não Acrescentaa noção de ordem à escala não-nominal. Rank ordenado de 1 a 20
restrita clubes de futebol
Intervalo 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

0 ou 1 ALR Simples Simples Média
2 ALR Simples Média Complexa
3 ALR em diante Média Complexa Complexa
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
0 ou 1 ALR Simples Simples 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 Características gerais Definição da característica
não- 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 Aspectos relacionados com a eficiência do aplicativo na interação
usuário 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 Aspectos relacionados com a reutilização do código do aplicativo;
Qualidade Reutilização do código 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.
Projeto Projeto
Requisitos Codificação Teste Implementação Manutenção
inicial detalhado
Contagem Contagem Contagem Contagem 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 nessa
abordagem e, posteriormente, também computadas para 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 Necessita definir Identificar

funcionais tamanho subconjunto camada de
requisitos?
do usuário softwares
Definir
propósito, Identificar a
escopo e ponto fronteira do
de vista de software
mensuração
Identificar
processos
funcionais
FUR no
Identificar grupo
modelo
de dados
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
Movimento Descrição
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,
a pontuação dos processos de log e estatísticos.
20
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.
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
Características
Modelo Algorítmo Algorítmo Funcional Funcional Funcional Funcional
Possibilidade Não Não Sim Sim Sim Sim
estimativa no inicio
do projeto
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
da abordagem
Possibilidade Não Não Segundo a Segundo a Segundo a Não
aplicação em todas métrica sim, mas métrica sim, mas métrica sim,
as tecnologias existem existem mas existem
questionamentos questionamentos questionamentos
Proposta especifica Não Não Não Não Não Sim
para adequação à
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
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%
22
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 Projeto
Requisitos Codificação Teste Implementação Manutenção
inicial detalhado
Projeto Seleção e
arquitetura produto
Projeto e Manutenção
Modelagem
Definição dos Projeto físico desenvolvimento Distribuição e
Planejamento dimensional da data staging
requisitos do crescimento
do projeto
negócio
analítica
analítica
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ão-
utilizaçã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 Proposta Santillo

mas
ALI AIE EE SE CE IF PFN FA PFA
I1S1 120 48 168,00 1 168,00
I1S2 240 96 336,00 1 336,00
I1S3 195 78 273,00 1 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 Qtd PF (Proposta Tempo
em meses Santillo) estimado
em meses
(Proposta
Santillo)
I1S1 10 6 168,00 2,54
I1S2 8 /9 7 336,00 4,36
I1S3 19 5 273,00 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
5 Tempo estimado Santillo
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.
26
É 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.
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ão-
ajustado. 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 Itens de Influência Justificativa
Processamento Aspectos 0. O aplicativo não auxilia na transferência de dados ou funções O processo de Data Mart
distribuído relacionados entre os processadores envolvidos. prepara dados para leitura
com 1. O aplicativo prepara dados para que o usuário final os utilize do usuário final em outra
processamento em outro processador (planilhas de cálculo, por exemplo). ferramenta, no caso uma
e funções 2. O aplicativo prepara dados e os transfere para que outros ferramenta OLAP ou na
distribuídas. 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 0. Nenhum requisito especial de performance foi solicitado pelo É aplicável ao projeto de
relacionados a usuário. Data Mart que trabalha com
parâmetros 1. Requisitos de desempenho foram estabelecidos e revistos mas volumes altos de transações,
estabelecidos nenhuma ação especial foi requerida. mesmo que sejam
pelo usuário 2. Tempo de resposta e volume de processamento são itens transações efetuadas por
quanto a críticos durante horários de pico de processamento. Porém , ferramentas OLAP.
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
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 em qualquer
reutilização do 2. Menos de 10% do código do aplicativo foi projetado para ser contexto de software.
código do utilizado em outros aplicativos.
aplicativo. 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 quando
Operacional relacionados normal de salvamento de dados. direcionado aos
com a 1 a 4 - determinado de acordo com os itens abaixo: procedimentos batch de
facilidade de Foram desenvolvidos procedimentos de iniciação, salvamento e extração e carga.
operação do recuperação, mas a intervenção do operador é necessária.
aplicativo. Foram desenvolvidos procedimentos de iniciação, salvamento e
Avalia recuperação, sem necessidade de intervenção do operador (vale
procedimentos dois itens).
operacionais O aplicativo minimiza a necessidade de montar fitas
automáticos e magnéticas.
mecanismos O aplicativo minimiza a necessidade de manuseio de papel.
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.
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 de ferramentas OLAP que acessam o 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.
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ão-
funcionais 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 de Estão disponíveis facilidades como consultas e relatórios flexíveis para atender a
itens mudanças 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.
graduação de 2. Aplicativo batch com entrada e saída de dados remota.
complexidade 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.

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
74

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

metadados;
metadados;
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;
/carga;
/carga;
3. quando houver previsão de 30% a 40% de atualizações arquivos de extração
/carga;
/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
Medida de capacidade de armazenamento do computador, representando aproximadamente um bilhão de bytes.
34
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.
Projeto Seleção e
arquitetura produto
Modelagem
do projeto
negócio
analítica
analítica
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 I1S7 Em desenvolvimento
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 APF Proposta
ALI AIE EE SE CE IF PFN FA PFA ALI AIE EE SE CE IF PFN FA PFA
I1S1 252 5 110 13 367 0,78 286,26 504 5 110 40 619 1,07 662,33
I1S2 252 24 116 13 392 0,78 305,76 504 24 116 39 644 1,06 682,64
I1S3 507 7 234 14 748 0,79 590,92 1014 7 234 43 1255 1,1 1380,50
I1S4 87 7 41 15 135 0,80 108,00 167 7 41 40 215 1,07 230,05
I1S5 112 7 50 11 169 0,76 128,44 224 7 50 41 281 1,08 303,48
I1S6 91 14 40 10 145 0,75 108,75 182 14 40 23 236 0,9 212,40
I2S1 0 0 80 8 80 0,73 58,40 151 80 21 231 0,88 203,28
I3S1 105 65 48 6 218 0,71 154,78 210 65 48 17 323 0,84 271,32
I3S2 175 132 78 143 8 528 0,73 385,44 350 132 78 143 28 703 0,95 667,85
I3S3 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 Tempo
em meses utilizados APF estimado APF Proposta estimado
em meses Proposta em
meses
I1S1 10 6 286,26 4,33 662,33 10,03
I1S2 8,5 7 305,76 3,97 682,64 8,86
I1S3 19 5 590,92 10,74 1380,5 25,1
I1S4 10,5 2 108,00 4,9 230,05 10,45
I1S5 5,5 4,2 128,44 2,78 303,48 6,56
I1S6 8 2 108,75 4,94 212,40 9,65
I2S1 1,5 5 58,4 0,53 203,28 1,84
I3S1 3,0 3 154,78 1,99 271,32 3,49
I3S2 6 4 385,44 3,72 667,85 6,44
I3S3 4 1,3 42,60 1,26 168,21 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.
Projeto Seleção e
arquitetura produto
Modelagem
do projeto
negócio
analítica
analítica
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 estimado PF Proposta Tempo

APF estimado
proposta
I1 I1S7 153,30 2,78 357,00 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
800
PF
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.
37
É 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.
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.
Valores mínimos e máximos da amostra estudada.
40
Software comercial que possui um conjunto de ferramentas estatísticas
93
Tabela 4.8 - Estatísticas descritivas
Estatísticas Descritivas
95% Intervalo de confiança para a média

Tratamentos N Média Desvio Padrão Erro Padrão Mínimo Máximo
Limite Inferior Limite Superior
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 Graus de Quadrado
p-valor
Quadrados Liberdade Médio
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
Diferença 95% Intervalo de confiança
Erro
Entre as Médias Sigcalc.
Padrão
(I)Tratamento (J)Tratamento (I-J)
Limite Inferior Limite Superior
Tempo Apf 4,3664(*) 1,5455 0,023 0,5344 8,1984

Tempo Real
Tempo proposta 0,4949 1,5455 0,945 -3,3371 4,3269
Tempo Proposta Tempo Apf 3,8715(*) 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 ª
Subgrupos para α45 = 0.05

Tratamentos N
Médias Médias
Tempo Apf 10 3,2336
Tempo proposta 10 7,1051
Tempo Real 10 7,6000
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.
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: McGraw-
Hill, 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/cgi-

bin/litlib.cgi?URL=TowersPerrin.pdf>. Acesso em 08/08/2003.
BROKAW, Erik. Aquila. Disponível no site < http://www.ascentialsoftware.com/cgi-

bin/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. 121-
132, 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ós-
Graduaçã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. 58-

65, 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
___________________________________________________________________________
Item de
Características gerais Níveis de influência
Influência
1 0. O aplicativo não auxilia na transferência de

Processamento distribuído de dados dados ou funções entre os processadores
Aspectos relacionados com envolvidos;
processamento e funções distribuídas. 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. Nenhum requerimento especial de
Desempenho/Performance performance foi solicitado pelo usuário;
Aspectos relacionados a parâmetros 1. Requerimentos de performance foram
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
Item de
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 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.
3 0. quando é utilizada ferramenta para 100% do
Utilização de ferramenta apropriada processo de extração/transformação/carga;
para extração e carga 1. quando é utilizada ferramenta para até 80% do
Indica o nível de automatização e processo de extração/transformação/carga
complexidade do processo de Data Mart 2. quando é utilizada ferramenta para até 60% do
processo de extração/transformação/carga;
3. quando é utilizada ferramenta para até 40% do
4. quando é utilizada ferramenta para até 20% do
5. quando nenhuma ferramenta é utilizada para
extração/transformação/carga dos dados
transacionais
4 0. Não se aplica
Quantidade de sistemas transacionais 1. quando o projeto envolve 1 sistema
envolvidos no projeto transacional;
Descreve o grau em que a quantidade de 2. quando o projeto envolve de 2 a 3 sistemas
interfaces com outros sistemas transacionais;
influenciará o desenvolvimento da 3. quando o projeto envolve de 4 a 5 sistemas
aplicação. transacionais
Quando a quantidade de sistemas 4. quando o projeto envolve de 6 a 7 sistemas
transacionais é alto, influencia o projeto, transacionais;
desenvolvimento, implantação e suporte 5. quando o projeto envolve mais de 8 sistemas
da aplicação. transacionais.
5 0. quando todos os sistemas de origem possuem
112
Item de
Influência
Documentação dos sistemas metadados;

transacionais de origem (Existência de 1. quando acima de 90% dos sistemas de origem
Metadados dos sistemas de origem) possuem meta dados;
Nível de documentação dos sistemas de 2. quando acima de 70% dos sistemas de origem
origem, de forma a identificar a existência 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. De quatro a cinco quantidades de agregação
desempenho das consultas do usuário identificadas;
final 4. Seis ou sete quantidades de agregação
identificadas;
5. Oito ou mais quantidades de agregação
identificadas.
7 0. quando houver previsão de 0% a 10% de
Freqüência de atualização das fontes de atualizações dos arquivos de extração /carga;
dados 1. quando houver atualizações de 10% a 20% dos
Descreve o grau em que os sistemas arquivos de extração /carga;
transacionais são alterados implicando em 2. quando houver atualizações de 20% a 30% dos
constantes alterações nas aplicações de 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
Item de
Influência
rejeitados, erro de conteúdo, etc. 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
2. quando ocorrer de três a quatro das
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
Item de
Influência
9 0. Nenhuma preocupação com reutilização de

Reusabilidade de código 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 0. Não se aplica;
Definição da estrutura em que estão os 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. quando existir mais de quatro estruturas.
11 0 Nenhuma consideração especial de operação
Facilidade operacional 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
Item de
Influência
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.
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.
___________________________________________________________________________
Item de
Características gerais Níveis de influência Influência
1 0 Aplicativo batch ou stand alone;

Comunicação de dados 1 Aplicativo batch com entrada ou saída de dados
Aspectos relacionados aos recursos remota;
2 Aplicativo batch com entrada de dados e saída de
utilizados na comunicação de dados do
dados remotas;
aplicativo. É importante determinar que 3 Aplicativo com entrada de dados on-line para
alimentar processamento batch;
protocolos são utilizados pelo aplicativo para
4 Aplicativo com entrada de dados on-line, suportando
o recebimento ou envio de informações. apenas um tipo de protocolo de comunicação;
5 Aplicativo com entrada de dados on-line, suportando
vários tipos de protocolo.
2 0 Aplicativo não auxilia na transferência de dados ou
funções entre os processadores envolvidos;
Processamento distribuído de dados
1 Aplicativo prepara dados para que o usuário final os
Aspectos relacionados com processamento utilize em outro processador (planilhas de cálculo,
por exemplo);
e funções distribuídas.
2 Aplicativo prepara dados e os transfere para que
Comentários: outros equipamentos os utilizem;
3 Processamento é distribuído e a transferência de
Leitura via client ou via Internet ou Intranet
dados acontece de forma on-line apenas em uma
pode receber o valor 2 a 4. 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.
3 0 Nenhum requerimento especial de performance foi
solicitado pelo usuário;
Desempenho/Performance
1 Requerimentos de performance foram estabelecidos e
Aspectos relacionados a parâmetros revistos, mas nenhuma ação especial foi requerida;
2 Tempo de resposta e volume de processamento são
estabelecidos pelo usuário quanto a
itens críticos durante horários de pico de
tempos de resposta. 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.
117
Item de
4 0 Não há restrições operacionais

Utilização do equipamento 1 Existem poucas restrições de caráter operacional; não
Aspectos relacionados com o nível há necessidade de esforço adicional para implementar
o aplicativo.
de utilização dos equipamentos necessários à
2 Algumas considerações de ajuste de performance e
execução do aplicativo. A Avaliação visa de segurança precisam estar implementadas
3 Existem especificações especiais que precisam ser
identificar a carga de trabalho exigida pelo
observadas para módulos específicos do aplicativo.
aplicativo quando em produção 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.
5 0 Não há previsão de períodos com grande volume de
Volume de transações transações;
Aspectos relacionados com a capacidade do 1 Estão previstos grandes volumes de transações
sistema em relação ao volume de transações mensais, trimestrais, anuais ou em determinado
esperado 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.
6 0 Todas as transações previstas no aplicativo são
Entrada de dados on-line processadas em modo batch.
Aspectos relacionados com a quantidade de 1 1% a 7% das transações são entradas de dados on-line
entrada de dados on-line do aplicativo. 2 8% a 15% das transações são entradas de dados on-
line.
3 16% a 23% das transações são entradas de dados on-
line.
4 24%a 30% das transações são entradas de dados on-
line.
5 Acima de 30% das transações são processadas em
modo on-line.
7 • Auxílio de navegação (teclas de função, acesso

Interface com o usuário direto e menus dinâmicos);
Aspectos relacionados com a eficiência do • Menus;
aplicativo na interação com o usuário. A • Documentação e ajuda on-line;
pontuação é decidida quantos aos recursos • Movimento automático de cursor;
implementados para tornar o aplicativo • Movimento horizontal e vertical da tela;
amigável. 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 on-
line através de hard copy;
• Utilização de mouse;
• Menus pop up;
118
Item de
Pontuação:
0 Nenhum item contado;

1 De um a três itens contados;
2 De quatro a cinco itens contados;
3 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.
8 0 Nenhuma atualização on line;
Atualização on-line 1 Atualização on-line de 1 a 3 arquivos lógicos
Aspectos relacionados com o modo de internos.O volume de atualizações é baixo e a
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.
do processamento. Detalhes específicos • O aplicativo trabalha com processamento lógico
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.
10 0 Nenhuma preocupação com reutilização de código.
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.
119
Item de
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.
11 0 Nenhuma consideração especial estabelecida pelo
Facilidade de Implantação usuário. Não há procedimentos especiais requeridos
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.
usuário. O impacto da conversão do aplicativo é de
vital importância.
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.
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.
12 0 Nenhuma consideração especial de operação além do
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.
13 0 Os requerimentos do usuário não consideram a
Múltiplas instalações (locais) possibilidade de instalação do aplicativo em mais de
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
120
Item de
ambientes similares em hardware e software.

locais foi considerada no projeto, estando o aplicativo
apto a operar em diferentes ambientes de hardware e
software.
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.
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 • Estão disponíveis facilidades como consultas e

Facilidade de mudança relatórios flexíveis para atender a necessidades
Aspectos relacionados com o grau de simples;
flexibilidade do aplicativo com relação a • Estão disponíveis facilidades como consultas e
mudanças nos requisitos do usuário. 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.
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, Rildo Ribeiro dos Santos

Caixa Econômica Federal Univ. Católica de Brasília Univ. Católica de Brasília
angelica.calazans@caixa.gov.br kathia@ucb.br, rildors@uol.com.br
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, size estimation, Function Point
Analysis.
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 Data Área de Ferramentas
Operacionais Staging Apresentação de acesso
De origem Área de dados a dados
Serviços: Data Mart número 1: Ferramentas de

Filtrar, combinar e Dados dimensionais consultas
Extrair Acessar específicas
padronizar atômicos e de resumo
dimensões de Carregar baseados em um único
conformidade processo de negócio
Criadores de
Armazenamento de relatórios
dados: tabelas
Extrair relacionais e
arquivos simples Barramento do Modelagem:
DW: fatos e Previsão, pontuaç
Processamento: decisões em ao e exploração de
dados
classificação e conformidade
processamento
Extrair sequencial
Data Mart número 2:
Carregar (projetado da mesma
Acessar
forma)
Figura 1 – Elementos básicos do Data Warehouse [8]

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 Baixa Média Alta

EE 3 4 6
SE 4 5 7
CE 3 4 6
ALI 7 10 15
AIE 5 7 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
1 O aplicativo não auxilia na transferência de dados ou funções
Processamento distribuído de dados entre os processadores envolvidos;
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.
2 Nenhum requerimento especial de performance foi solicitado pelo
Desempenho/Performance usuário;
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.
3 quando é utilizada ferramenta para 100% do processo de extração
Utilização de ferramenta apropriada para e/ou carga;
extração e carga quando é utilizada ferramenta para 80% do processo de extração
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

aplicabilidade
transacionais é alto, influencia o projeto,
desenvolvimento, implantação e suporte da
aplicação.
5 quando todos os sistemas de origem possuem metadados;
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;
sistemas de origem) quando 50% dos sistemas de origem possuem metadados;
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.
6 nenhum nível de agregação identificado;
Quantidade de agregação substituindo Um nível de agregação identificado;
Eficiência do usuário final De dois a três quantidades de agregação identificadas;
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
7 quando não houver previsão;

Freqüência de atualização das fontes de quando houver atualizações de 10% a 20% dos arquivos de
dados extração /carga;
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.
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 substitutas para cada
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

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;
9 Nenhuma preocupação com reutilização de código.
Reusabilidade de código Reutilização de código apenas no aplicativo.
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
Estrutura dos dados de origem quando existir uma única 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.
11 0 Nenhuma consideração especial de operação além do processo
Facilidade operacional normal de salvamento de dados;
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
Volume de dados 1 Baixo
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 Proposta de Adequação

Qtd Tempo
Sistema Ponto Função Tempo Ponto Função Tempo
recurso real
estimado estimado
SIST. 1 5 19 meses 590,92 10,74 meses 1355,40 24,64 meses
SIST. 2 7 8 a 9305,76 3,97 meses 669,76 8,69 meses
meses
SIST. 3 6 10 meses 286,26 4,33 meses 649,95 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.

Medição de Tamanho para Sistemas de Data Mart

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Medição de Tamanho para Sistemas de Data Mart

Hochgeladen von

Copyright:

Verfügbare Formate

__________________________________________________________________________

Medição de Tamanho para

MEDIÇÃO DE TAMANHO PARA SISTEMAS DE DATA MART

Dissertação submetida ao Programa de Pós-

Orientadores: Profa. Dra. Káthia Marçal de Oliveira

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

Profa. Dra. Káthia Marçal de Oliveira

Prof. Dr. Rildo Ribeiro dos Santos

Prof. Dr. Ricardo de Almeida Falbo

Prof. Dr. Hércules Prado

Prof. Dr. Nicolas Anquetil

Para melhor controlar tempo, custo e recursos em projetos de software as organizações

CAPÍTULO 1 - INTRODUÇÃO ............................................................................................. 1

CAPÍTULO 2 - SISTEMAS DE DATA WAREHOUSE/DATA MART ................................ 6

CAPÍTULO 3 - MEDIÇÃO DE TAMANHO DE SOFTWARE ......................................... 30

CAPÍTULO 4 - PROPOSTA DE MEDIÇÃO DE TAMANHO PARA DATA MART ..... 50

CAPÍTULO 5 - CONCLUSÕES E TRABALHOS FUTUROS.......................................... 98

REFERÊNCIAS BIBLIOGRÁFICAS................................................................................ 101

APÊNDICE A - ENTREVISTA ESTRUTURADA PARA LEVANTAMENTO DOS

APÊNDICE B - CARACTERÍSTICAS GERAIS ADEQUADAS A TECNOLOGIA DE

APÊNDICE C - CARACTERÍSTICAS GERAIS APF.................................................... 116

APÊNDICE D - ARTIGO PUBLICADO NO II SIMPÓSIO BRASILEIRO DE

APÊNDICE E - ARTIGO PUBLICADO NA DEVELOPERS´MAGAZINE, 2003...... 134

Figura 2. 1 - Elementos básicos do Data Warehouse ............................................................... 12

Quadro 2.1 - Dados e aplicações transacionais x Dados e aplicações analíticos........................ 8

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

O processo de mensurar o tamanho de um software ainda está muito pouco

1.2 OBJETIVOS E METODOLOGIA

Esta dissertação tem por objetivo a definição de uma proposta de mensuração de

1.2.1 Classificação da pesquisa

caso circunscrito aos projetos possíveis de serem mensurados em três instituições

As seguintes suposições foram elaboradas:

1.2.3 Coleta e análise de dados

Foram coletados dados em três instituições governamentais instaladas em Brasília,

1.3 ESTRUTURA DA DISSERTAÇÃO

CAPÍTULO 2 - SISTEMAS DE DATA WAREHOUSE/DATA MART

Para melhor entender a importância e a peculiaridade de sistemas de Data Warehouse,

2.2 SISTEMAS TRANSACIONAIS E SISTEMAS ANALÍTICOS

Um dos primeiros obstáculos para a construção de um Data Warehouse é a dificuldade

forma múltipla e combinada, permitindo inferência, busca de informações e reconhecimento

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

2.3 DATA WAREHOUSE E DATA MART

diferentes. No Data Mart as informações estão em maior nível de sumarização e normalmente

conceito de integração que é a base do Data Warehouse e possuem problemas de

2.4 ARQUITETURA DO AMBIENTE

Existem quatro componentes separados e distintos no ambiente de Data Warehouse

de Data Mart, baseados em um processo de negócio e que futuramente, se tiverem

Sistemas Data Área de Ferramentas

Data Mart número 1:

Figura 2. 1 - Elementos básicos do Data Warehouse

Já Watterson (1998) é mais detalhista, e identifica conforme Figura 2.2, os seguintes

Warehouse, os Data Mart ou mesmo um ODS4, se a arquitetura proposta trabalha

Origem dos dados Staging area Data Warehouse Suporte à decisão

Gerenciamento dos sistemas e Banco de dados

Figura 2.2 - Arquitetura de Data Warehouse

Existem outras propostas de arquitetura como a abordagem de Moody e Kortink

2.5 PROCESSO DE DATA WAREHOUSING

Os processos básicos para se criar e atualizar um Data Warehouse/Data Mart incluem,