Bruno Ramos Carneiro da Cunha Fernando Ramos Prata Marcel Mattos da Fonseca

1. Bruno Ramos Carneiro da Cunha Fernando Ramos Prata Marcel Mattos da Fonseca

2. Pontos de função • Grupo Internacional de Usuários de Pontos de Função (IFPUG) • ASQC - Conferência Internacional sobre Qualidade de Software • Pontos de Função medem o tamanho funcional do software • Apenas Pontos de Função são insuficientes para um desenvolvedor de software administrar um projeto

3. O que são Pontos de função • O tamanho em Pontos de Função NÃO mede a produtividade ou o esforço de desenvolvimento • Pontos de função medem o tamanho do QUE o software faz, ao invés de COMO ele é desenvolvido e implementado

4. O Que é o Processo de Contagem de Pontos de Função? • Determinar o tipo de contagem (pode ser um projeto de novo desenvolvimento, uma contagem básica de aplicação ou uma contagem de projeto de melhoria) • Identificar a fronteira da aplicação (i.e., quais funções o software deve executar?) • Contar os tipos de funções de dados (divididos em: i) Arquivos Lógicos Internos ou ALIs, que são os grupos lógicos de dados mantidos dentro da fronteira da aplicação, e ii) Arquivos de Interface Externa ou AIEs, os quais são apenas referenciados pela aplicação). Cada ALI vale 7, 10 ou 15 PF,enquanto cada AIE vale 5, 7 ou 10 PF.

5. Contar os tipos de funções de transações (divididos em: • a) Entradas Externas ou EEs, que são processos de entrada de dados • b) Saídas Externas ou SEs, por exemplo, relatórios e • c) Consultas Externas ou CEs, por exemplo, Consultar Detalhes de Empregados). Cada EE ou CE vale 3, 4 ou 6 pontos de função, enquanto cada SE vale 4, 5 ou 7 pontos de função.

6. Diversas matrizes simples baseadas nos tipos de elementos de dados (reconhecidos pelos usuários e não recursivos), juntamente com tipos de registros (subconjunto dos dados reconhecidos pelos usuários) ou tipos de arquivos referenciados (número de grupos lógicos de dados necessários à execução completa de um processo) são utilizados para determinar a complexidade de cada função, Baixa, Média ou Alta. A seguinte tabela do IFPUG sintetiza o número de pontos de função atribuídos a cada tipo de função

