Perguntas e Respostas sobre Análise de Pontos de Função (APF)

Prévia do material em texto

Perguntas e respostas sobre Análise de Pontos de Função (APF) 
Definições:
1. O que é a Análise de Pontos de Função? E o que é Ponto de Função? 
2. Como os Pontos de Função São Contados?
3. Os Pontos de Função medem as horas necessárias ao desenvolvimento de um projeto?
4. Quem inventou a APF? Como ela surgiu?
5. A técnica APF é propriedade de alguma empresa?
6. O que é backfiring? 
7. O que vem a ser o padrão ISO/IEC de medição de tamanho funcional?
8. O que são Pontos por Caso de Uso (ou Use Case Points)?  
9. Quais as vantagens da APF sobre os Pontos por Caso de Uso (PCU)? 
10. O que é Feature Point? 
1. O que é a Análise de Pontos de Função? E o que é Ponto de Função? 
 Análise de Pontos de Função (APF) é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seus usuários. Ponto de função (PF) é a sua unidade de medida, que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software. Ou seja, a APF busca medir o que o software faz, e não como ele foi construído.
 Portanto o processo de medição (também chamado contagem de pontos de função) é baseado em uma avaliação padronizada dos requisitos funcionais do usuário. Este procedimento padrão está descrito pelo IFPUG em seu Manual de Práticas de Contagem.
 As principais técnicas de estimativa de projetos de desenvolvimento de software assumem que o tamanho 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.
 Daí é 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 poderá ser usado para derivar produtividade, estimar esforço e custo do projeto de software.
 Para saber um pouco mais, o artigo "O que é um Ponto de Função?" escrito por Carol Dekkers é uma boa opção.
 No Brasil, alguns usam o termo original do inglês: FPA - Function Point Analisys. Outros usam termos parecidos como "Análise de Pontos por Função", "Análise por Pontos de Função", ou "Análise por Pontos por Função", que são traduções ligeiramente diferentes da tradução oficial - Análise de Pontos de Função.
2.Como os Pontos de Função São Contados?
 A contagem de Pontos de Função é efetuada com base na especificação do sistema, complementada por informações dos usuários e analistas.
 I. Componentes Considerados
 São contados os seguintes componentes, conforme definidos na Análise de Pontos de Função:
 Arquivos Lógicos Internos – Correspondem aos arquivos mantidos e utilizados pelo sistema sendo contado.
