Engenharia de Software: Métricas de Softwares

O que é a Análise e Ponto de Função?

A Análise de Ponto de Função (APF) é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seu usuário. Ponto de Função é a unidade de medida desta técnica que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software. Ou seja, a AFP busca medir o que o software faz, e não como ele foi construído.

O processo de medição, ou a imagem de pontos de função, baseia-se em uma avaliação padronizada dos requisitos lógicos do usuário.

Empiricamente as principais técnicas de estimativas de projetos de desenvolvimento de software assumem que o trabalho de um software é um vetor importante para a determinação do esforço para sua construção. Logo, saber o seu tamanho é um dos primeiros passos do processo de estimativa de esforço, prazo e custo.

É importante destacar que pontos de função não medem diretamente esforço, produtividade ou custo. É exclusivamente uma medida de tamanho funcional do software. Este tamanho em conjunto com outras variáveis é que pode ser usado para derivar produtivamente, estimar esforço e custo.

APF - Análise de Ponto de Função

Conceito básico: é a visão do usuário, baseada nos requisitos funcionais do sistema.

Base para análise:

Análise de Requisitos
Estimativa

Contagem:

Para estabelecermos a contagem de Ponto de Função é fundamental estabelecermos a fronteira entre o sistema que está sendo medido e o mundo exterior. (usuário, outros sistemas...).
Especificar a fronteira baseado na perspectiva de negócio (onde acaba um sistema e onde começa o outro)

Processo da Contagem APF

Definir o propósito da contagem para nortear todo o processo.
Reunir toda documentação disponível.
Determinar o Escopo e a Fronteira da Contagem, identificando os requisitos funcionais do usuário.

Passo a passo da contagem

Identificar o propósito da contagem.
Identificar o tipo de contagem com base no objetivo. (projeto de desenvolvimento, projeto de melhoria ou aplicação pronta).
Determinar o escopo da contagem, com base no objetivo e tipo de contagem.
Determinar a fronteira de cada aplicação contida no escopo da contagem com base na visão do usuário não levando em consideração a técnica.
Medir função de dados (ALI e AIE).
Medir funções de Transações (EE, SE, CE).
Calcular o tamanho funcional.
Documentar e Reportar.

Glossário

ALI - Arquivo Lógico Interno
AIE - Arquivo de Interface Externa
EE - Entrada Externa
SE - Saída Externa
CE - Consulta Externa

Os Requisitos e a Contagem de Ponto de Função

Na análise de ponto de função, os requisitos funcionais são a base para o cálculo dos pontos de função e o tamanho funcional de cada software pode ser expresso em ponto de função. Requisitos funcionais são definidos no CPM como um subconjunto dos requisitos do usuário, como requisitos que descrevem o que o software fará, em termos de tarefas e serviços. Eles incluem, mas não estão limitados a:

Transferência de dados.
Transformação de dados.
Armazenamento de dados.
Recuperação de dados.

A precisão alcançada com a contagem depende da qualidade e maturidade dos requisitos identificados.

Níveis de maturidade:

Proposta de projeto
Especificação de necessidade de negócio
Documento de visão
Modelo de entidade e relacionamento
Diagrama de fluxo de dados
Diagrama de casos de uso
Especificação de caso de uso
Protótipo de interface e etc.

Fases do ciclo de vida do software em que é possível realizar uma medição ou estimativa do tamanho do projeto em Ponto de Função.

Fase em um ciclo de vida	Tamanho pode ser aproximado/estimado	Tamanho pode ser medido
Proposta: Usuário expressa necessidade e intenção	Sim	Não
Requisitos: Analista de Requisitos e usuários reveem e acordam quanto à expressão das necessidades e intenção do usuário.	Sim	Sim
Projeto: Desenvolvedores podem incluir elementos para implementação que não são utilizados pela análise de pontos de função.	Sim	Sim
Construção	Sim	Sim
Implantação	Sim	Sim
Manutenção	Sim	Sim

Determinando o Tipo de Contagem