8. Determinar o Fator de Ajuste de Valor (FAV) baseado na equação (FAV = 0,65 + (Soma das Características Gerais do Sistema x 0,01) e a avaliação, em uma escala de 1 a 5, das seguintes quatorze Características Gerais do Sistema. Instruções específicas para avaliação são fornecidas no CPM do IFPUG • Calcular a contagem ajustada final de PF (contagem final de PF = contagem não ajustada * FAV)

9. Como os Pontos de Função São Utilizados? • Os pontos de função nos oferecem uma medida funcional de tamanho a partir da perspectiva do usuário e NÃO uma panacéia para a solução de qualquer problema • Os pontos de função podem ser correlacionados com outras medidas para produzir métricas de software específicas • Métricas de software são ferramentas passivas, utilizadas para quantificar e informar os resultados das mudanças. Pontos de função não são exceção a essa regra

10. Como as Métricas de Software e os Pontos de Função se Encaixam em um Programa de Mensuração? • Pontos de Função nos oferecem uma medida padronizada e normalizada do tamanho funcional dos requisitos lógicos dos usuários e, juntamente com outras medidas, podem ilustrar vários aspectos do processo de desenvolvimento de software, de modo a ensejar melhorias

11. São métricas orientadas ao processo de desenvolvimento as quais concentram-se na funcionalidade ou utilidade do programa.  Os pontos de função derivam-se de uma relação empírica baseada em medidas de informações e complexidade do software. O PF é utilizado para medir o tamanho do software pela sua funcionalidade externa tendo como objetivos: • Medir o que o Cliente requisitou; • Propiciar uma métrica quantitativa de Análise do Software; • Propiciar uma forma de realizar Estimativas a respeito do Software.

12. Cálculo do Ponto de Função (PF) • Determina-se o tipo de contagem; • Identificam-se as fronteiras da contagem; • Determinam-se os Pontos de Função não ajustados (PFna); • Determina-se o Fator de Ajustamento (FA); • Calcula-se o Ponto de Função ajustado (PFa).

13. Cálculo do Ponto de Função não ajustado (PFna): Para a determinação do Ponto de Função não ajustado (PFna), deve-se observar a funcionalidade específica requerida pelo Usuário. Quantifica-se fatores como: • Número de entradas do usuário - Cada dado do usuário que proporciona dados distintos. Ex. Pedal esquerdo pressionado; • Número de saídas do usuário - Relatórios, Telas e Mensagens de erro. Ex. Aviso sonoro quando ocorrer falhas;

14. Cálculo do Ponto de Função não ajustado (PFna): (cont.) • Número de consultas do usuário- Entrada on-line que resulta em alguma resposta. Ex. Existência de corrente elétrica; • Número de arquivos- Agrupamento lógico de dados, que pode ser uma parte de banco de dados ou um arquivo. Ex. Log de falhas ocorridas; • Número de interfaces externas- Interfaces usadas para transmitir informações a outros sistemas. Ex. Barramentos de dados.

15. Cálculo do Ponto de Função não ajustado (PFna): (cont.) Abaixo apresenta-se a tabela de contagem total do sistema HADECB e o valor da complexidade associado acada contagem:

16. Calculo do Fator de Ajustamento (FA): A funcionalidade proporcionada pelo software é indicada pelo fator de ajustamento (FA). Avalia-se o Nível de Influência (NI), determinando-se um valor entre 0 e 5, que ela representa.

17. Calculo do Fator de Ajustamento (FA):(cont.)

18. Calculo do Fator de Ajustamento (FA):(cont.)

19. Calculo do Fator de Ajustamento (FA):(cont.) Determina-se o Fator de Ajustamento (FA), a partir da fórmula: FA = 0,65 +(0,01*NI) FA = 0,65 +(0,01*27)=0,92 Ponto de Função Ajustado(PFa) é determinado pela formula: PFa = FA*PFna PFa = 0,92*84=77,28

20. Tamanho do Software em PF X Número Esperado de Defeitos do Software:

21. Tamanho do Software em PF X Número Esperado de Defeitos do Software: Equações da Regressão Linear Calcula-se o Número Esperado de Defeitos do HADECB com o Ponto de Função ajustado igual a 77,28

22. Tamanho do Software em PF X Número Esperado de Defeitos do Software:(cont.) • Logo, o número de Defeitos Esperados é determinado pela fórmula: Y = -35,15 + 2,625*X; • Para X = 77,28, tem-se: Y = -35,15 + 2,625*77,28 = 167,71; • Portanto, para o HADECB, com Ponto de Função Ajustado igual a 77,28 pode-se prever a existência de aproximadamente 167,71 Defeitos.

23. O Ponto de Função no Uso da Medição da Produtividade, Qualidade, Custo e Documentação: Após ter calculado o Ponto de Função Ajustado pode-se estimar também a Produtividade, Qualidade, Custo e Documentação. Produtividade = FP/pessoa mês = 77,28 / 4 = 19.32 : Qualidade= Defeito/FP= 167,71 / 77,28 = 2,17 Custo=$/FP=3,55 / 77,28 = 0.046 Documentação = páginas de documentação/FP= 8 / 77,28 = 0,1035

24. Utilizando Pontos de Função para Ajudar a Definir Quando e Onde Fazer Reengenharia • Utilizando Pontos de Função para Estimar Casos de Teste • Utilizando Pontos de Função para Ajudar a Entender Faixas de Produtividade Amplas • Utilizando Pontos de Função para Entender o Aumento do Escopo • Utilizando Pontos de Função para Ajudar a Calcular o Custo Real do Software • Utilizando Pontos de Função para Ajudar a Estimar o Custo, Cronograma e Esforço do Projeto • Utilizando Pontos de Função para Ajudar a Entender os Custos de Manutenção • Utilizando Pontos de Função para Ajudar em Negociações Contratuais • Utilizando Pontos de Função para Desenvolver um Conjunto Padrão de Métricas

25. Utilizando Pontos de Função para Ajudar a Definir Quando e Onde Fazer Reengenharia Objetivo : encontrar os aplicativos que mais se beneficiarão dos esforços de reengenharia. Duas perguntas devem ser feitas: 1- Como identificamos aplicativos que devem ser objeto de reengenharia? 2- Como calculamos os benefícios potenciais do esforço de reengenharia?

26. Identificando aplicações para reengenharia Calcular horas de manutenção por FP:

27. Estimando benefícios (calculando o retorno) • Informações necessárias para estimar os benefícios de um projeto de reengenharia: • Horas de manutenção atuais por ponto de função; • Horas de manutenção por ponto de função esperadas após o projeto de reengenharia; • Período de retorno desejado;

28. Ex: FP= 1.000 (Horas de manutenção) / FP= 10h Valor desejado= 8h (Horas de manutenção) / FP - Valor desejado= 10 - 8 = 2h Período de retorno= 1 ano Conclui-se que o projeto de reengenharia não poderia levar mais que 2.000 horas. (2h x 1.000 FP)

29. Utilizando Pontos de Função para Estimar Casos de Teste Estimado por Capers Jones. Idéia: “Conforme um aplicativo cresce, os interrelacionamentos nele contidos tornam-se mais complexos” Nº de casos de teste = (FP)^1,2 Ex: FP=1.000 , logo deverão existir 1.000^1,2=3981 4.000 casos de teste.

30. Entendendo o Potencial de Defeitos Objetivo: Entender os defeitos potenciais do software para aprimorar a qualidade. “A diferença na quantidade real e estimada dos casos de teste é um bom indicador do potencial de defeitos” Se casos reais < quantidade esperada, conclui-se que a cobertura de testes será inadequada.

31. Conclusão “Há muitos usos para pontos de função além de estimar o cronograma, esforço e custo. Muitos gerentes de projeto não acreditam que os pontos de função possuem qualquer utilidade. De certa forma, eles estão certos. Muitas organizações estão utilizando pontos de função e métricas de software para reportar tendências a nível organizacional. Muitas equipes de projeto enviam dados a um grupo central de métricas e nunca mais tornam a ver seus dados. Isto é análogo a enviar os dados a um buraco negro. Se os gerentes de projetos começarem a entender como os pontos de função podem ser utilizados para estimar casos de teste, calcular custos de manutenção e assim por diante, eles provavelmente investirão na contagem de pontos de função.”