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

 

 

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 é 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, assista às vídeo aulas introdutórias sobre:

 

Vídeo - O que é a Análise de Pontos de Função (7:06) - Apresenta a definição do que é a Análise de Pontos de Função; quem são os responsáveis pela sua manutenção e evolução; e qual o objeto da medição (o que é medido e considerado na análise).

 

Vídeo - Objetivos da Análise de Pontos de Função (6:28) - Apresenta os quatro objetivos da análise de pontos de função e do processo de medição, explicando os conceitos subjacentes necessários ao entendimento dos mesmos.

 

No Brasil, alguns usam o termo original do inglês: FPA - Function Point Analisys. Outros usam termos parecidos como "Análise de Pontos por Função", "Análise por Pontos de Função", ou "Análise por Pontos por Função", que são traduções ligeiramente diferentes da tradução oficial - Análise de Pontos de Função.

 

 

2. Quem inventou a APF? Como ela surgiu?

 

 

A APF surgiu em meados da década de 1970 como resultado de um projeto desenvolvido por Allan Albrecht, pesquisador da IBM. Seu trabalho envolvia um estudo de produtividade para projetos de software desenvolvidos por uma unidade de serviços da IBM. Como nem todos os projetos usavam a mesma linguagem de programação, ele buscou elaborar uma medida que observasse apenas aspectos externos do software, no caso, suas funcionalidades. A esta medida baseada na visão do usuário, e independente da linguagem de programação ou de qualquer outro aspecto relacionado à implementação do software, ele chamou de Pontos de Função.

 

Em Outubro de 1979 o autor apresentou e publicou o resultado deste estudo: Measuring Application Development Productivity - Allan J. Albrecht (se preferir, leia a versão traduzida para o português: Medindo a Produtividade do Desenvolvimento de Aplicativos). Isso despertou o interesse por pessoas de outras empresas pela técnica de Pontos de Função e o seu uso começou a se difundir nos anos seguintes até culminar com a formação do IFPUG em 1986. Este artigo é muito mais que uma curiosidade histórica, continua ainda bastante atual.

 

 

3. A técnica APF é propriedade de alguma empresa?

 

 

Não. Apesar de ter sido elaborada na IBM, o resultado desse projeto foi aberto à comunidade em 1984.

 

 

4. Quais os benefícios da Análise de Pontos de Função?

 

 

As organizações usam pontos de função muitas vezes com diferentes propósitos 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 ao de 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.

 

Vídeo - Benefícios da Análise de Pontos de Função (6:03) - Os objetivos do vídeo são: saber identificar e explicar os benefícios da aplicação da Análise de Pontos de Função e entender a relação entre os Pontos de Função e outras métricas afins na geração de indicadores de Produtividade, Qualidade e Escopo.

 

 

 

5. É necessário ser desenvolvedor de software (analista de sistemas, programador, etc) para 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.

 

 

6. Existe alguma entidade ou organização responsável pela padronização da APF?

 

 

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. 

BFPUG - Brazilian Function Point Users Group é a representação oficial do IFPUG no Brasil.

 

 

7. Houve alguma evolução na 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 a 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. Há um comitê responsável pela atualização do Manual de Práticas de Contagem, que é a referência padrão para uso da APF e 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 medição; melhorando assim a consistência das medições e reduzindo a subjetividade nas interpretações.

 

 

8. O que é a certificação CFPS do IFPUG?

 

 

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%. Para aqueles que atingem nota entre 80% e 89% é concedido o título CFPP (Certified Function Point Practioner). Este exame consiste em pouco mais de 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. A renovação deve ocorrer mesmo que não tenha havido mudança alguma na versão do Manual do IFPUG. Este programa de extensão (válido apenas para o CFPS) permite que se prorrogue 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. Esta renovação pode ser realizada por várias vezes consecutivas, desde que não haja mudança significativa (major change) do Manual; neste caso 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, assim como coreano e italiano. 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).

 

 

9. Quais as dicas para o exame CFPS do IFPUG?

 

 

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

 

 