Para usarmos Análise de Ponto de função precisamos definir o escopo, ou seja, o tipo da contagem. No segundo post da série fiz uma breve introdução e agora avançaremos fundamentando alguns conceitos fundamentais para uma contagem bem sucedia.

Algumas definições antes de avançarmos:

ALI - Arquivo Lógico Interno: grupo logicamente relacionado de dados ou informações de controle, identificável pelo usuário, mantido dentro da fronteira da aplicação que está sendo controlada. Por exemplo: as tabelas ou classes do sistema.

AIE - Arquivo de Interface Externa: grupo logicamente relacionado de dados ou informações de controle, referenciado pela aplicação, identificável pelo usuário, mantido fora da fronteira da aplicação que está sendo controlada. Por exemplo: as tabelas acessadas noutro sistema.

TED - Tipos de Elementos de Dados: campo único, reconhecido pelo usuário, não recursivo. Por exemplo: campos das tabelas.

TER - Tipos de Elementos de Registros: subgrupo de dados, reconhecido pelo usuário. Por exemplo: generalização/especialização de classes.

EE - Entrada Externa: processo elementar da aplicação que processa dados ou informações de controle que vêm de fora da fronteira da aplicação que está sendo controlada. Exemplos: validações, fórmulas e cálculos matemáticos cujos parâmetros vêm de fora da fronteira da aplicação.

SE - Saída Externa: processo elementar da aplicação que gera dados ou informações de controle que são enviados para fora da fronteira da aplicação que está sendo controlada. Exemplos: relatórios e gráficos.

CE - Consulta Externa: processo elementar da aplicação que representa uma combinação de entrada (solicitação de informação) e saída (recuperação de informação). Exemplos: consultas implícitas, verificação de senhas e recuperação de dados com base em parâmetros.

Processo de Contagem

Vimos antes que o processo de contagem dos pontos de função pode ser dividido em sete etapas:

Determinar tipo de contagem;
Identificar a fronteira da aplicação;
Contar as funções tipo dados;
Contar as funções tipo transação;
Calcular pontos de função não ajustados (com base nos resultados obtidos em (3) e (4));
Calcular o valor do fator de ajuste;
Calcular os pontos de função ajustados (com base nos resultados obtidos em (5) e (6)).

1. Determinar o Tipo de Contagem

Projeto de Desenvolvimento: mede a funcionalidade fornecida aos usuários finais do software para a primeira instalação da aplicação. Inclui as funcionalidades da contagem inicial da aplicação e as funcionalidades requeridas para conversão de dados.

Projeto de Manutenção: mede as modificações realizadas para aplicações existentes. Inclui as funcionalidades fornecidas aos usuários através de adição, modificação ou exclusão de funções na aplicação. As funcionalidades de conversão de dados também devem ser consideradas, caso existam. Após a manutenção, a contagem da aplicação deve ser refeita para refletir as alterações realizadas.

Aplicação: mede uma aplicação instalada. É também referenciada como contagem de linha de base ou contagem instalada e avalia as funcionalidades correntes providas aos usuários finais da aplicação.

2. Identificar a Fronteira da Aplicação

Após determinado o tipo de contagem, a fronteira da aplicação deve ser identificada. Ela indica a separação entre o projeto que está sendo medido e as aplicações externas ao domínio do usuário. É através dela que torna-se possível definir quais funcionalidades serão incluídas no processo de contagem dos pontos de função.

3. Contar Funções Tipo Dados

Nesta etapa as funcionalidades da aplicação começam a ser identificadas e contadas.

A funcionalidade da aplicação é avaliada em termos do quê é fornecido pela mesma, não do como é fornecido. Apenas componentes definidos e solicitados pelo usuário devem ser contados.

As Funções Tipo Dados representam as funcionalidades fornecidas pelo sistema ao usuário, para atender às necessidades referentes aos dados que o sistema irá manipular. Essas funções podem ser:

A diferença básica entre um ALI e um AIE é que o último não é mantido pela aplicação que está sendo contada. Um AIE contado para uma aplicação sempre será contado como um ALI em sua aplicação de origem.