Arquivos de Interface Externa –  Correspondem aos arquivos utilizados pelo sistema sendo contado, porém mantidos por outros sistemas.
Entradas Externas –  Correspondem a transações cujo objetivo é a manutenção de arquivos ou a alteração do comportamento do sistema.
Consultas Externas –  Correspondem a transações cujo objetivo é a apresentação de informações aos usuários, provenientes dos arquivos, sem a geração de dados derivados, atualização de arquivos ou a utilização de cálculos/fórmulas.
Saídas Externas – Correspondem a transações cujo objetivo é a apresentação de informações aos usuários, não necessariamente proveniente de arquivos, podendo ocorrer a geração de dados derivados, atualização de arquivos e a utilização de cálculos/fórmulas.
II. Etapas do Processo de Contagem
Identificação 
Inicialmente os componentes são identificados, o que exige a aplicação de uma série de regras, específicas para cada um deles. Esta é a etapa mais difícil e que exige a maior prática do Analista de Pontos de Função – equivale, em dificuldade, à Modelagem de Dados.
Complexidade e Contribuição 
Após a identificação, a cada um dos componentes é atribuída a complexidade baixa, média ou alta, conforme o número de campos no caso dos arquivos, ou o número de campos e referências a arquivos no caso das transações. Com base na complexidade e em tabelas específicas, a cada componente é atribuída uma quantidade de pontos de função, denominada contribuição do componente à contagem.
Pontos de Função Não Ajustados 
A soma das contribuições de todos os componentes resulta na quantidade de pontos de função não ajustados.
Pontos de Função Ajustados 
Os pontos de função ajustados, resultado final da contagem, são obtidos a partir da aplicação de 14 fatores, denominados Características Gerais dos Sistemas (CGS), os quais alteram a contagem anterior em –35% a +35% do valor inicial não ajustado.
III. Aplicação da ContagemA contagem de pontos de função é realizada para medir o tamanho funcional de um sistema, independentemente de sua forma de implementação. Podem ser medidos:
Um projeto de sistema – neste caso, a contagem inclui tanto o sistema entregue ao final, quanto as modificações efetuadas ao longo do projeto e os programas destinados especificamente à implantação.
Uma alteração em sistema – neste caso, a contagem inclui os novos componentes incluídos, os alterados e, também, os removidos do sistema original.
Um sistema – esta contagem é efetuada exclusivamente sobre o sistema entregue aos usuários, medindo o tamanho do sistema propriamente dito.
A técnica utilizada na contagem é a mesma em cada caso; a diferença está no que é considerado em cada um.
3. Os Pontos de Função medem as horas necessárias ao desenvolvimento de um projeto?
Embora exista uma  forte relação entre o tamanho funcional de um software (medido em Pontos de Função) e o esforço gasto no seu desenvolvimento (medido em pessoas-hora), os Pontos de Função não medem diretamente o esforço de desenvolvimento. Nesse sentido, os Pontos de Função são semelhantes ao metro quadrado na construção civil: embora o metro quadrado influa consideravelmente no esforço de construção e no custo de um imóvel, outros fatores poderão contribuir tanto ou mais quanto o metro quadrado. Exemplos de fatores são a localização do imóvel, a idade, o material utilizado na construcão e acabamento, o prestígio do arquiteto, etc. Da mesma forma, dois sistemas podem ter a mesma medida em Pontos de Função e preços  totalmente diferentes. Por exemplo, um sistema pode ser monousuário, implementado em uma ferramenta como o Access; o outro pode ser uma aplicação web com várias camadas, envolvendo um mainframe e sofisticados dispositivos de segurança. Neste caso, certamente a quantidade de horas e o preço de cada um desses sistemas será completamente diferente. A conclusão é que o tamanho em Pontos de Função é apenas um dos fatores que influem sobre o esforço de desenvolvimento e sobre o custo de um sistema. Outros importantes fatores são a confiabilidade desejada para o software, a metodologia de desenvolvimento utilizada, o nível de testes requerido, a complexidade dos algoritmos, a dificuldade da plataforma computacional, o estilo de interface com o usuário, o grau de reutilização desejado, a capacidade e experiência da equipe, a disponibilidade de ferramentas de software adequadas e outros.
4. Quem inventou a APF? Como ela surgiu? 
A APF surgiu em 1979 como resultado de um projeto desenvolvido por Allan Albrecht, pesquisador da IBM. O objetivo era encontrar uma técnica de estimativa para esforço de desenvolvimento de software que fosse independente da linguagem de programação utilizada.
5. A técnica APF é propriedade de alguma empresa?
Não. Apesar de ter surgida na IBM, o resultado desse projeto foi aberto à toda comunidade de software em 1984.
6. O que é backfiring? 
Esse método consiste em derivar o número de pontos de função da aplicação a partir de seu tamanho físico, medido em linhas de código (LOC), utilizando um fator de conversão constante dependente da linguagem de programação. A idéia possui bastante apelo, uma vez que a contagem de linhas de código pode ser feita através de ferramentas automáticas e consequentemente o número de pontos de funçãopoderia ser derivado de imediato. Por exemplo, utilizando um fator de conversão de 80 LOC/PF para Java e tendo uma aplicação escrita com 8.000 linhas de código Java, chega-se a 1.000 pontos de função para essa mesma aplicação.
Entretanto, frequentemente, esta técnica apresenta erros consideráveis quando confrontada com uma contagem manual dos pontos de função de uma aplicação. Isto porque assume uma relação linear entre tamanho funcional (em pontos de função) e o tamanho físico do programa (em linhas de código), que são grandezas distintas. Outros aspecto é que não há consenso nas diferentes organizações que publicam estas relações. Os números apresentados podem divergir em até 100%! Quando se tem um cenário de sistema desenvolvido com um mix de linguagens de programação, a questão se complica mais ainda. A tabela seguinte apresenta um exemplo dessas variações para a linguagem COBOL.
	Fonte
	Fator de Conversão (COBOL)
	Quantitative Software Management
	77 LOC/PF
	Capers Jones
	107 LOC/PF
	David Consulting Group
	177 LOC/PF
 