10. Qual o custo para se obter e manter a certificação CFPS do IFPUG?

 

 

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:  http://www.ifpug.org/?page_id=26

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 Nacional - US$1.200,00
Corporativa Mundial - US$1.850,00 

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. 

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. Para consultar lista de cidades com centros autorizados a ministrar o exame CFPS, acesse http://www.prometric.com/IFPUG

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, com total flexibilidade de horário. Inscreva-se!;
- Instrutores certificados CFPS 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.

 

 

 

 

11. Quem usa APF no Brasil e no mundo?

 

 

No Brasil pode-se citar empresas como Accenture, Bradesco, Vale, Caixa, Correios, CPMBraxis, Datamec, Totvs, DBA, EDS, IBM, Petrobras, Politec, OI, 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.

 

 

12. É 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.

 

 

13. Qual o tamanho para considerar um projeto de software pequeno, médio ou grande?

 

 

Em uma organização é desejável que os processos de gestão de projetos sejam escaláveis de acordo com o tamanho do projeto. Projetos grandes necessitam de mais rigor e formalismo na gestão que projetos pequenos. Usar a mesma abordagem para qualquer tamanho de projeto, significa onerar os projetos menores com um custo relativamente alto de gestão, ou seja, desperdício de recursos. 

Não existe uma definição padrão na indústria do que seja um projeto de software pequeno, médio e grande. Este é um conceito relativo, que cabe ser elaborado por cada organização. Na verdade nem sempre há a necessidade de se definir o enquadramento de projetos em 3 níveis (pequeno, médio e grande). Para organizações que trabalham com projetos sempre de porte similar, esta classificação pode ser desnecessária e usar um único processo de gestão para todos os projetos pode ser a melhor abordagem. Há organizações com processos de gestão para apenas dois tipos de projetos (pequenos e grandes). Também não há nada que impeça uma organização querer definir mais de 3 níveis para o porte de projetos; (por exemplo: pequeno, médio, grande e muito grande). Mas esta situação tende a ser mais incomum. 

Em resumo, o conceito de projeto pequeno, médio ou grande é relativo; cada organização pode estabelecer os seus próprios critérios para segmentar os seus projetos com relação ao tamanho.

 

 

14. 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. Deve-se avaliar o conjunto de atividades relativas à disponibilização das funcionalidades medidas em pontos de função, o modelo de contrato que ditará a remuneração de um ponto de função e também os aspectos não funcionais que são desconsiderados na medição dos pontos de função para obter uma referência confiável. A melhor alternativa para obter esta referência é analisar os 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. 

É possível obter informações de preço do PF dos contratos governamentais, pois são dados públicos. Na tabela seguinte, http://fattocs.com/pt/recursos/editais.html, apresentamos algumas referências para fins de ilustração. Pode-se observar que a variação dos números é muito significativa, com valores orbitando de R$100/PF a R$1.000/PF. Para entender parte destas discrepâncias é necessário olhar com atenção o objeto de contratação do serviço para identificar as diferenças técnicas e de complexidade de cada contrato.

 

 

15. É 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.

 

 

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.

 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?

 

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.

 

 

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

 

 

18. O que é backfiring?

 

 

Esse método consiste em derivar o número de pontos de função da aplicação a partir de seu tamanho físico, medido em linhas de código (LOC), utilizando um fator de conversão constante dependente da linguagem de programação. A idéia possui bastante apelo, uma vez que a contagem de linhas de código pode ser feita através de ferramentas automáticas e consequentemente o número de pontos de função poderia ser derivado de imediato. Por exemplo, utilizando um fator de conversão de 80 LOC/PF para Java e tendo uma aplicação escrita com 8.000 linhas de código Java, chega-se a 1.000 pontos de função para essa mesma aplicação. 