Nas definições de ALI e AIE foram utilizados alguns termos e expressões que merecem esclarecimento. São elas:

Informações de Controle: são dados utilizados pela aplicação para garantir aderência com os requisitos funcionais especificados pelo usuário. Por exemplo: datas e horas são utilizadas pelos usuários para estabelecer a sequência ou o momento de eventos. Assim, datas e horas são informações de controle.

Identificável pelo Usuário: refere-se aos requisitos específicos que um usuário ou grupo de usuários seria capaz de definir para a aplicação.

Mantido: refere-se ao fato de que o dado pode ser modificado através de um processo elementar da aplicação. Um processo elementar é a menor atividade capaz de produzir resultados significativos para o usuário. Por exemplo: incluir, alterar e excluir.

Cada Arquivo Lógico Interno e cada Arquivo de Interface Externa possuem dois tipos de elementos que devem ser contados para cada função identificada:

Tipos de Elementos de Dados (TED): campo único, reconhecido pelo usuário, não recursivo. Por exemplo: campos das tabelas.

Tipos de Elementos de Registros (TER): subgrupo de dados, reconhecido pelo usuário. Por exemplo: generalização/especialização de classes.

Ao final dessa etapa devem estar identificados quantos Arquivos Lógicos Internos e Arquivos de Interface Externa o sistema possui e para eles, quantos são os Tipos de Elementos de Dados e os Tipos de Registros encontrados.

4. Contar Funções Tipo Transação

As Funções Tipo Transação representam as funcionalidades de processamento dos dados fornecidas pelo sistema ao usuário. Cada Entrada Externa, Saída Externa e Consulta Externa possui dois tipos de elementos que devem ser contados para cada função identificada:

Tipos de Elementos de Dados (TED): campo único, reconhecido pelo usuário, não recursivo. Por exemplo: campos das tabelas.

Tipos de Arquivos Referenciados ou Arquivos Referenciados (TAR): arquivos lógicos utilizados para processar a entrada e/ou saída. É o total de ALI e AIE utilizados pela transação.

Ao final dessa etapa devem estar identificadas quantas Entradas Externas, Saídas Externas e Consultas Externas o sistema possui e, para elas, quantos são os Tipos de Elementos de Dados e os Arquivos Referenciados encontrados.

5. Calcular os Pontos de Função Não Ajustados

Após serem contadas todas as Funções Tipo Dados e as Funções Tipo Transação e seus elementos, é preciso calcular os pontos de função não ajustados, que refletem especificamente as funcionalidades fornecidas ao usuário pelo produto. Para isso, é preciso identificar a complexidade e a contribuição, em pontos por função, de cada uma das funções e elementos contados.

Para determinar a complexidade e contribuição das funções e seus elementos, é necessário utilizar as relações dos valores de complexidade e contribuição fornecidas pela técnica. A seguir são apresentadas tabelas que indicam a complexidade e contribuição das funções e seus elementos em um sistema, de acordo com a contagem estabelecida nas etapas (3) e (4).

Complexidade de um Arquivo Lógico Interno ou Arquivo de Interface Externa de acordo com o número de Tipos de Elementos de Dados e de Tipos de Elementos de Registros identificados para ele.

Complexidade ALI e AIE		Tipo de Elemento de Dados
Complexidade ALI e AIE		1 a 19	20 a 50	≥ 51
Tipo de Elementos de Registro	1	BAIXA	BAIXA	MÉDIA
	2 a 5	BAIXA	MÉDIA	ALTA
	≥ 6	MÉDIA	ALTA	ALTA

Complexidade de uma Entrada Externa de acordo com o número de Tipos de Elementos de Dados e de Arquivos Referenciados identificados para ela. Também é utilizada para determinar a complexidade das entradas de uma Consulta Externa.

