Estimativa por Ponto de Função

Juliana Jenny Kolb

teste

 

Home > Engenharia de Software > SumárioProjeto de Software > Métricas

Estimativa por Ponto de Função

Modelo: Estimativa por FP

 

A Métrica por Ponto de Função (Function Point – FP), inicialmente proposta por Albrecht (1979), pode ser efetivamente como um meio para medir a funcionalidade entregue por um sistema.

Os objetivos do Ponto de Função, são:

  • medir o que foi requisitado e recebido pelo usuário;
  • medir independente da tecnologia utilizada para a
    implementação;
  • prover uma métrica de medição para apoiar a análise de produtividade e qualidade;
  • prover uma forma de estimar o tamanho do software e prover um fator de normalização para comparação de software;
  • minimizar o trabalho adicional do processo de mensuração;
  • permitir consistência, ao longo do tempo dos projetos,
    e entre os usuários da técnica.

Um dos primeiros passos para efetuar a contagem por pontos de função de um sistema, é definir o tipo de contagem que serão efetuado. Esses tipos se dividem em:

A Métrica por Ponto de Função (usando dados históricos) é utilizada para:

  • estimar o custo ou esforço necessário para projetar, codificar e testar software;
  • prever o número de erros que vão ser encontrados durante o teste;
  • prever o número de componentes e/ou número de linhas de código projetadas no sistema implementado.

Pontos por Função são derivados usando uma relação empírica baseada em medidas de contagem (direta) do domínio de informação do software e avaliação da complexidade do software.

Valores do domínio de informação são definidos da seguinte maneira:

  • Número de entradas externas (EE ou External Inputs – Eis): uma entrada externa processa dados ou processa informações de controle que entram pela fronteira da aplicação. Esses dados, através de um processo lógico único, atualizam Arquivos Lógicos Internos. Exemplo: Tela de Entrada on-line (Contar uma entrada para cada função de manutenção como inclusão, alteração e exclusão).
  • Número de saídas externas (SE ou External Output – Eos): cada saída do usuário que proporcione informações orientadas à aplicação. (Relatórios, mensagens de erro, etc);
  • Número de consultas externas  (CE ou External Inquiries – EQs): uma consulta é definida como uma entrada on-line que resulte na geração de alguma resposta. Exemplo: Telas de alteração ou remoção de dados, que mostram o que será alterado ou removido antes de sua ação efetiva, devem ser consideradas como Consultas Externas, Telas de seleção de relatórios que permitem informar parâmetros para o relatório escolhido, devem ser consideradas como sendo a parte de entrada de uma Consulta Externa;
  • Número de arquivos lógicos internos  (ALI ou Internal Logical Files – ILFs): cada arquivo-mestre lógico, isto é, um agrupamento lógico de dados, que pode ser uma parte de um grande banco de dados ou um arquivo convencional, é contado. Exemplo: tabela de clientes, tabela de usuários, etc;
  • Número de interfaces externas  (AIE): um Arquivo de Interface Externa é um grupo de dados logicamente relacionados ou informações de controle especificadas pelo usuário, que é utilizado pela aplicação, mas sofre manutenção a partir de outra aplicação. Exemplo: APIs, WebServices, etc.

Uma vez coletado estes dados, a tabela 1 é completada e um valor de complexidade é associado com cada contagem. Organizações que usam métodos de ponto por Função desenvolvem critérios para determinar se uma entrada é simples, média ou complexa.

Tabela 1: Valores de Complexidade.

 . Fator de Ponderação
Parâmetro de Medida Contagem Simples Médio Complexo
EE/Eis – Número de Entradas x 3 4 6 =
SE/Eos – Número de Saídas x 4 5 7 =
CE/EQs – Número de Consultas x 3 4 6 =
ALI/ILFs- Número de Arquivos x 7 10 15 =
AIE – Número de Interfaces Externas x 5 7 10 =
Contagem Total

Fonte: adaptado pela autora (2010).

Além do cálculo de complexidade, é necessário calcular os Fatores de Ajuste (Fi), para tanto, deve-se responder às perguntas explicitadas na tabela 2.

Tabela 2: Fatores de Ajuste (Fi)

1) O sistema requer backup e recuperação confiáveis?
2) São exigidas comunicações de dados?
3) Há funções de processamento distribuídas?
4) O desempenho é crítico?
5) O sistema funcionará num ambiente operacional existente, intensiamento utilizado?
6) O sistema requer entrada de dados on-line?
7) A entrada de dados on-line exige que a transação de entrada seja elaborada em múltiplas telas ou operações?
8 ) Os arquivos-mestres são atualizados on-line?
9) A entrada, saída, arquivos ou consultas são complexos?
10) O processo interno é complexo?
11) O código foi projetado de forma a ser reusável?
12) A conversão e a instalação estão incluídos no projeto?
13) O sistema é projetado para múltiplas instalações em diferentes organizações?
14) A aplicação é projetada de forma a facilitar mudanças e o uso pelo usuário?
<– Total de (Fi)

Fonte: PRESSMAN (2010, pg. 358).

Cada uma destas questões é respondida usando uma escala, onde:

0 – Sem influência
1 – Incidental
2 – Moderado
3 – Médio
4 – Significativo
5 – Essencial

*As características gerais dos sistemas (fatores de ajuste), pode influenciar em até 35% em relação ao valor inicial.

Para calcular os Pontos por Função, a seguinte relação é usada:

FP = Contagem Total x (0,65 + 0,01 x ∑ (fi))

Produtividade = FP/pessoa mês

Qualidade = defeitos/FP

Custo = $/FP

Documentação = páginas de documentação/FP

Porém, ao se chegar em uma valor de FP, deve-se estipular a quantidade de horas por FP. Por exemplo:

-> FP = 25

-> 5h por FP

-> Estimativa de horas: 5 * 25 = 125 horas.

Referência Bibliográfica

PRESSMAN, Roger S. Engenharia de Software, Sexta Edição. Editora MCGrawHill: Porto Alegre, 2010.

http://fattocs.com/files/pt/livro-apf/citacao/WerleyTeixeiraReinaldo-CristinaDOrnellasFilipakis-2009.pdf

msg

Deixe uma resposta