Entretanto, frequentemente, esta técnica apresenta erros consideráveis quando confrontada com uma contagem manual dos pontos de função de uma aplicação. Isto porque assume uma relação linear entre tamanho funcional (em pontos de função) e o tamanho físico do programa (em linhas de código), que são grandezas distintas. Outros aspecto é que não há consenso nas diferentes organizações que publicam estas relações. Os números apresentados podem divergir em até 100%! Quando se tem um cenário de sistema desenvolvido com um mix de linguagens de programação, a questão se complica mais ainda. A tabela seguinte apresenta um exemplo dessas variações para a linguagem COBOL. 

 

 

 

Fonte

Fator de Conversão (COBOL)

Quantitative Software Management

77 LOC/PF

Capers Jones

107 LOC/PF

David Consulting Group

177 LOC/PF

 

 

 

 


Algumas das razões para explicar essa variação tão grande são: premissas distintas na definição do que é uma linha de código e bases de projetos com características muitos distintas. Daí a necessidade 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.

 

 

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

 

 

21. 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: 

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

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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.

 

 

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

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.

 

 

27. O que são Pontos por Caso de Uso (ou Use Case Points)?

 

 

Até o 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.

 

 

28. Quais as vantagens da APF em relação a Pontos por Caso de Uso (PCU ou UCP)?

 

 

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 em relação ao 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 (mas não eliminar) 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 em relação 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 continuamente para sua evolução.

 

 

29. Que tipos de software podem ser medidos pela APF?

 

 

A Análise de Pontos de Função (APF) é uma técnica para medir as funcionalidades oferecidas por um software para seus usuários. E esta medição é sempre feita numa perspectiva externa; do ponto de vista dos usuários. Porém cabe destacar que o conceito de usuário para a APF não é apenas do usuário final do software. Usuário para APF é qualquer pessoa ou coisa que interage com o software a qualquer momento. Ou seja, usuário para APF pode ser tanto uma pessoa agindo como usuário final do software ou também outro software que utiliza serviços do software em análise. 

Considerando que todo e qualquer software existe para oferecer um ou mais serviços (funções) para alguém (pessoa ou coisa); então conclui-se que todo e qualquer software pode ser medido pela APF

Um equívoco comum de alguns iniciantes com a APF é usar como ponto de vista da análise apenas o usuário final. Neste caso alguns softwares serão parcialmente (ou completamente) "invisíveis" para este usuário. E daí o iniciante conclui equivocadamente que a APF não serve para medir aquele software. O mais comum é o iniciante aprender os princípios da APF aplicada a sistemas com telas e relatórios. Porém quando este se depara com softwares que não possuem telas, softwares com processamento batch, middlewares, softwares básicos, é natural sentir dificuldade em fazer a medição. 

Vamos imaginar que o objetivo fosse medir um driver de impressora. Ora, não há um usuário final (pessoa) para este tipo de software. Nesta perspectiva, o driver de impressora é "invisível" para o usuário final. Porém o driver de impressora existe para oferecer serviços a alguém; no caso o sistema operacional. Analisando portanto o driver de impressora na perspectiva do sistema operacional, é possível enxergar funções; por exemplo: funções para iniciar a impressora, informar a situação geral do dispositivo, ejetar uma folha, imprimir, alertar tinta próxima do final, dentre outras.

 

 

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

 

 

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

 

 

32. 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 d

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

 

 

33. É possível usar a APF em projetos que seguem a abordagem “ágil”?

 

 

Certamente que sim! A 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 abordagem ágil ou outra abordagem qualquer. 

O que irá diferenciar a medição de um projeto “agilista” e outro tradicional serão os artefatos usados para se realizar a análise. Numa abordagem mais convencional, por exemplo similar ao RUP, os artefatos usados para a medição serão provavelmente especificações de caso de uso, que são descrições detalhadas das funcionalidades na ótica da interação do usuário com o software. 

Na abordagem ágil há uma ênfase maior em entregar o software funcionando do que em produzir uma documentação detalhada do que será feito. Sendo assim, o mais provável de se utilizar para a medição numa abordagem ágil são as histórias de usuário, que são descrições breves das funcionalidades desejadas pelo usuário. 

