FAQ - Perguntas Frequentes

 

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

Geral

1. Quais os benefícios da Análise de Pontos de Função?
2. É necessário ser desenvolvedor de software (analista de sistemas, programador, etc) para aprender ou usar a APF?
3. Existe algum organismo responsável pela padronização da técnica?
4. Houve alguma evolução na técnica da APF após sua criação?
5. Quem usa APF no Brasil e no mundo?
6. É possível utilizar a APF em um projeto Orientado a Objeto?
7. Onde posso obter mais informações sobre APF?
8. Qual o preço de um ponto de função?
9. É possível aplicar a APF em tarefas que não são organizadas como projetos?
10. 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?
11. Por que não existem ferramentas para a contagem automática dos pontos de função de um sistema?
12. Além dos pontos de função do IFPUG existem outros métodos padrão de medição funcional?
13. Quais os primeiros passos para a aplicação da APF em minha organização?
14. Quais as orientações iniciais para a aplicação da APF em estimativas de projetos de software?
15. Quais as orientações iniciais para a aplicação da APF em contratos de desenvolvimento de sistemas?
16. Quais as orientações gerais para a utilização da APF no processo de benchmarking da produtividade no desenvolvimento de software?
17. 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?
18. Em que situações pode ser vantajosa a terceirização da contagem de pontos de função?
19. A APF pode ser utilizada para produzir estimativas para os testes de aceitação e de sistema?
20. Qual o conceito do termo "Usuário" para a APF?
21. Como a APF define o termo "Aplicação"?
22. Como a APF define o termo "Melhoria"?
23. Quais os objetivos do Manual de Práticas de Contagem do IFPUG?
24. Como é o processo de contagem de pontos de função?
25. Onde é possível obter o Manual de Práticas de Contagem do IFPUG?
26. Quantos pontos de função é possível se contar em um dia?
27. Quais as ferramentas indicadas para apoiar e/ou automatizar (ainda que parcialmente) o uso da APF?
28. É possível aplicar a APF para projetos de manutenção de sistemas?
29. Em que momento do ciclo de vida do projeto de software é possível contar pontos de função?
30. A APF é uma técnica de gestão de projetos de software?
31. A APF onera o esforço de um projeto de software?
32. Quais atividades são compreendidas na estimativa de esforço (usando pontos de função) de um projeto de software?
33. Quais as principais causas para erros em uma contagem de pontos de função?
34. Que documentos são necessários para uma contagem de pontos de função?
35. Qual a importância dos requisitos do software para a APF?
36. O que um órgão do governo deve fazer para obter a filiação ao IFPUG?
 

 

1. 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.

Voltar ao Topo


2. É necessário ser desenvolvedor de software (analista de sistemas, programador, etc) para aprender ou usar a APF?


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.

Voltar ao Topo


3. 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.
Voltar ao Topo

Voltar ao Topo

4. Houve alguma evolução na técnica da APF após sua criação?

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.

Voltar ao Topo


5. Quem usa APF no Brasil e no mundo?

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.

Voltar ao Topo

6. É possível utilizar a APF em um projeto Orientado a Objeto?

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.

Voltar ao Topo

7. Onde posso obter mais informações sobre APF?

O site do BFPUG (http://www.bfpug.com.br/) e o do IFPUG (http://www.ifpug.org/) são os pontos de partida mais indicados.

Voltar ao Topo

8. Qual o preço de um ponto de função?

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.

 

Voltar ao Topo


9. É possível aplicar a APF em tarefas que não são organizadas como projetos?

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.

10. 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?

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.

Voltar ao Topo

11. Por que não existem ferramentas para a contagem automática dos pontos de função de um sistema?

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.

Voltar ao Topo

12. Além dos pontos de função do IFPUG existem outros métodos padrão de medição funcional?

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.

Voltar ao Topo

13. Quais os primeiros passos para a aplicação da APF em minha organização?

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:

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).

Voltar ao Topo

14. Quais as orientações iniciais para a aplicação da APF em estimativas de projetos de software?

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.

Voltar ao Topo

15. Quais as orientações iniciais para a aplicação da APF em contratos de desenvolvimento de sistemas?

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.

Voltar ao Topo

16. Quais as orientações gerais para a utilização da APF no processo de benchmarking da produtividade no desenvolvimento de software?

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.

Voltar ao Topo

17. 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?

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.

 

 

Voltar ao Topo

18. Em que situações pode ser vantajosa a terceirização da contagem de pontos de funçã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).


Voltar ao Topo

19. A APF pode ser utilizada para produzir estimativas para os testes de aceitação e de sistema?

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.

 

Voltar ao Topo

20. Qual o conceito do termo "Usuário" para a APF?

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.

Voltar ao Topo

21. Como a APF define o termo "Aplicação"?

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.

Voltar ao Topo

22. Como a APF define o termo "Melhoria"?

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.

Voltar ao Topo

23. Quais os objetivos do Manual de Práticas de Contagem do IFPUG?

 

  • 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.

 

Voltar ao Topo

24. Como é o processo de 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

Voltar ao Topo

25. Onde é possível obter o Manual de Práticas de Contagem do IFPUG?

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.

