CENTRO EDUCACIONAL DA FUNDAÇÃO SALVADOR ARENA
FACULDADE DE TECNOLOGIA TERMOMECANICA
LEONARDO HENRIQUE ZANAROLLI DE OLIVEIRA
MARCOS DE FREITAS JUNIOR
MAURÍCIO MOURA ARAÚJO
Estudo Sobre a Técnica de Análise de Pontos de Função
São Bernardo do Campo
2012
LEONARDO HENRIQUE ZANAROLLI DE OLIVEIRA
MARCOS DE FREITAS JUNIOR
MAURÍCIO MOURA ARAÚJO
Estudo Sobre a Técnica de Análise de Pontos de Função
Trabalho de Conclusão de Curso, realizado
sob orientação da Prof. Dra. Violeta Sun,
apresentado à Faculdade de Tecnologia
Termomecanica como requisito para obtenção
do título de Tecnólogo em Análise e
Desenvolvimento de Sistemas.
São Bernardo do Campo
2012
Leonardo Henrique Zanarolli de Oliveira
Marcos Freitas de Junior
Maurício Moura Araújo
Estudo Sobre a Técnica de Análise de Pontos de Função
Trabalho de Conclusão de Curso – Faculdade de Tecnologia Termomecânica
Comissão Julgadora
Professora Dra. Violeta Sun
Professor Msc. João Caldas
Professor Dr. Edmir Parada Vasques Prado
São Bernardo do Campo
2012
AGRADECIMENTOS
Agradecimentos serão, nesse momento, nosso singelo reconhecimento a aqueles que,
de forma direta ou indireta, nos ajudaram a construir este trabalho. Singelo pelo fato de que
esta monografia é, para nós, o resultado de uma formação acadêmica intensa e gratificante ao
lado de grandes colegas.
Em primeiro lugar, agradecemos à nossa orientadora Violeta Sun, que nos acolheu
sem receios e nos possibilitou desenvolver um grande trabalho por meio de seus
aconselhamentos e de sua experiência.
Não poderíamos deixar de agradecer também aos professores do curso, que exigiram
de nós a dedicação aos estudos e que nos fizeram compreender o real valor do conhecimento,
não só para a realização profissional como para a vida.
Agradecemos também a todos os participantes da pesquisa realizada, que sem nenhum
interesse responderam e realizaram a contagem de um extenso e complexo questionário. Sem
eles, o trabalho não passaria de um projeto. Agradecemos também a todos que se
disponibilizaram e, por um motivo ou outro, não conseguiram responder a tempo para a
pesquisa.
Aos professores da banca examinadora Dr. João Caldas e Dr. Edmir Parada Vasques
Prado, pela gentileza da participação e pelas correções necessárias.
Eu, Marcos de Freitas, não devo esquecer de Elaine Manhães, que sempre de forma
pró-ativa se mostrou apta a auxiliar no desenvolvimento do trabalho, me ajudando na análise e
na interpretação de alguns casos, me aconselhando e discutindo os principais tópicos
relevantes.
À Diana Baklizky e a “Cidoca”, por terem confiado no meu potencial e ter permitido
que eu me desenvolvesse no assunto, me fornecendo o substrato de todo o conhecimento em
Análise de Pontos de Função. Aos colegas de profissão, que me possibilitam a cada dia
crescer profissionalmente, desenvolvendo minhas habilidades.
À minha namorada Adriana Dominici Cintra, que não titubeou em nenhum segundo
em me fornecer apoio, me passando sempre tranquilidade e sendo meu pilar nos momentos
mais difíceis, cuja importância não pode ser descrita.
“Uma ciência é tão moderna quanto seus
instrumentos de medição"
Louis Paster
RESUMO
Uma característica importante de qualquer software é o tamanho, já que a partir do
mesmo é possível tornar algo abstrato em algo palpável, possibilitando a derivação de outros
indicadores como produtividade, custo, tempo de desenvolvimento, entre outros. O tamanho
de um software pode ser obtido a partir de métricas orientadas ao tamanho, onde a mais
conhecida é a LOC, ou métricas orientadas a função onde destaca-se a análise de pontos de
função que pode gerar diferenças entre os contadores.
Este trabalho apresenta uma reflexão a respeito da aplicação da técnica de Análise de
Pontos de Função quando exercida por profissionais certificados. Comparando as técnicas
apresentadas pelo CPM (Manual de Práticas de Contagem de Pontos de Função) com as
contagens realizadas por profissionais certificados, o presente trabalho pretende verificar se
existem divergências nos tamanhos funcionais encontrados.
Nesse sentido, é apresentado um cenário elaborado pelos integrantes e aplicados junto
a profissionais certificados de maneira que se possa verificar possíveis divergências nas
contagens de pontos de função.
Palavras-chave: APF. Análise de Pontos por Função.
ABSTRACT
An important feature in every software is its size just because from the same it is
possible to turn something abstract in palpable, enabling the derivation of other indicators,
such as yield, cost, time of development, among others. It is possible to obtain the size of a
software through the size-oriented metrics, in which the most common is the LOC, or metricsdriven role where there is the analysis of function points that can generate differences
between the counters.
This paper presents a reflection on the application of the technique of function point
analysis as it is practiced by certified professionals. Through the comparison of the techniques
presented by the CPM (Manual of Practice Point Spread Function) with the scores performed
by certified professionals, this study aims to determine if there are functional differences in
the counted sizes.
Accordingly, it is presented a fictitious scenario that was applied to the certified
professionals so that it permits to check possible differences in the function point counts.
Keywords: FPA. Function Point Analysis. Functional Size.
LISTA DE TABELAS
TABELA 1 – Complexidade Funções Dados ..........................................................................26
TABELA 2 – Tamanho funcional Funções Dados por Complexidade....................................26
TABELA 3 – Complexidade EE ..............................................................................................28
TABELA 4 – Complexidade SE e CE .....................................................................................28
TABELA 5 – Tamanho funcional EE e CE por complexidade ...............................................29
TABELA 6 – Tamanho funcional SE por complexidade ........................................................29
TABELA 7 – Total pontos encontrados pelos informantes .....................................................38
TABELA 8 – Total pontos FD encontrados pelos informantes ...............................................40
TABELA 9 – Total pontos FT encontrados pelos informantes ...............................................41
TABELA 10 – RLR do Arquivo Lógico Cliente identificado pelos informantes ...................49
TABELA 11 – RLR do Arquivo Lógico Funcionário identificado pelos informantes............49
TABELA 12 – DERs do Arquivo Lógico Cliente identificado pelos informantes..................50
TABELA 13 – DERs do Arquivo Lógico Funcionário identificado pelos informantes..........51
TABELA 14 – RLR do Arquivo Lógico Plantação identificado pelos informantes................55
TABELA 15 – DERs do Arquivo Lógico Plantação identificado pelos informantes .............57
TABELA 16 – DERs do Arquivo Lógico Plantação identificado pelos informantes 4 e 9.....58
TABELA 17 – RLRs do Arquivo Lógico Veículo e Posição do Veículo identificado pelos
informantes................................................................................................................................60
TABELA 18 – DERs do Arquivo Lógico Veículo e Posição do Veículo identificado pelos
informantes................................................................................................................................61
TABELA 19 – RLRs do Arquivo Lógico de Monitoramento identificado pelos
informantes................................................................................................................................67
TABELA 20 – DERs da Função de Transação Carga Inicial Monitoramento Pragas
identificado pelos informantes 2,4 e 9......................................................................................72
TABELA 21 – DERs da Função de Transação Efetuar Expurgo Posição Veículo identificado
pelos informantes......................................................................................................................75
TABELA 22 – DERs da Função de Transação Incluir Dados Monitoramento Plantação
identificado pelos informantes .................................................................................................77
TABELA 23 – DERs da Função de Transação Incluir Dados de Reparo da Plantação
identificados pelos informantes................................................................................................79
TABELA 24 – DERs da Função de Transação Enviar Alerta Criticidade identificados pelos
informantes..............................................................................................................................83
TABELA 25 – DERs da Função de Transação Consultar Mapa pelos informantes...............85
TABELA 26 – DERs da Função de Transação Incluir Posição Veículo identificados pelos
informante................................................................................................................................87
LISTAS DE FIGURAS
FIGURA 1 - Interrelacionamento entre os termos medida, métrica e indicador......................16
FIGURA 2 - Principais papéis na Medição de Software..........................................................17
FIGURA 3 - Evolução dos métodos.........................................................................................20
FIGURA 4 - Procedimentos de Contagem...............................................................................23
FIGURA 5 - Interrelação entre Propósito, Tipo de Contagem, Escopo e Fronteira.................24
FIGURA 6 - Procedimentos para a contagem das funções de dados........................................25
FIGURA 7 - Procedimentos para contagem funções transação................................................27
FIGURA 8 - Resultados obtidos na pesquisa............................................................................32
FIGURA 9 - Gráfico de dispersão em relação ao tamanho funcional encontrados pelos
respondentes..............................................................................................................................39
FIGURA 10 – Quadro comparativo dos CFBs e complexidade encontrados pelos
informantes...............................................................................................................................40
FIGURA 11 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 1..............................................................................................................................42
FIGURA 12 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 2 .............................................................................................................................43
FIGURA 13 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 3 ............................................................................................................................ 43
FIGURA 14 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 4 .............................................................................................................................44
FIGURA 15 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 5 .............................................................................................................................44
FIGURA 16 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 6 .............................................................................................................................45
FIGURA 17 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 7 .............................................................................................................................46
FIGURA 18 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 8 .............................................................................................................................46
FIGURA 19 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 9..............................................................................................................................47
FIGURA 20 - Distribuição porcentual da quantidade de pontos de função encontrados pelo
informante 10 ...........................................................................................................................48
FIGURA 21 - Quantidade de informantes que contaram Agrupamento Lógico de
Função......................................................................................................................................53
FIGURA 22 - Quantidade de informantes que contaram Agrupamento Lógico de
Plantação.................................................................................................................................54
FIGURA
23
-
Quantidade
de
informantes
que
contaram
Arquivo
Lógico
Veículo.....................................................................................................................................59
FIGURA 24 - Quantidade de informantes que contaram Arquivo Lógico de Faixa de
Criticidade................................................................................................................................62
FIGURA 25 - Quantidade de informantes que contaram Arquivo Lógico de
Plantação_Cliente....................................................................................................................65
FIGURA 26 - Quantidade de informantes que contaram Arquivo Lógico de
Monitoramento.......................................................................................................................66
FIGURA
27
-
Quantidade
de
informantes
que
contaram
Arquivo
Lógico
Beneficiados.............................................................................................................................68
FIGURA 28 - Quantidade de informantes que contaram Arquivo Lógico de Reparos
Plantação.................................................................................................................................69
FIGURA 29 - Quantidade de informantes que contaram Carga Inicial Monitoramento
Pragas.......................................................................................................................................71
FIGURA 30 - Quantidade de informantes que contaram Efetuar Expurgo Posição
Veículo.....................................................................................................................................74
FIGURA 31 - Quantidade de informantes que contaram Incluir Dados Monitoramento
Plantação.................................................................................................................................77
FIGURA 32 - Quantidade de informantes que contaram Incluir Dados de Reparo da Plantação
e Consultar Dados de Reparo da Plantação..............................................................................79
FIGURA 33 - Quantidade de informantes que contaram Consultar Dados Reparo de
Plantação...................................................................................................................................80
FIGURA 34 - Quantidade de informantes que contaram Enviar Alerta de Criticidade...........81
FIGURA 35 - Quantidade de informantes que contaram Consultar Mapa...............................84
FIGURA 36 - Quantidade de informantes que contaram Incluir Posição Veículo...................86
LISTAS DE EQUAÇÕES
EQUAÇÃO 1 - Tamanho funcional não ajustado do projeto de desenvolvimento..................29
EQUAÇÃO 2 - Tamanho funcional não ajustado após o projeto de desenvolvimento............29
EQUAÇÃO 3 - Tamanho funcional não ajustado do projeto de melhoria...............................30
EQUAÇÃO 4 - Tamanho funcional não ajustado após projeto de melhoria............................30
SUMÁRIO
1.
INTRODUÇÃO...................................................................................................... 12
1.1
OBJETIVO GERAL .................................................................................................... 12
1.2
OBJETIVOS ESPECÍFICOS ..................................................................................... 12
1.3
JUSTIFICATIVA......................................................................................................... 13
1.4
DELIMITAÇÃO DO PROBLEMA DE PESQUISA................................................ 13
1.5
HIPÓTESES ................................................................................................................. 14
2.
QUALIDADE DE SOFTWARE E ANÁLISE DE PONTOS DE FUNÇÃO .......... 15
2.1
MÉTRICAS DE SOFTWARE ....................................................................................... 15
2.2
MEDIDAS, MEDIÇÃO, MÉTRICAS E INDICADORES ........................................... 16
2.3
PRINCÍPIOS DA MEDIÇÃO........................................................................................ 17
2.4
CARACTERÍSTICAS DAS MÉTRICAS DE SOFTWARE ........................................ 18
2.5
CATEGORIZAÇÃO DAS MÉTRICAS........................................................................ 19
2.5.1
Métricas Orientadas a Tamanho..................................................................................... 19
2.5.2
Métricas Orientadas a Função ........................................................................................ 19
2.6
ANÁLISE DE PONTOS DE FUNÇÃO - APF ............................................................. 20
2.6.1
Definição da Fronteira, Escopo e Propósito da contagem ............................................. 23
2.6.2
Funções de dados ........................................................................................................... 24
2.6.3
Funções de transação ..................................................................................................... 26
2.6.4
Calcular o tamanho funcional ........................................................................................ 29
2.6.5
Documentar a contagem e Reportar os resultados ......................................................... 30
2.7
ESTUDOS CORRELATOS .......................................................................................... 31
2.7.1
Reliability of function point counts................................................................................ 31
2.1.1
Reliability of Function Point Measurement: A Field Experiment ................................. 33
3.
METODOLOGIA DE PESQUISA............................................................................. 35
4.
ANÁLISE DOS DADOS .............................................................................................. 36
4.1
DESCRIÇÃO DE CENÁRIO ..................................................................................... 36
4.2
COMPARAÇÃO ENTRE AS CONTAGENS ENTREGUES PELOS
INFORMANTES ......................................................................................................................... 38
4.3
VALIDANDO OS RESULTADOS ............................................................................. 41
4.4
ANÁLISE FUNÇÕES DE DADOS ............................................................................ 48
4.4.1
Arquivo Lógico de Clientes e Funcionários................................................................... 48
4.4.2
Arquivo Lógico de Função............................................................................................. 52
4.4.3
Arquivo Lógico de Plantação ......................................................................................... 54
4.4.4
Arquivo Lógico de Veículo e Posição Veículo .............................................................. 58
4.4.5
Arquivo Lógico de Faixa de Criticidade ........................................................................ 62
4.4.6
Arquivo Lógico de Plantação_Cliente ........................................................................... 64
4.4.7
Arquivo Lógico de Monitoramento ............................................................................... 65
4.4.8
Arquivo Lógico de Beneficiados ................................................................................... 68
4.4.9
Arquivo Lógico de Reparos Plantação ........................................................................... 69
4.5
ANÁLISE FUNÇÕES DE TRANSAÇÃO ................................................................. 70
4.5.1
Carga Inicial Monitoramento Pragas ............................................................................. 70
4.5.2
Efetuar Expurgo Posição Veículo .................................................................................. 73
4.5.3
Incluir Dados Monitoramento Plantação ....................................................................... 76
4.5.4
Incluir Dados de Reparo da Plantação e Consultar Dados de Reparo da Plantação ...... 78
4.5.5
Enviar Alerta de Criticidade........................................................................................... 81
4.5.6
Consultar Mapa .............................................................................................................. 83
4.5.7
Incluir Posição Veículo .................................................................................................. 85
4.5.8
Assinalar Clientes sem Ocorrência de Praga ................................................................. 87
4.6
CONCLUSÃO .............................................................................................................. 88
2.1.1
Limitações da Pesquisa .................................................................................................. 89
2.1.2
Estudos Futuros .............................................................................................................. 89
APÊNDICE A - Cenário aplicado aos informantes da pesquisa ............................................. 91
APÊNDICE B - Modelo Físico do Cenário disponibilizado aos informantes ...................... 100
APÊNDICE C - Lista de Siglas e Abreviaturas ...................................................................... 101
12
1. INTRODUÇÃO
O crescente aumento da competitividade corporativa, gerada pela globalização e pela
preocupação com a qualidade dos produtos, levou as empresas a aperfeiçoarem cada vez mais
seus processos internos, de maneira a obter vantagem competitiva em relação aos seus
concorrentes (COLTRO, 1996).
Esse e outros fatores, aliados ao desenvolvimento tecnológico, provavelmente
motivaram a construção de sistemas de Informática capazes não só de aprimorar os processos
internos (PRADO et al., 2007), mas também de facilitar a integração entre os setores de uma
empresa e otimizar o armazenamento de informações. A utilização de sistemas de informática
no cotidiano empresarial tornou-se uma solução para empresas que desejavam manter um
diferencial sobre seus concorrentes e indispensável para aquelas que não poderiam ficar em
desvantagem com relação às que já utilizavam tais sistemas (BAILARINE, 2002). As
vantagens obtidas com o uso dos sistemas possivelmente motivaram as empresas a investirem
mais no desenvolvimento de software, o que evidenciou a imaturidade do setor em conseguir
atender uma grande demanda de clientes e atender as expectativas de cumprimento de prazos
e qualidade do produto de software principalmente (MEIRA, 2003).
A seguir, são apresentados os objetivos deste trabalho para, então, se apresentar o seu
conteúdo.
1.1
OBJETIVO GERAL
Avaliar a acurácia da aplicação da técnica de Análise de Pontos de Função por
profissionais certificados e atuantes no mercado corporativo.
1.2
OBJETIVOS ESPECÍFICOS
Com este estudo, busca-se:
•
Estimar a assertividade do profissional na aplicação da técnica de contagem de
Análise de Pontos de Função.
•
Investigar a existência de divergências entre os profissionais certificados em APF.
•
Comparar a aplicação da técnica prevista pelo manual, em relação a utilizada
individualmente pelos profissionais, em algumas funcionalidades específicas.
13
1.3
JUSTIFICATIVA
Sendo a Análise de Pontos de Função uma técnica que visa determinar o tamanho
funcional de um software, e sendo atualmente o método padrão aconselhado pelo governo
brasileiro para a mensuração de softwares, os erros nas contagens podem ser danosos a
organização que a adota. Isso ocorre por que, sem a correta aplicação da técnica, ora o mesmo
profissional contará mais Pontos de Função, ou menos Pontos de Função comprometendo a
base histórica da empresa.
Uma empresa que mensura seus softwares com profissionais despreparados,
possivelmente terá grandes problemas em conseguir traçar tendências e padrões de maneira a
conseguir atingir seu propósito no momento em que a métrica foi implantada.
Dessa maneira, esse trabalho contribuirá positivamente ao verificar se existem
possíveis divergências nas contagens entre profissionais certificados e, no caso de
constatações de desvios no processo de contagem possibilitar verificar eventuais pontos que
devam ser tratados com maior atenção durante a mensuração dos sistemas.
1.4
DELIMITAÇÃO DO PROBLEMA DE PESQUISA
Dentre as diversas métricas existentes no mercado, a técnica de Pontos de Função tem
como principal vantagem a possibilidade de servir como um fator normalizador do tamanho
dos softwares mensurados - Tal vantagem deve-se ao fato de que a aplicação da APF é
homogênea, visto que a mesma foi desenvolvida a partir de um conjunto de padrões e
métodos descritos pelo CPM (Counting Practices Manual), cuja versão mais atual foi
publicada no ano de 2011, pelo IFPUG (International Function Point Users Group).
Entretanto, em muitos casos de mensuração nota-se entre profissionais certificados
uma aplicação divergente da métrica. Sendo assim, a aplicação heterogênea dos métodos e
padrões previstos pelo CPM descaracterizariam o principal objetivo e uma das características
da Análise de Pontos de Função que é ser homogênea.
Considerando que possíveis divergências por parte desses profissionais, na
interpretação do manual podem oferecer distorções nos resultados, que deveriam ser iguais se
mensurados por quaisquer profissionais certificados, pretende-se verificar a acurácia da
técnica quando aplicada pelos profissionais da área.
14
1.5
HIPÓTESES
Adotou-se como hipótese para este estudo que há divergências nas contagens
realizadas por profissionais certificados na técnica de análise de pontos de função.
15
2.
QUALIDADE DE SOFTWARE E ANÁLISE DE PONTOS DE FUNÇÃO
2.1
MÉTRICAS DE SOFTWARE
As medidas, em diversas atividades do nosso dia, são extremamente importantes, por
exemplo, para determinar a distância de um ponto a outro. Com tal intuito se desenvolveram
métricas reconhecidas no mundo todo, definidas por meio de unidades padrões que servem de
referência para todos.
Usualmente, as métricas existentes visam traduzir em números ideias abstratas, como
peso, tamanho, volume, entre outras. O mesmo ocorre ao se tentar medir um software que não
possui volume ou tamanho passível de ser analisado. A dificuldade em determinar a sua
complexidade, o tamanho, o tempo de desenvolvimento entre outras características dos
softwares é, atualmente, um desafio para os profissionais da área que, normalmente, se
baseiam em métricas existentes a fim de transpor tais características abstratas em número
palpáveis.
De acordo com Guarizzo (2008):
o uso das métricas de software permite obter uma série de vantagens como: diminuir
defeitos, prazo de entrega, desperdício e custo e aumentar a satisfação do cliente, a
produtividade dos recursos, a visibilidade das ações e a qualidade de gerenciamento.
Além disso, de acordo com Pressman (2006):
apesar de as métricas de produto para software de computador serem freqüentemente
não absolutas, elas nos dão um modo sistemático de avaliar qualidade com base em
um conjunto de regras claramente definidas. Elas também dão ao engenheiro de
software entendimento imediato, ao invés de posterior. Isso permite ao engenheiro
descobrir e corrigir problemas potenciais, antes que se transformem em defeitos
catastróficos.
Logo, apesar dos desafios existentes, a necessidade de se mensurar os softwares em
todos os ciclos de vida se faz necessária para aprimorar a qualidade do produto, bem como
para garantir um maior controle sobre ele. Segundo L. Kelvin (18-?) quando se pode medir
aquilo sobre o qual se está falando e expressá-lo em números, sabe-se alguma coisa sobre o
mesmo; mas quando não se pode medi-lo, quando não se pode expressá-lo em números, o
conhecimento que se tem é de um tipo inadequado e insatisfatório; este pode ser o começo do
16
conhecimento, mas dificilmente alguém terá avançado em suas ideias para o estágio de
ciência.
2.2
MEDIDAS, MEDIÇÃO, MÉTRICAS E INDICADORES
Os termos medidas, medição, métricas e indicadores, embora possam ser utilizados de
maneira equivocada, possuem diferenças sutis entre si. O IEEE Standard Glossary (1993)
define métrica como "uma medida quantitativa do grau em que um sistema, componente ou
processo possui um determinado atributo". O interrelacionamento entre os mesmos pode ser
visualizado conforme figura abaixo:
Figura 1 – Interrelacionamento entre os termos medida, métrica e indicador
Fonte: Elaboração própria
A partir daí, entende-se que uma medida é a coleta de informações de um único
ponto, como por exemplo, a determinação da altura de um indivíduo (1,70m); já a medição é
o ato de coletar uma medida, no caso, estender uma fita métrica ao longo do corpo de uma
pessoa até que se chegue ao extremo que indicará a sua altura. Métrica, por sua vez,
configura-se como a relação quantitativa entre dois atributos. Segundo o IEEE, métrica é
"uma medida quantitativa do grau segundo o qual um sistema, componente ou processo
possui um dado atributo".
17
O indicador por sua vez é uma combinação de métricas que fornece profundidade na
visão do processo de software (PRESSMAN, 2006). Por meio dos indicadores, os envolvidos
no processo podem tomar decisões baseando-se neles, de maneira a ajustar ou aperfeiçoar o
processo em questão.
2.3
PRINCÍPIOS DA MEDIÇÃO
Segundo Roche (apud SILVA, 2010), um processo de medição pode ser caracterizado
por cinco atividades, sendo elas:
Análise
Coleta
Formulação
Interpretação
Medição
Software
Realimentação
Figura 2 – Principais papéis na Medição de Software
Fonte: Elaboração própria
•
Formulação: Derivação de medidas e métricas de software adequadas para a
representação do software que está sendo considerado.
•
Coleta: Mecanismo usado na obtenção dos dados necessários para derivar as
métricas formuladas.
•
Análise: Cálculo de métricas por meio de ferramentas matemáticas.
•
Interpretação: Avaliação das métricas de forma a se obter profundidade nas
características do sistema e respaldo para a tomada de decisão.
18
•
Realimentação: Recomendações derivadas da interpretação das métricas de
produto, transmitidas à equipe de software.
2.4
CARACTERÍSTICAS DAS MÉTRICAS DE SOFTWARE
Segundo Ejiogu (apud SILVA, 2010) uma métrica deve ter as seguintes características:
•
Simples e computáveis: A forma de derivar a métrica deve ser de fácil
entendimento e seu cálculo não deve exigir um esforço ou tempo sobremaneira
alto.
•
Empíricas e intuitivas: A métrica deve satisfazer às noções intuitivas do
engenheiro sobre o atributo do produto que está sendo considerado, além de ser
baseada em experimentos comprovados.
•
Consistentes e objetivas: A métrica deve sempre produzir resultados não
ambíguos. Além disso, o resultado deve agregar valor à análise do software.
•
Consistentes no uso de unidades e dimensões: O cálculo matemático da
métrica deve usar medidas que não levam a combinações de unidades
incompatíveis.
•
Independentes da linguagem de programação: Métricas devem ser baseadas
no modelo de análise, modelo de projeto ou na estrutura do programa.
Dentre as diversas métricas existentes, dificilmente uma aplicará de maneira
satisfatória todos os atributos citados acima. Normalmente, a métrica desenvolvida focará
determinadas características em detrimento de outras. A métrica de análise de pontos de
função, por exemplo, embora seja independente da linguagem de programação diferentemente
do LOC (Lines of Code), não é necessariamente consistente e objetiva, visto que em alguns
casos pode produzir resultados distintos entre os especialistas, o que, aliás, é alvo deste
estudo.
Segundo Pressman (2006), o desenvolvimento de uma métrica abrangente capaz de
equiparar todos os atributos de um software, resultando em um número final vem sendo
buscado por muitos profissionais. Obviamente, as diversas métricas propostas e apresentadas
levam em consideração pontos de vista distintos e determinados atributos do software em
detrimento de outros.
19
2.5
CATEGORIZAÇÃO DAS MÉTRICAS
Dentre as diversas métricas propostas para mensuração de sistemas, as métricas
podem ser categorizadas de maneiras diferentes, tais como métricas diretas e indiretas, ou
métricas orientadas a tamanho, ou funções, entre outras (Guarizzo, 2008). Algumas dessas
categorias serão apresentadas a seguir.
2.5.1
Métricas Orientadas a Tamanho
As métricas orientadas a tamanho são medidas diretas do tamanho dos artefatos de
software associados ao processo por meio do qual o software é desenvolvido (Vasconcelos,
2005). Estas visam mensurar, por exemplo, o tamanho da aplicação sob a ótica do volume das
linhas de código existentes. Portanto, observa-se que as mesmas são intrinsecamente ligadas à
implementação e ao fator tecnológico.
Pode-se citar como pertencente a essa categoria a métrica LOC, que, a partir das linhas
de código de determinado programa, fornece um tamanho em LOC. A métrica tem como
característica ser bastante objetiva e facilmente calculada, porém, por estar vinculada à
tecnologia utilizada, pode ocasionar variações significativas quando comparadas com outras
tecnologias.
2.5.2
Métricas Orientadas a Função
Por sua vez, as métricas orientadas à função, diferentemente das métricas orientadas a
tamanho, se propõem a analisar a funcionalidade oferecida pelo software. O grande marco das
métricas funcionais se deu quando Allan Albrecht, em 1979, propôs a Análise de Pontos de
Função, explicitada com mais detalhes no tópico a seguir. Desde então, surgiram diversas
métricas funcionais, como por exemplo, o Mark II, Use Case Points, NESMA, COSMIC-FPP
entre outras. Na figura 3, apresenta-se uma evolução destes métodos.
20
Figura 3 – Evolução dos métodos
Fonte: Salvador (2005)
As métricas orientadas a função, tem como vantagem ser independentes da tecnologia
utilizada, já que medem o software sob a ótica do "negócio", quando comparada a métricas
orientadas ao tamanho. Além disso, as métricas funcionais fornecem um tamanho
independente da produtividade da aplicação e/ou tecnologia.
2.6
ANÁLISE DE PONTOS DE FUNÇÃO - APF
A contagem de Pontos de Função, como métrica para definir o tamanho funcional de
um sistema de software, foi inicialmente formulada por Alan Albrecht em seu trabalho
intitulado A New Way of Looking at Tools (1979) como resultado de um projeto na empresa
IBM.
Em 1986 foi criado o IFPUG (International Function Point User Group), uma
organização sem fins lucrativos, com a missão de promover o gerenciamento efetivo do
desenvolvimento e manutenção do software de aplicação por meio da utilização da análise de
pontos de função e outras técnicas de medida de software. Além de formular um manual para
a contagem de pontos de função, o IFPUG certifica profissionais para realização dessa
atividade.
21
A Análise de Pontos de Função é uma técnica utilizada para a mensuração do tamanho
funcional de um software, visando estabelecer uma medida de tamanho a partir dos requisitos
funcionais, considerando a funcionalidade implementada no software que o usuário solicita e
recebe. A métrica é aplicada independente da linguagem de programação ou da tecnologia
que será usada para implementação. De acordo com Gonçalves (1995), a Análise de Pontos de
Função é "uma técnica de dimensionamento de projetos de software, que considera como
unidade de medida os aspectos externos do software, requisitados e visíveis ao usuário".
Segundo o IFPUG(2010), o método de análise de pontos de função é "suficientemente
simples para minimizar o custo adicional introduzido pelo processo de medição e uma medida
consistente entre diversos projetos e organizações". Além disso, o próprio IFPUG (2010) cita
que:
a métrica pode dar suporte à análise de qualidade e produtividade, estimar o custo e
recursos requeridos para o desenvolvimento, melhoria e manutenção do software;
fornecer um fator de normalização para a comparação de software; determinar o
tamanho de um pacote de aplicação adquirido, por meio do dimensionamento
funcional de todas as funções incluídas no mesmo e ajudar os usuários a determinar
o benefício provido por um pacote de aplicação para a sua organização, por meio do
dimensionamento funcional das funções que correspondam especificamente aos seus
requisitos.
Porém, apesar das vantagens citadas acima, outros autores apontam desvantagens e
criticam o método de medição proposto por Albrecht. Symons, autor do artigo Function Point
Analysis: Difficulties and Improvements, faz as seguintes críticas a respeito da técnica:
A classificação de todos os componentes funcionais do sistema (entradas, saídas
etc.), com complexidade baixa, média ou alta, tem o mérito de ser direta e clara,
entretanto parece ser também demasiadamente simplificada. A um componente
funcional do sistema contendo mais de 100 elementos de dados é atribuído, no
máximo, duas vezes os pontos de um componente com um elemento dado.
A escolha por ‘pesos’ tem sido justificada por Albrecht como refletindo “o valor
relativo de uma função para o usuário” e que a mesma “foi determinada por debate e
teste.” Parece uma questão razoável para perguntar se os pesos obtidos por Albrecht
a partir dos seus usuários na IBM serão válidos em todas as circunstâncias e úteis
para medir o tamanho na avaliação e estimativa da produtividade. Outras avaliações
mais objetivas dos pesos são recomendáveis. Sendo assim, os pesos aumentam os
efeitos-surpresa. 1
Nota-se no trecho acima, que o autor questiona a complexidade das funções à serem
atribuídas aos componentes funcionais da aplicação, bem como o método utilizado para que
se chegasse a tais números. Meli (1998) converge com a opinião de Symons, ao afirmar que
1
Tradução Própria
22
"à Técnica de Pontos de Função do IFPUG falha ao considerar o aspecto algorítmico do
processo elementar dado pelo cálculo baseado na quantidade de dados tratados (DER, RLR,
ALR) e não pela complexidade desses tratamentos.".
Meli, em seu texto, faz outras críticas a respeito da técnica, sugerindo que,
diferentemente do que prevê o manual de práticas de contagem, "o nível do detalhe necessário
para aplicar às regras padrão de contagem do IFPUG sugere que uma grande parte do projeto
já tenha sido feita (Especificações Funcionais levam em consideração de 15% a 40% do total
dos esforços do trabalho)".
Symons, por fim, cita algumas limitações à respeito da técnica de análise de pontos de
função:
O método não é tão fácil de aplicar na prática como parece. Especificamente,
retornar de um sistema físico instalado, provendo um diálogo interativo a fim de
originar transações lógicas, requer certa experiência. Algumas vezes surgem casos
em que há um tipo de julgamento subjetivo quando transações lógicas (por exemplo,
aquelas que têm trajetórias de processo ligeiramente diferentes, dependendo do valor
da entrada) são contadas como transações lógicas separadas, ou quando essas
diferenças podem ser ignoradas. Entretanto, em algum momento, ainda por vir, isso
será melhor em qualquer organização se todas as medidas forem supervisionadas por
um analista de pontos de função experiente e objetivo.
Tal analista deve acumular e documentar casos e obter disso regras gerais, como as
fornecidas no apêndice, as quais irão ajudar a assegurar a consistência e a
objetividade na análise e pontos de função.2
Os diversos releases do CPM lançadas pelo IFPUG tendem a aperfeiçoar a descrição
da técnica, desvirtuando possibilidades de grandes variações na contagem, ou no sentido de
incrementar a consistência e confiabilidade da técnica, que é atualmente utilizada no mercado
corporativo.
Deve-se ressaltar porém, que dificilmente a técnica, por mais consistente e confiável
que possa ser, englobaria com maestria todas as características explicitadas no tópico acima,
para as métricas de software, possuindo consequentemente pontos positivos e negativos.
Para a utilização correta da técnica, é necessário que o analista tenha certificação
CFPS – Certified Function Point Specialist, obtida por meio da realização de uma prova
desenvolvida pelo IFPUG. O manual que explicita todos os conceitos referentes à técnica tem,
conforme, descrito por seus autores, os seguintes objetivos:
manter conformidade com a norma ISO/IEC 14143-1:2007 Information technology
– Software measurement – Functional size measurement – Definition of concepts;
Prover uma descrição clara e detalhada da contagem de pontos de função; Garantir
que as contagens sejam consistentes com as práticas de contagem dos affiliates do
IFPUG; Fornecer um guia para permitir a contagem de pontos de função a partir dos
2
Tradução Própria
23
entregáveis das metodologias e técnicas mais conhecidas; Prover um entendimento
comum para permitir que os fornecedores de ferramentas forneçam suporte
automatizado para a contagem de pontos de função.
Portanto, deve-se ressaltar que a técnica de análise de Pontos de Função pode ser
aplicada tanto no dimensionamento de projetos de aplicações já implantadas, quanto no
dimensionamento de projetos de desenvolvimento ou manutenção de aplicações.
A aplicação da técnica de contagem de pontos de função, segundo o CPM 4.3,
descreve os seguintes passos para a realização de uma contagem, conforme é possível notar
abaixo:
Figura 4 – Procedimentos de Contagem
Fonte: IFPUG, 2010
2.6.1
Definição da Fronteira, Escopo e Propósito da contagem
A fronteira da aplicação é definida estabelecendo um limite lógico entre a aplicação
que esta sendo contada, os usuários e as demais aplicações (IFPUG, 2010).
A fronteira depende somente da visão externa do negocio do usuário, sendo assim, é
determinada com base nessa visão. O posicionamento da fronteira pode ser subjetivo, por isso
é muito comum haver certa dificuldade no momento de delinear onde termina uma aplicação
e começa outra. Nessa situação, devem-se sempre delinear a fronteira de uma perspectiva de
negocio, ao invés de se basear em considerações técnicas (VAZQUEZ, 2005).
O posicionamento da fronteira impacta diretamente no resultado da contagem, visto
que sem a delimitação das fronteiras torna-se impraticável a contagem de pontos de função.
Sem a definição da fronteira, por exemplo, não seria possível determinar quais atributos
reconhecidos pelo usuário entram ou saem pela fronteira.
A definição do propósito de contagem também é essencial no processo de contagem.
Mediante definição do propósito da contagem, define-se qual o tipo de contagem será
realizada e qual o escopo deverá ser considerado. Quando se deseja realizar uma contagem,
24
deve-se, inicialmente, definir qual a necessidade de realizá-la. Empresas não iriam investir em
contagem se não existisse um motivo relevante para a realização de tal atividade. Portanto, o
propósito da contagem deve responder a um problema de negócio.
Por fim, a delimitação do escopo a ser considerado na contagem é necessária já para
nortear o processo de contagem, definindo qual será o conjunto de requisitos funcionais que
será incluído na contagem de pontos de função.
O interrelacionamento entre a fronteira, o propósito e o escopo pode ser observado na
figura abaixo:
Figura 5 – Interrelação entre Propósito, Tipo de Contagem, Escopo e Fronteira
Fonte: Elaboração Própria
2.6.2
Funções de dados
A funcionalidade de dados satisfaz os Requisitos Funcionais do Usuário referentes a
armazenar e/ou referenciar dados (IFPUG, 2010). Para que as funções de dados existentes na
fronteira da aplicação possam ser identificadas, devem-se seguir as seguintes atividades:
25
Identificar e
agrupar todos os
dados lógicos em
funções de
dados.
Classificar cada
função de dados
como um ALI ou
AIE
Contar os DERs
para cada função
de dados.
Contar os RLRs
para cada função
de dados.
Determinar a
complexidade
funcional de cada
função de dados.
Determinar o
tamanho
funcional de cada
função de dados.
Figura 6 – Procedimentos para a contagem das funções de dados
Fonte: IFPUG, 2010; Elaboração Própria
Inicialmente, para determinação das funções de dados existentes na aplicação, deve-se
agrupar as tabelas do ponto de vista lógico. Se determinada informação é criada ou excluída
juntas, então há uma forte indicação de que, provavelmente, tais dados não existam de
maneira independente e, portanto, devem ser agrupados. Entidades como dados de código,
key-to-key, entidades que não são mantidas por nenhuma aplicação ou que não possuem dados
reconhecidos pelo usuário devem ser desconsideradas durante a identificação dos
agrupamentos lógicos de dados. Devem-se desconsiderar também entidades associativas que
contenham atributos adicionais não requeridos pelo usuário e entidades associativas que
contenham apenas chaves estrangeiras (IFPUG, 2010).
As demais entidades devem ser agrupadas quando forem dependentes entre si, ou seja,
quando uma não possui significado para o negócio sem a ocorrência de outra a ela vinculada.
A entidade de empregado e dependente, por exemplo, pode ilustrar tais casos. Se ao se excluir
um empregado, todos os dependentes a ele relacionados devam ser excluídos, conforme a
regra de negócio da empresa, nota-se que os dependentes, sem estarem vinculados a um
determinado empregado, não possuem significado para o negócio e, portanto, devem ser
agrupados.
Após ter sido realizado o agrupamento das funções de dados, as mesmas devem ser
classificadas como Arquivos Lógicos Internos ou Arquivos Lógicos Externos. Segundo o
IFPUG (2010) uma função de dados deve ser classificada como:
•
Arquivo Lógico Interno (ALI), se for mantida pela aplicação medida, ou
•
Arquivo de Interface Externa (AIE), se for: referenciada, mas não mantida,
pela aplicação sendo medida, e identificada como ALI em uma ou mais outras
aplicações.
26
Por fim, deve-se determinar a quantidade de DERs e RLRs de cada ALI e de cada
AIE, para determinação de sua complexidade e, consequentemente, seu tamanho funcional.
As tabelas abaixo apresentam a complexidade e o tamanho funcional das funções de dados.
Tabela 1 - Complexidade Funções Dados
1 RLR
2 a 5 RLRs
6 ou mais RLRs
1 a 19 DERs
Baixa
Baixa
Média
20 a 50 DERs
Baixa
Média
Alta
50 ou mais DERs
Média
Alta
Alta
Fonte: IFPUG, 2010; Elaboração Própria
Após definir a complexidade de cada função de dado, pode-se determinar o tamanho
funcional de cada função de dado. Para definir o tamanho funcional de uma ALI se utiliza a
tabela abaixo:
Tabela 2 - Tamanho Funcional Funções Dados por complexidade
Grau de Complexidade Funcional
Baixo
Médio
Alto
Pontos de Função
7
10
15
Fonte: IFPUG, 2010
2.6.3
Funções de transação
A função de transação representa a funcionalidade que é fornecida ao usuário para o
processamento de dados por uma aplicação e pode ser classificada em Entrada Externa,
Consulta Externa e Saída Externa. Os seguintes passos devem ser seguidos para que uma
função de transação possa ser mensurada:
Identificar o
Processo
Elementar
Classificar cada
função de
transação
Contar os ALRs
Contar os DERs
Determinar a
complexidade
da cada função
Figura 7 – Procedimentos para contagem funções transação
Fonte: IFPUG, 2010; Elaboração Própria
Determinar o
tamanho
funcional de
cada função
27
A partir do requisito funcional do usuário (ex: Manter Cliente) é possível compor ou
decompor (ex: Incluir Cliente, Alterar Cliente, etc) os requisitos para a delimitação das
menores unidades de atividades.
Delimitar, porém, as menores unidades de atividades existentes não são suficiente para
classificá-las como processos elementares. Para isso, é necessário que as menores unidades
satisfaçam os seguintes itens, conforme prevê o CPM 4.3:
1. É significativa para o usuário
2. Caracteriza uma transação completa
3. É autocontida
4. Deixa o estado da aplicação contada em um estado consistente.
Apenas quando as menores unidades satisfizerem todos estes itens, é que elas podem
ser entendidas como um processo elementar. Analogamente, podemos comparar a
identificação de processos elementares com situações do dia-a-dia, por exemplo, quando se
deseja lavar o quintal, é necessário enxaguá-lo, ensaboar e esfregar o chão, enxaguar
novamente e secar. Quaisquer das atividades mencionadas acima que sejam executadas de
maneira independente não satisfariam a atividade de "Lavar o quintal", sendo, portanto, a
menor unidade possível dessa atividade.
A partir da definição dos processos elementares, deve-se proceder com a classificação
de cada função de transação. Uma função de transação pode ser classificada em Entrada
Externa, Consulta Externa e Saída Externa.
Uma entrada externa (EE) é um processo elementar que processa dados ou
informações de controle que vêm de fora da fronteira da aplicação. A intenção primária de
uma EE é manter um ou mais ALIs e/ou alterar o comportamento do sistema (IFPUG, 2010).
Uma consulta externa (CE) é um processo elementar que envia dados ou informações
de controle para fora da fronteira da aplicação. A intenção primária de uma consulta externa é
apresentar informações ao usuário por meio da recuperação de dados ou informações de
controle (IFPUG, 2010).
Uma saída externa (SE) é um processo elementar que envia dados ou informações de
controle para fora da fronteira da aplicação e que inclui um processamento adicional ao de
uma consulta externa. A intenção primária de uma SE é apresentar informações ao usuário por
meio de lógica de processamento que não seja apenas a recuperação de dados ou informações
de controle (IFPUG, 2010).
28
A partir da determinação das funções de transação envolvidas e os seus respectivos
tipos, deve-se verificar a complexidade de cada função, após ter se determinado o número de
ALRs e DERs para cada função de transação.
A complexidade de cada função de transação pode ser determinada mediante
observação das tabelas de complexidades listadas abaixo.
Tabela 3 - Complexidade EE
0 a 1 ALRs
2 ALRs
3 ou mais ALRs
1 a 4 DERs
Baixa
Baixa
Média
5 a 15 DERs
Baixa
Média
Alta
16 ou mais DERs
Média
Alta
Alta
Fonte: IFPUG, 2010; Elaboração Própria
Tabela 4 - Complexidade SE e CE
0 a 1 ALRs
2 a 3 ALRs
4 ou mais ALRs
1 a 5 DERs
Baixa
Baixa
Média
6 a 19 DERs
Baixa
Média
Alta
20 ou mais DERs
Média
Alta
Alta
Fonte: IFPUG, 2010; Elaboração Própria
Por fim, após determinada a complexidade funcional de cada função deve-se
determinar o tamanho funcional de cada uma, conforme tabelas na próxima página:
Tabela 5 - Tamanho Funcional EE e CE por complexidade
Grau de Complexidade Funcional
Baixo
Médio
Alto
Pontos de Função
3
4
6
Fonte: IFPUG, 2010; Elaboração Própria
Tabela 6 - Tamanho Funcional SE por complexidade
Grau de Complexidade Funcional
Baixo
Médio
Alto
Pontos de Função
4
5
7
Fonte: IFPUG, 2010; Elaboração Própria
29
2.6.4
Calcular o tamanho funcional
Para o cálculo do tamanho funcional, deve-se considerar o objetivo e o escopo da
contagem.
O tamanho funcional de um projeto de desenvolvimento deverá ser calculado
utilizando-se a Fórmula (1):
DFP = ADD + CFP (1)
onde
DFP é a contagem de pontos de função do projeto de desenvolvimento;
ADD é o tamanho das funções a serem entregues ao usuário pelo projeto de
desenvolvimento;
CFP é o tamanho da funcionalidade de conversão. (IFPUG, 2010).
O tamanho funcional de uma aplicação, medido após o projeto de desenvolvimento, ou
a qualquer tempo no ciclo de vida da aplicação deverá ser calculado utilizando-se a Fórmula
(2):
AFP = ADD (2)
onde
AFP é a contagem de pontos de função da aplicação;
ADD é o tamanho das funções a serem entregues ao usuário pelo projeto de
desenvolvimento (excluído o tamanho de qualquer funcionalidade de conversão), ou a
funcionalidade existente no momento da contagem da aplicação. (IFPUG,2010).
O tamanho funcional de um projeto de melhoria deverá ser calculado utilizando-se a
Fórmula (3):
EFP = ADD + CHGA + CFP + DEL (3)
onde
EFP é a contagem de pontos de função do projeto de melhoria;
ADD é o tamanho das funções incluídas pelo projeto de melhoria;
CHGA é o tamanho das funções alteradas pelo projeto de melhoria – conforme as
mesmas estão / estarão após a implementação;
CFP é o tamanho da funcionalidade de conversão;
DEL é o tamanho das funções excluídas pelo projeto de melhoria. (IFPUG,2010).
O tamanho funcional de uma aplicação após um projeto de melhoria deverá ser
calculado utilizando-se a Fórmula (4):
AFPA = (AFPB + ADD + CHGA) - (CHGB + DEL) (4)
30
onde
AFPA é a contagem de pontos de função da aplicação após o projeto de melhoria;
AFPB é a contagem de pontos de função da aplicação antes do projeto de melhoria;
ADD é o tamanho das funções incluídas pelo projeto de melhoria;
CHGA é o tamanho das funções alteradas pelo projeto de melhoria – como estão /
estarão após a implementação;
CHGB é o tamanho das funções alteradas pelo projeto de melhoria – como estão /
estavam antes do início do projeto;
DEL é o tamanho das funções excluídas pelo projeto de melhoria. (IFPUG, 2010).
As fórmulas acima não se aplicam para cálculo do tamanho funcional ajustado da
aplicação.
2.6.5
Documentar a contagem e Reportar os resultados
Segundo o manual de práticas de contagem (IFPUG, 2010), deve-se documentar a
contagem de pontos de função na seguinte ordem:
•
O propósito e o tipo da contagem;
•
O escopo da contagem e a fronteira da aplicação;
•
A data da contagem;
•
Uma lista de todas as funções de dados e de transação, incluindo o respectivo tipo
e a complexidade, bem como o número de pontos de função atribuído a cada uma;
•
O resultado da contagem;
•
Quaisquer suposições feitas e questões resolvidas.
Além de assegurar a rastreabilidade do tamanho funcional encontrado ao final de uma
contagem de pontos de função, a documentação de possíveis premissas adotadas na contagem
e suposições realizadas, essa documentação torna a métrica mais consistente e pode indicar
possíveis melhorias a serem realizadas na documentação fornecida.
31
As premissas adotadas, quando bem discriminadas, podem tornar mais evidentes
possíveis erros de interpretação dos insumos disponibilizados para a contagem e tornar a
métrica mais consistente. Sem a documentação dessas informações, o tamanho funcional
passa a ser apenas um número, não agregando, necessariamente, ao processo de contagem.
2.7
ESTUDOS CORRELATOS
2.7.1
Reliability of function point counts
No contexto de aprofundamento do tema proposto identificou-se estudos correlatos
que, com suas pesquisas científicas, relatam dados altamente pertinentes e consistentes quanto
à acurácia da medição de Pontos de Função. No primeiro estudo, realizado em 2005 pela
Universidade de Amsterdam, no Departamento de Ciência da Computação, intitulado
Reability of Function Point Counts, foram analisados 311 projetos de softwares e totalizados
58.143 Pontos de Função. Nesse estudo, afirma-se:
não encontramos evidências estatísticas que comprovassem que os contadores
contaram de maneira diferente, portanto a contagem de pontos de função é, nessa
empresa, uma métrica confiável para controle e decisões. 3
Nota-se em estudo realizado que contadores inexperientes realizavam a mensuração, a
contagem chegava a obter uma distorção de até 50%, enquanto para contadores experientes
não foi encontrada nenhuma evidência na pesquisa aplicada que comprovassem alguma
distorção sistemática na contagem de Pontos de Função.
A metodologia adotada para tal estudo contempla a coleta de projetos realizados por
uma empresa que já possuía uma base histórica das contagens de pontos de função realizadas.
O intuito era aplicar os mesmos projetos a profissionais distintos, a fim de se verificar se
existiam divergências nas contagens realizadas por tais profissionais. O objetivo do estudo era
analisar um conjunto de resultados para saber se a probabilidade de obterem o mesmo
resultado.
A figura 8 apresenta os resultados obtidos nas contagens realizadas por profissionais
internos e externos da empresa com o intuito de se observar a variação na contagem.
3
Tradução própria.
32
Figura 8 – Resultados obtidos na pesquisa
Fonte: Reliability of function point counts
Na análise comparativa, comprovou-se que contadores internos obtinham números de
Pontos de Função maiores quando comparado aos contadores externos à empresa, indicando
aparentemente uma inflação quanto à produtividade da empresa, conforme apontado no
estudo.
O referido estudo conclui que, durante o processo de contagem de Pontos de Função
num determinado projeto de software, pode haver variação de até 30% na contagem, porém
observam que tais erros não são sistemáticos, havendo, portanto, uma compensação.
O estudo aponta um coeficiente de correlação de Pearson de p = 0,80 (p = 0,0001),
sugerindo uma forte correlação entre as contagens de Pontos de Função de dois avaliadores,
usando o método padrão.
33
Contudo, é também de interesse a magnitude média dessas diferenças. A média é igual
a 10,78%, uma diferença que, se comparada àquelas relatadas por Rudolph – 30% - é
significativamente baixa. Tal dado sugere que, pelo menos para o padrão de método, a
confiabilidade interavaliadores de avaliadores múltiplos usando o mesmo padrão é alta, com
uma diferença média que é aceitável para os tipos de estimação entre outras tarefas às quais
pontos de função são normalmente aplicadas.
Como resultado final da análise, o estudo confirma que a técnica de contagem de
Pontos de Função, quando se trata de indicadores de confiabilidade entre avaliadores, é
confiável e não há evidência real estatística sistemática a respeito dos erros praticados pelos
profissionais.
2.1.1
Reliability of Function Point Measurement: A Field Experiment
Em estudo realizado no MIT – Massachussets Institute of Tecnology – Center for
Information System Research por Chris F. Kemerer e intitulado Reliability of Function Point
Measurement – A Field Experiment, foi utilizado como metodologia pares de avaliadores,
com resultados assertivos de 95% nas amostras coletadas, sugerindo ser a APF uma técnica
muito mais confiável do que se suspeitava até então.
A pesquisa justifica a necessidade de um estudo voltado para a técnica de APF,
baseando-se no grande número de empresas que a adotam. Dreguer (1989) estima que cerca
de 500 grandes corporações em todo o mundo estão utilizando a APF como métrica de
software . Uma pesquisa realizada pelo Instituto de Garantia da Qualidade constatou que a
APF foi considerada a melhor técnica disponível para métrica de produtividade (PERRY,
1986).
A principal crítica aborda a confiabilidade entre os avaliadores numa mesma
contagem, ou seja, questiona se dois indivíduos que exercem a contagem para um mesmo
sistema gerariam o mesmo resultado. Jones (1989) elaborou uma lista contendo 14 variações
indicadas e sugere que "os valores obtidos podem ser diferentes em 50% a partir do método
Albrecht original"
Em tal estudo, aborda-se a confiabilidade da APF por meio de um estudo de campo
com um total de 111 projetos de sistemas de softwares, utilizando-se vários avaliadores para
contagem estimada de 433 Pontos de Função.
O resultado obtido foi de 95% de assertividade, sugerindo que a APF é uma métrica
confiável e, portanto, passível de maior disseminação entre as empresas.
34
Segundo Rudolph (1983), programas disponíveis em código, fonte ou com
especificação de projeto detalhada devem ter uma margem de erro inferior a 10% na
contagem de Pontos de Função. Com uma descrição detalhada do sistema, não há muito
espaço para interpretações diferentes.
Os autores concluem que:
Atualmente, a métrica de software amplamente disponível apenas que tem o
potencial para preencher este papel no próximo futuro é Pontos de Função. A
pesquisa atual mostra que, ao contrário de algumas especulações e a pesquisa
limitada anterior, a confiabilidade inter-examinador e inter-método de medição da
AFP suficientemente elevado para que a sua confiabilidade não deva representar
uma barreira para a sua prática continuada e maior adoção.4
4
Tradução Própria
35
3.
METODOLOGIA DE PESQUISA
Neste trabalho será realizado um estudo de caso com profissionais certificados na
técnica de análise de pontos de função. Será feito um estudo exploratório no qual o principal
objetivo é verificar a existência de divergências entre as contagens dos respondentes.
A pesquisa foi realizada entre março e abril de 2012 com profissionais certificados que
trabalham na mesma área, de mensuração de softwares.
A pesquisa consistiu de um questionário composto de duas partes: a) com perguntas
relacionadas ao profissional e b) com um cenário fictício desenvolvido pelos autores, com a
descrição de um sistema que deveria ser mensurado (contado) pelos profissionais. O cenário
aplicado aos informantes encontra-se no Apêndice A deste documento. (pág 92).
Os questionários foram enviados a 25 profissionais por email, onde foi especificado
que se tratava de um trabalho acadêmico, porém sem maiores detalhes sobre os objetivos do
trabalho. Dos 25 enviados, o grupo recebeu o retorno de 10 respondentes, que
disponibilizaram os dados em planilhas Excel.
Neste estudo não foram utilizados conceitos e/ou modelos estatísticos para análise de
dados, sendo feita uma análise qualitativa dos dados devido ao baixo número de respondentes.
A escolha dos respondentes se deu por conveniência, ou seja, não foram estabelecidos
variáveis, como idade, sexo, cargo ou empresa. As únicas condições dadas para a participação
na pesquisa foram: a) Ser certificado em Pontos de Função (CFPS) e b) não manter contato
com os outros respondentes durante a contagem, uma vez que qualquer troca de informações a
respeito da pesquisa poderia influenciar a interpretação do cenário e, consequentemente, os
resultados. Após coleta das contagens realizadas pelos informantes foi iniciada a etapa de
análise e interpretação dos dados.
A presente pesquisa buscou comparar a aplicação da técnica de APF pelos informantes
nas contagens enviadas com a prevista no Manual de Práticas de Contagem. O estudo utilizou
como referência bibliográfica artigos acadêmicos, livros e o manual de práticas de contagem.
36
4. ANÁLISE DOS DADOS
4.1
DESCRIÇÃO DE CENÁRIO
O cenário fornecido para contagem abrangia um sistema de controle de pragas, onde o
cliente ao adquiri-lo teria controle sobre suas plantações. O sistema exibia na tela um mapa do
Brasil com as áreas da plantação de seus clientes delimitadas por cores que indicavam o nível
de infestação do local. Com o auxilio do sistema, os funcionários da empresa se
locomoveriam para determinadas áreas, a fim de erradicar as pragas e finalizariam o chamado
do sistema via dispositivo móvel. A descrição detalhada do sistema pode ser encontrada no
apêndice, bem como o modelo físico.
A construção do cenário privilegiou a inclusão de temas considerados críticos e/ou
definidos de maneira superficial pelo manual do IFPUG e, portanto, que ainda podem gerar
discussões durante a metrificação de determinados sistemas. Observa-se que temas como
Múltiplas Mídias, por exemplo, embora tenham sido contemplados com um white-paper
específico do IFPUG, não possuem uma definição clara; outros, como processos internos sem
dados cruzando a fronteira, também apresentam pontos a serem discutidos. Dessa maneira, o
cenário tem como objetivo verificar se os profissionais certificados em análise de Pontos de
Função conseguem chegar ao mesmo tamanho funcional ou se existirá variação entre eles.
Usualmente, grande parte dos sistemas exibem os dados por meio de consultas em
datagrids na tela e/ou até mesmo por relatórios. A utilização de Sistemas de Informação
Geográfica (SIG) proporcionou uma nova abordagem na exibição dos dados, permitindo que
informações antes exibidas em texto, agora passem a ganhar uma forma visual. Entretanto,
independente de os dados serem apresentados em texto ou com ícones e cores de significação
para o usuário, as duas abordagens têm a intenção de apresentar dados para o usuário final,
devendo ser mensurados sem distinção entre o modo de exibição, visto tratar-se de uma
técnica voltado aos requisitos funcionais do usuário, e não ao modo como foi implementada,
conforme cita CPM 4.3 (2010):
O método análise de Pontos de Função do IFPUG é um padrão ISO e deve ser
aderente à ISO/IEC 14143-1:2007. O método pode medir apenas “tamanho
funcional” e não “tamanho não-funcional”.
A simples visualização do mapa na tela implica em consultas sendo exibidas aos
usuários, visto que, como explicitado no cenário, ao ser carregado o mapa, já eram mostradas
37
informações relevantes ao negócio em um formato distinto, como por exemplo, por meio de
ícones plotados na tela.
Portanto, a escolha de um sistema que se utilizasse de Geoprocessamento foi feita com
o intuito de proporcionar ao CPFS um cenário com uma nova abordagem, diferindo de parte
dos sistemas que os mesmos possam mensurar habitualmente. A intenção foi avaliar se os
mesmos conseguem abstrair as técnicas contidas no manual e aplicar da mesma forma em
sistemas que utilizam Geoprocessamento, determinando de maneira satisfatória os processos
elementares envolvidos, bem como o número de DERs e ALRs de cada função de transação.
No cenário fornecido para a contagem, também procurou-se contemplar temas como
múltiplas mídias, processos de expurgo, processos batch sem dados cruzando a fronteira e
funções de conversão. A inclusão destes temas resultou em um cenário de grande
complexidade, tornando-se mais um obstáculo para a coleta de um número maior de
informantes.
Além dos temas mencionados acima, que tem o propósito de verificar se todos os
informantes possuem o mesmo comportamento frente a estes tópicos, procurou-se também
ocultar informações do cenário, para verificar até que pontos os informantes seguiam o
"Procedimento do Método de Medição de Tamanho Funcional" que prevê que todas as
considerações e premissas adotadas na contagem sejam documentadas e reportadas.
Informações de como os dados são mantidos, ou se os mesmos são mantidos juntos
e/ou separados, representam informações que são relevantes para as contagens de pontos de
função, embora não presentes no cenário fornecido para a contagem. As premissas, portanto,
são essenciais no processo de contagem, e representam o último passo da contagem de pontos
de função. Muitas vezes tais considerações, quando pertinentes, podem tornar a
documentação fornecida mais consistente, se a empresa estiver disposta a disponibilizar tais
informações na documentação.
Logo, além da contagem, também será observado se os profissionais seguiram com
rigor todos os passos previstos pelo Procedimento do Método de Tamanho Funcional, ou se
assumiram premissas sem documentar.
Em suma, o cenário desenvolvido e aplicado aos informantes, teve como propósito:
•
Constatar se os informantes seguiram todos os procedimentos de contagem
previsto pelo "Procedimento do Método de Medição de Tamanho Funcional".
•
Determinar se o CPFS é capaz de verificar se o processo batch, embora não
possua dados cruzando a fronteira, é passível de mensuração no cenário a ele
38
submetido, já que o processo é relevante para o negócio e reconhecido pelo
usuário.
4.2
•
Avaliar em que o item de múltiplas mídias poderá interferir na contagem, visto que
o IFPUG reconhece as duas abordagens para estes processos.
•
Observar como os informantes realizarão o agrupamento lógico de dados, e como
perseguirão com a contagem dos DERs e RLRs dos mesmos.
•
Verificar se os informantes conseguiram identificar os processos elementares
envolvidos, e a partir da observação da sua intenção primária e classificá-lo quanto
ao tipo de função de transação.
•
Verificar se os informantes conseguem realizar a contagem dos DERs e ALRs de
cada função de transação de acordo com as regras contidas no manual de práticas
de contagem.
•
Observar se os profissionais conseguem abstrair os requisitos funcionais do
usuário e notar como os CPFS encaram processos de expurgo.
COMPARAÇÃO
ENTRE
AS
CONTAGENS
ENTREGUES
PELOS
INFORMANTES
Após coleta das contagens realizadas por cada informante, observou-se a seguinte
quantidade de pontos de função, encontradas por cada profissional:
Tabela 7 - Total pontos encontrados pelos informantes
Tamanho Total Contagem
Informante
Número de PF
Informante 1
79
Informante 2
62
Informante 3
70
Informante 4
73
Informante 5
55
Informante 6
63
Informante 7
68
Informante 8
87
Informante 9
105
Informante 10
77
Tamanho Médio
72,54
Fonte: Elaboração Própria
39
Considerando todos os profissionais obteve-se uma média de aproximadamente 72,54
pontos de função. A média foi obtida excluindo-se do cálculo os informantes 5 e 9, que
apresentam os extremos. Ressalta-se que metade dos informantes (informantes 2, 5, 6,8 e 9)
ultrapassaram 10% de diferença em relação à média obtida, fugindo dos padrões apontados
por Rudolph (1983).
Conforme nota-se na figura 9, a quantidade de pontos de função encontrados pelos
informantes no cenário fornecido apresentou heterogeneidade entre os respondentes, existindo
variação em alguns casos de até 50 PF.
110
Tamanho Funcional
100
90
80
70
60
50
0
2
4
6
8
10
Informantes
Figura 9 – Gráfico de dispersão em relação ao tamanho funcional encontrados pelos respondentes
Fonte: Elaboração Própria
Na figura 10 observa-se a discordância entre os respondentes a respeito da
identificação dos componentes funcionais, bem como em relação à sua complexidade. Os
espaços em branco representam os CFB que não foram identificados pelos respondentes. As
células pintadas representam os CFB que foram identificados pelos informantes e a sua
complexidade, sendo respectivamente para as células amarela, laranja e vermelha, baixa,
média e alta. A heterogeneidade de cores na figura abaixo demonstram a discordância entre os
40
profissionais certificados em relação a identificação do CFB e de suas respectivas
complexidades. O detalhamento da figura 10 pode ser verificado no Apêndice D.
Figura 10 – Quadro comparativo dos CFBs e complexidade encontrados pelos informantes
Fonte: Elaboração Própria
Ao se analisar a composição da variedade dos dados, nota-se que a maior variedade se
deu no agrupamento lógico realizado pelos informantes, conforme observa-se na tabela 8:
Tabela 8 - Total pontos FD encontrados pelos informantes
Tamanho Total Contagem
Informante
Número de PF
Informante 1
43
Informante 2
26
Informante 3
31
Informante 4
38
Informante 5
24
Informante 6
31
Informante 7
29
Informante 8
38
Informante 9
59
Informante 10
27
Tamanho Médio
34,6
Fonte: Elaboração Própria
41
Conforme prevê o manual de práticas de contagem, o agrupamento lógico realizado de
maneira incorreta é o fator que promove a maior distorção no tamanho funcional da aplicação,
visto que além de aumentar os pontos de função das funções de dados, também pode
aumentar a complexidade das funções de transação.
O tamanho das funções de transação encontradas pelos informantes, mostrou-se mais
equilibrado quando comparado as funções de dados. Porém, nota-se também uma
considerável diferença entre os tamanhos funcionais encontrados, como pode-se averiguar na
tabela 9:
Tabela 9 - Total pontos FT encontrados pelos informantes
Tamanho Total Contagem
Informante
Número de PF
Informante 1
36
Informante 2
36
Informante 3
39
Informante 4
35
Informante 5
31
Informante 6
32
Informante 7
39
Informante 8
49
Informante 9
46
Informante 10
50
Tamanho Médio
39,3
Fonte: Elaboração Própria
Observa-se que os informantes 8, 9 e 10 fugiram do padrão quando comparado aos
demais informantes.
4.3
VALIDANDO OS RESULTADOS
Após as contagens serem entregues pelos informantes envolvidos na pesquisa,
avaliou-se a quantidade dos tipos de processos elementares e os tipos de arquivos lógicos
identificados por cada certificado, a fim de obter uma visão abrangente das contagens
realizadas por eles.
De acordo com Morris (2001), deve-se verificar nas contagens de Pontos de Função de
um projeto de desenvolvimento uma distribuição de aproximadamente:
42
Entretanto, ambas as bases de dados indicam que, aproximadamente, 24% dos
Pontos de Função são relacionados a Arquivos Lógicos Internos, entre 12-14% a
Saídas Externas, 22%-24% a Consulta Externa, 26-39% a Entrada Externa e 4%5
12% a Arquivo de Interface Externa.
Logo, ao analisar as contagens geradas, considerando uma variação de até 5%6 para
mais ou para menos em relação aos valores preestabelecidos acima, pode-se notar que:
Informante 1
AIE
17%
CE
35%
ALI
18%
SE
12%
EE
18%
Figura 11 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 1
Fonte: Elaboração Própria
O informante 1 fugiu dos padrões esperados para a contagem, visto que houve grande
variação da porcentagem obtida em relação à porcentagem esperada. Observou-se, portanto,
que todos os componentes funcionais, com exceção das saídas externas, não correspondem ao
padrão apontado acima, indicando uma grande probabilidade de a contagem estar incorreta.
5
6
Tradução Própria.
Número escolhido pelo Grupo por conveniência.
43
Informante 2
CE
21%
AIE
7%
ALI
22%
SE
14%
EE
36%
Figura 12 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 2
Fonte: Elaboração Própria
Já o informante 2 apresentou-se dentro dos padrões esperados para a contagem, visto
que não houve grande variação da porcentagem obtida em relação à porcentagem esperada.
Observou-se que todos os componentes funcionais estavam dentro do padrão esperado.
Informante 3
AIE
12%
CE
38%
ALI
19%
SE
12%
EE
19%
Figura 13 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 3
Fonte: Elaboração Própria
Assim como o informante 1, o informante 3 também se apresentou fora dos padrões
esperados para a contagem, com porcentagens bem diferentes das esperadas. É possível notar
que, com exceção das saídas externas e arquivos de interface externa, todos os componentes
44
funcionais não estão no padrão apontado anteriormente, indicando novamente uma
probabilidade de a contagem estar incorreta.
Informante 4
AIE
13%
CE
33%
ALI
27%
EE
20%
SE
7%
Figura 14 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 4
Fonte: Elaboração Própria
Enquanto isso, a contagem do informante 4 também mostrou-se fora dos padrões
esperados para a contagem das funções de transação, porém dentro dos padrões para a
contagem das funções de dados. Logo, é possível constatar, em um primeiro momento, que há
uma probabilidade maior de a contagem das funções de transação estarem incorretas, o que
pode significar que esse informante apresenta certa dificuldade na identificação de processos
elementares.
Informante 5
AIE
15%
CE
39%
ALI
15%
SE
8%
EE
23%
Figura 15 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 5
Fonte: Elaboração Própria
45
O informante 5, por sua vez, apresentou grande variação na contagem das Consultas
Externas, excedendo o esperado em até 10% (já considerando a margem de erro de 5% para
mais ou para menos). Além das consultas externas, também notou-se uma variação de
aproximadamente 10% do valor esperado em relação aos Arquivos Lógicos Externos.
Informante 6
AIE
13%
CE
40%
ALI
20%
SE
7%
EE
20%
Figura 16 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 6
Fonte: Elaboração Própria
O informante 6, apresentou um comportamento parecido com o informante anterior,
em uma situação novamente com grande variação na contagem das Consultas Externas,
excedendo o esperado em até 12% (já considerando a margem de erro de 5% para mais ou
para menos). Além da consulta, também notou-se variação de aproximadamente 10% do valor
esperado em relação aos Arquivos Lógicos Externos. Nesse caso, percebe-se também uma
possível dificuldade do informante na identificação dos processos elementares, visto que
todas as porcentagens obtidas para as funções de transação excederam o esperado.
46
Informante 7
AIE
19%
CE
31%
ALI
12%
SE
0%
EE
38%
Figura 17 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 7
Fonte: Elaboração Própria
Os resultados do informante 7 também não podem ser considerados segundo os
padrões esperados para a contagem, visto que houve grande variação da porcentagem obtida
em relação à porcentagem esperada. Observou-se, portanto que todos os componentes
funcionais, com exceção das entradas externas, não estão dentro do padrão indicado
anteriormente, o que pode justificar uma grande probabilidade de a contagem estar incorreta.
Nota-se que esse informante foi o único dentre os certificados a não identificar funções de
transação do tipo saída externa, demonstrando possivelmente problemas na identificação
desse tipo de processo elementar.
Informante 8
CE
21%
AIE
10%
ALI
21%
SE
16%
EE
32%
Figura 18 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 8
Fonte: Elaboração Própria
47
Já o informante 8 apresentou-se dentro dos padrões esperados para a contagem, visto
que em sua contagem não houve grande variação da porcentagem obtida em relação à
porcentagem esperada.
Informante 9
AIE
9%
CE
24%
ALI
33%
SE
10%
EE
24%
Figura 19 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 9
Fonte: Elaboração Própria
Finalmente, o informante 9 também apresentou-se dentro dos padrões esperados para a
contagem, visto que não houve grande variação da porcentagem obtida em relação à
porcentagem esperada. Porém, deve-se ressaltar que, embora os resultados desse informante
tenham se apresentado próximo das porcentagens esperadas, houve grande variação na
identificação de Arquivos Lógicos Internos, o que pode indicar dificuldades no agrupamento
lógico e ocasionar considerável aumento nas complexidades das funções de transação
encontradas.
48
Informante 10
AIE
12%
CE
29%
ALI
12%
EE
18%
SE
29%
Figura 20 – Distribuição porcentual da quantidade de pontos de função encontrados pelo informante 10
Fonte: Elaboração Própria
Por fim o informante 10 apresentou-se fora padrões esperados para a contagem.
Observa-se para este informante grande variação nos arquivos lógicos internos e nas funções
de transação, especialmente nas saídas externas, ficando aproximadamente 10% acima da
média dos outros informantes.
A partir dos gráficos de todos os informantes observa-se uma heterogeneidade nas
contagens dos informantes quando comparada com os demais. Enquanto alguns encontraram
uma grande porcentagem de ALIs, chegando aos 33% do total de pontos encontrados, outros
encontraram 12%. Houve variação consideráveis em todos os componentes funcionais
observados, demonstrando entendimentos diversos dos profissionais envolvidos.
4.4
ANÁLISE FUNÇÕES DE DADOS
4.4.1
Arquivo Lógico de Clientes e Funcionários
Mediante a análise dos dados recebidos pelos informantes da pesquisa, nota-se, apenas
para os agrupamentos lógicos de clientes e funcionários, consenso entre os profissionais
certificados. Para os demais arquivos lógicos existiram divergências.
No cenário fornecido para a contagem, observa-se o seguinte trecho:
49
As tabelas de Clientes, Função e Funcionário não são mantidas dentro dessa
fronteira. Elas provem de outros sistemas, nos quais elas são ALIs, conforme
detalhado no tópico fronteiras envolvidas.
Conforme consta no cenário proposto para a contagem, está explícito que os Arquivos
Lógicos de Clientes e Funcionários caracterizam ALIs na fronteira de Recursos Humanos e na
Fronteira de Marketing, sendo, portanto AIEs na fronteira de Monitoramento de Pragas já que
foram referenciados pelos processos elementares da aplicação contada. Dessa maneira, o
consenso entre os profissionais era previsível e não representa um resultado extraordinário.
Entretanto, embora haja consenso com relação à identificação dessas funções de dados, bem
como os seus tipos, foram constatadas divergências na contagem de DERs e RLRs.
Os informantes identificaram os seguintes RLRs para o arquivo lógico de Cliente:
Tabela 10 – RLR do Arquivo Lógico Cliente identificado pelos informantes
Inf 1
Inf 2
Inf 3
Inf 4
Inf 5
Inf 6
Inf 7
Inf 8
Inf 9 Inf 10
Clientes
Beneficiados
Fonte: Elaboração Própria
E identificaram os seguintes RLRs para o arquivo lógico de Funcionários:
Tabela 11 – RLR do Arquivo Lógico Funcionário identificado pelos informantes
Inf 1
Inf 2
Inf 3
Inf 4
Inf 5
Inf 6
Inf 7
Inf 8
Inf 9 Inf 10
Funcionário
Função
Veículo
Fonte: Elaboração Própria
Segundo consta no manual de práticas de contagem:
O tipo de registro elementar (RLR) representa a visão do usuário dos subgrupos de
dados dentro de um arquivo lógico identificado.
Percebe-se que os informantes adotaram duas abordagens distintas na realização da
contagem dos RLRs do Arquivo Lógico de Clientes. Cinco deles consideraram que, além do
registro de cliente, exista também o registro de beneficiados. A outra metade, contudo,
considerou apenas um registro referente aos clientes.
Para o arquivo lógico de funcionário, houve consenso na identificação do RLR de
Funcionário, por outro lado apenas o Informante 6 considerou como RLR o subgrupo,
denominado pelo mesmo, como veículo.
50
Tanto a tabela de beneficiados (contado por alguns especialistas como RLR do AIE
Clientes) quanto a tabela de Veículos (contado por alguns especialistas como RLR do AIE
Funcionários) possuem apenas um atributo próprio reconhecido pelo usuário e não repetido.
Questiona-se, portanto, para os RLR mencionados se a chave estrangeira somada ao atributo
de total de descontos caracterizaria um subgrupo de dados, conforme definição do Manual de
Práticas de contagem.
A contagem dos Dados Elementares Referenciados também apresentou divergência
entre os informantes, como se pode notar abaixo:
Tabela 12 – DERs do Arquivo Lógico Cliente identificado pelos informantes
Inf 1
Inf 2
Inf 3
Inf 4
Inf 5
Inf 6
Inf 8
Inf 9 Inf 10
Código Cliente
Código Plantação
Indicador de beneficiado
Logradouro
Nome Cliente
Número Logradouro
Telefone Fixo
Total Descontos
Fonte: Elaboração Própria
Nota-se, portanto que houve discordância, principalmente, em relação aos campos
Logradouro e Número de Logradouro.
De acordo com o Manual de Práticas de contagem do IFPUG:
Nos Estudos de caso, o endereço é sempre usado inteiramente. Não existem telas ou
relatórios, onde uma única parte do endereço seja usada sem as outras partes. Não
existe situação onde uma parte do endereço seja usada para ordenação, edição ou
critério de seleção.
Conclui-se, portanto que a contagem do campo Número de Logradouro como DER
mostra-se inadequada, visto que no cenário fornecido para a contagem não consta indicação
de que o Número de Logradouro seja usado de maneira independente na aplicação.
O informante 9, adotou a seguinte interpretação e considerou como premissa na
contagem enviada, a respeito destes campos que:
51
Os campos referentes ao logradouro e número logradouro, referentes ao endereço do
cliente não são utilizados na aplicação que está sendo contada, desta forma não
foram considerados.
A informação levantada pelo informante não se aplica em sua totalidade, já que,
conforme descrito no cenário fornecido para a contagem, o campo de logradouro é utilizado
ao se enviar um SMS para os funcionários das Corporações Dummont. O cenário não deixa
evidente de que maneira o campo de número de logradouro é utilizado na aplicação sendo
contada, embora possa ser adotada como premissa que ao enviar o logradouro via SMS ao
cliente, é enviado também o número de logradouro.
Para o arquivo lógico de Funcionários, os informantes identificaram os seguintes
DERs:
Tabela 13 – DERs do Arquivo Lógico Funcionários identificado pelos informantes
Inf 1
Inf 2
Inf 3
Inf 4
Inf 5
Inf 6
Inf 8
Inf 9 Inf 10
Admissão
Ano Compra
Código Função
Código Funcionário
Código Reparo
Data Contratação
Descrição Função
Foto funcionário
Nome Funcionário
Nome Meio Funcionário
Sobrenome Funcionário
Nome meio Funcionário +
Sobrenome
Nome + Nome meio +
Sobrenome Funcionário
Teto Salarial
Vencimento Carta
Placa Veículo
Fonte: Elaboração Própria
Para a identificação dos Dados Elementares Referenciados do Agrupamento lógico de
Funcionários, nota-se uma homogeneidade maior entre os especialistas. A maior discordância
52
está na contagem dos campos de Nome Funcionário, sobrenome de Funcionários e Nome do
Meio do Funcionário.
Segundo o Manual de Práticas de Contagem:
Nos Estudos de caso, o Nome do Funcionário é sempre usado inteiramente. Não
existem telas ou relatórios, onde uma única parte do nome seja usada sem as outras
partes. Também não existem situações onde uma parte do nome é usada para
ordenação, edição ou critério de seleção.
No cenário aplicado, o nome do motorista é apresentando isoladamente em consulta
apresentada na tela, apartado do sobrenome e do nome do meio. Em outras consultas o nome
aparece acompanhado de sobrenome e nome do meio. Logo, considera-se que a contagem do
nome como único DER é inadequada, bem como a contagem apartada de todos os campos
referentes ao nome. Sendo o nome do funcionário utilizado de maneira independente na
aplicação, o mesmo deve ser considerado como um DER distinto, do nome meio Funcionário
e do sobrenome funcionário, visto que não existem evidências de que esses possuam
significados independentes. O sobrenome e o nome do meio sempre que apresentados, são
apresentados juntos. O único informante que adotou essa interpretação foi o informante 3.
É importante destacar que o informante 7 não documentou os DERs considerados e,
portanto, foi excluído desta análise. Já os demais informantes não colocaram observações
adicionais a respeito da contagem realizada.
4.4.2
Arquivo Lógico de Função
O Arquivo Lógico de Função não foi considerado por alguns informantes envolvidos
na contagem, embora existam ponderações no cenário indicando que função caracteriza um
arquivo lógico interno dentro da fronteira de Recursos Humanos.
A tabela de função motivou diversas interpretações entre os informantes. Enquanto
alguns a identificaram como Arquivos Lógicos, outros identificaram a tabela de função como
um registro lógico referenciado. Por fim houve informantes que não consideraram função
como arquivo ou como registro.
A divergência a respeito do Agrupamento Lógico de Função pode ser conferida na
figura 21:
53
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Arquivo lógico Função
Figura 21 – Quantidade de informantes que contaram Agrupamento Lógico de Função
Fonte: Elaboração Própria
Dentre os informantes que não consideraram função como agrupamento lógico de
dados, apenas dois documentaram considerações a respeito desse agrupamento na contagem
entregue, observando que o agrupamento não é utilizado, em nenhum momento, pelas
funcionalidades da Fronteira de Monitoramento de Pragas.
Os quatro informantes que desconsideraram a função de dados da contagem não
indicaram o motivo de tal decisão, não sendo possível, portanto, afirmar com precisão o
motivo de os mesmos adotarem esse comportamento.
Ressalta-se, portanto que houve desvio do "Procedimento do Método de Medição de
Tamanho Funcional", já que grande parte dos envolvidos na pesquisa não documentaram as
premissas adotadas na contagem.
Devido à grande discordância em relação ao agrupamento lógico, considerou-se
inadequada a comparação dos DERs e RLRs da função, visto que seriam encontradas grandes
diferenças já que o agrupamento dessa função não seguiu nenhum padrão entre os
informantes.
Para a tabela de função foram consideradas todas as possibilidades, ou seja, a função
não foi contada, foi contada como Arquivo Lógico, ou como registro lógico. Além disso,
percebe-se um equilíbrio numérico entre as diferentes abordagens adotadas pelos informantes:
quatro optaram pela primeira abordagem, três optaram pela segunda, enquanto três optaram
pela última.
54
4.4.3
Arquivo Lógico de Plantação
Mediante insumos fornecidos para a contagem, nota-se que a tabela de plantação está
relacionada
às
tabelas
de
"Cliente-has_Plantacao",
"Cidade",
"Bairro",
"Plantação_has_Criticidade", "reparosPlantação", "tipoProduto" e "Monitoramento".
Verifica-se no cenário fornecido, a seguinte informação referente à tabela de
Plantação: “As tabelas de “FaixaCriticidade” e “Plantação” serão mantidas via script que será
executado diretamente no banco de dados”. Tendo em vista essas considerações, sete
informantes determinaram o agrupamento lógico de dados passível de mensuração, conforme
demonstra a figura 22:
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Arquivo lógico Plantação
Figura 22 – Quantidade de informantes que contaram Agrupamento Lógico de Plantação
Fonte: Elaboração Própria
Nota-se, portanto, divergências na identificação do Arquivo Lógico de Plantação.
O informante 2 desconsiderou o Arquivo Lógico de Plantação, e identificou que se
tratava de Dados de Código. Segundo o manual de práticas de contagem:
A terceira categoria de dados, referenciada a seguir neste capítulo como “Dados de
Códigos”, contudo, geralmente existe para satisfazer requisitos não-funcionais do
usuário (para requisitos de qualidade, implementação física e/ou uma razão técnica)
ao invés de um requisito funcional do usuário.
55
Nota-se que o informante 2 foi o único dentre os dez certificados a identificar que a
tabela de plantação existe para atender requisitos não funcionais do usuário. Essa
interpretação pode ter sido adotada porque a tabela "Plantação" possui dados chaves e apenas
um atributo não chave, se aproximando das possíveis características físicas apontadas pelo
manual para entidades do tipo Dados de Código. Entretanto, nota-se que, no cenário, a tabela
de "Plantação" não possui dados estáticos, sendo necessária a sua inclusão toda vez que um
cliente com uma plantação optar pelos serviços da empresa. Além disso, a tabela de plantação
se distancia de todas as características lógicas de Dados de Código apontadas pelo manual de
práticas de contagem. Dessa maneira, considera-se inadequada a identificação do Arquivo
Lógico de Plantação como dados de Código.
Os informantes 5 e 6 consideraram que o Arquivo Lógico de plantação fosse um RLR
do Arquivo de monitoramento. A classificação de Plantação como um RLR provavelmente
resultou da conclusão, por parte dos informantes, de que a tabela de plantação não possui
significado independente para o negócio. A indicação de que a tabela de plantação é mantida
via script, pode nos dar evidências de que existe significado para o negócio manter apenas
dados referentes a plantação, independentes dos dados de monitoramento. Porém, o cenário
não abrange com detalhes como ocorre a manutenção dos dados de plantação, permitindo
variações a respeito das interpretações dos especialistas envolvidos. Entretanto, independente
da abordagem adotada, os informantes deveriam ter documentado possíveis premissas. Logo
para os informantes citados acima, nota-se desvio do Procedimento do Método de Medição de
Tamanho Funcional, já que os mesmos não documentaram as intepretações adotadas para a
contagem.
Os demais informantes que identificaram o arquivo lógico de Plantação como passível
de mensuração demonstraram divergências com relação à identificação dos DERs e RLRs.
Foram contados os seguintes RLRs para o arquivo lógico de plantação:
Tabela 14 – RLR do Arquivo Lógico Plantação identificado pelos informantes
Inf 1
Inf 3
Inf 4
Inf 7
Plantação
Reparo Plantação
Monitoramento
Tipo Produto
Bairro
Cidade
Fonte: Elaboração Própria
Inf 8
Inf 9
Inf 10
56
Nota-se que existe uma pequena heterogeneidade em relação à identificação dos
RLRs, já que alguns profissionais apresentaram interpretações distintas durante a contagem
dos Registros Lógicos Referenciados do Arquivo Lógico de Plantação. O informante 4 foi o
que apresentou maior desvio, já que considerou as tabelas de "Bairro", "Cidade" e "Tipo de
Produto" como RLR do Arquivo Lógico de plantação, enquanto esses deveriam ser Dados
Elementares Referenciados. Já o informante 9 contou apenas um RLR, considerando que
monitoramento e reparos de plantação caracterizam Arquivos Lógicos Independentes do
Arquivo Lógico de plantação. Esse último observou os seguintes pontos na contagem
entregue:
Foi considerado que o grupo de dados Monitoramento poderá existir, mesmo que a
plantação não exista mais (para fins de estatística, por exemplo). Esta premissa foi
assumida, pois não foi localizada informações esclarecedoras acerca do assunto.
É importante ressaltar que o informante 9 foi o único dentre os informantes a apontar a
necessidade da complementação do cenário enviado, indicando possibilidades na melhoria do
documento, por exemplo, com inclusão de informações relevantes para a contagem de Pontos
de Função. Além disso, o mesmo seguiu o Processo de Contagem previsto pelo manual, que
indica que todas as premissas e considerações devem ser documentadas e relatadas. A
premissa adotada pelo informante 9 é coerente, visto que nos insumos fornecidos para a
contagem não está evidente quais dados são mantidos ao se incluir uma plantação ou se, ao se
excluir uma plantação, o monitoramento ainda possui significado independente para o
negócio, conforme dito anteriormente. Considera-se, portanto, que embora os informantes
tenham adotado a mesma linha de raciocínio na identificação dos registros lógicos
referenciados, os mesmos não documentaram as premissas adotadas, com exceção do
informante 9.
Já com relação à identificação dos DERs, também se foram detectadas variações.
Embora os informantes 1, 3, 7, 8 e 10 tenham identificado os mesmo RLR, foram encontradas
heterogeneidades na contagem dos DERs dos agrupamentos lógicos destes informantes.
57
Tabela 15 – DERs do Arquivo Lógico Plantação identificado pelos informantes 1, 3, 8 e 10
Inf 1
Inf 3
Inf 8
Inf 10
Código Cliente
Código da Plantação
Código funcionário
Código Reparo
Coordenada X
Coordenada Y
Data Criticidade
Descrição Bairro
Descrição Cidade
Descrição Criticidade
Descrição da Cidade
Descrição do Produto
Descrição do Reparo
ID Bairro
ID Cidade
ID Criticidade
ID Faixa Criticidade
ID Monitoramento
Indicador Ácaros
Indicador Insetos
Justificativa reparo
Logradouro
Temperatura
Tipo Produto
Umidade Relativa
Valor Máximo
Valor Mínimo
Fonte: Elaboração Própria
Destaca-se que o informante 10 teve grande variação na contagem dos DERs se
comparado aos demais informantes listados acima. Essa variação ocorre porque o mesmo
considerou como DERs os campos de tabelas que foram mensurados pelos
informantes como Arquivos Lógicos distintos
outros
ou não foram considerados na contagem
enviada.
Observa-se, portanto que entre os profissionais que identificaram três RLRs, houve
variação da complexidade da função de dados para o informante 10. Ressalta-se que o
informante 7 não documentou os DERs considerados e, portanto, foi excluído desta análise.
58
Para os informantes 9 e 4, que divergiram na identificação dos RLRs, conforme
exposto acima, foram identificados os seguintes DERs:
Tabela 16 – DERs do Arquivo Lógico Plantação identificado pelos informantes 4 e 9
Inf 4
Inf 9
Código Cliente
Código da Plantação
Descrição Bairro
Descrição Cidade
Descrição Produto
Descrição Tipo Produto
ID Bairro
ID Cidade
ID Tipo de Produto
Logradouro
Fonte: Elaboração Própria
Os informantes acima apresentaram relativa homogeneidade na identificação dos
DERs. Sendo assim, tendo em vista o grupo de informantes, é observada certa
heterogeneidade na contagem no agrupamento lógico realizado, na identificação dos RLRs e
na identificação dos DERs.
Dos dez profissionais envolvidos na pesquisa, três não consideraram o Arquivo Lógico
de Plantação independente. Dos sete restantes, dois consideraram RLRs distintos dos demais e
os outros cinco divergiram a respeito da identificação dos DERs dos arquivos lógicos.
4.4.4
Arquivo Lógico de Veículo e Posição Veículo
O cenário fornecido para a contagem não relata como os dados de veículos são
mantidos, e se os mesmos são incluídos dentro da fronteira de monitoramento de pragas. No
cenário demonstra-se a necessidade de realizar consultas a essa tabela, bem como realizar o
processo de expurgo.
Para tal agrupamento nota-se relativa homogeneidade em relação a sua identificação
por parte dos profissionais envolvidos na pesquisa já que oito informantes consideraram
Veículo como um Arquivo Lógico Interno, em detrimento de dois que não os consideraram na
contagem enviada, conforme demonstra figura 23.
59
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Arquivo lógico Veículo
Figura 23 – Quantidade de informantes que contaram Arquivo Lógico Veículo
Fonte: Elaboração Própria
A falta de informações sobre como e em qual fronteira os dados de veículo são
mantidos, pode ter provocado distorção na identificação desse agrupamento lógico por parte
dos informantes, já que os mesmos não puderam realizar o agrupamento utilizando o metódo
de Processos Elementares, conforme descrito no CPM 4.3. A esse respeito o informante nove
acrescentou o seguinte comentário na contagem entregue:
Foi considerado que o grupo de dados Posição Veículo é dependente de Veículo, ou
seja, ao excluir um registro da tabela Veículo todos os registros de sua posição
também são apagados. Nesse caso não foi considerada a possibilidade utilização de
dados historicamente para estatística, pois os mesmos são expurgados
periodicamente. Observa-se uma inconsistência na especificação, onde não foi
identificado como/onde são mantidos os dados da tabela Veículo.
Nota-se que o último paragráfo apontado pelo mesmo converge para o exposto acima.
A falta dessa informação muitas vezes pode dificultar a identificação correta dos
agrupamentos lógicos, visto que sem essa informação o metódo de processos elementares para
identificação dos agrupamentos lógicos não pode ser utilizado.
Dessa forma, o comentário acima, é muito importante para garantir a consistência da
contagem, bem como indicar possíveis melhorias na documentação enviada para contagem.
60
Os dois informantes que não consideraram Posição de Veículo como RLR, a
mensuraram como Arquivo Lógico, e desconsideraram na contagem os dados contidos na
tabela de veículos.
Embora esse comportamento tenha sido adotado por dois informantes distintos, não foi
possível identificar o motivo de os mesmos realizarem tal agrupamento e desconsiderarem os
dados da tabela de veículos.
Dentre os oito informantes que consideraram veículo como um ALI, nota-se a seguinte
identificação dos RLRs:
Tabela 17 – RLRs do Arquivo Lógico Veículo e Posição do Veículo identificado pelos informantes
Inf 1
Inf 3
Inf 4
Inf 5
Inf 7
Inf 8
Inf 9
Inf 10
Veículo
Posição Veículo
Funcionário
Dados Básicos
Plantação
Fonte: Elaboração Própria
A identificação dos Registros Lógicos Referenciados não apresentou variação
significativa, visto que praticamente todos os profissionais envolvidos identificaram veículo e
posição de veiculo como RLR. A principal variação se deu em razão dos informantes 4 e 7,
que consideraram também o RLR de Funcionário e Dados Básicos da Plantação,
respectivamente.
Não foi possível identificar as causas que originaram o agrupamento de dados básicos
de plantação com veículos, até mesmo porque as tabela de plantação e de Veículo, não
possuem nenhum relacionamento no modelo de dados enviado. Por sua vez o informante 4,
considerou como RLR a tabela de Funcionários. Tal interpretação foi adotada porque o
mesmo provavelmente identificou que a tabela de Funcionário não possui significado
independente para o negócio sem uma ocorrência de Veículo a ela associada. Tanto o
informante 4 como o informante 7 não documentaram possíveis premissas adotadas na
contagem.
Os DERs considerados pelos informantes que identificaram
Veículo como
agrupamentos lógicos podem ser visualizados mediante observação da tabela 18.
61
Tabela 18 – DERs do Arquivo Lógico Veículo e Posição do Veículo identificado pelos informantes
Inf 1
Inf 3
Inf 4
Inf 5
Inf 8
Inf 9
Inf 10
Ano Compra
Cód. Funcionário
Coordenada X
Coordenada Y
Coordenadas
Data
Data
-
Hora
-
Minuto - Segundo Microssegundo
Hora
Id posição Veiculo
Microssegundo
Minuto
Placa Veiculo
Segundo
Timestamp
Fonte: Elaboração Própria
Há um equilíbrio na identificação dos Dados Elementares Referenciados do
agrupamento lógico acima, tendo, entretanto, como principal fator de divergência a contagem
dos campos data, hora, minuto, segundo e microssegundo.
Enquanto alguns informantes consideraram que apenas a junção de todos esses
campos era significativa para o negócio, outros consideraram que todos tinham sentido
distinto e eram independentes. A respeito dessa questão, o informante 8, realizou a seguinte
observação: “A granularidade (minuto, segundo, microssegundo) é irrelevante para o
usuário”.
No cenário não existe indicação de que tais campos, quando separados, são utilizados
para determinadas transações, ou são utilizados independentes dos outros campos, embora os
mesmos tenham sido separados fisicamente na tabela.
Segundo o manual de práticas de contagem, pode-se notar a seguinte orientação para
contagem de atributos compostos de diversos elementos de dados:
Se o atributo é sempre usado por inteiro, então ele é contado como um único
elemento de dados (DER). Não devem existir situações em que um componente
62
individual de um atributo é usado sem os outros. Baseado neste uso, o atributo é
contado como um único elemento de dado.
Logo, considera-se que a contagem separada de tais atributos apresenta-se inadequada,
visto que não existem informações suficientes no cenário fornecido.
4.4.5
Arquivo Lógico de Faixa de Criticidade
Conforme consta no cenário proposto para a contagem, nota-se a seguinte observação
a respeito dessa tabela:
Após o cálculo, o sistema identifica se o resultado gerado está dentro da faixa de
valores da cor Verde, Azul ou Amarelo. Para isso ele deve ler os dados da tabela
"faixaCriticidade" após ter realizado os cálculos necessários, e gravar na tabela
“Plantacao_has_Criticidade” a criticidade para determinada plantação.
Também há a seguinte observação no cenário: As tabelas de “FaixaCriticidade” e
"Plantação” serão mantidas via script que será executado diretamente no banco de dados”.
Nota-se relativa heterogeneidade na contagem desta entidade por parte dos
profissionais envolvidos. Dos dez profissionais, sete não consideraram faixa de criticidade
como um agrupamento lógico de dados. Em contrapartida três profissionais consideraram que
trata-se de um ALI na fronteira de monitoramento de pragas. Tal fato pode ser comprovado
conforme figura 24.
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Arquivo lógico Criticidade
Figura 24 – Quantidade de informantes que contaram Arquivo Lógico de Faixa de Criticidade
Fonte: Elaboração Própria
63
Dos sete profissionais que desconsideraram esse agrupamento, seis não documentaram o
motivo por terem adotado tal decisão.
O informante oito, por sua vez, desconsiderou tal agrupamento, já que segundo o
mesmo "Não existe PE para atualizar estas informações de controle". Tal consideração revela
por um lado o não desenvolvimento de uma funcionalidade capaz de incluir dados na
aplicação mediante interface gráfica com os usuário, porém conforme nota-se no cenário a
inclusão de dados na tabela de faixa de criticidade é realizada diretamente no gerenciador de
banco de dados. O cenário não deixa evidente o motivo de serem realizadas inclusões
diretamente no Banco de dados.
Entretanto, o fato de a tabela não ser mantida por um processo elementar da aplicação
não deve ser justificativa para a mesma ser desconsiderada, visto que ela é utilizada pela
aplicação, para determinar se a criticidade da plantação se encaixa dentro das cores Vermelha,
Laranja ou Vermelha, além de ser reconhecida pelos usuários do sistema. Logo representando
a necessidade de possíveis parametrizações a respeito da faixa de criticidade, considera-se que
a não contagem desse agrupamento (como DER, RLR ou ALR) pelo motivo apresentado é
inadequada.
Os informantes 5 e 6, desconsideraram a tabela de Faixa de Criticidade, uma vez que
identificaram tratar-se de Dados de Código. Conforme nota-se no modelo de dados enviado, a
tabela de Faixa de Criticidade contém atributos que identificam os valores máximos e
mínimos que devem ser considerados para determinação da criticidade da plantação.
Tal interpretação adotada por esses informantes, mostra-se pertinente já que no cenário
não há informações a respeito da dinamicidade dos dados, de maneira que se possa verificar
se os dados são ou não estáticos. Entende-se que a possibilidade de manter os dados
diretamente no gerenciador de banco de dados, não é indicador para a determinação da
dinamicidade ou não dos atributos dessa tabela.
Os informantes 1, 4 e 9, que contaram faixa de criticidade como Arquivo Lógico
Interno, consideraram como RLR - faixa de criticidade - e como DERs, os campos Id Faixa
Criticidade, Criticidade, Descrição Criticidade, Valor Minimo e Valor Máximo. Os três
identificaram os mesmos RLRs e DERs, não apresentando variações entre si. O informante 9
documentou as seguintes observações a respeito da identificação de faixa de Criticidade como
ALI:
64
Mesmo não havendo funções de transação que alimentam esse arquivo lógico, foi
considerado que a mesma é um grupo de dados reconhecimento pelo negócio e
mantido dentro da fronteira da aplicação via script no banco de dados.
Provavelmente os três informantes adotaram como premissa que os dados contidos na
tabela não são estáticos e, portanto, agregam valor ao negócio. Considerando também que
ambos os informantes consideraram Faixa de Criticidade como um ALI, subentende-se que
o informante 1, assim como o informante 9, considerou que a possibilidade de incluir
dados na tabela via script do banco de dados é suficiente para caracterizar o agrupamento
lógico de dados como mantido pela aplicação, e consequentemente classificá-lo como um
ALI.
4.4.6
Arquivo Lógico de Plantação_Cliente
A tabela Plantação_has_Criticidade configura-se como uma entidade associativa entre
as tabelas Plantação e Criticidade. As entidades associativas só serão consideradas como
Arquivos Lógicos Internos quando as mesmas forem mantidas pela aplicação sendo contada.
Conforme cita o Manual de práticas de contagem:
Embora Funções Atribuídas seja uma entidade associativa, ela é mais que um
mapeamento key-to-key entre duas entidades, e é mais que um RLR associado com
um arquivo lógico. Se uma regra de negócio solicita que a informação de Funções
Atribuídas deva ser retida independentemente, Funções Atribuídas é considerada um
arquivo lógico como descrito na Seção “Identificar Arquivos Lógicos Utilizando o
Método de (In)Dependência de Entidades (Subpasso 1.3b)”.
Conforme cenário aplicado, nota-se:
Após o cálculo, o sistema identifica se o resultado gerado está dentro da faixa de
valores da cor Verde, Azul ou Amarelo. Para isso ele deve ler os dados da tabela
"faixaCriticidade" após ter realizado os cálculos necessários, e gravar na tabela
“Plantacao_has_Criticidade” a criticidade para determinada plantação.
Observa-se no trecho acima, que o sistema mantém os dados da tabela, para armazenar
as criticidades de cada plantação, atributo este reconhecido pelo usuário e relevante para o
mesmo.
Apenas três informantes dentre os dez consideraram que Plantação_Criticidade tratase de um Arquivo Lógico independente, conforme pode-se observar na figura 25.
65
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Arquivo lógico Plantação_has_Criticidade
Figura 25 – Quantidade de informantes que contaram Arquivo Lógico de Plantação_Cliente
Fonte: Elaboração Própria
Dessa maneira, observa-se um comportamento heterogêneo entre os informantes que
colaboraram com a pesquisa. O informante 9 realizou a seguinte observação a respeito desse
componente funcional:
Foi considerado que o grupo de dados Criticidade Plantação poderá existir, mesmo
que a plantação não exista mais (para fins de estatística, por exemplo). Esta premissa
foi assumida, pois não foi localizada informações esclarecedoras acerca do assunto.
Os demais informantes envolvidos, que desconsideraram essa entidade como Arquivo
Lógico não documentaram as premissas adotadas na contagem.
Os informantes 1, 8 e 9 que mensuraram tais depósitos de dados como arquivos
lógicos internos, consideraram os mesmos DERs e RLRs, sendo eles Código plantação,
Ccriticidade, Data e Plantação_has_Criticidade, respectivamente.
4.4.7
Arquivo Lógico de Monitoramento
Conforme evidencia-se no cenário, a tabela de monitoramente tem o propósito no
sistema de armazenar informações referentes às condições das plantação, como por exemplo
dados de temperatura e umidade. Pode-se notar tal fato conforme exposto abaixo:
66
Os receptores enviam informações de cinco em cinco minutos para a aplicação, que
armazena os dados recebidos na tabela de "Monitoramento". Os dados, transmitidos
via satélite pela aplicação, são respectivamente: Coordenada X, Coordenada Y,
Temperatura Ambiente, Umidade Relativa, Indicador de movimentação de ácaros ou
insetos. A partir dessas coordenadas, o sistema consegue localizar o código da
plantação correspondente.
Dos dez informantes envolvidos na pesquisa, metade considerou a entidade de
monitoramento como ALI, enquanto os demais a consideraram como RLR do Arquivo
Lógico Interno de Plantação.
Inicialmente nota-se grande heterogeneidade na contagem deste componente
funcional. Tal fato pode ser verificado conforme figura 26.
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Arquivo lógico Monitoramento
Figura 26 – Quantidade de informantes que contaram Arquivo Lógico de Monitoramento
Fonte: Elaboração Própria
A respeito desta entidade o informante 9 realizou a seguinte observação:
Foi considerado que o grupo de dados Monitoramento poderá existir, mesmo que a
plantação não exista mais (para fins de estatística, por exemplo). Esta premissa foi
assumida, pois não foi localizada informações esclarecedoras acerca do assunto.
O cenário não deixa evidente a independência ou não desta entidade com a entidade de
plantação. Considera-se, portanto, que a observação é pertinente. Os demais informantes não
documentaram observações ou premissas à respeito desta entidade.
67
Considera-se, portanto que a omissão desta informação no cenário provocou
divergência entre os profissionais que adotaram duas abordagens: Os que contaram e os que
não contaram este Agrupamento lógico.
Segundo consta no Manual de práticas de contagem (2012:2-25): Na dúvida decida
por entidades independentes. Dessa maneira, considera-se que a consideração deste arquivo
lógico acompanhado de premissas seja a melhor abordagem a ser utilizada.
Considera-se que os profissionais que consideraram o agrupamento lógico como
passível de mensuração, bem como os informantes que não consideraram o agrupamento
lógico sem premissas, adotaram abordagens inadequadas, neste caso.
Os outros informantes que consideraram a entidade de monitoramento como RLR do
ALI Plantação, provavelmente adotaram como premissa que Monitoramento não possui
significado independente para a aplicação.
Dentre os cinco informantes que consideraram a entidade de monitoramento como um
ALI independente, identificaram-se os seguintes RLR:
Tabela 19 – RLRs do Arquivo Lógico de Monitoramento identificado pelos informantes
Inf 2
Inf 4
Inf 5
Inf 6
Inf 9
Monitoramento
Reparos Plantação
Plantação_Criticidade
Plantação
Fonte: Elaboração Própria
Observa-se também divergência a respeito da contagem dos RLR do ALI de
monitoramento. Não é possível determinar com acurácia o motivo da divergência entre os
profissionais visto que os mesmos não documentaram as premissas adotadas.
As entidades de Reparos_Plantação, Plantação_Criticidade e Plantação apresentaram
divergências na contagens realizadas visto possíveis interpretações divergentes dos
profissionais que participaram da pesquisa.
Devido a considerável divergência na identificação dos RLR deste agrupamento
considera-se que a comparação dos DERs encontrados pelos informantes não seja relevante à
pesquisa, devido ao agrupamento distinto entre os profissionais.
68
4.4.8
Arquivo Lógico de Beneficiados
Conforme nota-se nos insumos fornecidos para a contagem, a tabela denominada
“Beneficiados” contém além do atributo total de descontos, um atributo de chave estrangeira.
A tabela é utilizada para armazenar os dados dos clientes que não tiveram nenhuma
ocorrência de praga durante o ano, e, portanto obtiveram uma quantia em desconto a ser
descontada na fatura de janeiro, conforme se comprova no trecho abaixo:
Para os clientes que não apresentaram problemas em suas plantações, o sistema
armazenará o ID desses clientes na tabela "Beneficiados". Dessa maneira, no
primeiro dia do ano o Sistema de Pagamentos e Cobranças lerá os dados dessa tabela
para gerar os boletos do mês de janeiro, abatendo as despesas.
A contagem deste componente funcional apresentou divergências entre os
informantes, visto que dos dez profissionais, três consideraram que Beneficiados
caracterizava um ALI, e, portanto era passível de mensuração, como demonstra figura 27.
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Arquivo lógico Beneficiados
Figura 27 – Quantidade de informantes que contaram Arquivo Lógico Beneficiados
Fonte: Elaboração Própria
Observa-se, conforme exposto no tópico “Arquivo lógico de Clientes e Funcionários”
que os informantes 2, 4, 5, 7 e 9 consideraram beneficiados como RLR de Cliente.
Logo, contata-se comportamentos heterogêneos adotados pelos informantes na
contagem enviada.
69
O informante 8 realizou o seguinte comentário à respeito deste agrupamento lógico:
Trata-se de ALI compartilhado.
Dentre os três informantes que realizaram a contagem, todos eles consideraram como
RLR – Beneficiado – e como DERs – Código de Cliente e Total de Descontos.
Entende-se que os informantes, provavelmente identificaram que Beneficiados possui
significado independente para o negócio, sem a ocorrência de um cliente a ele vinculado.
4.4.9
Arquivo Lógico de Reparos Plantação
Por fim, observa-se que para a contagem da entidade Reparos Plantação, os
informantes seguiram um comportamento heterogêneo, visto que apenas um dentre os dez
considerou a entidade como Arquivo Lógico interno. Tal fato pode ser observado na figura
28.
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Arquivo lógico Reparos Plantação
Figura 28 – Quantidade de informantes que contaram Arquivo Lógico de Reparos Plantação
Fonte: Elaboração Própria
O informante não documentou premissas para a contagem desta entidade como
Arquivo Lógico Interno. Provavelmente, o informante tenha identificado que Reparos
Plantação é independente da entidade de Plantação, ou seja, ela possui significado para o
negócio, sem a ocorrência de uma entidade de Plantação vinculada.
70
Os outros nove informantes que não classificaram o arquivo Reparos Plantação como
ALI, cinco contaram a entidade como RLR do Arquivo Lógico de Plantação e três
consideraram como RLR do Arquivo Lógico de Monitoramento. Apenas um desconsiderou a
entidade de Reparos de Plantação da contagem, sem apontar possíveis premissas.
Logo, constata-se uma aplicação heterogênea da técnica, em relação à identificação
dos Arquivos Lógicos da aplicação.
4.5
ANÁLISE FUNÇÕES DE TRANSAÇÃO
A análise das funções de transação como apresentadas abaixo, tem como propósito
analisar detalhadamente os processos elementares identificados pelos informantes, bem como
possíveis divergência encontradas em relação a identificação do tipo de função de transação e
contagem dos DERs.
Devido à realização de agrupamentos de dados distintos efetuados por cada
informante, e explicitados nos tópicos acima, considera-se que a análise dos Arquivos
Lógicos Referenciados não seja parâmetro para indicar possíveis divergências entre os
certificados visto que devido a diferentes agrupamentos lógicos os ALRs, consequentemente,
irão variar de informante para informante.
A análise das funções de transação se baseou em processos elementares que
apresentaram divergências consideráveis entre os informantes da pesquisa, e, portanto as
funcionalidades Consultar Plantação, Detalhar Veículos, Detalhar Funcionários e Emitir
Relatório Clientes Desconto não serão avaliadas nos próximos tópicos visto que houve
consenso em relação a identificação dos processos elementares.
4.5.1
Carga Inicial Monitoramento Pragas
Conforme já descrito, no cenário aplicado aos informantes, à empresa "Corporações
Dummont" armazenavam seus dados em planilhas Excel, havendo a necessidade de migrar os
dados já coletados para o novo sistema de maneira que tais dados não se perdessem:
Antes da implantação deste sistema, os próprios responsáveis pelo local coletavam
os dados diariamente (informações de temperatura e umidade, bem como a presença
de insetos e/ou ácaros). Dessa maneira, as informações eram todas armazenadas em
um arquivo Excel.
71
Dos 10 profissionais que participaram da pesquisa, apenas três contaram
funcionalidades para refletir a necessidade de migrar os dados. Observa-se, portanto, uma
heterogeneidade a respeito desse processo. Tal constatação pode ser evidenciada na figura 29.
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Migrar Monitoramento Pragas
Figura 29 – Quantidade de informantes que contaram Carga Inicial Monitoramento Pragas
Fonte: Elaboração Própria
De acordo com o manual de Práticas de Contagem, funcionalidades de conversão são:
funções transacionais ou de dados, fornecidas para converter dados e/ou prover
outros requisitos de conversão especificados pelo usuário.
As funcionalidades de conversão devem ser contadas considerando a identificação
padrão de processos elementares.
Dos seis certificados que não consideraram a funcionalidade, apenas um apontou o
motivo de não ter considerado tal função de conversão como pertencente ao tamanho
funcional do sistema. Os outros cinco informantes em nenhum momento especificaram o
motivo de tal decisão, desviando-se do Procedimento do Método de Medição de Tamanho
Funcional, que prevê que todas as considerações a respeito da contagem sejam documentadas
e reportadas. Sendo assim, não é possível afirmar com propriedade o motivo pelo qual essa
funcionalidade não foi considerada pelos informantes envolvidos.
Considerando que o propósito da contagem solicitada é: Determinar o tamanho da
aplicação instalada, quaisquer funcionalidades de conversão deveriam ser imediatamente
72
desconsideradas pelos informantes, visto que as funcionalidades de conversão não fazem
parte do tamanho funcional da aplicação, devendo ser considerada apenas em projetos de
desenvolvimento e melhoria.
O informante 1, que desconsiderou a funcionalidade, apresentou a seguinte
observação:
Não mensurável, pois poderá ser feito através de utilitário do banco de dados. Logo,
como não está claro o propósito da necessidade de desenvolvimento de uma
funcionalidade de migração, a funcionalidade não foi considerada.
Se a migração for feita por meio de um utilitário de um banco de dados, conclui-se que
não haverá necessidade de realizar o desenvolvimento de uma funcionalidade com tal
propósito, portanto, não existirá razão em mensurá-la.
Como no cenário aplicado não existem informações a respeito de como será feita a
implementação da funcionalidade, a dúvida procede, mas não deveria existir já que a
funcionalidade de conversão não faz parte do escopo da contagem.
Observa-se ainda que, embora os três informantes tenham considerado a
funcionalidade, existem divergências em relação à contagem dos DERs do processo. Os
DERs considerados pelos informantes estão listados abaixo:
Tabela 20 – DERs da Função de Transação Carga Inicial Monitoramento Pragas identificado pelos informantes
2, 4 e 9
Inf 2
Inf 4
Inf 9
Comando
Data
Indicador de movimentação de ácaros
Indicador de movimentação de insetos
Mensagem
Temperatura ambiente
Umidade relativa
Fonte: Elaboração Própria
Logo, observa-se que o informante 2 considerou não apenas os dados sendo migrados,
mas também a habilidade da aplicação de enviar uma mensagem de resposta e a habilidade de
iniciar uma ou mais ações, mesmo que existam diversas maneiras de fazer isso. No cenário
aplicado, não consta a informação se o sistema exibirá mensagens ao usuário da aplicação
após a migração ser realizada e não deixa evidente se existirá a possibilidade de o usuário
iniciar essa funcionalidade. Embora o informante tenha adotado possivelmente como premissa
73
que existem maneiras de a funcionalidade ser iniciada pelo usuário e que a mesma possa
exibir mensagem, as premissas que subsidiaram essa interpretação não foram apontadas por
ele.
Observa-se, para esta funcionalidade, uma divergência significativa, demonstrando
que não houve uma aplicação homogênea da técnica prevista pelo manual. Logicamente, caso
existisse um cenário parecido no meio corporativo, os analistas de sistema poderiam
solucionar rapidamente as dúvidas que não foram expostas com detalhes nos documentos
fornecidos para a contagem. Entretanto, considera-se inadequada a mensuração desta
funcionalidade já que a mesma não deveria fazer parte do tamanho funcional da aplicação.
4.5.2
Efetuar Expurgo Posição Veículo
Com a necessidade de atualizar, em certa periodicidade, o sistema com informações da
localização dos veículos da “Corporação Dummont”, também foi solicitado pelo gestor a
realização de um processo de expurgo.
Por fim, será desenvolvida uma nova funcionalidade, responsável por realizar o
expurgo da tabela de "posicaoVeiculo". O expurgo não será feito por limitações
técnicas. O expurgo irá ocorrer conforme as Regras de Negócio da Empresa, que
arquivava após cinco meses todas estas informações referentes a localização dos
veículos (Arquivo Morto). A funcionalidade pode ser executada de maneira
automática ou de maneira manual.
No trecho acima, entende-se que, a funcionalidade de expurgo originou-se conforme
solicitação do usuário, respeitando as regras de negócio da empresa, que tinha como parte do
processo armazenar estas informações após um período de cinco meses. O cenário fornecido
para a contagem não deixa claro o motivo da existência dessa regra de negócio, nem sequer
detalha a regra existente. Contudo, é evidente que o expurgo não possui origem técnica. Por
exemplo, embora as informações sobre a posição do veículo sejam relevantes para o negócio
até um determinado período, a partir de uma certa periodicidade o negócio não julga que
aquela informação necessita ser armazenada e transfere para o arquivo morto da empresa.
De todos informantes envolvidos, seis consideraram o processo de expurgo como
passível de mensuração e quatros não consideraram como parte do tamanho funcional.
Observa-se novamente uma não homogeneidade em relação a essa funcionalidade, conforme
figura 30.
74
12
Quantidade de CPFS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Efetuar Expurgo Posição Veículo
Figura 30 – Quantidade de informantes que contaram Efetuar Expurgo Posição Veículo
Fonte: Elaboração Própria
No manual de práticas de contagem não existe nenhuma definição ou interpretação a
respeito de processos de expurgo, portanto, para as funcionalidades de expurgo deve-se
utilizar todas as regras que permeiam a identificação de processos elementares.
Percebeu-se que, durante a mensuração, alguns profissionais envolvidos na pesquisa
questionaram a necessidade dessa funcionalidade, visto que o expurgo tinha origem técnica e
não deveria ser considerado como pertencente ao tamanho funcional. Observa-se portanto, em
alguns casos, associação quase imediata da palavra expurgo com "requisito técnico".
Conforme definição da ISO/IEC 14143-1:1998, existem três tipos de requisitos que,
em sua totalidade, representam o conjunto completo de requisitos do usuário. Logo, é
esperado que o processo de expurgo possa ter sido originado a partir de requisitos não
funcionais. Nesse, caso tais requisitos não devem ser encarados como parte do tamanho
funcional do software, já que segundo o artigo IFPUG (2003):
Entre outras considerações, isso significa que o método pode medir apenas
requisitos funcionais, não requisitos técnicos ou requisitos de qualidade. Isso NÃO
significa que os requisitos técnicos e de qualidade não possam ou não devam ser
medidos, apenas que eles precisam ser apresentados claramente como medidas
separadas. 7
7
Tradução Própria.
75
Por outro lado, é conveniente afirmar que o processo de expurgo descrito no cenário
não possui limitações técnicas e, portanto, representa o fluxo de negócio da empresa, visto
que no próprio documento consta que o processo respeita as regras de negócio da empresa.
Os informantes envolvidos que não consideraram o expurgo como parte do tamanho
funcional do software não justificaram o motivo ou apresentaram as premissas adotadas para
tais interpretações, o que configura um desvio com relação ao "Procedimento do Método de
Medição de Tamanho Funcional", que prevê que todas as considerações a respeito da
contagem sejam documentadas e reportadas.
Os seis informantes envolvidos na contagem que mensuraram a funcionalidade
apresentaram divergências em relação à identificação dos DERs, conforme pode-se notar
abaixo:
Tabela 21 – DERs da Função de Transação Efetuar Expurgo Posição Veículo identificado pelos informantes 1,
2, 7, 8 e 9
Inf 1
Inf 2
Inf 7
Inf 8
Inf 9
Ação
Coordenada X
Coordenada Y
Coordenadas
Data
Hora
ID Posição Veículo
Mensagem
Microssegundo
Minuto
Segundo
Timestamp
Fonte: Elaboração Própria
Dessa maneira, constata-se além de divergências na identificação dos processos
elementares, divergências na contagem dos DERs. Nota-se que, enquanto o informante 1
considerou como Dados Elementares Referenciados todos os atributos da tabela
"posiçãoVeiculo", o informante 2 considerou apenas a data e a ação como DER. Outra
divergência é que o primeiro informante considerou que todos os dados estão cruzando a
fronteira e o segundo provavelmente considerou que o expurgo será realizado como processo
batch, que será iniciado a partir de data parametrizada. Já o informante 3 considerou, além da
ação, um DER para o timestamp e para a mensagem, mesmo o cenário não explicitando
claramente se são exibidas mensagens ao final do processo. Nenhum apontamento ou
76
premissa foi apontada para esse processo. Por fim, o informante 9 considerou como DERs a
habilidade do sistema de iniciar a funcionalidade e a chave primária da tabela veículo.
A heterogeneidade nesses casos descritos, embora tenha um impacto mínimo no
tamanho funcional, demonstra a existência de possíveis vícios nas contagens realizadas, bem
como conceitos ainda não esclarecidos a respeito da contagem dos DERs de uma aplicação.
Observa-se que o informante 4 contou um DER para mensagem, embora o cenário em
nenhum momento deixe claro que é exibido mensagem. A falta de premissas dessa suposição
torna o agrupamento realizado questionável.
Ou seja, é possível concluir que, além das divergências entre os certificados a respeito
da identificação desse processo elementar, houve divergências também nos campos
considerados como DERs.
4.5.3
Incluir Dados Monitoramento Plantação
De acordo com o cenário aplicado, nota-se a seguinte funcionalidade:
Para que seja possível alimentar o sistema com os dados de temperatura e umidade
relativa do ar de determinada plantação, a Corporações Dummont investiu em
aparelhos de última geração responsáveis por realizar a leitura da temperatura
ambiente, bem como da umidade relativa do ar e enviá-las via satélite ao sistema de
monitoramento de pragas. Os receptores enviam informações de cinco em cinco
minutos para a aplicação, que armazena os dados recebidos na tabela de
“Monitoramento”. Os dados, transmitidos via satélite pela aplicação, são
respectivamente: Coordenada X, Coordenada Y, Temperatura Ambiente, Umidade
Relativa, Indicador de movimentação de ácaros ou insetos. A partir dessas
coordenadas, o sistema consegue localizar o código da plantação correspondente.
Conforme a imagem abaixo ilustra, 88% dos informantes envolvidos na contagem
consideraram a funcionalidade descrita acima como um processo elementar.
Apenas o informante 4 não considerou o processo como passível de mensuração. O
motivo para essa decisão não foi indicado pelo informante em questão e também não consta
nas premissas adotadas para a contagem.
77
12
11
10
Quantidade de CFPS
9
8
7
6
Total CFPS
5
CFPS Contaram
4
3
2
1
0
Incluir Dados Monitoramento Plantação
Figura 31 – Quantidade de informantes que contaram Incluir Dados Monitoramento Plantação
Fonte: Elaboração Própria
Nota-se, portanto, que esse processo foi considerado por praticamente todos os
certificados, conforme observa-se na figura 31, existindo poucas divergências entre os
profissionais em relação a ele.
Tabela 22 – DERs da Função de Transação Incluir Dados Monitoramento Plantação identificado pelos
informantes
Inf 1 Inf 2 Inf 3 Inf 5 Inf 6 Inf 8 Inf 9 Inf 10
Ação
Código Plantação
Coordenada X
Coordenada Y
Coordenadas
Data
Indicador de movimentação de ácaros
Indicador de movimentação de ácaros/insetos
Indicador de movimentação de insetos
Mensagem
Temperatura Ambiente
Timestamp
Umidade Relativa
Fonte: Elaboração Própria
78
Analisando os DER’s contados acima é possível perceber que todos os profissionais
consideraram os campos de umidade relativa e temperatura ambiente. Com exceção dos
informantes 1 e 9, os demais profissionais também consideraram os campos de indicador de
movimentação de ácaros e/ou insetos como distintos.
A maioria dos informantes também considerou como Tipo de Elemento de Dados os
atributos Coordenadas X e Coordenadas Y, embora o cenário deixe evidente que estes campos
não são mantidos pela EE e são utilizados apenas para determinar a qual plantação pertencem
aqueles dados.
Além disso, houve variação na contagem de campos que indicam a habilidade da
aplicação de enviar mensagens ao usuário. O atributo foi contado pelo informante 8, apesar de
não estar evidente no cenário que a aplicação apresente mensagem ao usuário final.
Sendo assim, conclui-se que há uma não homogeneidade em relação à determinação
dos DERs do processo.
4.5.4
Incluir Dados de Reparo da Plantação e Consultar Dados de Reparo da Plantação
Segundo o cenário aplicado:
Ao chegarem à plantação, e após ter eliminado as ocorrências de pragas, os técnicos
devem preencher um questionário, por meio de um dispositivo móvel, com
informações referentes à descrição do reparo que foi feito e justificando a
necessidade da medida tomada. A consulta aos dados será feita através de um
relatório impresso em papel ou nos formatos .xls ou .doc. Na consulta, serão
exibidos os mesmos dados incluídos pelos usuários.
Mediante análise das contagens realizadas, constata-se que há uma homogeneidade
entre todos
os informantes em relação a esse processo. Essa homogeneidade pode ser
comprovada a partir da leitura do gráfico abaixo, o qual aponta que todos os informantes
consideraram a funcionalidade como um processo elementar:
79
12
11
10
Quantidade de CPFS
9
8
7
6
Total CFPS
5
CFPS Contaram
4
3
2
1
0
Incluir Dados Reparos Plantação
Figura 32 – Quantidade de informantes que contaram Incluir Dados de Reparo da Plantação e Consultar
Dados de Reparo da Plantação
Fonte: Elaboração Própria
É percebida também uma pequena variação a respeito da contagem dos DERs
envolvidos. Os dados encontrados por cada informante estão discriminados abaixo.
Tabela 23 – DERs da Função de Transação Incluir Dados de Reparo da Plantação
Inf 1 Inf 2 Inf 3 Inf 4 Inf 5 Inf 6 Inf 8 Inf 9
Ação
Código da Plantação
Descrição Reparo
Funcionário que executou o reparo
Justificativa do reparo
Mensagem
Técnico responsável
Fonte: Elaboração Própria
Mediante análise dos DER’s mensurados acima, pode-se dizer que houve mínimas
divergências na contagem desse processo, inclusive na identificação dos itens de dados. O
principal fator que causou divergência na identificação dos DERs foi o campo de mensagens,
que em muitos casos foi contado, mesmo na ausência de evidências no cenário fornecido se o
sistema exibe mensagens ao final ou durante o processamento desta funcionalidade.
Para o processo de Consultar Dados Reparos de Plantação também houve consenso na
identificação dos processos elementares, conforme mostrado na figura 33.
80
12
11
10
Quantidade de CFPS
9
8
7
6
Total CFPS
5
CFPS Contaram
4
3
2
1
0
Consultar Dados Reparos Plantação
Figura 33 – Quantidade de informantes que contaram Consultar Dados Reparo de Plantação
Fonte: Elaboração Própria
A identificação dos DERs dessa funcionalidade foram os mesmos listados
anteriormente.
Deve-se ressaltar que nenhum dos informantes considerou como processos
elementares distintos as consultas geradas em .xls, e .doc. Conforme o IFPUG (2010):
O IFPUG reconhece ambas as abordagens: única e múltipla mídia para a aplicação
das regras, definidas pelo manual de práticas de contagem. O IFPUG não dá
preferência a uma das abordagens em detrimento da outra. Na maioria dos casos, as
duas abordagens podem ser aplicadas se os resultados da contagem de pontos de
função forem utilizados no contexto da abordagem adotada. A determinação a
respeito de qual delas será utilizada para contar únicas ou múltiplas mídias em um
projeto ou aplicação deve ser acompanhada por um analista de pontos de função,
uma vez que se trata se uma situação específica, uma organização particular,
histórico de práticas anteriores e objetivos.
Havendo duas possibilidades a serem adotadas na contagem, o IFPUG(2010) recomenda:
Nós providenciamos descrições para ambas abordagens nesses exemplos; entretanto,
uma vez que você tenha adotado a abordagem mais apropriada para a sua análise,
essa escolha deverá ser consistente a fim de satisfazer seus objetivos e metas. Por
exemplo, NÃO faça a contagem utilizando “única instância” para requisitos e depois
mude para “múltiplas mídias” nas implementações. Estimativas futuras devem ser
baseadas segundo taxas atuais de produtividade, obtidas em consonância com a
deformação de escopo calculada a partir da análise dos requisites funcionais. O
resultado final mostra que uma análise comparativa precisa ser coerente a fim de
gerar uma análise sólida a partir de dados consistentes, rastreáveis e passíveis de
auditoria.
81
Dessa maneira, considera-se que os profissionais seguiram apenas uma vertente de
posicionamento a respeito de múltiplas mídias e aplicaram a mesma abordagem em todos
os processos.
4.5.5
Enviar Alerta de Criticidade
Conforme consta no cenário:
Os técnicos deverão se locomover para o local, respondendo ao chamado do sistema,
que encaminhará via SMS os dados dos clientes que necessitam de auxílio
especializado. O sistema enviará via SMS, os seguintes campos: "Nome Cliente,
Bairro, Município, Coordenadas Plantação e Logradouro Plantação.
Os informantes apresentaram comportamento homogêneo na contagem desta
funcionalidade, visto que oito dos dez envolvidos consideraram a funcionalidade como
processo elementar, conforme consta na figura 34.
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Enviar Alerta Criticidade Técnico
Figura 34 – Quantidade de informantes que contaram Enviar Alerta de Criticidade
Fonte: Elaboração Própria
Apresentou-se também, para esta funcionalidade divergência na classificação do tipo
de função de transação. Enquanto cinco consideraram a funcionalidade como CE, três como
SE.
82
Considerando que para o envio do SMS aos técnicos é necessário que o sistema
identifique qual o responsável técnico que receberá a convocação para efetuar possíveis
reparos na plantação, conforme nota-se abaixo:
Dessa maneira, o sistema irá monitorar a criticidade das plantações em tempo real e,
dependendo do nível indicado pelo sistema em relação à proliferação de pragas nas
plantações, deverá ser capaz de identificar os responsáveis técnicos que se
encontram mais próximos daquela região, baseados no seu posicionamento atual, e
os acionar imediatamente para que os mesmos se dirijam ao local.
Verificando que não há atributos no banco de dados que indique a proximidade de
determinado técnico com a plantação, o sistema necessitará efetuar cálculos para que seja
possível determinar a distância dos diversos técnicos, em relação a determinada plantação.
Verifica-se que o sistema só poderá enviar a mensagem no momento em que definir para qual
técnico a mesma será direcionada, concluindo-se, portanto que a determinação do técnico
responsável por efetuar o reparo na plantação caracteriza Lógica de Processamento da
funcionalidade de envio de SMS.
Dessa maneira, conclui-se que a consideração da funcionalidade como CE é
inadequada, visto que é necessário a execução de cálculos para determinação da distância dos
técnicos em relação a determinada plantação.
Ressalta-se ainda que nenhum dos informantes que considerou a funcionalidade como
CE, documentou possíveis premissas para classificação do processo elementar, tornando a
contagem inconsistente, já que diverge dos procedimentos de contagem.
Os outros dois informantes que desconsideraram a funcionalidade da contagem
realizada não documentaram o motivo de terem adotado tal comportamento na contagem.
Observa-se que os oito informantes que consideraram a funcionalidade como Processo
Elementar, efetuaram a seguinte contagem dos DERs:
Tabela 24 – DERs da Função de Transação Enviar Alerta Criticidade identificados pelos informantes
Inf
1
Ação
Bairro
Código Criticidade
Código Funcionário
Código Plantação
Coordenada X
Coordenada Y
Coordenadas Plantação
Inf
3
Inf
5
Inf
6
Inf
7
Inf
8
Inf
9
Inf 10
83
Logradouro Plantação
Mensagem
Município
Nome Cliente
Placa do veículo
SMS
Fonte: Elaboração Própria
Mediante análise do quadro acima, nota-se que uma das principais divergências na
contagem dos DERs por parte dos informantes, se deu em razão do campo de coordenada, que
alguns consideraram como um único elemento de dados referenciado, enquanto os outros
informantes consideraram como dois. Considera-se inadequada a contagem dos DERs de
coordenada x e coordenada y como dois elementos de dados referenciados, visto que em
nenhum momento eles são utilizados de maneira independente pela aplicação sendo contada,
conforme cita o manual de práticas de contagem:
Se o atributo é sempre usado por inteiro, então ele é contado como um único
elemento de dados (DER). Não devem existir situações em que um componente
individual de um atributo é usado sem os outros. Baseado neste uso, o atributo é
contado como um único elemento de dado.
Além disso, os informantes consideraram como DERs a habilidade do sistema em
exibir mensagens para o usuário de qualquer maneira, o que não é evidenciado pelo cenário e,
caso fosse considerado deveria constar nas premissas adotadas para a contagem. Apenas o
informante 6 colocou observações neste sentido: Foi considerado um DER de mensagem.
Porém, não é descrito que as funcionalidades possuem ou não.
As divergências dos DERs apontadas não influenciaram a complexidade das funções
de transação, embora tornem as possíveis contagens inconsistentes.
4.5.6
Consultar Mapa
Conforme consta no cenário, o sistema exibe plotados no mapa:
O sistema tem como tela principal um mapa de todo território brasileiro, mostrando
as áreas que contêm plantações delimitadas por linhas tracejadas. Toda a área que
contém plantações possui um nível de criticidade.
Observa-se também que:
84
Além disso, o sistema também irá exibir, em tempo real e plotados no mapa, ícones
com a exata posição dos veículos que serão os responsáveis em se dirigir às
plantações que estejam com nível de criticidade "Laranja" ou "Vermelha".
Dentre os dez profissionais envolvidos na contagem, metade mensurou a
funcionalidade como um Processo Elementar, conforme elucidado na figura 35.
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Consultar Mapa
Figura 35 – Quantidade de informantes que contaram Consultar Mapa
Fonte: Elaboração Própria
Dentre os cinco profissionais que consideraram essa funcionalidade como passível de
mensuração, apresentou-se também divergência na determinação do tipo de função de
transação, visto que dois consideram o processo elementar como SE e três como CE.
Nenhum dos profissionais envolvidos documentou do motivo da classificação do
Processo Elementar, não sendo possível determinar o motivo de tal comportamento na
contagem.
Apresentou-se também variação na contagem dos DERs conforme evidenciado no
quadro abaixo:
Tabela 25 – DERs da Função de Transação Consultar Mapa pelos informantes
Inf
3
Ação
Área de plantio
Bairro
Checkbox Criticidade
Inf
6
Inf
8
Inf
9
Inf
10
85
Checkbox Veículo
Cidade
Coordenada X
Coordenada Y
Criticidade Plantação
Logradouro
Mensagem
Placa
Plantação
Posição Veículo
Veículo
Fonte: Elaboração Própria
Observa-se acima divergência principalmente em relação ao campo de Coordenada X
e Coordenada Y, que já foi analisado no tópico acima.
Nota-se que o informante 9 considerou uma quantidade maior de DERs se comparadas
a todos os outros informantes que mensuraram o processo. Tal fato ocorreu por que o mesmo
identificou como parte do processo ementar de "Consultar Mapa", lógicas adicionais não
consideradas como parte do processo elementar pelos outros informantes.
4.5.7
Incluir Posição Veículo
De acordo com o exposto no cenário, consta:
Por meio de um aparelho instalado nos carros, será feita uma comunicação via
satélite com o sistema, que atualizará a cada cinco segundos a tela do sistema com as
exata localização dos veículos. Os dados com as posições em tempo real dos
veículos serão armazenados na tabela "posiçãoVeículo".
Dentre os dez profissionais envolvidos na contagem, seis consideraram o processo
passível de mensuração, conforme nota-se na figura 36.
86
12
Quantidade de CFPS
10
8
Total CFPS
6
CFPS Contaram
4
2
0
Incluir Posição Veículo
Figura 36 – Quantidade de informantes que contaram Incluir Posição Veículo
Fonte: Elaboração Própria
Não houve divergências a respeito da classificação do tipo de função de transação,
entre os informantes que mensuraram a funcionalidade, já que todos mensuraram a
funcionalidade como EE.
Nota-se apenas divergência entre os DERs identificados pelos informantes, que pode
ser observada na tabela 26.
Tabela 26 – DERs da Função de Transação Incluir Posição Veículo identificados pelos informantes
Inf 4
Inf 5 Inf 6 Inf 8
Ação
Coordenada X
Coordenada Y
Coordenadas
Data
Hora
Id posição Veiculo
Mensagem
Microssegundo
Minuto
Placa Veículo
Segundo
Veículo
Fonte: Elaboração Própria
Inf 9
87
Observa-se que os informantes adotaram um comportamento homogêneo na contagem
dos DERs ocorrendo pequenas variações que não influenciaram na complexidade da
funcionalidade.
4.5.8
Assinalar Clientes sem Ocorrência de Praga
Pode-se no observar no cenário, a possibilidade do sistema verificar quais são os
clientes que não tiveram nenhuma ocorrência de praga no ano. O processo é realizado de
maneira batch, ou seja, não há evidência de dados atravessando a fronteira da aplicação, nem
tampouco evidências de mensagens exibidas ao usuário. O trecho contendo a descrição desta
funcionalidade pode ser observado abaixo:
Para isso, o sistema também é capaz de determinar, por meio de um processo batch
executado no último dia do ano, todos os clientes que não tiveram criticidade da cor
Laranja, ou Vermelha. O processo Batch deverá percorrer a tabela
"Plantação_has_Criticidade" no sistema e verificar se existem criticidades
"Vermelhas" ou "Laranjas" para determinado cliente no ano corrente. Para os
clientes que não apresentaram problemas em suas plantações, o sistema armazenará
o ID desses clientes na tabela "Beneficiados". Dessa maneira, no primeiro dia do ano
o Sistema de Pagamentos e Cobranças lerá os dados dessa tabela para gerar os
boletos do mês de janeiro, abatendo as despesas.
Dentre os 10 informantes, apenas um considerou o processo passível de contagem. Os
demais consideraram que o processo batch por si só não era passível de ser classificado como
um processo elementar independente. O informante considerou os seguintes DERs na
contagem realizada "Código da Plantação, Criticidade, Data, Código do Cliente, Desconto,
Ação e Mensagem". Embora tais dados possam ser utilizados internamente durante a
execução da funcionalidade, a contagem deles como DERs, é imprecisas, já que os mesmos
não cruzam a fronteira da aplicação. O processo apenas grava os dados em uma tabela, que
posteriormente, pode ser consultada via emissão de um relatório.
O informante 3, por sua vez considerou o processo de Assinalar Clientes sem
Ocorrência de Praga, como lógica de processamento da geração do boleto. Tal classificação
também é equivocada, visto que a geração do boleto é realizada por outro sistema, o de
pagamentos. Dessa maneira, sendo responsabilidade de outra fronteira executar a geração do
boleto, o tamanho funcional desta funcionalidade deveria compor o tamanho funcional total
da outra fronteira, e não da fronteira de Monitoramento de Pragas.
Os demais participantes não consideraram a funcionalidade como processo elementar
independente, conforme observa-se na figura 37.
88
12
Quantide de CFPS
10
8
CFPS Contaram
6
Total CFPS
4
2
0
Assinalar Clientes sem Ocorrência de Praga
Figura 37 – Quantidade de informantes que contaram Incluir Posição Veículo
Fonte: Elaboração Própria
4.6
CONCLUSÃO
A análise apresentada mostrou as divergências nas contagens realizadas pelos
informantes. Notou-se que os profissionais não seguiram todos os passos previstos pelo
procedimento do método de medição de tamanho funcional, já que a maioria dos informantes
não documentaram as premissas adotadas para a contagem, impossibilitando uma análise mais
aprofundada.
Além disso, identificou-se discordância a respeito de itens como processos sem dados
cruzando a fronteira conforme a análise realizada no item 4.5.8 Assinalar Clientes sem
Ocorrência de Praga, bem como processos de expurgo conforme demonstra a análise realizada
no item 4.5.2 Efetuar Expurgo Posição veículo.
Também observou-se variações no
agrupamento lógico das funções de dados e transação, bem como na contagem de DERs,
RLRs e ALRs.
Observa-se, portanto que o estudo não obteve resultados homogêneos entre os
informantes envolvidos já que em cinco ocasiões excedeu-se uma diferença superior a 10%,
conforme comprova o item 4.2 Comparação entre as contagens entregues pelos informantes.
A análise evidenciou que há percepções distintas entre os informantes, levando a diferentes
resultados. Portanto, a partir dos itens expostos confirmou-se a hipótese apresentada por este
89
trabalho de que há divergências nas contagens realizadas por profissionais certificados na
técnica de análise de pontos de função.
Destaca-se também que a qualidade de uma contagem de pontos de função pode ser
afetada devido a baixa qualidade nos insumos disponibilizados para a contagem, levando o
profissional a uma contagem menos assertiva. O estudo desta maneira, também pode
evidenciar tal fato, conforme contatou-se nos item 4.4.5 Arquivo Lógico de Faixa de
Criticidade e no item 4.4.7 Arquivo Lógico de Monitoramento, onde notou-se a ausência de
determinadas informações consideradas relevantes para a contagem.
Por fim, verificou-se que há possibilidades de interpretações distintas das regras
contidas no manual conforme comprovado em grande parte das funcionalidades analisadas,
onde notou-se inúmeras discordâncias entre os respondentes.
2.1.1
Limitações da Pesquisa
Embora tenha se constado divergências entre as contagens realizadas pelos
informantes, ressalta-se que o presente trabalho não é conclusivo à respeito da confiabilidade
da técnica de Análise de Pontos de Função, não devendo ser encarado como parâmetro para se
descartar a aplicação da técnica, já que conforme indica os estudos correlatos apontados a
técnica apresenta divergências que não são significativas quando analisadas com um conjunto
maior de dados, demonstrando-se portanto uma técnica robusta e confiável.
A análise foi realizada com 10 respondentes, número absoluto considerado pequeno
para pareceres conclusivos a respeito da confiabilidade da técnica. A quantidade de
respondentes portanto foi um fator limitante da pesquisa realizada.
A dificuldade em reproduzir o dia-a-dia dos profissionais durante a realização da
contagem pode ser citada como outro fator limitante da pesquisa. Desde o primeiro momento,
buscou-se evitar com que os profissionais ficassem receosos em realizar a contagem, ou se
precavessem realizando atividades não repetidas durante contagens rotineiras no ambiente
corporativo.
2.1.2
Estudos Futuros
Propõe-se para futuros estudos, a possibilidade de expansão do número de
respondentes como maneira de se obter um espaço amostral maior, e poder se chegar a
90
conclusões ou constatações com maior precisão, possibilitando ainda identificação de padrões
nas contagens em
grupos com determinadas características. Como maneira de
complementação do assunto abordado, também é sugerido a investigação mais aprofundada a
respeito das causas que originam a divergência entre os certificados durante a aplicação da
técnica.
91
REFERÊNCIAS BIBLIOGRÁFICAS
BALARINE, O. F. O. Gestão da informação: tecnologia da informação como vantagem
competitiva. Revista de Administração de Empresas – eletrônica, v.1, n.1, jan/jun. São
Paulo,
2002.
Disponível
em:
<http://www.rae.com.br/eletronica/index.cfm?FuseAction=Artigo&ID=1059&Secao=INFOR
MAÇÃO&Volume=1&Numero=1&Ano=2002>. Último acesso em: 03 fev 2012.
COLTRO, A. A gestão da qualidade total e suas influências na competitividade empresarial.
Caderno de pesquisas em administração. Vol.1, nº2. São Paulo: jan-jun/1996.
DREGUER, J. B. Function Points Analysis. Prentice Hall, Englewood Cliffs, NJ. 1989.
GONÇALVES, L. H. V. B. VII ENUPF – Encontro Nacional de Usuários de Pontos de
Função, 1995.
GUARIZZO, K. Métricas de Software. Monografia (Bacharelado em ciência da computação).
Curso de Ciência de computação da Faculdade de Jaguariúna. Jaguariúna, 2008. Disponível
em: <bibdig.poliseducacional.com.br/document/?view=184>. Último acesso em: 12 mai
2012.
IFPUG. Manual de Práticas de Contagem de Pontos de Função. V.4.3.1. Trad. SILVEIRA,
M. et. all. São Paulo: IFPUG – International Function Point Users Group. 2010.
92
JONES, C. Selecting a FP counting method, software productivity research, Inc. mimeo,
1989.
KAMPSTRA, P.; VERHOEF, C. Reliability of Function Point Counts. Amsterdam:
Department of Computer Science, 2005.
KEMERER, F. C. Reliability of Function Points Measurement: A field experiment.
Massachusetss: Institut of Technoloy, 1990.
MEIRA, S. L. Um mundo feito (quase completamente) de software. Ciência e Cultura,
Vol.55 nº2 São
Paulo, jun. 2003.
Disponível
em:
<http://cienciaecultura.bvs.br/scielo.php?pid=S000967252003000200020&script=sci_arttext>. Último acesso em: 22 fev 2012.
MELI, R. Functional Metrics: Problems and Possible Solutions. FESMA, Antuérpia, 1998.
MÉTRICA. In: IEEE Standard Glossary of Computer Languages. 1993. Disponível em: <
http://standards.ieee.org/findstds/standard/610.13-1993.html>. Último acesso em: 27 mai
2012.
__________. In: Weiszflog, W (org.). Moderno Dicionário da Língua Portuguesa. São Paulo:
Editora Melhoramentos Ltda., 2007, p.
MORRIS, P. M; DESHARNAIS, J. M. Function Point Analysis: validating the result. 2001
93
PERRY, W. E., The best measures for measuring data processing quality and productivity.
Quality assurance institute technical report. 1986.
PRADO, A. A. et al. Tecnologia da informação aplicada de forma estratégica nos processos
organizacionais, por meio dos sistemas de informações gerenciais. janus, lorena, Vol.4, nº 5,
jan./jun., 2007.
PRESSMAN, R. S. Software Engineering a Practitioners Approach. 5. ed. New York: Mac
Graw Hill, 2001.
______________. Engenharia de Software. 6.ed. São Paulo: Makron Books, 2006.
RUDOLPH, E. E. Productivity in computer application development, University of Auckland,
Dept. of Management Studies. Auckland: 1983.
VASCONCELOS, A. Introdução a Métricas de Software. 2005. Apresentação em Power
Point.
Disponível
em
<www.cin.ufpe.br/~if720/slides/introducao-a-metricas-de-
software.ppt>. Último acesso em: 27 mai 2012.
VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de Pontos de Função –
Medição, Estimativas e Gerenciamento de Projetos de Software. 3. ed. São Paulo: Editora
Erica, 2005.
94
SILVA, M. A. IAVEMS: Infraestrutura de Apoio à Visualização da Evolução de Métricas de
Software. 2010. 98 p. Trabalho de Conclusão de Curso (Bacharelado em Ciência da
Computação). Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2010.
SALVADOR, E. Implementando um método de estimativa no DotProject. Monografia
(Bacharelado em ciência da computação). Curso de Ciência de computação da Universidade
Federal de Pernambuco, 2005. Disponível em: <www.-cin.-ufpe.-br/-~tg/-2005--1/-evfs-proposta.-pdf>. Último acesso em: 16 mai 2012.
SYMONS, C. R. Function Point Analysis: Difficulties and Improvements. In: IEEE
Transactions on Software Engineering, vol. 14, n. 1, 1988.
95
APÊNDICE A - Cenário aplicado aos informantes da pesquisa
1.
Em qual versão do CPM você é certificado?
a.
CPM 4.3
b.
CPM 4.2
c.
CPM 4.1
d.
Anteriores
2. Há quantos anos você trabalha com medições em Análise de Pontos por Função?
a.
1 - 2 anos
b.
2 - 5 anos
c.
5 - 10 anos
d.
Acima de 10 anos
3.
Você possui formação acadêmica na área de informática?
a.
Sim
b.
Não
c.
Apenas formação técnica (curso técnico)
4. Indique quantos anos de experiência você possui na área de informática:
___ anos.
5.
Qual das afirmações abaixo se aproxima mais da sua opinião?
a.
Considero que a Análise de Pontos por Função não se adeque ao
cenário atual da Engenharia de Software e, portanto, está fadada ao
fracasso.
b.
Considero que a Análise de Pontos por Função não se adeque ao
cenário atual da Engenharia de Software. Porém, acredito que a sua
utilização poderá tornar o mercado mais maduro e adepto ao uso de
novas metrificações.
c.
Acredito que a Análise de Pontos por Função se encaixa perfeitamente
no cenário atual da Engenharia de Software.
d.
Nenhuma das Anteriores.
6. A respeito da metrificação de Processos internos sem dados cruzando a fronteira
da aplicação, porém reconhecidos pelo usuário:
a.
Considero que devam ser metrificados todos os processos internos
reconhecidos pelo usuário, independente de ter dados cruzando a
fronteira da aplicação.
b.
Considero que, por não existirem dados atravessando a fronteira da
aplicação, o processo não deve ser mensurado.
7. De acordo com o IFPUG, a respeito de múltiplas mídias, deve-se:
a.
Metrificar como processos elementares distintos as funcionalidades que
geram arquivos com extensões diferentes
b.
Metrificar como um único processo elementar, independentes da mídia
em que é disponibilizado.
c.
Metrificar como processos elementares únicos, ou como processos
elementares distintos dependendo do entendimento do analista.
96
d.
e.
Nenhuma das anteriores.
BeC
Cenário Geral
Empresa solicitante da Contagem de Pontos por Função: Corporações
Dummont.
Propósito da Contagem: Determinar o tamanho da aplicação instalada.
Fronteiras Envolvidas: Fronteira Monitoramento Pragas (Nova), Fronteira
Recursos Humanos (Dados Funcionários e Função) e Fronteira Marketing (Dados
Clientes).
Foco
Negocial
da
Empresa:
A
empresa
Corporações
Dummont
corresponde a uma parcela do mercado responsável por eliminar as ocorrências de
Pragas que infestam as plantações.
Propósito da Implantação do Sistema: A empresa Dummont conta,
atualmente, com aproximadamente mil clientes no território brasileiro e irá desenvolver
um sistema que tem como principal objetivo reduzir custos e aumentar a eficácia do
monitoramento de pragas.
Funcionamento do Sistema: O sistema tem como tela principal um mapa de
todo território brasileiro, mostrando as áreas que contêm plantações delimitadas por linhas
tracejadas. Toda a área que contém plantações possui um nível de criticidade, que é definida
por:
• Verde - Indica que a área do plantio possui temperatura e umidade adequada à
não-proliferação de pragas e não foi detectado nenhum movimento de insetos e
ácaros.
• Laranja - Indica que a área do plantio possui temperatura e umidades
adequadas à proliferação de pragas e ainda não foi detectado nenhum movimento
de insetos e ácaros.
• Vermelho - Indica que a área do plantio possui temperatura e umidades
adequadas à proliferação de pragas e foi detectado movimento de insetos e ácaros.
Para que seja possível alimentar o sistema com os dados de temperatura e umidade
relativa do ar de determinada plantação, a Corporações Dummont investiu em aparelhos de
última geração responsáveis por realizar a leitura da temperatura ambiente, bem como da
umidade relativa do ar e enviá-las via satélite ao sistema de monitoramento de pragas. Os
97
receptores enviam informações de cinco em cinco minutos para a aplicação, que armazena os
dados recebidos na tabela de "Monitoramento". Os dados, transmitidos via satélite pela
aplicação, são respectivamente: Coordenada X, Coordenada Y, Temperatura Ambiente,
Umidade Relativa, Indicador de movimentação de ácaros ou insetos. A partir dessas
coordenadas, o sistema consegue localizar o código da plantação correspondente.
Antes da implantação deste sistema, os próprios responsáveis pelo local coletavam os
dados diariamente (informações de temperatura e umidade, bem como a presença de insetos
e/ou ácaros). Dessa maneira, as informações eram todas armazenadas em um arquivo Excel.
Com a implantação desse sistema, elas deverão migrar para a tabela "Monitoramento", onde
constarão os seguintes dados: "Temperatura, Umidade Relativa, Indicador Ácaros, Indicador
de Insetos e Data".
A criticidade de cada plantação é determinada de maneira automática pelo sistema. Ao
ser inicializado, o sistema ativa os receptores da plantação e aguarda que todos eles enviem os
dados referentes a ela. Após o envio dos dados, o sistema determina a criticidade da área
naquele exato momento. Cada vez que os receptores enviam novos dados, a criticidade é
recalculada por meio da combinação da temperatura, umidade e o indicador de presença de
ácaros ou insetos. Após o cálculo, o sistema identifica se o resultado gerado está dentro da
faixa de valores da cor Verde, Azul ou Amarelo. Para isso ele deve ler os dados da tabela
"faixaCriticidade" após ter realizado os cálculos necessários, e gravar na tabela
“Plantacao_has_Criticidade” a criticidade para determinada plantação.
Além disso, o sistema também irá exibir, em tempo real e plotados no mapa, ícones
com a exata posição dos veículos que serão os responsáveis em se dirigir às plantações que
estejam com nível de criticidade "Laranja" ou "Vermelha. Por meio de um aparelho instalado
nos carros, será feita uma comunicação via satélite com o sistema, que atualizará a cada cinco
segundos a tela do sistema com as exata localização dos veículos. Os dados com as posições
em tempo real dos veículos serão armazenados na tabela "posiçãoVeículo".
Dessa maneira, o sistema irá monitorar a criticidade das plantações em tempo real e,
dependendo do nível indicado pelo sistema em relação à proliferação de pragas nas
plantações, deverá ser capaz de identificar os responsáveis técnicos que se encontram mais
próximos daquela região, baseados no seu posicionamento atual, e os acionar imediatamente
para que os mesmos se dirijam ao local.
Os técnicos deverão se locomover para o local, respondendo ao chamado do sistema,
que encaminhará via SMS os dados dos clientes que necessitam de auxílio especializado. O
98
sistema enviará via SMS, os seguintes campos: "Nome Cliente, Bairro, Município,
Coordenadas Plantação e Logradouro Plantação".
Ao chegarem à plantação, e após ter eliminados as ocorrências de pragas, os técnicos
devem preencher um questionário, por meio de um dispositivo móvel, com informações
referentes à descrição do reparo que foi feito e justificando a necessidade da medida tomada.
Os dados são armazenados na tabela "reparosPlantacao". Esses dados não poderão ser
alterados ou excluídos. A consulta aos dados será feita através de um relatório impresso em
papel ou nos formatos .xls ou .doc. Na consulta, serão exibidos os mesmos dados incluídos
pelos usuários.
Os usuários do sistema poderão visualizar os dados de determinada área de plantio ao clicar
na área delimitada por linhas tracejadas que indicam que, naquele local, há plantações. Ao
clicar na área do plantio plotada pelo sistema na tela, será exibido um pop-up com as
seguintes informações: "Temperatura, Umidade Relativa do Ar, Nome do Responsável
Técnico pelo local, Nome do dono legal da área de plantio, Número do celular do dono legal
da área de plantio, Quantidade de Trabalhadores na área de plantio, Produto cultivado”. As
tabelas “Monitoramento”, “Funcionário”, “Clientes” e “tipoProduto” são lidas para exibição
destes dados.
Caso o usuário clique sobre o ícone de algum carro plotado no mapa, serão exibidos os
seguintes dados: Ano Compra, Placa, Nome Motorista e Foto Motorista. Se o usuário clicar
na foto do motorista, serão exibidos os seguintes dados: Nome Motorista, Nome do Meio do
Motorista, Sobrenome do Motorista, Foto Motorista, Data Contratação e Vencimento Carta
Motorista. Caso as "check-box”, contidas na parte superior da tela, sejam desabilitadas, o
sistema irá ocultar os ícones de criticidade e/ou dos carros se locomovendo.
Além disso, a empresa pretende fomentar uma ação governamental que estimule
cuidado e reparos com a plantação, antes mesmo de ela apresentar problemas considerados
críticos.
Dessa maneira, a fim de fidelizar seus clientes, a empresa pretende conceder-lhes
descontos e benefícios quando não necessitarem do auxílio dos responsáveis técnicos para se
livrar de pragas. Caso o agricultor não possua nenhuma ocorrência de pragas em sua
plantação, será devolvido a ele 50% do valor anual pago à empresa.
Para isso, o sistema também é capaz de determinar, por meio de um processo batch
executado no último dia do ano, todos os clientes que não tiveram criticidade da cor Laranja,
ou Vermelha. O processo Batch deverá percorrer a tabela "Plantação_has_Criticidade" no
sistema e verificar se existem criticidades "Vermelhas" ou "Laranjas" para determinado
99
cliente no ano corrente. Para os clientes que não apresentaram problemas em suas plantações,
o sistema armazenará o ID desses clientes na tabela "Beneficiados". Dessa maneira, no
primeiro dia do ano o Sistema de Pagamentos e Cobranças lerá os dados dessa tabela para
gerar os boletos do mês de janeiro, abatendo as despesas.
O sistema também permite que seja extraído um relatório com a relação de todos os
clientes que obtiveram descontos. No relatório, são exibidos os seguintes dados: "Nome do
Cliente, Valor Descontos". Os dados são recuperados da tabela "Beneficiários". Caso o
usuário solicite, também poderá visualizar os mesmos relatórios no formato .xls, .doc ou em
uma impressão do relatório exibida na tela.
As tabelas de Clientes, Função e Funcionário não são mantidas dentro dessa fronteira.
Elas provem de outros sistemas, nos quais elas são ALIs, conforme detalhado no tópico
fronteiras envolvidas. As tabelas de “FaixaCriticidade” e “Plantação” serão mantidas via
script que será executado diretamente no banco de dados.
Por fim, será desenvolvida uma nova funcionalidade, responsável por realizar o
expurgo da tabela de "posicaoVeiculo". O expurgo não será feito por limitações técnicas. O
expurgo irá ocorrer devido conforme as Regras de Negócio da Empresa, que arquivava após
cinco meses todas estas informações referentes a localização dos veículos (Arquivo Morto).
A funcionalidade pode ser executada de maneira automática ou de maneira manual.
100
APÊNDICE B - Modelo Físico do Cenário disponibilizado aos informantes
101
APÊNDICE C - Lista de Siglas e Abreviaturas
AIE ─ Arquivos de Interface Externa
ALI ─ Arquivo Lógico Interno
ALR ─ Arquivo Lógico Referenciado
CE ─ Consultas Externas
CFB ─ Componente Funcional Básico
CFPS – Certified Function Point Specialist
CPM ─ Manual de Práticas de Contagem de Pontos de Função
DER(DET) ─ Dado Elementar Referenciado
EE ─ Entrada Externa
FPA ─ Function Point Analysis
IFPUG ─ International Function Points Users Group
ISO ─ International Standardization Organization
LOC ─ Linhas de Código
PF ─ Pontos de Função
RLR(RET) ─ Registro Lógico Referenciado
SE ─ Saídas Externas
102
APÊNDICE D – Figura 10 - Ampliada