Porém apenas as histórias de usuário não são suficientes para prover toda informação necessária para a medição dos pontos de função (embora sejam suficientes para fornecer uma estimativa/aproximação do tamanho em PFs). Então como se conseguirá medir o projeto? 

Ora, o desenvolvedor também não consegue construir o software apenas com as informações das histórias de usuário. São necessários requisitos mais detalhados para que se consiga construir o software desejado. E onde o desenvolvedor consegue informações mais detalhadas, além das histórias de usuário, para construir o software? Muito provavelmente com o próprio usuário! A abordagem ágil prega que o usuário participe do time de desenvolvimento, numa interação muito próxima aos desenvolvedores. 

Portanto, considerando que o desenvolvedor consegue informações detalhadas dos requisitos para construir o software, essas mesmas informações serão úteis para o processo de medição dos PFs. 

 

 

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

 

O Manual de Práticas de Contagem (ou Counting Practices Manual - CPM) do IFPUG possui os seguintes objetivos:

  • 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.
  • Ser aderente ao padrão ISO/IEC 14143-1 de medição funcional de software.

Para o objetivo de aprender a aplicar a Análise de Pontos de Função, o manual não é tão didático. Uma alternativa mais didática é o livro Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software. Se o objetivo for estudar para o exame CFPS, então o manual é material obrigatório para estudo.

 

 

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

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

 

 

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.

 

 

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

 

 

O Manual de Práticas de Contagem (ou Counting Practices Manual - CPM) é fornecido somente pelo IFPUG. Para os filiados ao IFPUG 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 idioma Inglês. Versões em outras idiomas também estão disponíveis: espanhol, italiano, francês, coreano, chinês e também em português.

 

 

38. Quantos pontos de função um analista conta em um dia?

 

 

Há uma variação grande na produtividade da contagem de pontos de função por dia para um profissional, causada principalmente por: 

1. Conhecimento do negócio sobre o qual o projeto/sistema atua: se o analista de métricas tem conhecimento do negócio, terá facilidade para efetuar a medição, mesmo até que a documentação do projeto/sistema não esteja com boa qualidade. 

2. Qualidade da documentação disponível: a principal fonte de informação para a contagem é a documentação do projeto/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 a medição é um problema mais comum para contagens de aplicação e projetos de melhoria. 

3. Experiência dos contadores: quanto mais experiência o analista adquire em contagens, mais ágil ele é na análise dos requisitos. Ele aprende a buscar quais informações são relevantes para a medição na documentação e a desprezar aquilo que não interessa (poupando tempo de análise de algo que não afetará a medição). A experiência acumulada também evita que se tenha que consumir tempo em análise de situações que ele já lidou anteriormente. 

4. Disponibilidade dos usuários: muitas vezes mesmo com documentação disponível do sistema, é necessário entrevistar usuários para complementar alguma necessidade de informação que não foi documentada ou documentada de forma não clara. Para sistemas legados que não possuem documentação, a única forma de medí-los é com o apoio dos usuários. Se não há um usuário disponível para suprir informações, o analista de métricas ficará aguardando essa disponibilidade para poder dar prosseguimento à medição. 

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

6. Automação do processo: softwares de apoio podem agilizar a contagem, principalmente das partes do processo que não envolvem análise. 

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

8. Guia de Contagem: o guia de contagem é um documento que simplifica e contextualiza as regras do IFPUG para as situações específicas de uma organização. Para analistas com pouca experiência ou com pouco conhecimento do contexto da organização, o guia facilitará bastante o trabalho de medição, proporcionando agilidade. 