Voltar ao Topo

26. Quantos pontos de função é possível se contar em um dia? 

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.

Voltar ao Topo

27. Quais as ferramentas indicadas para apoiar e/ou automatizar (ainda que parcialmente) o uso da APF?

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. 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;

O tamanho em pontos de função não-ajustados de um software é determinante para a especificação do hardware necessário à sua execução? Por quê?

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.

Voltar ao Topo

28. É possível aplicar a APF para projetos de manutenção de sistemas?

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.

Voltar ao Topo

29. Em que momento do ciclo de vida do projeto de software é possível contar pontos de função?

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.

Voltar ao Topo

30. A APF é uma técnica de gestão de projetos de software?

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.

Voltar ao Topo

31. A APF onera o esforço de um projeto de software?

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.
 

 

Voltar ao Topo

32. Quais atividades são compreendidas na estimativa de esforço (usando pontos de função) de um projeto de software?

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.

Voltar ao Topo

33. Quais as principais causas para erros em uma contagem de pontos de função?

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.

Voltar ao Topo

34. Que documentos são necessários para uma contagem de pontos de função?

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.

Voltar ao Topo

35. Qual a importância dos requisitos do software para a APF?

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.

Voltar ao Topo

36. O que um órgão do governo deve fazer para obter a filiação ao IFPUG?

Muitas vezes recebemos consultas a respeito do que um órgão do governo deve fazer para realizar a filiação ao IFPUG. As dúvidas geralmente dizem respeito ao pagamento da filiação, que deve ser feito em dólares no exterior. Não deve haver motivo para preocupação, pois vários órgãos estaduais, federais e empresas estatais já se filiaram e permanecem filiados. Os passos irão variar um pouco dependendo do órgão, mas basicamente são:

1. Dirigir-se à área de compras, suprimentos ou filiações a associações, com uma solicitação devidamente embasada, justificando a necessidade de filiação ao IFPUG. Ressaltar que o único fornecedor dos serviços almejados é o IFPUG (por exemplo, para ter acesso ao CPM e realizar o exame CFPS o IFPUG é a única fonte).

2. Aprovado o pedido, a área de compras provavelmente solicitará ao IFPUG uma invoice (fatura, ou instrumento de cobrança) que servirá de base ao pagamento e especificará o valor a ser pago. A invoice pode ser solicitada via e-mail ao escritório do IFPUG, tendo-se o cuidado de enviar ao IFPUG todos os dados necessários à identificação do órgão: razão social, endereço, CNPJ, etc. Orientar o escritório do IFPUG sobre a necessidade de colocar todos os dados na invoice. Normalmente a invoice virá através de e-mail.

3. Recebida a invoice, a área de compras estará ciente do valor a ser pago (conforme o tipo de filiação solicitado) e dos dados bancários do IFPUG para remessa do dinheiro. Nesta data (01 de julho de 2010) esses dados são:

International Function Point Users Group
191 Clarksville Rd.
Princeton Junction, NJ 08550
Sovereign Bank
44 Princeton Hightstown Rd
Princeton Jct., NJ 08550
877-768-1145
ABA # 231372691
Account # 0741078090
Amount:______________
Swift Code: SVRNUS33

Notar que o campo Amount (valor) acima deve ser preenchido com o valor da filiação acrescido de US$ 50.00 (cinquenta dólares norte-americanos), correspondentes à taxa de remessa internacional cobrada pelo banco e repassada ao filiado pelo IFPUG.

4. De posse dos dados bancários acima, um funcionário do órgão deve ir a uma agência do Banco do Brasil, que realizará o serviço de remessa eletrônica ao exterior. Este serviço é uma operação de câmbio, devendo existir uma taxa cobrada pelo BB e possivelmente impostos. Efetuada a remessa, o BB fornecerá um comprovante em reais, que será contabilizado pelo órgão. Dessa forma, não existirá contabilmente uma operação em dólar no órgão, mas sim um pagamento em reais ao BB (esta é uma dúvida que costuma surgir - alguns colegas dizem "Meu órgão não pode realizar pagamentos em dólares", mas isto não deve constituir impeditivo, já que o fato contábil será registrado em reais).

5. Realizada a transferência, uma cópia do comprovante fornecido pelo BB deverá ser enviada via fax ou e-mail ao IFPUG, juntamente com o formulário de filiação que pode ser baixado de http://www.ifpug.org/membership/membershipApplication.pdf (ver http://www.ifpug.org/membership/). Notar que o nome do órgão deverá aparecer exatamente da mesma maneira no comprovante do BB e no formulário de filiação - não colocar, por exemplo, Serviço Federal de Processamento de Dados em um documento e SERPRO no outro, etc.).

6. Tudo isto feito, os contatos constantes do formulário de filiação receberão um e-mail de confirmação com identificação de usuário e senha para acesso à área de filiados do site do IFPUG. Notar que este retorno pode levar mais de uma semana. Se demorar demais, enviar ao IFPUG uma mensagem em inglês solicitando explicação.

Fonte: FATTO Consultoria e Sistemas

Voltar ao Topo