[3] Passo 3: neste passo, utiliza-se uma expressão empírica proposta pelo modelo para obtenção dos pontos de função:
Apenas para ilustrar, vamos apresentar a tabela completamente preenchida, para um determinado projeto de software, o que seria feito no passo 1.
Supondo que no passo 2 foi realizado o cálculo que resultou em
o valor que indica que o produto é moderadamente complexo.
No passo 3 calculamos o PF.
PF = 50 x [0.65+ (0.01 x 46)] = 55.5 => 56
| 1. O sistema exige backup e recuperação confiáveis | 8. Os arquivos são atualizados on-line? |
| 2. É requerida comunicação de dados? | 9. Entradas, saídas, arquivos e consultas são complexos? |
| 3. Existem funções de processamento distribuído? | 10. O processamento interno é complexo? |
| 4. O desempenho é crítico? | 11. O código é projetado para ser reusável? |
| 5. O sistema funcionará num sistema operacional existente e intensamente utilizado? | 12. A conversão e a instalação estão incluídas no projeto? |
| 6. São requeridas entrada de dados on-line? | 13. O sistema é projetado para múltiplas instalações em diferentes organizações? |
| 7. As entradas on-line requerem que as transações de entrada sejam construídas com várias telas e operações? | 14. A aplicação é projetada de forma a facilitar mudanças e o uso pelo usuário? |
Para evitar o problema da subjetividade ao avaliar a influência de cada funcionalidade, o IFPUG desenvolveu recomendações a serem seguidas.
No final desse segundo passo, você terá a soma das influências de cada uma das 14 perguntas. O valor dessa soma variará de um mínimo de 0 (todas as 14 perguntas tendo valor 0) a um valor máximo de 70 (todas as perguntas tendo valor igual a 5).
A métrica Ponto de Função (PF) ou Function Point (FP) pode ser utilizada como forma de medir a funcionalidade fornecida por um sistema. Pressman e Maxim (2016, p. 659) indicam que podem ser usadas para:
Os PFs são derivados de medidas calculáveis do domínio de informações do software com base em:
Para o cálculo de Pontos de Função, os passos descritos a seguir devem ser seguidos.
[1] Primeiro passo: preencher as colunas sombreadas da tabela. Note que nessa tabela você deve preencher apenas os dados da coluna Contagem e fazer o cálculo da coluna Contagem x Fator de Peso e totalizar a Contagem Total. As colunas Valor do domínio da informação e Fator de Pesos já estão preenchidas, pois são valores são propostos pelo modelo e, a princípio, são fixos. Então, nesse passo, você terá que estimar a quantidade de cada parâmetro previsto para o software a ser desenvolvido e atribuir um fator de peso para cada um deles.
Uma grande questão que surge é como minimizar a subjetividade na atribuição desses fatores de ponderação, porque isso pode variar de pessoa para pessoa. O IFPUG – International Function Points Users Group – disponibiliza uma série de recomendações visando minimizar essa subjetividade.
| Valor do domínio da informação | Contagem | Fator de Peso | Contagem x Fator de Peso | ||
| Simples | Médio | Complexo | |||
| Nº de Entradas Externas (EIs) | 3 | 4 | 6 | ||
| Nº de Saídas Externas (EOs) | 4 | 5 | 7 | ||
| Nº de Consultas Externas (EQs) | 3 | 4 | 6 | ||
| Nº de ArqLóg Internos (ILFs) | 7 | 10 | 15 | ||
| Nº de ArqInterf Externos (EIFs) | 5 | 7 | 10 | ||
| Contagem Total → | |||||
A qualidade de um sistema, aplicação ou produto é tão melhor quanto melhor estejam descritos os requisitos que o descrevem, o projeto que modela sua solução, o código que o implementa e os testes que o exercitam para descobrir defeitos e erros.
Desta forma, métricas como erros por ponto de função, erros descobertos por horas de revisão, erros descobertos por horas de teste e eficiência na remoção de defeitos proporcionam informações relevantes que ajudam no controle de qualidade do software.
Há um grande número de métricas de software, que normalmente são aplicadas de forma isolada e consideradas insatisfatórias por grande parte dos desenvolvedores.
No passado, várias métricas e uma série de processos foram propostos, mas a maioria não possuía uma base teórica suficiente e/ou uma significativa validação experimental. Várias delas foram definidas e, em seguida, testadas e utilizadas em apenas um ambiente limitado. Apesar de, em alguns casos, existirem relatos de validação ou de aplicação dessas métricas, testes ou uso em ambientes diferentes produziram resultados não esperados. Essas diferenças acabam por não serem surpreendentes, uma vez que faltam definições claras e hipóteses de testes bem definidas.
Assim, existe um grande número de métricas que podem ser utilizadas, mas devemos observar quais delas têm sido mais amplamente utilizadas ou aceitas, pois certamente apresentam resultados mais efetivos.
Se o desenvolvedor construir uma aplicação apoiada por métricas escolhidas de forma criteriosa, elas poderão produzir resultados úteis se forem utilizadas de acordo com o ambiente especificado.
Independentemente das métricas adotadas. é muito importante para as organizações a coleta efetiva dessas métricas e o registro histórico dos projetos, formando uma base de conhecimento que auxilie nos processos de análise, melhoria e tomada de decisão.
Muitos fatores devem ser levados em consideração para a escolha das métricas. Recomendamos que você identifique qual a necessidade de medição do projeto (qualidade, produtividade, erros, falhas etc.) para, em seguida, adotar mecanismos que permitam uma medição mais significativa e efetiva.
As métricas de processo têm finalidade estratégica e objetivam fornecer um conjunto de indicadores de processo visando o seu aperfeiçoamento no longo prazo. As métricas de projeto têm finalidade tática e permitem ao gerente de projeto avaliar o estado de um projeto em desenvolvimento, acompanhar riscos em potencial, descobrir setores que apresentam problemas antes que se tornem críticos, ajustar o fluxo de trabalho e ainda avaliar a capacidade da equipe para controlar a qualidade do produto e dos artefatos de software.
As medidas que são coletadas com base em dados de qualidade e produtividade são convertidas em métricas e analisadas e comparadas com métricas anteriores. Essas métricas podem ser usadas durante o projeto para detectar problemas ocorridos no desenvolvimento e serem transmitidas para quem tem responsabilidade sobre o aperfeiçoamento do processo de software. Desta forma, muitas métricas são usadas tanto no domínio do processo quanto do projeto.
Ainda de acordo com Pressman e Maxim, o processo situa-se no centro de um triângulo (conforme ilustra a figura) que liga três fatores que influenciam significativamente tanto a qualidade de software quanto o desempenho da organização:
Além destes fatores, o triângulo do processo encontra-se dentro de um círculo que inclui o ambiente de desenvolvimento (exemplo: ferramentas CASE), condições de negócios (exemplo: prazos e regras de negócio) e características do cliente (exemplo: facilidade de comunicação).
Triângulo de fatores que impactam o processo
A eficácia de um processo pode ser medida pelas saídas dele derivadas como: medidas dos erros descobertos antes da entrega do produto, defeitos relatados pelos usuários finais, produtividade da equipe, esforço humano dispendido, tempo gasto, cumprimento do cronograma, entre outras. Desta forma, as métricas de processo podem fornecer benefícios significativos na medida em que a organização trabalha para corrigir e melhorar seus problemas, buscando maior maturidade de processo. Em um nível mais avançado, a organização pode adotar a abordagem SSPI – Statistical Software Process Improvement, que usa a análise de falhas de software para coletar informação sobre erros e defeitos encontrados no produto em operação.
As métricas de projeto são usadas por um gerente de projeto para adaptar o fluxo de trabalho e sua primeira aplicação ocorre, geralmente, durante a estimativa. Métricas usadas em projetos anteriores podem ser usadas como base. O gerente utiliza medidas de esforço e tempo dispendidos comparadas com as estimativas previstas no cronograma para monitorar e controlar o progresso do projeto.
Na medida em que o trabalho técnico prossegue, outras métricas de projeto são utilizadas, como taxa de produção, horas de revisão, pontos por função, linhas de código entregues etc. Além disso, os erros descobertos são registrados e outras métricas técnicas são utilizadas para avaliar a qualidade do projeto, o que irá influenciar a abordagem de testes.
As métricas de projeto são usadas tanto para minimizar o tempo do cronograma, buscando evitar atrasos e diminuir riscos, quanto para avaliar a qualidade do produto. Na medida em que a qualidade é melhorada, os defeitos são reduzidos e a quantidade de retrabalho também é minimizada, levando à redução do custo do projeto.
Existem muitas classificações para métricas de software. Um software pode ser medido orientado ao tamanho, a funções, aos objetos, aos recursos humanos envolvidos, a qualidade e pela produtividade, entre outras medições.
Apresentamos algumas classificações de métricas a seguir, com base no trabalho de Meirelles (2008).
Existem outras classificações, como métricas privadas e públicas.