Complexidade EE e CE		Tipo de Elemento de Dados
Complexidade EE e CE		1 a 4	5 a 15	≥ 16
Tipo de Arquivo Referenciado	0 a1	BAIXA	BAIXA	MÉDIA
	2	BAIXA	MÉDIA	ALTA
	≥ 3	MÉDIA	ALTA	ALTA

Complexidade de uma Saída Externa de acordo com o número de Tipos de Elementos de Dados e de Arquivos Referenciados identificados para ela. Também é utilizada para determinar a complexidade das saídas de uma Consulta Externa.

Complexidade SE e CE		Tipo de Elemento de Dados
Complexidade SE e CE		1 a 5	6 a 19	≥ 20
Tipo de Arquivo Referenciado	0 a1	BAIXA	BAIXA	MÉDIA
	2 a 3	BAIXA	MÉDIA	ALTA
	≥ 4	MÉDIA	ALTA	ALTA

Contribuições (pesos) obtidas através das complexidades calculadas para as funções identificadas.

Contribuições das Complexidades	Contribuições (peso)
Contribuições das Complexidades	ALI	AIE	EE	SE	CE
Complexidades	7	5	3	4	3
	10	7	4	5	4
	15	10	6	7	6

Para calcular os pontos de função não ajustados, multiplica-se o número de funções identificadas para uma determinada complexidade por sua contribuição. Ao final, soma-se todos os pontos de função encontrados.

A seguir é apresentado um exemplo para o cálculo dos pontos de função não ajustados (PFNA) gerados pelos ALI de um sistema hipotético. O mesmo deve ser feito para outras funções do sistema (AIE, EE, SE e CE).

Função	Itens Contados por Complexidade	Contribuição	Total por Complexidade	Total de PFNA da Função
ALI	1 Baixa	x 7	7	42
	2 Média	x 10	20
	1 Alta	x 15	15

6. Calcular Valor do Fator de Ajuste

O número de pontos de função não ajustados de um sistema reflete a funcionalidade que o sistema fornecerá ao usuário, sem considerar as especificidades do sistema. Por exemplo, um mesmo sistema pode ser implementado para operar stand alone para um cliente e em arquitetura cliente servidor para outro. As funcionalidades seriam as mesmas, o que resultaria na mesma contagem de pontos de função não ajustados, mas quando considera-se as características do sistema para cada cliente, observa-se que os pontos de função devem ser ajustados para refletir a maior complexidade do sistema na arquitetura cliente servidor.

Para ajustar os pontos de função encontrados na etapa (5) devem ser levadas em consideração 14 (quatorze) características do sistema que serão analisadas e fornecerão o valor do fator de ajuste. São elas:

Comunicação de Dados
Processamento Distribuído
Performance
Configuração Altamente Utilizada
Taxa de Transações
Entrada de Dados On-Line
Eficiência do Usuário Final
Atualização On-Line
Processamento Complexo
Reutilização
Facilidade de Operação
Facilidade de Instalação
Múltiplos Locais
Modificações Facilitadas.

Para cada característica deve ser atribuído um nível de influência de 0 (zero) a 5 (cinco), onde:

0 (zero) indica nenhuma influência

1 (um) influência mínima

2 (dois) influência moderada

3 (três) influência média

4 (quatro) influência significativa

5 (cinco) grande influência.

Para calcular o valor do fator de ajuste deve-se seguir a relação VFA = (GIT * 0,01) + 0,65

VFA é o valor do fator de ajuste
GIT é o grau de influência total (soma de todos os valores dos níveis de influência).

7. Calcular Pontos de Função Ajustados

Após calculado o valor do fator de ajuste, os pontos de função não ajustados serão ajustados, multiplicando-se o valor dos pontos de função não ajustados (PFNA), obtidos em (5), pelo valor do fator de ajuste (VFA),obtido em (6).

Assim, PFA = PFNA x VFA

O número de pontos de função encontrado representa o tamanho da aplicação de acordo com sua funcionalidade.