Analisando um cenário de pior caso, onde os fatores citados anteriormente estariam influenciando de forma negativa o trabalho de medição, um limite inferior para a produtividade seria 100 PF/dia. Para um cenário de melhor caso seria razoável considerar 1.000 PF/dia. Cabe destacar que a produtividade média não está no meio desta faixa, mas mais perto do cenário de pior caso, que corresponde às situações mais comuns de se encontrar no dia a dia. Dependendo das especificidades que uma organização possui, ela pode eventualmente apresentar números fora da faixa citada, mas não seria um comportamento típico esperado. Produtividade abaixo de 100 PF/dia é sinal de problema, deve-se investigar e atacar as suas causas. Muitas vezes o analista de métricas executa atividades de análise de requisitos, devido à falta de documentação ou à baixa qualidade da mesma. Não seria correto computar este esforço como o de medição, mas sim de análise de requisitos. 

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. 

 

 

39. 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. 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://184.173.196.212/~ifpug/?page_id=316. 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;

 

 

40. O tamanho em pontos de função 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.

41. É 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. Apenas as manutenções que alteram os requisitos funcionais de um software podem ser medidas pela APF, neste caso o IFPUG usa o termo "melhoria" em vez de "manutenção", exatamente para deixar destacada que a melhoria não é qualquer manutenção. No conceito do IFPUG a 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. 

Manutenções para correção de defeitos ou para manter apenas requisitos não funcionais não são medidas pela APF.

 

 

42. 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 elaborados, 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 de software da Holanda - NESMA. São as abordagens: contagem indicativa e a contagem estimativa, detalhadas em http://fattocs.com/pt/contagem-antecipada.html

 

 

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

 

 

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

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

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

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

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

 

 

49. O que é COSMIC?

 

COSMIC é um acrônimo para Common Software Measurement International Consortium. Ela é a organização responsável pela definição e manutenção do método de medição do tamanho funcional que leva o mesmo nome. Seu método de medição:


• É o primeiro projetado para conformidade aos padrões do consórcio entre a ISO e o IEC (ISO/IEC 14143);


• Define uma medida padrão do tamanho funcional do software e cuja aplicabilidade é o software em aplicações comerciais, software em tempo real e híbridos;

 

• Permite o desenvolvimento de extensões locais para funcionalidades com processamento matemático intensivo, funcionalidade em algoritmos complexos e processamento de variáveis contínuas como áudio e vídeo;

 

A aplicação do método produz uma medição (ou uma aproximação do tamanho conforme o interesse e o momento no ciclo de vida em que se encontre) expressa na unidade denominada Pontos de Função COSMIC.

Ele oferece um nível de confiabilidade compatível por todos os tipos de software, está no domínio público e sem custos, tem reconhecimento total pela ISO/IEC e sua base conceitual é compatível com a moderna engenharia de software. Estimativas e medição de desempenho (como a projeção ou a avaliação de metas de produtividade e qualidade) podem ser realizadas com uma maior acuidade se a unidade de produto utilizada é o Ponto de Função COSMIC. O método considera que a medição de um pedaço de software dependa essencialmente de seu uso e permite a medição do mesmo software em múltiplas perspectivas.

 

Para entender um pouco mais da diferença do método COSMIC do método IFPUG, veja Qual a diferença dos métodos COSMIC e IFPUG?

 

O método COSMIC é assunto de nosso curso "Medição e Estimativa de Software com o Método COSMIC".

 

50. Qual a diferença dos métodos COSMIC e IFPUG?

 

O método do COSMIC está para o método do IFPUG na medição do tamanho funcional como o C# está para o COBOL nas linguagens de programação.

 

Por que uma funcionalidade de transação pode chegar no máximo a 07 PF quando usamos o método do IFPUG? Porque o estudo para criar o método foi realizado com uma amostra de 22 projetos entre 1974 e 1979 e os números usados nas tabelas de complexidade nasciam a partir de:

 

"Essas contagens são ponderadas pelos números projetados para refletir o valor da função
para o cliente. As ponderações utilizadas foram determinadas por debates e julgamentos. Esses
pesos têm nos dado bons resultados:
• Número de Entradas x 4;
• Número de Saídas x 5;
• Número de Consultas x 4;
• Número de Arquivos Mestre x 10;" - Allan Albrecht em Medindo a Produtividade do Desenvolvimento de Aplicativos (1979).

 

