Esta lista de perguntas e respostas sobre a Análise de Pontos de Função foi elaborada a
partir das questões surgidas nos treinamentos ministrados pela FATTO, nos serviços de
consultoria prestados e também nas listas de discussões das quais seus profissionais
participam.
Entendemos que essa lista seja útil para nossos clientes e também para todos os
visitantes de nosso site com interesse em APF.
Pretendemos revisar e atualizar esta lista com novas questões periodicamente. Você
pode dar a sua contribuição ou enviar a sua questão através do
Fale Conosco do nosso site.
Em algumas questões poderão ser citados termos técnicos da APF, e se o leitor
precisar de mais esclarecimento sobre algum termo, sugerimos que consulte
o mesmo em nosso
glossário.
1. O que é a Análise de Pontos de Função? E o que é Ponto de Função?
2. Quem inventou a APF? Como ela surgiu?
3. A técnica APF é propriedade de alguma empresa?
4. Quais os benefícios da Análise de Pontos de Função?
5. É necessário ser desenvolvedor de software (analista de sistemas, programador, etc) para aprender ou usar a APF?
6. Existe algum organismo responsável pela padronização da técnica?
7. Houve alguma evolução na técnica da APF após sua criação?
8. O que é a certificação CFPS do IFPUG?
9. Quais as dicas para o exame CFPS do IFPUG?
10. Qual o custo para se obter e manter a certificação CFPS do IFPUG?
11. Quem usa APF no Brasil e no mundo?
12. É possível utilizar a APF em um projeto Orientado a Objeto?
13. Onde posso obter mais informações sobre APF?
14. Qual o preço de um ponto de função?
15. É possível aplicar a APF em tarefas que não são organizadas como projetos?
16. Duas funções, significativamente distintas no esforço de implementação, são dimensionadas com o mesmo número de pontos de função. Tal constatação não tira muito do valor da APF?
17. Por que não existem ferramentas para a contagem automática dos pontos de função de um sistema?
18. O que é backfiring?
19. O que vem a ser o padrão ISO/IEC de medição de tamanho funcional?
20. Além dos pontos de função do IFPUG existem outros métodos padrão de medição funcional?
21. Quais os primeiros passos para a aplicação da APF em minha organização?
22. Quais as orientações iniciais para a aplicação da APF em estimativas de projetos de software?
23. Quais as orientações iniciais para a aplicação da APF em contratos de desenvolvimento de sistemas?
24. Quais as orientações gerais para a utilização da APF no processo de benchmarking da produtividade no desenvolvimento de software?
25. A estimativa de esforço (em horas) a partir do tamanho (em pontos de função) é relativa apenas às atividades de construção ou de todo o ciclo de vida do projeto de software?
26. Em que situações pode ser vantajosa a terceirização da contagem de pontos de função?
27. O que são Pontos por Caso de Uso (ou Use Case Points)?
28. Quais as vantagens da APF sobre os Pontos por Caso de Uso (PCU)?
29. O que é Feature Point?
30. A APF pode ser utilizada para produzir estimativas para os testes de aceitação e de sistema?
31. Qual o conceito do termo "Usuário" para a APF?
32. Como a APF define o termo "Aplicação"?
33. Como a APF define o termo "Melhoria"?
34. Quais os objetivos do Manual de Práticas de Contagem do IFPUG?
35. Como é o processo de contagem de pontos de função?
36. Qual indicador de produtividade (pontos de função / homem-mês) ou taxa de entrega (horas / ponto de função) deve ser utilizado para estimar o esforço de projetos de software?
37. Onde é possível obter o Manual de Práticas de Contagem do IFPUG?
38. Quantos pontos de função é possível se contar em um dia?
39. Quais as ferramentas indicadas para apoiar e/ou automatizar (ainda que parcialmente) o uso da APF?
40. Existe alguma relação entre o tamanho em pontos de função de um software e o hardware necessário à sua execução?
41. É possível aplicar a APF para projetos de manutenção de sistemas?
42. Em que momento do ciclo de vida do projeto de software é possível contar pontos de função?
43. A APF é uma técnica de gestão de projetos de software?
44. A APF onera o esforço de um projeto de software?
45. Quais atividades são compreendidas na estimativa de esforço (usando pontos de função) de um projeto de software?
46. Quais as principais causas para erros em uma contagem de pontos de função?
47. Que documentos são necessários para uma contagem de pontos de função?
48. Qual a importância dos requisitos do software para a APF?
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.
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.
3. 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.
4. Quais os benefícios da Análise de Pontos de Função?
Pode-se destacar vários benefícios da aplicação da análise de
pontos de função nas organizações:
- Uma ferramenta para determinar o tamanho de um pacote adquirido,
através da contagem de todas as funções incluídas.
- Provê auxílio aos usuários na determinação dos benefícios de um
pacote para sua organização, através da contagem das funções que
especificamente correspondem aos seus requisitos. Ao avaliar o custo
do pacote, o tamanho das funções que serão efetivamente utilizadas,
a produtividade e o custo da própria equipe é possível realizar uma
análise do tipo "make or buy".
- Suporta a análise de produtividade e qualidade, seja diretamente ou
em conjunto com outras métricas como esforço, defeitos e custo. Porém
se o processo de desenvolvimento da organização for caótico (cada
projeto é desenvolvido de forma diferente), mesmo que a contagem dos
pontos de função do projeto e o registro do esforço tenham sido feitos
de forma correta, a análise da produtividade entre os projetos será
prejudicada.
- Apóia o gerenciamento de escopo de projetos. Um desafio de todo
gerente de projetos é controlar o "scope creep", ou aumento de seu
escopo. Ao realizar estimativas e medições dos pontos de função do
projeto em cada fase do seu ciclo de vida é possível determinar se os
requisitos funcionais cresceram ou diminuíram; e se esta variação
corresponde a novos requisitos ou a requisitos já existentes e que
foram apenas mais detalhados.
- Complementa o gerenciamento dos requisitos ao auxiliar na verificação
da solidez e completeza dos requisitos especificados. O processo de
contagem de pontos de função favorece uma análise sistemática e
estruturada da especificação de requisitos e traz benefícios
semelhantes a uma revisão em pares do mesmo.
- Um meio de estimar custo e recursos para o desenvolvimento e
manutenção de software. Através da realização de uma contagem ou
estimativa de pontos de função no início do ciclo de vida de um
projeto de software, é possível determinar seu tamanho funcional.
Esta medida pode ser então utilizada como entrada para diversos modelos
de estimativa de esforço, prazo e custo.
- Uma ferramenta para fundamentar a negociação de contratos. Pode-se
utilizar pontos de função para gerar diversos indicadores de níveis de
serviço (SLA - "Service Level Agreement") em contratos de desenvolvimento
e manutenção de sistemas. Além disso permite o estabelecimento de
contratos a preço unitário - pontos de função - onde a unidade
representa um bem tangível para o cliente. Esta modalidade possibilita
uma melhor distribuição de riscos entre o cliente e o fornecedor.
- Um fator de normalização para comparação de software ou para a
comparação da produtividade na utilização de diferentes técnicas.
Diversas organizações, como o ISBSG, disponibilizam um repositório
de dados de projetos de software que permitem a realização de
benchmarking com projetos similares do mercado.
Não. A grande vantagem da APF é que ela é baseada na VISÃO DO USUÁRIO, permitindo que seus conceitos possam ser compreendidos tanto pelo desenvolvedor quanto pelo usuário. O objetivo da técnica é medir a funcionalidade que o software fornece ao usuário independente da tecnologia usada para a implementação do mesmo. Essa medição é baseada somente nos requisitos que o software deve atender.
6. Existe algum organismo responsável pela padronização da técnica?
O padrão reconhecido pela indústria de software para APF é o Manual de Práticas de Contagem
de Pontos de Função (CPM - Counting Practices Manual) mantido pelo
IFPUG - International Function Point Users Group.
O IFPUG é uma entidade sem fins lucrativos composta por pessoas e empresas de diversos
países cuja finalidade é promover um melhor gerenciamento dos processos de desenvolvimento e
manutenção de software através do uso da APF.
O BFPUG - Brazilian Function Point Users Group
é a representação oficial do IFPUG no Brasil.
Sim, desde a publicação da proposta da APF em 1979 diversos refinamentos foram incorporados à técnica
ao longo dos anos. E este processo ainda continua. Porém a essência da
técnica mudou muito pouco. Isto resulta do fato da técnica ser orientada à medir a funcionalidade
que um software fornece ao usuário, independente da plataforma tecnológica na qual o software rodará,
metodologia de desenvolvimento ou linguagem de programação usada para sua construção.
Após a fundação do IFPUG em 1986, criou-se uma sistemática consistente para
evolução da APF. O IFPUG possui um comitê responsável pela edição e atualização do Manual de Práticas de
Contagem, que atualmente encontra-se na versão 4.3, versão esta publicada em Janeiro de 2010.
Não há uma periodicidade definida para que o IFPUG publique atualizações do seu manual. E as atualizações
não visam mudanças radicais. Elas tem o intuito de fornecer mais esclarecimentos em relação à definições
e regras de contagem; melhorando assim a consistência das medições e reduzindo a subjetividade nas
interpretações.
O programa de certificação CFPS - Certified Function Point Specialist - tem por objetivo reconhecer formalmente os profissionais capazes de realizar contagens de pontos de função precisas e consistentes e que também conheçam as práticas de contagem mais recentes do IFPUG.
Para ser certificado, o profissional deve ser aprovado em um exame elaborado pelo IFPUG cuja taxa de acerto mínima deve ser
de 90%. Este exame consiste em aproximadamente 150 questões de múltipla escolha baseadas no seu Manual de Práticas de Contagem. A duração da prova é de 3 horas. É um exame de difícil aprovação em função do tempo disponível e também da exigência da taxa de acerto elevada, mas infelizmente o IFPUG não divulga nenhuma informação relativa à taxa de aprovação no exame.
O prazo de validade da certificação é de três anos, após o qual o profissional deve submeter-se novamente ao exame para renovação da certificação
ou participar do programa de extensão de certificação (independente de ter havido alguma mudança na versão do manual). Este programa
(ainda não implementado no Brasil) permite que prorrogue-se em dois anos a validade da certificação através da acumulação de créditos em diversas atividades como: realizar contagens de pontos de função, ministrar cursos, escrever artigos ou livros, participar como voluntário de algum dos comitês do IFPUG.
Entretanto esta renovação somente pode ser realizada por duas vezes consecutivas, após as quais o profissional deverá obrigatoriamente submeter-se ao exame para renovar sua certificação.
Até o início de 2008 o exame de certificação era realizado em papel, com correção manual, sendo ministrado no Brasil duas vezes por ano, ao final de cada semestre, com a promoção do BFPUG. A partir de Julho de 2008 o exame foi automatizado e pode ser aplicado por qualquer centro credenciado pela Prometric no mundo, na data agendada pelo interessado. Há a opção do exame em inglês e também em português. Para buscar a lista de centros autorizados a ministrar o exame CFPS, acesse http://www.prometric.com/IFPUG.
Não há a exigência de formação superior, comprovação de experiência com APF ou ter assistido qualquer curso para tentar a certificação. O único pré-requisito para prestar o exame CFPS é ser filiado ao IFPUG. Porém, sem uma preparação adequada, a chance de aprovação é pequena. Mesmo para o profissional que está fazendo o exame para renovar a certificação, é necessária uma preparação com estudo e exercícios. O nosso curso
Preparação para o Exame CFPS foi elaborado especificamente para apoiar o candidato ao exame do IFPUG em sua jornada de preparação para a certificação (ou recertificação).
Uma das dúvidas do candidato à certificação é com relação ao tempo de preparação ideal para a prova.
Não há um prazo igual para todos; a variação é muito grande de indivíduo para indivíduo. Se no dia
a dia o profissional trabalha usando a APF, certamente precisará de menos tempo que outro que o faz
apenas de forma esporádica. Em geral, um prazo de um a três meses de preparação costuma ser suficiente.
Com relação ao material de estudo, o texto de referência fundamental é o próprio Manual de Práticas de
Contagem, no qual a prova é toda baseada. Não é preciso chegar ao exagero de decorá-lo; mas é importante
que ele seja lido atentamente por completo e que não fiquem dúvidas. Algumas questões de prova são
baseadas nos seus vários exemplos. Embora todo o conteúdo da prova seja extraído do Manual, este não
aborda nada referente ao processo de certificação. Daí ser importante buscar outras fontes de estudo.
O melhor indicador de preparação do candidato são os exercícios simulados da prova.
Uma alternativa interessante (e gratuita) de manter o assunto de pontos de função sempre em mente durante
o período de preparação para o exame é participar dos fóruns de discussão do
IFPUG
, do
BFPUG
, do
Grupo de leitores do livro "Análise de Pontos de Função: Medição, Estimativas e
Gerenciamento de Projetos de Software".
O livro
Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software
contém um capítulo dedicado ao processo de certificação do IFPUG com dicas e apresentação do
processo de certificação e também um exame simulado.
O curso da FATTO Preparação para o Exame CFPS oferece mais de 1.000 questões ao
estilo da prova como recurso para o candidato além do apoio do instrutor até a data do exame. Na versão
de
Demonstração do Curso de Preparação para o Exame CFPS
é possível realizar alguns exercícios e acessar outros recursos relacionados ao exame
de forma gratuita, inclusive um micro-simulado com 30 questões.
A partir de 2004 o IFPUG alterou as regras do seu programa de certificação, e desde então somente pessoas filiadas
podem se inscrever para o exame CFPS. Além disto, aqueles que foram aprovados no exame devem manter sua filiação
regular por todo o período de validade da certificação sob pena da mesma ser cancelada. Portanto, os custos para
a certificação devem ser analisados conjuntamente com os custos da filiação ao IFPUG.
Com relação aos custos de filiação, todos os detalhes podem ser
obtidos diretamente no site do IFPUG:
https://www.ifpug.org/membership/dues.htm
Existem várias modalidades de filiação, as mais comuns são:
Individual - US$185,00
Corporativa (uma única região geográfica) - US$625,00
Corporativa Mundial - US$1.850,00
Em todas elas existe um custo adicional no primeiro ano de US$75,00 referente ao envio de material do IFPUG.
O manual de práticas de contagem, que é a referência para o exame de certificação, é disponibilizado para download
gratuito somente para os filiados.
Para a empresa que deseja certificar a partir de 3 profissionais, a filiação corporativa pode ser a mais econômica.
Para um ou dois empregados candidatos à certificação, a melhor opção é a filiação individual desses profissionais.
Cabe ressaltar que, para que os profissionais possam usufruir das condições de filiação da empresa, a comprovação
da existência de vínculo dele para com a empresa deve ser via CLT ou contrato social.
O custo para inscrição no exame é de US$250,00 por pessoa. É importante destacar que pode haver também despesas de viagem
para a cidade de realização do exame (qualquer uma que possua um centro autorizado da Prometric) caso o participante
não resida em nenhuma dessas cidades.
Como o custo da certificação é significativo, é altamente recomendável que o participante tenha
uma preparação para o exame adequada, com tempo disponível para estudo, participação em curso
preparatório para certificação e aquisição de material adicional de estudo. Logo, é importante
considerar também estes outros custos.
Ciente de todos estes custos, a FATTO oferece o seu curso de
Preparação para Exame de Certificação do IFPUG
com os seguintes benefícios:
- Em caso de não aprovação, há a garantia exclusiva de assistir gratuitamente outra edição do curso;
- Desconto de 80% para ex-aluno que precisa renovar a sua certificação prestando novo exame ou para ex-aluno que não chegou a prestar o exame;
- Único curso no mercado na modalidade de ensino à distância (e também com aulas presenciais em Brasília e São Paulo),
confira nosso calendário;
- Instrutores certificados pelo IFPUG e com vários anos de experiência no uso da APF;
- Possibilidade de realização de turmas fechadas em empresas com qualquer quantidade de alunos e nas datas e horários mais convenientes.
No Brasil pode-se citar empresas como Accenture, Bradesco, Companhia Vale do Rio Doce,
Caixa Econômica Federal, Correios, CPM, Datamec, Datasul, DBA, EDS, IBM, Petrobras, Politec,
Tata, Unibanco, Unisys, Xerox, dentre outras.
O IFPUG possui filiados de mais de 40 países; sendo que o uso da APF é mais intenso na
Alemanha, Austrália, Brasil, Canadá, Coréia, Estados Unidos, Índia, Inglaterra, Itália e Holanda.
Exemplos de outras empresas no mundo que usam a APF: IBM, Unisys, Xerox, EDS, Citigroup,
Tata, Lockheed Martin-EIS, Booz Allen & Hamilton, Nielsen Media Research, Bank of Canada,
Ralston Purina Co., Northrop Grumman Corp, Samsung SDS Co Ltd, BASF Corporation, Accenture,
Pepsi Co, Compuware, Pricewaterhouse Cooper.
Sim. APF é uma técnica independente da tecnologia utilizada para modelar ou implementar um
software. Portanto um software terá o mesmo tamanho em pontos de função quer venha a ser
desenvolvido utilizando tecnologia OO ou uma outra abordagem.
O que poderá diferenciar as duas abordagens é que no projeto OO a produtividade (hora/PF)
poderá ser melhor devido ao reuso. Fazendo uma analogia com a construção
civil: pode-se construir uma casa de 100m2 da maneira convencional ou utilizando módulos
pré-fabricados. Em ambos os casos o tamanho da casa será o mesmo, apenas o tempo de
construção ou o custo poderá variar.
Você pode entrar em contato com a FATTO diretamente através do Fale Conosco do nosso site,
será um prazer poder ajudá-lo.
Há também na seção Links do nosso site um bom conjunto de referências para diversas
organizações que desenvolvem pesquisa, prestam serviços ou disponibilizam recursos como
artigos e referências bibliográficas sobre APF. O site do BFPUG e o do IFPUG são os
pontos de partida mais indicados.
O valor R$/PF irá variar de acordo com o
trabalho exigido para a entrega das funcionalidades do software de acordo com o padrão
técnico e de qualidade solicitado pelo cliente, como também conforme a quantidade
de entregáveis (artefatos, documentos, modelos, etc) exigidos pelo cliente.
Em resumo, tudo aquilo que afeta custo de forma significativa mas que não tem relação
direta com o tamanho medido pela APF acaba sendo computado no preço do ponto de função.
Exemplo 1: ao se contratar uma empresa apenas para o trabalho de codificação e testes
de um sistema espera-se que o preço do ponto de função seja inferior ao caso
da contratação da mesma empresa para a realização de todo o ciclo de desenvolvimento do
sistema, desde o levantamento de requisitos até a implantação.
Exemplo 2: o preço do ponto de função para a entrega apenas do software certamente é
inferior ao preço do ponto de função onde, além do software, devem ser entregues vários
documentos (subprodutos) como: modelos da UML, manual de usuário, ajuda on-line, protótipos,
casos e planos de testes, etc.
Exemplo 3: atualmente a gama de tecnologias disponíveis para desenvolvimento de sistemas é enorme,
cada uma delas podendo influenciar diretamente na produtividade (tanto positivamente quanto negativamente)
do trabalho a ser realizado. Sendo assim é bastante comum no mercado a diferenciação do R$/PF de acordo
com a plataforma tecnológica (mainframe, web, cliente-servidor, etc) e/ou linguagem de programação
(cobol, C, java, .net, etc).
Exemplo 4: A APF, segundo o padrão IFPUG, mede manutenções desconsiderando o tamanho da manutenção que
a função sofrerá. Geralmente o esforço para se manter uma função costuma ser inferior ao de se desenvolvê-la.
Sendo assim, pode haver diferenciação de preço do ponto de função em projetos de melhoria para funcionalidades novas, alteradas e excluídas.
Em resumo, não existe um preço único para ponto de função bem como também não há
atualmente uma tabela de preços disponível publicamente onde se possa consultar
valores para o preço do ponto de função. Até mesmo porque esta é uma informação considerada reservada
ou estratégica para muitas organizações. Porém é possível obter informações de preço
dos contratos governamentais através de uma pesquisa nas licitações ocorridas, no diário oficial ou
diretamente com o órgão do governo.
Outra possibilidade para se obter essa tabela de preços é recorrer às organizações que mantém base
histórica de projetos de software (exemplo: ISBG - www.isbsg.or) e efetuar uma conversão dos indicadores
de taxa de entrega (H/PF) para preço (R$/PF). Porém mesmo que se consiga obter uma tabela de valores R$/PF, a variação dos números é tão significativa que facilmente se encontra uma faixa de valores cuja variação entre o mínimo e o máximo pode ser de até 10 vezes, por exemplo de R$100/PF a R$1.000/PF.
Para obter uma informação mais realista do preço (ou custo) do PF é melhor buscar isto internamente nos projetos já realizados.
Para projetos já concluídos uma informação certamente disponível é o quanto se pagou ou
se cobrou por cada projeto e quais atividades estavam compreendidas. Caso o tamanho funcional (PF) dos projetos não esteja disponível, pode-se obtê-lo rapidamente através de uma medição ou de uma estimativa; basta analisar seus requisitos.
Tendo o preço do projeto e o seu tamanho em pontos de função, obtém-se o seu preço
por ponto de função (R$/PF). No entanto é provável que sua organização empreenda projetos de diferentes tipos. Neste caso deve-se proceder a análise do R$/PF para cada categoria de projetos, pois dificilmente um preço único será representativo para projetos de tipos distintos.
Normalmente este tipo de trabalho envolve um escopo muito reduzido. Como conseqüência é difícil estabelecer uma relação entre o tamanho funcional e outras métricas fundamentais como esforço, prazo e custo. Entretanto deve-se lembrar que APF não é simplesmente uma ferramenta para geração de estimativas, utilizada em planejamento de projetos. A natureza do trabalho envolvido na pergunta caracteriza-se não como um projeto mas como uma operação contínua.
Tome-se como exemplo a manutenção de sistemas com esforço estimado em até 200 horas. Isoladamente o dimensionamento das ordens de serviço que representam os requisitos (nem sempre funcionais) objeto de manutenção pode não apresentar uma relação linear com o esforço envolvido em sua realização. Contudo, levando-se em conta o universo compreendido pelo conjunto destas solicitações em determinado período de tempo maior, pode-se chegar a conclusões diferentes.
Por exemplo, determinada solicitação de manutenção não envolvia o acréscimo, modificação ou exclusão de funcionalidades de determinado sistema. Neste caso sem dúvida é inútil saber que o tamanho funcional da manutenção será de zero pontos de função. Mas o sistema em que se dá a manutenção tem um tamanho funcional. Pode-se acompanhar a evolução da quantidade de horas de manutenção por ponto de função deste sistema. Tal tendência ajuda a avaliar se está na hora de substituir este sistema por um novo.
Suponha que nesta organização haja um processo onde, após a ordem de serviço ter sido atendida pela equipe de manutenção, o produto passe por um processo de homologação. O conjunto de funcionalidades em homologação pode ser dimensionado em termos de pontos de função. Da mesma forma pode ser documentada a quantidade de defeitos identificadas no processo. O acompanhamento do inter-relacionamento destas duas métricas - Pontos de Função e Defeitos - durante um período de tempo pode trazer a tona problemas no processo de manutenção. Com base nessa tendência é possível empreender ações para diminuir esta relação.
O Ponto de Função mede o tamanho funcional do software e não o esforço envolvido em sua concepção e construção. Quanto maior a linearidade encontrada entre o tamanho funcional e este esforço, ou seja, a produtividade, maior o valor prático da medida obtida. Quanto mais linear for esta relação, mais facilmente podem ser extrapoladas outras medidas a partir do tamanho funcional, como o custo e o esforço por exemplo.
Se observarmos em um nível micro, na avaliação do dimensionamento de duas transações pontuais, sem dúvida o potencial de desvio na produtividade auferida é alto, mas na medida que expandimos esta amostragem percebemos que as situações extremas se compensam e, em média, podemos observar uma maior linearidade na relação entre o esforço e o tamanho funcional.
Vamos pensar em algumas métricas alternativas ao ponto de função avaliando o impacto destas considerações sobre estas métricas, por exemplo, Linhas de Código. Na organização como um todo, ou mesmo em um projeto específico, também existem situações em que a contagem do número de linhas de código não estará diretamente relacionada ao esforço envolvido na especificação, documentação e testes dos mesmos. Ou seja, existem dois projetos, com diferentes requisitos de qualidade ou maior demanda na especificação, onde apesar de um deles ser mais "complexo" e requerer maior esforço de desenvolvimento o software resultante possui menos linhas de código que o outro. Isto sem falar nas várias outras limitações inerentes à métrica de LOC.
Existem diversos softwares que, a partir do modelo de um programa ou de
seu código fonte calculam seu tamanho em pontos de função. Entretanto
comparações entre os números apresentados por diferentes ferramentas
para um mesmo sistema não raro apresentam uma variação inaceitável.
Estes números por sua vez, também freqüentemente diferem em muito de
uma contagem manual.
A resposta para essa variação está em como estas ferramentas calculam o
número de pontos de função. Algumas se baseiam nos arquivos, telas,
relatórios e outros elementos para derivar um número. Embora muitas vezes
haja uma relação direta entre estes objetos e as funções de dados e
transações da APF, deve ser lembrado que a técnica mede apenas as funções
lógicas do sistema. E estas ferramentas têm dificuldades em diferenciar
funções lógicas de funções físicas. Por exemplo, nem todo arquivo ou tabela
de um programa corresponde a um arquivo lógico interno ou arquivo de
interface externa. Ou ainda, um processo elementar pode estar implementado
através de várias telas. Para que a medição fosse feita corretamente, o software
teria que ter inteligência o suficiente para fazer este discernimento. Ou seja,
este software teria que ter a habilidade de ler o programa e interpretar os
requisitos do usuário. Ainda não há software com esta inteligência artificial.
Outras ferramentas se baseiam na técnica de backfiring, que consiste em derivar o
número de pontos de função a partir da quantidade de linhas de código do programa,
baseado numa relação pré-estabelecida entre LOC e PF. Contudo esta é uma técnica
que tem sido muito criticada e cuja aplicação é restrita.
Existem sim softwares de apoio ao processo de contagem de pontos de função que
automatizam parte do processo, porém a decisão e análise do que deve ser considerado,
continua sendo responsabilidade de um usuário humano que entra com os dados e não do software.
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 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.
19. 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.
Sim, existem três outros métodos padrão de medição funcional:
NESMA - A associação de métricas da Holanda mantém seu próprio manual de
contagem, atualmente na versão 2.0, cuja primeira versão em 1990 foi
baseada no manual do IFPUG. Utiliza a mesma filosofia, conceitos, termos
e regras do IFPUG, com algumas diretrizes diferentes. A medição de um
projeto de desenvolvimento ou de uma aplicação produz resultados bem
próximos tanto na abordagem do IFPUG quanto da NESMA. Entretanto ambas
organizações possuem abordagens distintas para a aplicação da análise de
pontos de função em projetos de melhoria de software.
Mark II - foi formulado por Charles Symons em meados da década de 80.
Sua disseminação foi dificultada inicialmente pelo fato do método ser
propriedade da consultoria KPMG por vários anos. Atualmente é um método
de domínio público mantido pela associação de métricas do Reino Unido -
UKSMA. É um método de aplicação restrita ao Reino Unido.
COSMIC-FFP - Em 1997 um grupo de pesquisadores da Universidade de Quebec
desenvolveu um novo método de medição funcional para sistemas de tempo
real, denominado Full Function Points (FFP). Em 1998 um grupo de
especialistas em medição de software constituiu o COSMIC (Common
Software Measurement International Consortium) com o objetivo de
desenvolver um novo método de medição de tamanho funcional baseado nas
melhores características dos métodos existentes e que incorporasse novas
idéias. Este novo método proposto em 2000, batizado de COSMIC-FFP, na
prática foi um refinamento do método FFP. Ainda não é uma técnica tão
disseminada no mundo quanto à do IFPUG, porém observa-se que muita
pesquisa está sendo realizada sobre este método. Pode-se dizer que o
mercado acompanha atento seus passos.
O primeiro passo é identificar claramente quais os objetivos da
organização. A APF pode ser empregada com várias finalidades:
estimativas de projetos de software, unidade de medição de contratos,
apoio ao controle de qualidade e produtividade, benchmarking e programa de métricas.
Cada enfoque específico possui suas particularidades; entretanto
existem aspectos comuns a todos eles, destacados a seguir.
1. Conquiste o apoio da direção da organização. Tenha em mente
que os resultados do emprego da APF na organização nem sempre serão
imediatos e que o sucesso de sua utilização dependerá de dedicação e do
emprego de recursos humanos e financeiros, assim como em qualquer
programa que objetive a melhoria de processos.
2. Aproveite as oportunidades já existentes na organização e que possam ter
alguns objetivos comuns. Exemplos destas iniciativas são: ISO, Six-Sigma, CMM,
PMI, Balanced Scorecard. Pegando carona nestas iniciativas e sabendo relacionar
(e mostrar para os patrocinadores) como a APF pode contribuir com alguns de seus
objetivos a aceitação fica facilitada.
3. Capacite-se. Conhecer corretamente a técnica é fundamental.
É surpreendente o número de casos que presenciamos em que a APF é
aplicada incorretamente, e que invariavelmente terminam em insucesso.
A referência oficial da técnica é o manual do IFPUG - o CPM (Counting
Practices Manual).
Ações interessantes neste sentido podem ser:
- Contratar uma turma fechada de um curso para toda equipe envolvida,
podendo assim adequar a carga horária ou ementa do curso com os objetivos
do processo e a realidade da organização. Neste caso a FATTO costuma realizar
um pacote de serviços com duração de uma semana: dois dias para ministrar
o curso Capacitação em Análise de Pontos de Função
e três dias para consultoria no início do processo e mentoring na aplicação
da técnica em casos práticos da organização.
- Inscrever pessoas chave no processo em cursos abertos sobre a técnica
de pontos de função. A FATTO ministra cursos abertos regularmente em
várias cidades no Brasil, consulte o nosso
calendário de cursos
para mais informações.
4. Estabeleça objetivos iniciais modestos. Comece com um projeto
piloto em um sistema simples. Avalie os resultados, efetue as correções
necessárias, revise os objetivos e siga em frente.
5. Esteja ciente das limitações da técnica. Existem domínios de
problema em que a APF não é indicada. Por exemplo, em sistemas de
otimização, a técnica não é adequada para medir as partes com alta
complexidade algorítmica.
6. Na dúvida, faça a analogia com o metro quadrado. Em geral, isto
é suficiente para resolver a questão.
7. Busque ajuda se necessário. Uma consultoria externa pode evitar
"cabeçadas desnecessárias" e agilizar o processo, trazendo experiências
e ajudando a corrigir rumos.
8. Não compare laranjas com bananas. As comparações devem ser feitas
apenas entre projetos que tenham similaridades (processo de
desenvolvimento, plataforma tecnológica, área de negócio, etc).
Além das considerações gerais apresentadas na pergunta anterior,
a seguir são apresentadas algumas orientações específicas para o uso
de pontos de função em estimativas.
Embora alguns autores citem o uso de pontos de função para derivar
diretamente estimativas iniciais de prazo, defeitos e tamanho de
equipe, o mais comum é o uso para estimativas de esforço (geralmente
quantidade de horas).
O processo para estimar esforço é muito simples: dada uma produtividade
(horas/ponto de função) em determinado ambiente de desenvolvimento,
basta multiplicá-la pelo tamanho funcional do software para se obter a
estimativa desejada.
Entretanto, a questão chave é: qual produtividade empregar? Muitos
utilizam os indicadores de mercado publicados por diversas
organizações. Porém muitas dessas pessoas ficam frustradas com o
resultado obtido.
A resposta é que não há números mágicos. A produtividade a ser empregada
é a própria de cada organização e não uma média do mercado. Ela deve
refletir a realidade do processo de desenvolvimento da organização em
determinado contexto: ferramenta de desenvolvimento, área de negócio ou
plataforma tecnológica.
Para obter seus próprios números, a organização pode recorrer aos dados
de projetos anteriores e recuperar suas informações de esforço e tamanho
em pontos de função. Agrupando os projetos similares, é possível obter
um indicador de produtividade confiável.
Além das considerações gerais apresentadas pergunta
21, são apresentadas
a seguir algumas orientações específicas para o uso de pontos de função
nos três principais modelos de
contratação utilizados: Homem/Hora, Preço Global Fixo e Preço Unitário.
Caso a modalidade de contratação utilizada seja homem/hora, onde a
remuneração do fornecedor não é baseada nos resultados apresentados,
mas sim na quantidade de horas de trabalho apuradas num período,
pode-se utilizar a APF para, por exemplo, monitorar a produtividade
da equipe. Para tanto, basta que os dados de resultados (pontos
de função) sejam medidos juntamente com os dados de esforço (horas) e
que sejam realizadas avaliações que relacionem ambas as informações.
Quando a contratação é baseada em preço global fixo, a APF pode ser
utilizada como um fator de normalização de preço, visando garantir
que o valor cobrado por funcionalidades adicionais não previstas ou
durante a fase de manutenção, seja compatível com o valor cobrado no
momento da contratação do serviço.
Mede-se o tamanho do projeto em pontos de função e, a partir do valor
total cobrado pelo fornecedor para o projeto, calcula-se o valor do
ponto de função. As novas propostas são medidas quanto ao seu tamanho
e, então aplica-se o valor do ponto de função para se obter o valor das
novas funcionalidades. Este valor pode então ser comparado ao valor
proposto pelo fornecedor.
Contudo, o modelo que melhor consegue equilibrar as deficiências da
contratação por homem/hora e por preço global fixo é o baseado em
preço unitário (pontos de função). Caso o fornecedor tenha uma
produtividade baixa, não será remunerado pelo tempo extra consumido.
Caso contrário poderá usufruir de uma melhor rentabilidade do serviço.
Se houver aumento de escopo do serviço, não serão necessárias
negociações desgastantes para se estabelecer um valor para o serviço
adicional.
Nesta modalidade, um fator importante é definir corretamente o valor do
ponto de função, conforme aborda a pergunta
14.
Em qualquer das modalidades de contratação adotada deve-se ter o cuidado
com os conflitos de interesse: a medição do serviço em pontos de função nunca
deve ser realizada somente pelo fornecedor, pois ele será remunerado
justamente pelo resultado da medição! Observa-se esta prática indesejável
em algumas organizações (inclusive públicas). Pode-se utilizar pessoal
interno para realizar a medição, ou na pior das hipóteses validar por
amostragem as medições realizadas. Outra opção é contratar uma empresa
externa para este serviço.
O processo de benchmarking da produtividade do desenvolvimento de
software, assim como o de qualquer outro indicador, depende
fundamentalmente do seguinte questionamento: sua organização possui
internamente dados válidos, comparáveis com aqueles que serão
obtidos no mercado?
Na verdade, a importância dessa pergunta pode ser percebida quando se
afirma que "não se pode realizar o benchmarking de um dado que
não foi coletado". Apesar de parecer óbvia, a simplicidade dessa
afirmação desaparece ao se avaliar o esforço necessário para obter
dados internos confiáveis, que retratem a realidade da organização.
O processo começa, então, com a coleta desses dados. Deve-se ter em
mente que não é suficiente escrever um questionário e entregá-lo
para que as pessoas o respondam. É necessário se ter um planejamento
para garantir que as definições das variáveis de interesse e as
possíveis respostas estejam claras antes de iniciar a coleta de dados.
Um maior tempo gasto com tal planejamento visa reduzir o risco
da coleta de dados errados e o esforço gasto na validação dos dados.
Agora, por analogia e conhecendo-se o conceito de produtividade,
pode-se afirmar que não é possível realizar o benchmarking da
produtividade do desenvolvimento de software sem o conhecimento dos
dados de tamanho e esforço dos projetos da organização. O tamanho
geralmente é medido em Pontos de Função (PF) e o esforço em Horas (H).
Conforme já mencionado, a coleta desses dados deve ser realizada
de forma que possam ser comparados com os indicadores obtidos no
mercado. A chave para o sucesso do benchmarking é a extratificação
dos dados. É fundamental que as coletas sejam realizadas segundo a
similaridade dos projetos, uma vez que a produtividade pode ser
altamente variável dependendo do setor de negócios do projeto, da
plataforma de hardware e software, da época em que o projeto foi
iniciado, etc.
O benchmarking é realizado, então, sob a mesma extratificação adotada
no momento das coletas dos dados internos à organização. Contudo,
nesse momento ainda é necessário observar atenciosamente algumas outras
questões, na tentativa de explorar o nível de adequação do
indicador a um determinado projeto ou ambiente:
a) Os critérios de coleta de horas utilizados na elaboração dos
indicadores de mercado são compatíveis com os utilizados na
organização?
Por exemplo: quantas horas são consideradas em um mês de trabalho
(126, 160, 168, etc.)? Qual a carga horária diária de trabalho
(4, 6, 8, etc.)?
b) O método de contagem do tamanho funcional utilizado na elaboração do
indicador de mercado é compatível com o da organização?
Por exemplo: utilizou-se o fator de ajuste definido pelo método do IFPUG?
c) As atividades envolvidas, os produtos gerados, a metodologia adotada
envolve a mesma utilização de recursos que o contexto em análise
exige?
Por exemplo: quais modelos de projeto e diagramas são utilizados?
Existem papéis definidos para cada atividade realizada, inclusive para
implementar o controle de qualidade dos projetos?
d) Mesmo sendo diferentes, o risco desta variabilidade é aceitável?
Um outro fator a ser considerado é a importância da atualização dos
dados utilizados no benchmarking. No mais, vale ressaltar que quanto
mais projetos forem utilizados no processo de benchmarking, melhor.
Após tomados todos os cuidados necessários, se ainda houverem dúvidas
quanto aos resultados obtidos para a produtividade do desenvolvimento
de software, utilize um intervalo ao invés de um valor exato para
o indicador.
Os principais questionamentos que um processo de estimativa de
software tenta responder estão relacionados ao tempo necessário para
concluir um projeto e ao custo de seu desenvolvimento. As respostas,
por sua vez, só podem ser consideradas confiáveis se todas as
atividades envolvidas na produção do software forem estimadas
quanto aos fatores que afetam as variáveis de tempo e custo. Tais
atividades envolvem desde a definição de requisitos até os testes e
implantação do produto.
A análise de pontos de função é um método utilizado para identificar um
desses fatores, o tamanho do software. Num processo de estimativa de
software, o tamanho é a primeira grandeza a ser analisada. Sem ele as
demais estimativas (como esforço, duração, custo e número de defeitos)
não podem ser determinadas sem que seja adicionado um alto grau de
subjetividade aos resultados.
Com base na quantidade de pontos de função é possível obter indicadores
como a taxa de entrega (H/PF), o custo (R$/PF) e indicadores de
qualidade (Defeitos/PF) de projetos já realizados. Pode-se então
extrapolar estas informações (de outra forma inacessíveis ou de difícil
apuração) para a aplicação em processos de estimativas de novos projetos.
Simplificando, se é sabido o QUANTO deve ser produzido, pode-se
extrapolar qual será o esforço, prazo e custo envolvidos neste
trabalho. Daí pode-se distribuir estes valores entre as várias fases do
ciclo de vida do desenvolvimento do software, desde que sejam
conhecidos os percentuais de distribuição de esforço determinados pelo
processo de produção de software adotado pela organização.
A avaliação para se terceirizar a contagem de pontos de função
basicamente envolve as mesmas questões de se terceirizar qualquer
outra atividade. A seguir são destacadas situações específicas onde
esta terceirização pode ser favorável à organização contratante.
- No período inicial da aplicação da técnica dentro da organização, a
contagem de alguns projetos por um profissional experiente com o
acompanhamento de parte da equipe do cliente pode agilizar o processo
e também ajudar na absorção do conhecimento prático pela equipe. É na
prática também um mentoring.
- Um profissional experiente possui mais agilidade no processo de
contagem. Caso a organização não possua ninguém com este perfil e
quando o escopo da contagem for muito grande e o tempo para realizá-la
for restrito, pode ser conveniente contratar um profissional externo
experiente em contagem atuando em conjunto com um profissional da
organização que conheça os sistemas a serem contados.
- Quando a contagem for uma necessidade esporádica, o custo-benefício
para se capacitar um profissional interno e mantê-lo atualizado pode
ser desvantajoso em relação à contratação pontual de um terceiro.
- Quando a contagem de pontos de função for uma necessidade sistemática
é importante que existam profissionais internos capacitados para a
tarefa. Neste caso a terceirização pode ser conveniente nos picos de
demanda por esta atividade.
- Quando há a necessidade que a contagem seja realizada (ou auditada)
por um profissional certificado (CFPS).
A FATTO possui uma equipe de especialistas certificados capazes de
ajudar sua organização não só no processo de contagem de pontos de
função mas também na correta aplicação da APF em estimativas, programa
de métricas e contratação de software. Entre em contato conosco para
mais informações sobre este serviço através do
Fale Conosco.
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.
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 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.
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.
Na literatura, frequentemente nos deparamos com muitas afirmações e
questionamentos distorcidos sobre a técnica da análise de pontos de
função, que não demonstram nada além da falta de conhecimento sobre o
assunto. Quem nunca ouviu a falsa afirmação "a análise de pontos de
função não serve para medir sistemas orientados a objetos"?
Mais recentemente, com a consolidação da UML como a linguagem padrão de
mercado para a análise e o projeto orientado a objetos, outra frequente
falsa afirmação é que a análise de pontos de função não serve para
medir sistemas cujos requisitos foram expressos segundo especificações
de casos de uso. Uma discussão específica sobre esse assunto foi
apresentada no Boletim de Março de 2004.
Desde o final da década de 90 uma técnica de gerenciamento de testes
surgida na Holanda, chamada "TMap - Test Management Approach" vem
conquistando adeptos, impulsionada pela onda de iniciativas de melhoria
de processos baseadas em padrões de qualidade como ISO e CMM. Sua
implementação é apoiada por uma técnica de estimativa de testes chamada
de Test Point Analysis (TPA) ou Análise de Pontos de Teste que, por sua
vez, é baseada na Análise de Pontos de Função.
A TPA é utilizada especificamente para estimar o esforço necessário na
execução de testes de aceitação e de sistema. Para isso, a TPA
considera relevantes, além do tamanho funcional determinado pelos
pontos de função, outros dois elementos: a estratégia de testes e a
produtividade. Mesmo quando trata o elemento "tamanho", adiciona
fatores que têm mais influência no esforço que especificamente no
tamanho funcional, como complexidade algorítmica, grau de integração
com outras funções e uniformidade funcional.
Embora sendo uma técnica consistente e útil para o aumento da qualidade
do processo e produto de software, a TPA prega mais um conceito
distorcido sobre a análise de pontos de função, quando afirma que esta
não pode ser utilizada na estimativa de esforço das atividades
envolvidas nos testes de aceitação e de sistema. Ora, afirmar isso
significa dizer que a FPA considera as particularidades do processo de
desenvolvimento durante a aplicação da técnica de contagem. O que não é
verdade.
O resultado da aplicação da TPA é medido em unidade de esforço (horas),
diferentemente da análise de pontos de função, que mede o tamanho
funcional do projeto de software. Dessa forma, assim como realmente não
mede diretamente o esforço empregado nos testes, a FPA também não mede
o esforço empregado na fase de análise, projeto ou construção do
software. Sua principal função é medir a funcionalidade entregue pelo
projeto de software. Contudo, os pontos de função podem, perfeitamente,
ser utilizados como dado de entrada de um processo de estimativa de
esforço das diferentes fases do desenvolvimento, como já discutido no
Boletim de Janeiro de 2004.
O maior benefício da TPA está em conseguir reunir, de forma
sistemática, os fatores que influenciam o esforço específico de uma das
etapas do processo de desenvolvimento, produzindo resultados mais
precisos.
Quando se trata da área de tecnologia da informação ao se mencionar o termo
"usuário" geralmente está se referindo à pessoa que interage ou
usa um software.
Sendo a APF um método padrão para medir software do ponto de vista do usuário,
nesse contexto, o termo "usuário" tem um sentido mais amplo. Segundo o Manual de
Práticas de Contagem, usuário é qualquer pessoa que especifica requisitos
funcionais para um software e/ou qualquer pessoa ou coisa que se comunica ou
interage com o software a qualquer momento. Ou seja, além de uma pessoa, um
usuário pode ser um grupo de pessoas que desempenha um papel específico durante
sua interação com o software, o gestor de um departamento, um outro software
ou mesmo um equipamento. E para a APF, interagir com o software significa enviar
dados para a aplicação ou receber dados dela.
Cabe observar que essa definição de usuário possui um sentido bem próximo
ao conceito de um ator de um caso de uso: qualquer
pessoa e/ou coisa que interage com o sistema e espera um resultado de valor
observável produzido pela execução de um ou vários casos de uso.
Levando-se em consideração essa amplitude do conceito de usuário, durante uma
contagem de pontos de função convém buscar no conjunto de usuários possíveis aquele
cuja visão melhor representa as funções que a aplicação fornece. Por exemplo, a
aplicação de auto-atendimento de um banco tem como usuários o cliente do banco, o
funcionário da agência, o gestor do departamento responsável. Basear a contagem
desta aplicação somente na visão do cliente final do banco e usuário do
auto-atendimento, é ter uma visão limitada da aplicação. É fundamental levar em
consideração também a visão do usuário que especifica os requisitos e regras de
negócio, neste caso, o gestor do departamento.
Na área da tecnologia da informação, de maneira geral, o termo "aplicação"
é utilizado para designar um programa executável que cumpre um ou um conjunto
de objetivos específicos dos usuários. Como exemplos clássicos podemos citar a
Calculadora do Windows, o Word, o Contas a Pagar, etc.
Os desenvolvedores, por sua vez, costumam determinar o escopo das aplicações
segundo a segmentação física do software. Sendo assim, Um conjunto único de
funções relacionadas é separado segundo questões tecnológicas:
1) Os modos de execução física. Por exemplo, funções executadas batch ou on-line;
2) As plataformas físicas em que os subconjuntos de funções residem. Por exemplo,
mainframe ou PC (plataforma baixa);
3) As arquiteturas segundo as quais as aplicações são projetadas. Por exemplo,
desktop, cliente-servidor, web ou 3-tier.
Na análise de pontos de função uma aplicação é definida segundo a visão do
usuário e de acordo com considerações de negócio e não com questões técnicas.
Segundo o Manual de Práticas de Contagem (CPM), uma aplicação é um conjunto
coeso de dados e procedimentos automatizados que suportam um objetivo de
negócio, podendo consistir de um ou mais componentes, módulos ou subsistemas.
Frequentemente, o termo "aplicação" é utilizado como sinônimo para sistema,
sistema aplicativo ou sistema de informação.
Para a análise de pontos de função o correto entendimento do termo e, por sua
vez, a correta identificação de uma aplicação (delimitada por sua fronteira)
é a base para o emprego consistente da técnica, evitando superdimensionamentos
ou subdimensionamentos durante as contagens.
Na área de sistemas da informação, de maneira geral, o termo "melhoria" ou "projeto de melhoria" é utilizado para referenciar qualquer projeto onde um software é melhorado em termos de plataforma, performance, aparência, funcionalidade, usabilidade, etc. Tanto do ponto de vista dos usuários quanto dos desenvolvedores. Possui ainda um significado diferente do termo "manutenção" ou "projeto de manutenção", que determina um trabalho executado com a finalidade de manter um software em perfeito estado de funcionamento.
Nesse sentido, seguem alguns exemplos de melhorias:
- Realizar mudanças em dados "hard coded" do software;
- Compatibilizar o software com uma nova versão do banco de dados;
- Dividir fisicamente uma tela em outras, sem que haja mudanças na funcionalidade;
- Alterações "cosméticas" em telas ou relatórios, como mudança de cores, fontes, rearrumação de campos, etc;
- Adicionar novos dispositivos ao software.
Segundo o Manual de Práticas de Contagem do IFPUG, uma contagem de um projeto de melhoria mede as alterações realizadas em uma aplicação existente com a finalidade de incluir, excluir ou modificar funcionalidades entregues quando o projeto estiver completo. Sendo assim, na terminologia da análise de pontos de função, se um "projeto de melhoria" não cria, modifica ou exclui funções lógicas, nenhum ponto de função pode ser contado. Aplicando esse conceito aos exemplos anteriores, observamos não haver funcionalidades novas, alteradas ou excluídas no escopo da contagem.
A APF trata como "melhorias" as modificações realizadas nos requisitos de dados dos usuários e nos processos elementares (ALI, AIE, EE, SE ou CE), resultantes de manutenções adaptativas. O esforço referente àquelas funcionalidades afetadas por manutenções corretivas deve ser atribuído ao projeto de desenvolvimento ou melhoria que introduziu os defeitos. Já as manutenções evolutivas, como aquelas para suportar upgrades de software ou de plataforma, incrementar a performance, etc. serão refletidas apenas nas características gerais da aplicação (GCS), e não em termos de modificação em funcionalidades lógicas.
Como exemplos de alterações consideradas no escopo de um projeto de melhoria, podemos citar:
- Quando um campo for adicionado, alterado ou excluído de um arquivo;
- Quando uma aplicação passar a referenciar ou manter um campo já existente no arquivo e que antes da melhoria não era utilizado;
- Quando houver alteração nos tipos de dados que atravessam a fronteira da aplicação;
- Quando houver alteração nas lógicas de processamento da transação.
- Ser aderente ao padrão ISO/IEC 14143-1 de medição funcional de software.
- Fornecer uma descrição clara e detalhada de como contar pontos de função.
- Garantir que as contagens sejam consistentes com as práticas de contagem dos membros filiados ao IFPUG.
- Fornecer orientação de como realizar contagens de pontos de função baseadas em artefatos das técnicas e metodologias mais utilizadas de desenvolvimento de software.
- Prover um entendimento comum que para que os desenvolvedores de ferramentas forneçam suporte automático à contagem de pontos de função.
Resumidamente o processo de contagem de pontos de função é composto pelos seguintes passos:
1. Identificação do propósito da contagem.
Neste passo, o objetivo é deixar bem claro o que se pretende atingir com a contagem
que será feita; qual o problema que se pretende resolver com ela. A forma como os
passos seguintes são conduzidos depende diretamente desse propósito.
2. Determinação do tipo de contagem.
Existem três tipos de contagem de pontos de função. A diferença no procedimento
adotado entre esses tipos de contagem está nas fórmulas aplicadas no passo final da contagem.
- projeto de desenvolvimento: mede todas as funções que o projeto entregará e eventuais funções de conversão de dados.
- projeto de melhoria: mede as funções alteradas, incluídas e excluídas pelo projeto e eventuais funções de conversão de dados.
- aplicação: mede as funções de um software instalado.
3. Identificação da fronteira da aplicação e do escopo da contagem.
A fronteira da aplicação é a interface conceitual entre o software e o usuário.
Ela delimita o software e o mundo externo.
É um elemento essencial para a correta identificação das funções do tipo dado e
transação nos passos seguintes.
O escopo da contagem define o que fará parte da contagem de pontos de função.
4. Contagem das funções tipo dado.
As funções do tipo dado representam requisitos de armazenamento do usuário.
São classificadas em:
- Arquivos Lógicos Internos (ALI): grupos de dados logicamente relacionados (do
ponto de vista do usuário) e mantidos pela própria aplicação.
- Arquivos de Interface Externa (AIE): grupos de dados logicamente relacionados
(do ponto de vista do usuário) e apenas referenciados de outras aplicações.
Nesse passo são identificados todos os ALIs/AIEs do sistema. As complexidades são
determinadas com base em dois parâmetros (tipos de dado e tipos de registro) e;
associada a cada complexidade existe uma quantidade de pontos de função correspondente.
5. Contagem das funções tipo transação.
As funções do tipo transação representam requisitos de processamento do usuário.
São classificadas em:
- Entradas Externas (EE): transações com o objetivo de atualizar arquivos lógicos internos
ou modificar o comportamento do sistema.
- Consultas Externas (CE): transações que representam simples recuperação de dados de
arquivos lógicos internos e/ou arquivos de interface externa.
- Saídas Externas (SE): transações com o objetivo de apresentação de informação, porém
envolvendo lógica de processamento adicional a uma consulta externa.
Nesse passo são identificadas todas as transações do sistema. Suas complexidades são
determinadas com base em dois parâmetros (tipos de dado e arquivos referenciados) e;
associada a cada complexidade existe uma quantidade de pontos de função correspondente.
6. Cálculo do fator de ajuste.
O fator de ajuste representa a influência de requisitos técnicos e de qualidade no tamanho do software.
É calculado com base nas 14 Características Gerais do Sistema (CGS) listadas a seguir:
( 1) Comunicação de Dados
( 2) Processamento Distribuído
( 3) Performance
( 4) Configuração Altamente Utilizada
( 5) Volume de Transações
( 6) Entrada de Dados On-Line
( 7) Eficiência do Usuário Final
( 8) Atualização On-Line
( 9) Complexidade de Processamento
(10) Reutilização
(11) Facilidade de Instalação
(12) Facilidade de Operação
(13) Múltiplos Locais
(14) Facilidade de Mudanças
Cada uma dessas características deve ser analisada com relação ao seu nível de influência sobre o
sistema e pontuada de 0 (nenhuma influência) a 5 (grande influência). Então soma-se todas essas
pontuações para obter o nível total de influência (TDI). Daí basta aplicar a seguinte fórmula
para obter o fator de ajuste: VAF = (TDI x 0,01) + 0,65.
Atualmente esse é um passo opcional do processo de contagem. Muitas organizações desconsideram o
fator de ajuste e usam apenas a medição dos pontos de função não ajustados.
Ainda assim, as orientações para determinação do VAF pode ser úteis para ajudar
a distinguir requisitos funcionais de requisitos técnicos e de qualidade.
7. Cálculo dos pontos de função ajustados.
O cálculo final dos pontos de função ajustados consiste basicamente em multiplicar o fator de ajuste
pelos pontos de função não ajustados. Porém existem fórmulas específicas para cada tipo de contagem:
- projeto de desenvolvimento: DFP = (UFP + CFP) x VAF, onde:
UFP - pontos de função da aplicação a ser instalada
CFP - pontos de função das funcionalidades de conversão de dados
VAF - valor do fator de ajuste
- projeto de melhoria: EFP = [(ADD + CHGA + CFP) x VAFA] + (DEL x VAFB), onde:
ADD - pontos de função das funcionalidades adicionadas
CHGA - pontos de função das funcionalidades alteradas
CFP - pontos de função das funcionalidades de conversão de dados
VAFA - valor do fator de ajuste do software após o projeto de melhoria
DEL - pontos de função das funcionalidades excluídas
VAFB - valor do fator de ajuste do software antes do projeto de melhoria
- aplicação: AFP = ADD x VAF
Há uma tentação muito grande entre os profissionais envolvidos em
estimativas de usar indicadores ditos "de mercado" para suas estimativas
baseadas em pontos de função. Certamente existem várias fontes onde é possível
obter números relacionados à produtividade com pontos de função para diversos
contextos tecnológicos. O
ISBSG (International Software Benchmarking Standards Group)
é uma delas. No entanto, usar essas fontes desconsiderando o contexto de como
aqueles números foram obtidos e o contexto de sua própria organização é um erro
grave. Estimativas obtidas dessa maneira dificilmente terão a confiabilidade
necessária ou alguma utilidade prática.
A melhor forma de obter indicadores de produtividade que realmente sejam úteis
nas estimativas com pontos de função é apurar esse indicador através dos projetos
desenvolvidos pela organização. Mas como fazer isto?
O primeiro passo é recuperar dos projetos passados as duas grandezas que compõe
o indicador de produtividade: o tamanho (em pontos de função) e o esforço (horas).
Com estes dois dados tem-se de forma direta a produtividade daquele projeto.
Mas se cada projeto tiver um número de produtividade diferente, qual deve ser
empregado no projeto a ser estimado?
Certamente que cada projeto pode apresentar um número distinto, mas se este
procedimento for repetido para um conjunto maior de projetos será possível
observar que para determinados subconjuntos a produtividade é bastante similar.
Isso acontece quando os projetos tem características similares em relação aos
fatores que afetam diretamente o esforço para desenvolvê-los. Logo, é razoável
concluir que dependendo da natureza dos projetos desenvolvidos pela organização,
não haverá um único indicador de produtividade para todos os projetos da
organização; mas sim indicadores de produtividade por grupos de projeto similares.
Sendo assim, o primeiro passo para estimar um novo projeto é enquadrá-lo em
algum grupo de projetos e só então usar o indicador de produtividade adequado.
Mas quais são os fatores que definem esses grupos de projetos?
Qualquer variável que tenha capacidade de produzir um impacto significativo no
esforço do projeto deve ser levada em consideração nessa análise de segmentação
de grupos de projeto. Convém destacar que os fatores podem ser diferentes de
organização para organização. Por exemplo: o uso ou não de uma determinada
metodologia de desenvolvimento de sistemas no projeto pode afetar sua
produtividade. No entanto se em uma determinada empresa todos os projetos
seguem a mesma metodologia, este fator será constante e não terá relevância
para a segmentação de projetos.
Sem a pretensão de estabelecer uma lista completa, pode-se citar os seguintes
fatores:
- tipo de projeto: desenvolvimento, melhoria, migração, redesenvolvimento, etc;
- plataforma tecnológica: mainframe, web, cliente x servidor, sistema embutido, etc;
- ordem de grandeza dos projetos;
- tamanho da equipe de desenvolvimento;
- ferramentas de desenvolvimento;
- metodologia empregada;
- área de negócio;
- número de usuários.
O manual de práticas de contagem é fornecido somente pelo IFPUG. Para os filiados ele está disponível para
download gratuitamente. Para os não filiados ele deve ser adquirido diretamente
com o IFPUG. Infelizmente o manual não é de acesso público e gratuito, isto
dificulta um pouco a difusão da técnica de pontos de função. As organizações responsáveis por outros
métodos de medição funcional como Mark II (UKSMA) e o COSMIC-FFP (COSMIC) disponibilizam acesso gratuito aos
seus manuais.
A versão original do manual do IFPUG está em língua
inglesa. Versões em outras línguas estão disponíveis em espanhol,
italiano, coreano e também em português.
Há uma variação grande na produtividade da contagem de pontos de função por dia,
causada principalmente por:
- Tipo de contagem: em geral a produtividade para contar projeto de melhoria é maior do que de projeto de desenvolvimento ou contagem de aplicação; principalmente se a aplicação que estiver sofrendo manutenção (objeto do projeto de melhoria) já tiver sido contada. Mas o inverso pode também ocorrer, se a medição for para um projeto de melhoria de uma aplicação que nunca foi medida e que tenha pouca documentação disponível.
- Propósito da contagem: dependendo da questão que se deseja responder com a contagem a ser realizada, a precisão da contagem e sua rastreabilidade podem não
ser questões primárias. Assim pode se analisar de forma mais superficial a documentação e também evitar um esforço adicional na documentação da própria
contagem. Ou seja, pode-se optar por uma estimativa de tamanho em vez de propriamente a medição. Mesmo a medição pode ser feita com diferentes níveis de documentação, o qual influenciam o tempo gasto nesta atividade.
- Qualidade da documentação disponível: a principal fonte de informação para a contagem é a documentação do sistema. Se a documentação estiver
incompleta ou ambígua mais tempo será consumido para elucidação de dúvidas referentes aos requisitos. Documentação insuficiente para contagem é um problema
mais comum para contagens de aplicação e projetos de melhoria.
- Disponibilidade dos usuários: muitas vezes mesmo com documentação disponível do sistema, é necessário entrevistar usuários.
- Experiência dos contadores: depende da frequência com que o profissional conta pontos de função, da familiaridade com o negócio do sistema, se é certificado CFPS, etc.
- Metodologia da contagem: cada organização pode ter requisitos distintos para operacionalizar a contagem: desde softwares específicos de apoio ao processo que podem automatizar parte do processo, até nível de rastreabilidade da documentação contra os requisitos do projeto para fins de auditoria.
Analisando um cenário de pior caso, um limite inferior para a produtividade seria 150 PF/dia. Para um cenário de melhor caso seria razoável
considerar 1.000 PF/dia.
Convém destacar que a produtividade não é constante durante todo o processo. O tempo de preparação, análise da documentação, esclarecimento de dúvidas é mais predominante no início da contagem do que a própria contagem em si. Após essas etapas o normal é que a contagem flua mais rapidamente.
O primeiro ponto a se destacar nessa questão é que não existem ferramentas capazes de produzir
de maneira automática uma contagem de pontos de função de forma confiável. As razões para isso foram abordadas
na pergunta 17 de nosso
FAQ. Entretanto existem ferramentas disponíveis
capazes de apoiar e automatizar parcialmente o processo de contagem de pontos de função e também de armazenar
e gerenciar os resultados das contagens.
A ferramenta de uso mais simples para registrar uma contagem de pontos de função é uma planilha. Na seção
Recursos de nosso site há disponível gratuitamente uma planilha formatada para contagens de pontos de função.
Apesar de ser a ferramenta mais simples e a primeira a ser usada por muitos, seu uso começa a ser pouco
prático à medida que se intensifica o número de contagens. O controle do repositório das contagens em geral
é manual, e com a quantidade crescente de dados, a tarefa torna-se custosa.
Quando a organização começa a perceber que a planilha já não atende suas necessidades atuais, uma evolução
natural é buscar no mercado ferramentas com mais recursos. O IFPUG possui um processo de certificação para
as ferramentas de apoio à contagem de pontos de função. A lista de ferramentas atualmente certificadas pode
ser visualizada em http://www.ifpug.org/certification/software.htm.
Segundo esse processo, as ferramentas podem ser classificadas em três tipos:
Tipo 1: O usuário faz a contagem de pontos função manualmente e software fornece as funcionalidades de coletas de dados e cálculos.
Tipo 2: O software fornece as funcionalidades de coletas de dados e cálculos e o usuário e o sistema fazem a contagem de pontos
de função interativamente, através de perguntas apresentadas pelo sistema e ações sendo tomadas automaticamente em função das
respostas fornecidas.
Tipo 3: O software produz automaticamente uma contagem de pontos de função usando várias fontes de informação, como a base de dados
da aplicação, a própria aplicação e artefatos das ferramentas de desenvolvimento. O usuário pode entrar com dados interativamente,
mas o seu envolvimento durante a contagem é mínimo. Importante destacar que não existem ferramentas certificadas deste tipo.
Embora existam várias opções de ferramentas no mercado para apoiar o uso de pontos de função; muitas organizações optam por
desenvolver uma ferramenta própria integrada a seus sistemas de controle internos. Algumas razões para isto podem ser:
- o custo para desenvolver uma solução interna é menor que o custo de aquisição e manutenção dos pacotes disponíveis no mercado;
- a falta de suporte local para a solução, uma vez que a maioria das ferramentas disponíveis no mercado são estrangeiras;
- necessidades de integração com sistemas internos;
Quando se fala em requisitos de hardware necessários para o ambiente de execução
de um determinado software, o foco da questão está em requisitos técnicos ou de
qualidade do mesmo, como capacidade de processamento, volume de transações e de
dados, número de usuários, segurança, etc. Os requisitos funcionais não
influenciam em nada nessa questão. Portanto, não há nenhuma relação direta entre
o tamanho de um software em pontos de função (seja ajustado ou não) com o
hardware necessário à sua execução.
Porém o fator de ajuste, analisado de forma isolada do tamanho funcional,
contempla várias características gerais de sistema (Processamento Distribuído,
Performance, Configuração Altamente Utilizada, Volume de Transações) que
poderiam auxiliar na definição dos requisitos de hardware de um software, mas ainda assim seria uma análise insuficiente para a definição do hardware.
Sim; porém nem todas as manutenções em um software são passíveis de serem medidas com a APF.
Existem três tipos de contagem de pontos de função:
- projeto de desenvolvimento: mede todas as funções que a aplicação terá quando da sua primeira instalação e também eventuais
funções de conversão de dados que o projeto possa ter.
- projeto de melhoria: mede todas as funções que serão adicionadas, alteradas ou excluídas da aplicação, bem como as eventuais
funções de conversão de dados.
- aplicação: mede todas as funções que a aplicação disponibiliza para o usuário.
As manutenções que alteram os requisitos funcionais de um software podem ser medidas pela APF, através da contagem dos pontos de
função do projeto de melhoria. Manutenções para correção de defeitos ou para atender requisitos não funcionais (técnicos ou de
qualidade) não são medidos pela APF.
A única informação de um software necessária para se contar pontos de função são os seus requisitos funcionais. Portanto,
uma vez que os requisitos estejam estabelecidos, qualquer que seja a fase do projeto é possível realizar a medição do seu tamanho.
Importante destacar também que a forma pela qual os seus requisitos estão documentados ou expressos é irrelevante para a medição,
isto apenas reforça que a APF mede o software de maneira independente pela qual ele é modelado, projetado ou construído.
Porém é válido levantar a seguinte questão: se só é possível contar pontos de função após a definição dos requisitos, como produzir
estimativas para o projeto antes desse momento, que é justamente onde a necessidade por estimativas é mais demandada? Neste caso
pontos de função ainda podem ser úteis?
Mesmo não sendo possível fazer a contagem de pontos de função em momentos iniciais do projeto (antes do detalhamento dos requisitos),
ainda assim é possível estimar o seu tamanho em pontos de função. Existem várias técnicas para estimar o tamanho em pontos de função
de um software, dentre as mais comuns duas foram propostas pela associação de métricas da Holanda -
NESMA. São a contagem indicativa e a contagem estimativa, detalhadas em
http://www.fattocs.com.br/traduzido/earlyfpa.asp.
Não, a APF é um método para medição do tamanho funcional de um software.
Ela apenas quantifica as funcionalidades que o software fornece aos usuários. No
entanto a técnica pode ser uma ferramenta, entre várias existentes, que o gerente de projetos
pode fazer uso para apoiá-lo na tarefa de gestão.
O processo de medição, tanto quanto o resultado da medição, ajuda a trazer visibilidade a
diversos aspectos do projeto, como por exemplo escopo e requisitos.
A associação entre o tamanho funcional e outras grandezas, como esforço, custo, quantidade de
defeitos, possibilita a geração de indicadores úteis à gerência para o acompanhamento de produtividade
e qualidade. O indicador de produtividade é muito empregado para a geração de estimativas
(baseadas em pontos de função) para o projeto.
A essência da APF, pregada pelo IFPUG,
é que o processo de contagem de pontos de função
deve ser consistente (pessoas diferentes medindo o mesmo projeto devem encontrar resultados
similares) e também, mas principalmente, que a contagem seja simples o suficiente para
minimizar o esforço de medição, reduzindo o impacto sobre o esforço global do projeto.
Assim como qualquer outra atividade de um projeto de desenvolvimento ou
manutenção de software, realizar uma contagem de pontos de função demanda o esforço
de um profissional da equipe. Logo haverá um esforço adicional no projeto para que se
realize a medição.
O que se deve considerar é que os benefícios obtidos pela realização da medição compensem
o esforço adicional dispendido. Em tese o software pode ser desenvolvido somente com as
atividades de codificação; porém outras atividades são realizadas (como análise, planejamento,
modelagem, testes, etc) que irão "onerar" o esforço do projeto mas que proporcionam benefícios
que suplantam esse esforço adicional.
Traduzindo em números, o ideal seria que esse esforço ocasionado pela medição não ultrapassasse
2% do esforço total do projeto. Importante destacar que, em muitos casos onde isto não ocorre,
a causa está numa deficiência da especificação dos requisitos. Nestes casos a maior parte do esforço
da contagem de pontos de função acaba sendo consumido em entrevistas, revisão e detalhamento de requisitos.
Atividades que deveriam ter sido realizadas na fase de especificação propriamente dita.
Basicamente todas as atividades que possuem relação direta com a construção e
entrega dos requisitos funcionais: levantamento e especificação
de requisitos, análise, projeto, modelagem, gerência do projeto, codificação,
testes, apoio à homologação do usuário, implantação e transferência de conhecimento
do serviço executado. Sendo que vários artefatos podem ser produzidos nestas
atividades, como: código fonte, diagramas, modelos, casos de uso, manuais,
planos, atas, etc.
Por complemento ao parágrafo anterior, quaisquer atividades não diretamente relacionadas aos
requisitos funcionais do projeto de desenvolvimento/manutenção do software não estão no escopo da estimativa por PF.
Exemplos: treinamento de usuários, acompanhamento do sistema em produção, administração do
banco de dados, atendimento de dúvidas ou reclamações de usuários, atividades de suporte a infra-estrutura tecnológica, etc.
É possível também realizar a estimativa para apenas algumas atividades
específicas do projeto. Para isto é necessário conhecer a distribuição (%) de
esforço que cada fase costuma consumir do projeto todo. Conhecendo esta relação,
estima-se o esforço total do projeto e aplica-se o percentual de cada fase
desejada para se saber o esforço estimado para aquelas atividades.
A maioria dos erros encontrados em uma contagem de pontos de função de um sistema é causada por quatro fatores:
- Desconhecimento da técnica: ainda há um grande número de profissionais que são designados para contar pontos de função
de um sistema sem o conhecimento necessário do processo de contagem. Talvez isto ocorra por haver uma idéia generalizada
de que a APF seja muito simples. E na realidade ela é, porém isto não significa que seja desnecessário treinamento profissional
ou um estudo mais dedicado da técnica. Com apenas um conhecimento superficial da APF é bem provável que o analista cometa erros
básicos. Sobre este aspecto, o IFPUG estabeleceu o seu programa de certificação profissional CFPS, que visa garantir que o
profissional certificado conhece todas as definições e regras do seu Manual de Práticas de Contagem em sua versão mais recente.
- Deixar a contagem ser "contaminada" pela implementação: a APF é uma técnica para medir requisitos funcionais de um software. Ou
seja, mede o que o usuário solicita e recebe do software independente do como este foi implementado. Logo, o resultado de uma
contagem de pontos de função tem que ser o mesmo, seja qual for a solução de implementação (processo, arquitetura, ferramentas,
ambiente computacional, etc) adotada pelo desenvolvedor. Contar pontos de função de um sistema é um exercício de abstração do
problema de negócio do usuário que o software deve atender. Porém nem sempre isto é uma tarefa fácil e mesmo analistas de pontos
de função experientes podem desviar o foco da contagem para a solução de implementação do desenvolvedor. Muitas vezes o analista
é induzido neste caminho por falta de documentação adequada.
- Falta de conhecimento do negócio: não adianta ser especialista na APF e não conhecer o negócio do usuário. Para que a contagem
de pontos de função seja feita de forma correta, ou seja, do ponto de vista do usuário, é necessário que o analista de pontos de
função busque o entendimento do negócio primeiro e somente depois realize a contagem de pontos de função. Muitas vezes não há
tempo disponível para que o analista de pontos de função busque este conhecimento. Neste caso ele irá atuar em parceria com um analista
de negócio ou com um usuário para poder realizar a contagem de pontos de função.
- Qualidade dos requisitos disponíveis: muito se fala na engenharia de software sobre a importância do levantamento de requisitos
e do impacto que isto tem em todo o projeto quando esta tarefa não é bem executada. Para a contagem de pontos de função isto não é
diferente. Se os documentos de onde o analista de pontos de função extrai os requisitos do usuário para realizar a contagem estão
ambíguos, incompletos ou mal escritos, certamente o resultado da contagem será afetado.
Esta relação de fatores não está apresentada em nenhuma ordem específica, mas é bastante representativa
dos principais fatores que causam contagem de pontos de função incorretas.
Não há um documento específico de uso obrigatório para se medir um software (ou contar pontos de função). Qualquer documento no qual seja possível extrair informações dos requisitos do usuário pode ser usado em uma contagem de pontos de função. Sejam eles casos de uso, manuais, protótipos, documentos de visão, modelo de dados, modelo de classes, etc. Isto é coerente com o próprio objetivo da APF que é ser uma técnica independente da implementação do software. Pode-se implementar um software através de diferentes métodos e ferramentas para análise, modelagem e construção, para diversas plataformas computacionais; mas nada disso afeta a medição do mesmo em pontos de função.
É claro que determinados tipos de documentos podem trazer a informação necessária para uma contagem de pontos de função de maneira mais fácil. Outros documentos podem conter apenas parte da informação necessária para a contagem de PFs, sendo necessário a análise conjunta de mais documentos para se efetuar a medição. Assim como também outros documentos, por terem um caráter mais técnico para o processo de desenvolvimento de software, podem dar mais trabalho para se extrair os requisitos do usuário. O melhor documento para se utilizar numa contagem de PFs é aquele que contém os requisitos do usuário explicitados na linguagem do seu negócio, e não num linguajar de TI.
Cada organização possui o seu processo de desenvolvimento particular, produzindo uma quantidade de documentos (ou artefatos) distintos em determinadas fases do processo. Logo, o momento no qual a medição é feita acaba determinando também quais documentos estarão disponíveis para se efetuar o trabalho de medição (ou estimativa) do tamanho funcional do projeto.
Os requisitos do software são fundamentais para a APF, pois o processo de medição é baseado exclusivamente neles. O insumo básico da medição são os requisitos do sistema. Convém destacar que a APF mede apenas uma parte dos requisitos do usuário para o sistema: os requisitos funcionais. Os requisitos não funcionais não são medidos pela APF. Porém num modelo de estimativa de custo baseado em PF (custo = tamanho x $/PF), ambos os tipos de requisitos (funcionais e não funcionais) são considerados: o primeiro irá afetar o tamanho funcional e o segundo afetará o custo unitário ($/PF).
Devido a esta importância dos requisitos para a APF, quanto melhor a qualidade dos requisitos, mais fácil e ágil torna-se o processo de medição, e mais preciso é o resultado. Requisitos de qualidade ruim afetam negativamente todo o projeto de software, inclusive a atividade de medição. Porém um efeito colateral benéfico do processo de medição é justamente evidenciar falhas nos requisitos. Quanto mais cedo no projeto estas falhas forem identificadas, menor o custo de corrigí-las e maior a chance de sucesso do projeto.
|
Para que possamos ter uma comunicação mais direcionada, convidamos para que complete/atualize o seu cadastro em http://www.fattocs.com.br/cadastro_boletim.asp. |