Para calcular as estimativas de esforço, prazo e custos para a aplicação é necessário conhecer valores como o custo de um ponto de função (por exemplo R$200,00) e o tempo necessário para realizar um ponto de função (por exemplo 2,5 h), ou o esforço para realizar um ponto de função (por exemplo 14 pessoas/mês) e o custo do esforço. Com esses valores é possível calcular as estimativas para o projeto através das relações entre o número total de pontos de função do sistema e os valores de um ponto de função.

Para determinar os valores de um ponto de função, a organização pode realizar medições em projetos anteriores e obter um valor médio para o ponto de função. Caso não existam projetos anteriores podem ser consultadas tabelas disponibilizadas pelo IFPUG (Institute Function Point Users Group) e por seus órgãos representantes em cada país.

APF - Análise de Ponto de Função

Tipo de contagem, identificação da fronteira da aplicação, função de dados e funções de transação:

Calculo do Ponto de Fução não ajustado, cálculo do fator de ajuste e cálculo do Ponto de Função ajustado.

Fatores que influenciam a métrica da aplicação.

ALI – Mantido dentro da fronteira da aplicação. (ex. tabelas de banco de dados atualizadas pela aplicação)

Como Identificar se é um ALI:

É um grupo de dados reconhecido pelo usuário?
Arquivo é mantido por algum processo elementar?
É mantido pela aplicação que está sendo contada?

Exemplos:

Dados das transações da aplicação.
Segurança da Aplicação: Dados de password mantidos dentro da aplicação.
Dados de Auditoria mantidos dentro da aplicação.
Dados de Controle mantidos dentro da aplicação.
Arquivos de Erros mantidos dentro da aplicação.
Dados de Histórico mantidos separadamente dentro da aplicação.

AIE – Mantido fora da fronteira da aplicação. (ex. tabelas de banco de dados lida pela aplicação, mas atualizada em outra aplicação).

TODAS as seguintes regras devem ser aplicadas para o grupo de dados ser identificado como um AIE:

O grupo de dados ou informação de controle é reconhecido pelo usuário.
O grupo de dados é externo e referenciado pela aplicação sendo contada.
O grupo de dados NÃO é mantido pela aplicação sendo contada.
O grupo de dados é mantido em um Arquivo Lógico Interno de outra aplicação.

Como Identificar se é um AIE:

É um grupo de dados reconhecido pelo usuário?
Arquivo é mantido por algum processo elementar?
É mantido pela aplicação que está sendo contada?
É mantido por um processo elementar de outra aplicação?

Exemplos:

Dados de outra aplicação APENAS Referenciados.
Segurança da Aplicação: Dados de password mantidos fora da aplicação.
Dados de Auditoria mantidos fora da aplicação.
Dados de controle mantidos fora da aplicação.
Arquivos de Erros mantidos fora da aplicação.
Dados de Histórico mantidos fora da aplicação.

Atenção: Entender ARQUIVO como um grupo de dados logicamente relacionados e reconhecidos pelo usuário, eventualmente pode estar mapeado em um ou mais arquivo do sistema operacional ou em tabelas de banco de dados.

· Arquivo:

1º Grupo de dados logicamente relacionados e reconhecidos pelo usuário.

2º Arquivo do sistema operacional.

3º Tabelas do banco de dados.

Dois aspectos que devem ser observado quando fazemos a AFP:

Visão do Desenvolvimento.
Visão do Negócio.

Quando implementamos um cadastro de clientes simples, ao normalizarmos as tabelas de banco de dados (visão do desenvolvedor) nos deparamos com várias tabelas, cuja relação é de 1 para N, como telefone fixo, celular e etc. Sob a óptica do desenvolvedor teremos diversas tabelas, mas sob óptica do negócio teremos um ALI.

Visão do Negócio

Visão do Desenvolvedor

Visão APF = 1 ALI

Para entendermos melhor a visão de negócio basta imaginarmos a operação do negócio sem o software, com os processos manuais. Então teríamos as fichas cadastrais como arquivo ou armários onde as informações dos clientes ficariam guardadas. As fichas dos clientes são guardadas em armários distintos das fichas de pedido e assim sucessivamente de acordo com o negócio.