Ter previamente definidos esses pesos entre 3 e 15 PF por funcionalidade provoca uma série de problemas. Fenômenos como o aumento da variabilidade em estimativas e a maior dificuldade no planejamento e na avaliação de desempenho no contexto em que a métrica está inserida (projeto, empresa, equipe, etc.). Por exemplo:

 

• Como tratar a contagem dos dados de código em um cenário em que os mesmos necessitam de uma apropriação direta de custos? Uma transação de manutenção em dados de código, no mínimo, contribuiria (se fosse medida) com 03 PF; estaria muito próximo à uma manutenção cadastral ainda que a diferença no esforço seja brutal?

 

• Como lidar com as várias funcionalidades com diversas pequenas variações e, ainda assim, no máximo pode contribuir com 07 PF? Ainda que exijam um esforço bem maior que outras, todas esbarram no mesmo teto?

 

A resposta para todos essas questões é considerar que há momentos em que se apura uma produtividade maior que a produtividade média e há momentos em que se apura uma produtividade menor que a produtividade média... Mas será que é necessária uma dispersão tão grande? Usando o método do COSMIC, não.

 

No método do COSMIC, não há qualquer critério empírico de complexidade. Não há entendimento comum na comunidade de engenharia de software do que seja complexidade! O método simplesmente conta cada movimentação de um grupo de dados entre o software e o usuário, ou entre o software e algum mecanismo de armazenamento, como uma unidade, um ponto de função COSMIC.

 

Outra diferença entre os dois métodos é o tratamento de manutenção. Enquanto o método do IFPUG considera apenas funcionalidades incluídas, alteradas e excluídas, o método do COSMIC considera os movimentos de dados incluídos, alterados ou excluídos. Com isso dando uma solução muito mais eficaz que a solução dada pelo IFPUG e muito mais elegante que a adoção de fatores de impacto entre 0,25 e 1,50 pela NESMA em seu ponto de função de melhoria. Com a abordagem do COSMIC, os resultados da medição podem ser usados em diversos casos que - quando medidos usando o método do IFPUG - ficam classificados como requisitos não funcionais e que não podem ser medidos por um método de medição do tamanho funcional.

 

O método do IFPUG trabalha essencialmente com a medição em uma camada de aplicação. Isso dificulta a medição do software em cenários que envolvem, por exemplo, a troca de uma infraestrutura de suporte como um banco de dados, sistema operacional ou servidor de aplicação. Já o método do COSMIC tem intrínseco em seu modelo o conceito de camada e o papel de usuário que um software em uma camada superior tem em relação ao software em uma camada inferior.

 

Além do conceito de camada, o COSMIC traz o conceito de componentes pares, que permite que uma mesma aplicação seja medida considerando, por exemplo, a sua camada de apresentação, sua camada de regras de negócio e sua camada de persistência. Obviamente a soma das partes será maior que o todo por a medição das partes considerar movimentos internos; contudo, o método orienta em como se trabalhar nesses cenários.

 

Enquanto no método do IFPUG há uma página descrevendo o que seja propósito, escopo e fronteira da aplicação, no método do COSMIC há toda uma fase denominada Estratégia da Medição para colocar o software em análise no modelo de contexto de software com as diferentes camadas e componentes pares conforme os objetivos da medição e os requisitos do usuário.

 

51. Como funciona o processo de medição COSMIC?

 

São três fases:

 

• Fase de Definição da Estratégia de Medição: consiste em avaliar os objetivos da medição em termos do modelo de contexto de software para definir o propósito da medição de cada pedaço de software a ser medido, incluindo fronteiras;

 

• Fase de Mapeamento: avalia os requisitos funcionais do usuário em artefatos do software a ser medido em termos do modelo geral de software. Ela organiza os requisitos na forma desse modelo para, na fase de medição, serem convertidos no tamanho funcional do software em unidades de pontos de função COSMIC;

 

• Fase de Medição: associa a cada movimento de dados entre as fronteiras definidas nas fases anteriores o valor de um ponto de função COSMIC.

.

 

.