Algumas das razões para explicar essa variação tão grande são: premissas distintas na definição do que é uma linha de código e bases de projetos com características muitos distintas. Daí a necessidade de calibrar esse fator de conversão para a realidade dos projetos desenvolvidos pela própria organização. Entretanto, para efetuar essa calibração, deve haver uma amostra representativa de projetos desenvolvidos pela organização em determinada linguagem e um profissional experiente e capacitado para saber interpretar os resultados e entender as razões de possíveis distorções para esse fator de conversão.
Devido a esses fatores, aplicar backfiring para obter um tamanho em pontos de função a partir de linhas de código é uma técnica arriscada e sujeita a uma grande margem de erro. Daí, o próprio IFPUG ressalta no seu FAQ, que ela até pode ser usada (com muita cautela) em sistemas legados, em que uma contagem manual de pontos é inviável na prática e a precisão não seja um fator crítico. Alguns profissionais advogam que backfiring é uma maneira rápida e barata de obter o tamanho em pontos de função do portfolio de aplicações de uma organização. Outros argumentam que o barato sai caro; é melhor investir na contagem manual dos pontos de função e ter confiabilidade desses dados, com compensação no longo prazo.
Por outro lado, muitos modelos de estimativa de software, como o COCOMO II, utilizam como dado primário de entrada de seu processo o tamanho em linhas de código. Nesses casos é muito comum realizar o inverso: obter o número de linhas de código a partir do tamanho em pontos de função. Isso porque nas fases iniciais de um projeto de software é mais fácil estimar ou medir o seu tamanho em pontos de função do que em linhas de código. Mesmo nesse caso, as considerações anteriores sobre backfiring continuam válidas.
7. O que vem a ser o padrão ISO/IEC de medição de tamanho funcional?
Com o objetivo de resolver as inconsistências existentes entre diversos métodos surgidos a partir do modelo da Análise de Pontos de Função proposto por Allan Albrecht e estabelecer um método mais rigoroso de medição de tamanho funcional, formou-se um grupo de trabalho denominado WG12 (Working Group 12), subordinado ao SC7 (Sub-Committee Seven) do JTC1 (Joint Technical Committee One) estabelecido pela ISO (International Organization for Standardization) em conjunto com o IEC (International Engineering Consortium).
Como resultado dos trabalhos do WG12 foi estabelecida a norma 14.143, que é dividida em cinco partes:
 14.143-1: Definição de Conceitos;
 14.143-2: Avaliação da Conformidade de Métodos de Medição de Software com Relação ao padrão ISO/IEC 14143-1;
 14.143-3: Verificação de um Método de Medição de Tamanho Funcional;
 14.143-4: Modelo de Referência para Medição Funcional de Tamanho;
 14.143-5: Determinação de Domínios Funcionais para uso com Medição de Tamanho Funcional.
 A norma ISO/IEC 14143 foi desenvolvida para garantir que todos os métodos de Medição de Tamanho Funcional sejam baseados em conceitos similares e que possam ser testados para assegurar que eles se comportam de maneira similar e da forma esperada por um método de medição, dependendo dos domínios funcionais a que se aplicam.
 Ao final do ano de 2002 a técnica de análise de pontos de função, conforme definida na versão 4.x do manual do IFPUG, foi aprovada (sob a norma 20.926) como um método de Medição de Tamanho Funcional aderente à norma ISO/IEC 14.143.
8. O que são Pontos por Caso de Uso (ou Use Case Points)? 
 Até há alguns anos atrás (início da década de 90) havia a falsa noção de que a APF não era adequada para medir sistemas orientados a objetos. Aqueles que compartilhavam desta noção, na prática desconheciam a APF.
 Com a disseminação da construção e projeto de sistemas orientados a objetos, houve também uma mudança na forma de se especificar e modelar os sistemas. A UML e os casos de uso rapidamente tornaram-se padrão na indústria de software.
 Dentro deste contexto, em 1993 Gustav Karner propôs em um trabalho acadêmico a metodologia dos Pontos por Caso de Uso (baseado na Análise de Pontos de Função) com o intuito de estimar recursos para projetos de software orientados a objeto desenvolvidos utilizando o processo Objectory.
 O processo de medição do PCU consiste resumidamente em:
 1 - Contar os atores e identificar sua complexidade;
 2 - Contar os casos de uso e identificar sua complexidade;
 3 - Calcular os PCUs não ajustados;
 4 - Determinar o fator de complexidade técnica;
 5 - Determinar o fator de complexidade ambiental;
 6 - Calcular os PCUs ajustados;
 Com o resultado desta medição e sabendo-se a produtividade média da organização para produzir um PCU, pode-se então estimar o esforço total para o projeto.