Quando informatizamos o negócio, os armários viram tabelas de um banco de dados, mas o que importa para APF são os armários e não as tabelas de banco de dados.

Identificando ALI e AIE

Identifique todos os dados ou informações de controle, logicamente relacionados, reconhecidos pelo usuário no escopo da contagem.

Descarte entidades ou atributos não requeridos pelo usuário.

Para cada entidade independente identificada

Dados de código?

Sim. Descarte mesmo se requerido pelo usuário.

Conceito completo?

Sim. Proceda para classificação.

Não. Para cada entidade dependente relacionada.

Agrupe com os dados da entidade independente.

Classificando ALI e AIE

Mantida pela aplicação medida?

Sim. ALI.

Não. Referenciada pela aplicação medida?

Não. Reavalie a Identificação

Sim. ALI em uma ou mais aplicação?

Sim. AIE.

Definição de Arquivo Lógico Interno – ALI

Um grupo de dados ou informações de controle.
Identificável pelo usuário.
Logicamente relacionado.
Mantido na fronteira da aplicação.

Definição de Arquivo de Interface Externa – AIE

Um grupo de dados ou informações de controle.
Identificável pelo usuário.
Logicamente relacionado.
Referenciado (lido) pela aplicação.

Principal diferença entre ALI e AIE

ALI - Mantido na fronteira da aplicação.
AIE - Referenciado (lido) pela aplicação. (ALI em outra aplicação)

Exemplos de Arquivos Lógicos

Tabelas que armazenam dados mantidos pela aplicação (ALI) ou referenciados por ela e mantidos por outra aplicação (AIE)
Arquivos de parâmetro de negócio mantido pela aplicação (ALI)
Arquivos mantidos não só pela aplicação, mas também por outra aplicação.

Determinação de Complexidade

Os ALIs e AIEs devem ser classificados de acordo com a sua complexidade funcional, com base em:

Número de Tipos de Dados (TD)
Número de Tipos de Registros (TR)

Complexidade do ALI/AIE

TR \| TD	> 20	20 a 50	> 50
1	Baixa	Baixa	Média
2 a 5	Baixa	Média	Alta
> 5	Média	Alta	Alta

Como classificar um TD - Tipo de Dado

É um campo único
Reconhecido pelo usuário
Não repetido
Mantido ou recuperado por um ALI ou AIE (por um processo elementar)

Regras de Contagem de Tipo de Dados

Contar como 1 TD nos casos em que vários campos implementam apenas um tipo de dados:

Realização de uma imagem, o conteúdo salvo nos campos em histórico conta um único tipo de dado.

Imagem = 11 TD, contamos os 10 campos de Contatos e 1 do Histórico, que é a imagem de Contatos.

Campos calculados e armazenados em ALI também deve ser contados como Tipos de Dados.
Campos do tipo timestamps, se reconhecidos pelo usuário, devem ser contados como tipos de dados.

Arquivos com várias ocorrências do mesmo campo: Janeiro, Fevereiro,..., Dezembro. Doze campos repetidos mapeados como dois tipos de dados únicos.

Cliente Saldos [12 campos]

| J | F | M | A | M | J | J | A | S | O | N | D |

1 ALI 2 TD = Saldo e Mês

Quando duas aplicações mantêm ou referenciam o mesmo ALI/AIE, conte apenas os campos utilizados pela aplicação em análise, por exemplo:

a. Se uma aplicação faz uso de 3 campos e a outra faz uso de 2 campos teremos respectivamente 3 TD para primeira e 2 TD para segunda aplicação.

b. Se uma aplicação faz uso de 6 campos e na outra aplicação só faz sentido usar o conjunto, pois as informações desassociadas são irrelevantes

Conte um Tipo de Dado para cada campo solicitado pelo usuário para estabelecer um relacionamento com outro arquivo (ALI ou AIE).

Funcionário

(independente)

# empresa

#funcionário

...

Cliente

(independente)

# cliente

# empresa

# funcionário

...

