Juliana Jenny Kolb
Home > Engenharia de Software > Sumário > Projeto 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