9. Quais as vantagens da APF sobre os Pontos por Caso de Uso (PCU)? 
 Em primeiro lugar é preciso desmistificar que somente a técnica do PCU é adequada para medir sistemas cujos requisitos foram expressos através de casos de usos. A APF pode ser utilizada normalmente para estes situações como também para medir sistemas cujos requisitos foram documentados utilizando outra metodologia.
 A seguir são listados algumas vantagens da APF sobre o PCU.
 1. O PCU somente pode ser aplicado em projetos de software cuja especificação tenha sido expressa por casos de uso. A medição da APF independe da forma como os requisitos do software foram expressos. Esta vantagem da APF foi citada pelo próprio Gustav Karner em seu trabalho original "Resource Estimation for Objectory Projects" (1993).
 2. Não é possível aplicar o PCU na medição de aplicações existentes cuja documentação esteja desatualizada ou sequer exista. A alternativa seria escrever os casos de uso destas aplicações para só então medí-las! Porém isto tornaria a medição inviável numa análise de custo x benefício. Com a APF é possível realizar a medição analisando-se a própria aplicação em uso.
 3. Não existe um padrão único para a escrita do caso de uso. Diferentes estilos na escrita dos caso de uso ou na sua granularidade podem levar a resultados diferentes na medição por PCU. A medição pela APF dos casos de uso de um sistema sempre chegará ao mesmo resultado independente do estilo de escrita dos casos de uso ou de sua granularidade pois a APF "quebra" o requisito no nível adequado para a medição usando o conceito de Processo Elementar.
 4. Devido ao processo de medição do PCU ser baseado em casos de uso, o método não pode ser empregado antes de concluída a análise de requisitos do projeto. Na maioria das vezes há a necessidade de se obter uma estimativa antes da finalização desta etapa. O processo de medição da APF também só pode ser empregado após o levantamento dos requisitos do projeto. Porém existem técnicas estimativas de tamanho em pontos de função que podem ser aplicadas com sucesso antes da análise de requisitos ser concluída. Um exemplo são as contagens indicativa e estimativa propostas pela NESMA. Vide o artigoContagem Antecipada de Pontos de Função.
 5. O método do PCU não contempla a medição de projetos de melhoria (manutenção) de software, somente projetos de desenvolvimento. A APF contempla a medição de projetos de desenvolvimento, projetos de melhoria e aplicações. Estes outros tipos de medição cumprem um importante papel em programas de métricas e na contratação do desenvolvimento de software.
 6. Não existe um grupo de usuários ou organização responsável pela padronização ou evolução do método PCU; e a bibliografia sobre o assunto é escassa. Não há um corpo de conhecimento oficial sobre PCU. Para a APF existe o IFPUG que é o responsável por manter o Manual de Práticas de Contagem - o corpo de conhecimento da APF, que é evoluído continuamente. E também há diversos fóruns de discussão sobre APF para a troca de experiências.
 7. O método PCU não é aderente à norma ISO/IEC 14143 que define um modelo para a medição funcional de software. A APF, conforme o manual do IFPUG, está padronizada sob a norma ISO/IEC 20926 como um método de medição funcional aderente à ISO/IEC 14.143.
 8. Não existe um programa de certificação de profissionais que conheçam a técnica do PCU e saibam aplicá-la de forma adequada. O IFPUG possui o programa de certificação CFPS para a APF.
 9. O fator ambiental inserido no PCU dificulta sua aplicação em programas de métricas de software e benchmarking entre organizações, pois torna o tamanho de um projeto variável; sem que sua funcionalidade sequer mude. Se um mesmo projeto for entregue a duas equipes distintas a contagem dos pontos por caso de uso deste projeto será também diferente em cada situação. Ou seja, o mesmo projeto tem dois tamanhos!
 10. A determinação dos fatores técnico e ambiental do PCU está sujeita a um certo grau de subjetividade que dificulta a consistência da aplicação do método em diferentes organizações. O fator de ajuste da APF também possui o mesmo problema, embora o IFPUG possua diretrizes específicas que ajudam a minimizar este impacto. No entanto o uso do fator de ajuste na APF é opcional e a contagem dos pontos de função não ajustados atualmente é um processo bem objetivo.
 Dentre as desvantagens citadas do PCU em relação à APF, algumas poderiam ser superadas com alguns ajustes simples. No entanto não há benefício adicional do PCU sobre a APF. Usar ambos os métodos também não compensaria o custo adicional de medição e o esforço para se treinar a equipe nos dois métodos.
 Embora a APF não seja uma técnica perfeita, há uma maturidade grande no mercado com relação ao seu uso e o IFPUG trabalha contínuamente para sua evolução.
10. O que é Feature Point? 
 O método Feature Point foi proposto por Capers Jones em 1986; mesmo ano de fundação do IFPUG e antes da primeira versão do Manual de Práticas de Contagem - publicado em 1988. O objetivo do método era o de medir com maior precisão softwares com grande complexidade algorítmica.
 A idéia por trás do método era simples: acrescentar à APF mais uma dimensão além dos dados e transações - os algoritmos. No entanto a falta de uma taxonomia para classificar algoritmos dificultou a aplicação do método. Além disto o próprio conceito de algoritmo deveria ser melhor elaborado. Qual a granularidade que se deve utilizar para identificar o algoritmo?
 Em seu livro "Applied Software Measurent" (segunda edição - 1996), Capers Jones ainda destacava que o método era experimental, isto dez anos após a proposta inicial. E até hoje na página da SPR - Software Productivity Research (www.spr.com), empresa fundada por ele, o método também é citado como experimental.
 Ainda no livro, o autor também já reconhecia que os conceitos da APF tinham evoluído bastante, permitindo sua utilização também nesses domínios de problemas (softwares com complexidade algorítmica) com razoável sucesso.
Em resumo, embora o método Feature Points ainda seja eventualmente citado em alguns trabalhos acadêmicos, o mercado não aderiu a esta proposta.
Fonte: FATTO Consultoria e Sistemas