2 Arquivos Lógicos

2 Tipo de Dados

Caso a chave estrangeira seja composta por vários campos, todos devem ser contados como tipos de dados.
Quando um único arquivo lógico é composto por mais de uma tabela no banco de dados, a chave estrangeira usada para estabelecer o relacionamento entre essas tabelas não deve ser contada mais de uma vez como tipo de dados.

Atenção: Nem sempre a relação entra Tipo de Dados e Campo de Arquivo é 100% correto.

Definição de Tipo de Registro (TR)

Um TR é um subgrupo de dados, reconhecido pelo usuário, componente de um Arquivo Lógico Interno ou Arquivos de Interface Externa.

Existem dois tipos:

Opcionais: não são informados no processo elementar, mas cria ou adiciona dados ao arquivo.

Obrigatórios: são aqueles que o usuário requer que sejam sempre utilizados pelo processo elementar que cria ou adiciona dados ao arquivo.

Subgrupo de dados reconhecido pelo usuário.

Compromisso

Rateio

Parcelas

Compromisso, Rateio e Parcelas são os 3 TR.

Regras de Contagem de Tipo de Registro

Conte um TR para cada função de dados, isto é, por default, cada função de dados tem um subgrupo de TD a ser contado como TR.
Conte um TR adicional para cada um dos seguintes subgrupos lógicos de TDs, compreendido na função de dados, que contém mais de um TD.

Entidade associativa com atributos não chaves.
Subtipo.
Entidade atributiva em um relacionamento que não seja mandatório.

Determinação da Contribuição

Tipo de Função	Baixa	Média	Alta
ALI	7 PF	10 PF	15 PF
AIE	5 PF	7 PF	10 PF

Por exemplo: um ALI de complexidade baixa contribui com 7 pontos de função.

Prática de Contagem – Abordagem prática de contagem de ALI e AIE.

Dados de Código (Metadados)

Os requisitos de armazenamento, funcionais e não funcionais, de uma aplicação são classificados em:

Dados de Negócio
Dados de Referência
Dados de Código

Aqueles enquadrados como Dados de Código, apesar de poderem representar até metade das entidades em um modelo de dados em terceira forma normal, não devem ser considerados Arquivos Lógicos. Eles são uma implementação de requisitos técnicos e não devem influenciar no tamanho funcional da aplicação, ou seja, os pontos de função não ajustados. As transações que existem exclusivamente para a manutenção de dados de código não devem ser consideradas processos elementares, assim como os dados de código não devem ser contados como arquivos referenciados nos processos elementares que os leiam e/ou atualizem.

Exemplos: data de início e término de vigência, sigla e nome das unidades federativas e etc... Não são especificados pelo usuário, mas identificado pelo desenvolvedor em resposta a um ou mais requisitos técnicos (fase de normalização) e ainda:

Arquivos que sempre armazenam apenas uma ocorrência e cujo conteúdo de seus atributos raramente mude.

Exceção: arquivos com apenas um registro, armazenar informação de controle do negócio (parâmetro).

Em que tanto a quantidade de ocorrências quanto seu respectivo conteúdo raramente mudam.
Templates que armazenam valores padrão para alguns atributos de uma nova ocorrência de um objeto de negócio.
Com apenas um atributo. Cada ocorrência representa somente um valor válido.
Com dados que raramente mudem e que representem uma faixa de valores válidos. Tabelas com valores da mão de obra.

Dados de Código

Dados de Referencia

São definidos como requisitos de armazenamento que suportam regras de negócio na manutenção de dados de negócio. É importante que os dados de referência, incluídos na medição dos Pontos de Função, não sejam confundidos com os dados de código.

Diferenças:

Dados de Códigos: podem ter o código substituído pela respectiva descrição nos objetos de negócio em que são utilizados sem que o significado desses últimos sejam alterados.

Dados de Referencia: estes são alterados.

Outras entidades não contadas como Arquivo Lógico

Arquivos de Índice

Não possuem funcionalidade de armazenar dados ou informações de controle, portanto não podem ser ALI ou AIE.

