Métricas de Software - Definições

Prévia do material em texto

FAQ - Perguntas Frequentes
 
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.
Voltar ao Topo
2.Como os Pontos de Função São Contados?
PERNAMBUCO GOVERNO SECRETARIAS PROGRAMAS NOTÍCIAS RÁDIO SEI EXPRESSO CIDADÃO VIRTUAL ACESSO À INFORMAÇÃO
Métricas de Software
Principal
Comunidade de Métricas
Análise de Pontos por Função
Notícias
Agenda
Fale Conosco
Mapa do Site
 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.
Voltar ao Topo
3. Os Pontos de Função medem as horas necessárias ao desenvolvimento de um projeto?
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.
Voltar ao Topo
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.
Voltar ao Topo
5. A técnica APF é propriedade de alguma empresa?
Não. Apesar de ter surgida na IBM, o resultadodesse projeto foi aberto à toda comunidade de software
em 1984.
Voltar ao Topo
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ção poderia 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
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.
Voltar ao Topo
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.
Voltar ao Topo
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.
Voltar ao Topo
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 poisa 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 artigo Contagem 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.
Voltar ao Topo
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
Voltar ao Topo
© Copyright 2013 - Métricas de Softw are