Arquivos com Dados Consolidados

Cujo único objetivo fim é agilizar o processamento, não representam requisitos funcionais, mas sim de desempenho, requisito não funcional. Exceção se as informações não forem constituídas a partir dos dados de outras tabelas.

Requisitos não Funcionais – atributos do sistema ou ambiente do sistema.

Extensibilidade
Usabilidade
Confiabilidade
Desempenho
Escalabilidade
Reusabilidade
Capacidade de manutenção
Reutilização de código
Eficiência no desenvolvimento
Confiabilidade nos dados apresentados

Arquivos Temporários e de Passagem de Movimento

Quando sua principal intenção é transportar dados, são de fato mensagens. Neste caso o arquivo original não representa um requisito funcional de armazenamento.

Distribuição de Dados

A distribuição de dados de um mesmo grupo lógico de dados em vários arquivos físicos mantidos em localidades diferentes não é um requisito funcional, portanto não pode ser considerados um ALI ou AIE.

Visões

Não são considerados Arquivos Lógicos, pois não representam requisitos funcionais de armazenamento do USUÁRIO. (visão do negócio)

Entidade de Ligação

As entidades com apenas as chaves de duas ou mais outras entidades como atributos, definindo com isso a intersecção entre elas, representam a implementação de um relacionamento em um modelo de dados normalizado, do tipo “N:M”, não podemos classificar o resultado da intersecção como um ALI ou AIE.

Entidades não Mantidas por Processos Elementares

Não são contadas como ALI ou AIE.

Atenção: Processo Elementar é a menor unidade de atividade significativa para o usuário final.

Após todo esse processo o que fazer com as entidades que sobraram?

Se não deixamos passar nada teoricamente as entidades que sobram são arquivos lógicos.

Observando as informações

As perspectivas de negócio do usuário quanto aos dados é refletida em como as transações os consultam e/ou atualizam. Verifique como os processos elementares da aplicação matem essas entidades. A inclusão e exclusão conjunta de determinado grupo de entidades é um forte indicador que esse grupo deve ser considerado único arquivo lógico. A alteração de dados normalmente está direcionada apenas para uma única entidade; consequentemente, ela não é uma orientação efetiva para agrupar entidades. Identifique os processos elementares de extração que consultam essas entidades e verifique se elas também são consultadas conjuntamente.

Uma ordem de serviço (OS) de ter as informações que identificam qual cliente a solicitou, a data de entrada, o prazo estimado, seu responsável e os vários itens envolvidos em sua execução. Durante a modelagem de dados foram especificadas as entidades Ordem de Serviço e Item da OS para atender a esse requisito de armazenamento. Os processos OS-Incluir e OS-Excluir também operam sobre estas entidades. Não é possível incluir uma OS sem que os itens sejam incluídos, assim como não é possível manter um itens sem a OS.

Entidades Atributivas

É a entidade dependente que estende conceitualmente outra entidade, a entidade principal, descrevendo uma ou mais de suas características e cujas ocorrências podem substituir a repetição pode substituir a repetição de um mesmo subgrupo de dados em uma única ocorrência da principal, ou seja, a entidade INDEPENDENTE, principal, em conjunto com todas as entidades dependentes que a descrevem, são contadas como um único arquivos lógico.

Na contagem quando uma ocorrência da entidade principal puder existir se o respectivo par na entidade dependente deve-se contar dois tipos de registro, sendo a entidade principal e a entidade dependente. Quando OBIGATÓRIAMENTE para cada ocorrência da entidade principal houver necessidade de uma ocorrência da entidade dependente, ou seja, uma só tem sentido para o negócio acompanhada do preenchimento da outra, deve-se contar apenas um tipo de registro, compreendendo os tipos de dados de ambas as entidades.

Generalização, Subtipos e Supertipos.

A relação entre um elemento mais geral – o pai – e um elemento mais específico que agrega informações adicionais e é totalmente consistente com o primeiro elemento – o filho – é chamado de Generalização.