FAQ.

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.

Não.

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

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.

A medição é baseada somente nos requisitos descrevendo o que o software deve atender.

O Grupo Internacional de Usuários de Pontos de Função ou International Function Point Users Group (IFPUG) é uma entidade sem fins lucrativos. Seus membros são pessoas e empresas associados de diversos países. Sua finalidade é promover um melhor gerenciamento dos processos de desenvolvimento e manutenção de software pelo uso da Análise de Pontos de Função (APF).

O padrão para medição de Pontos de Função reconhecido pela indústria de software é o Manual de Práticas de Contagem de Pontos de Função ou Counting Practices Manual (CPM). Atualmente, ele se encontra na versão 4.3; publicada em 2010.

Sim.

Desde a publicação da publicação original em 1979, diversos refinamentos foram incorporados à técnica ao longo dos anos. E isso ainda continua. No entanto, a essência da técnica muda muito pouco.

Os requisitos funcionais são derivados da inserção do software em atividades dos processos de negócio. São histórias contando o comportamento esperado pelo software naquele contexto.

Os elementos pelos quais cada história é contada depende dos ambientes produtivos e frameworks para execução de software;  ferramentas e ambientes de construção e testes; metodologias de desenvolvimento e gestão; ou linguagens de programação. Eles não influenciam diretamente a medição.

Enquanto os elementos de uma história podem se manter os mesmos por séculos, os elementos pelos quais uma história é contada pode e muda quase todo o dia.

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.

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 às práticas de medição; melhorando assim a consistência das medições e reduzindo a subjetividade nas interpretações.

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.

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 tecnologia OO ou uma outra abordagem.

O que poderá diferenciar as duas abordagens é que no projeto OO a produtividade 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.

Normalmente este tipo de trabalho envolve um escopo muito reduzido. Como conseqüência é difícil estabelecer uma relação entre o tamanho funcional e outras métricas fundamentais como esforço, prazo e custo. Entretanto deve-se lembrar que APF não é simplesmente uma ferramenta para geração de estimativas, utilizada em planejamento de projetos. A natureza do trabalho envolvido na pergunta caracteriza-se não como um projeto mas como uma operação contínua.

Tome-se como exemplo a manutenção de sistemas com esforço estimado em até 200 horas. Isoladamente o dimensionamento das ordens de serviço que representam os requisitos (nem sempre funcionais) objeto de manutenção pode não apresentar uma relação linear com o esforço envolvido em sua realização. Contudo, levando-se em conta o universo compreendido pelo conjunto destas solicitações em determinado período de tempo maior, pode-se chegar a conclusões diferentes.

Por exemplo, determinada solicitação de manutenção não envolvia o acréscimo, modificação ou exclusão de funcionalidades de determinado sistema. Neste caso sem dúvida é inútil saber que o tamanho funcional da manutenção será de zero pontos de função. Mas o sistema em que se dá a manutenção tem um tamanho funcional. Pode-se acompanhar a evolução da quantidade de horas de manutenção por ponto de função deste sistema. Tal tendência ajuda a avaliar se está na hora de substituir este sistema por um novo.

Suponha que nesta organização haja um processo onde, após a ordem de serviço ter sido atendida pela equipe de manutenção, o produto passe por um processo de homologação. O conjunto de funcionalidades em homologação pode ser dimensionado em termos de pontos de função. Da mesma forma pode ser documentada a quantidade de defeitos identificadas no processo. O acompanhamento do inter-relacionamento destas duas métricas - Pontos de Função e Defeitos - durante um período de tempo pode trazer a tona problemas no processo de manutenção. Com base nessa tendência é possível empreender ações para diminuir esta relação.

O Ponto de Função mede o tamanho funcional do software e não o esforço envolvido em sua concepção e construção. Quanto maior a linearidade encontrada entre o tamanho funcional e este esforço, ou seja, a produtividade, maior o valor prático da medida obtida. Quanto mais linear for esta relação, mais facilmente podem ser extrapoladas outras medidas a partir do tamanho funcional, como o custo e o esforço por exemplo.

Se observarmos em um nível micro, na avaliação do dimensionamento de duas transações pontuais, sem dúvida o potencial de desvio na produtividade auferida é alto, mas na medida que expandimos esta amostragem percebemos que as situações extremas se compensam e, em média, podemos observar uma maior linearidade na relação entre o esforço e o tamanho funcional.

Vamos pensar em algumas métricas alternativas ao ponto de função avaliando o impacto destas considerações sobre estas métricas, por exemplo, Linhas de Código. Na organização como um todo, ou mesmo em um projeto específico, também existem situações em que a contagem do número de linhas de código não estará diretamente relacionada ao esforço envolvido na especificação, documentação e testes dos mesmos. Ou seja, existem dois projetos, com diferentes requisitos de qualidade ou maior demanda na especificação, onde apesar de um deles ser mais "complexo" e requerer maior esforço de desenvolvimento o software resultante possui menos linhas de código que o outro. Isto sem falar nas várias outras limitações inerentes à métrica de LOC.

Existem diversos softwares que, a partir do modelo de um programa ou de seu código fonte calculam seu tamanho em pontos de função. Entretanto comparações entre os números apresentados por diferentes ferramentas para um mesmo sistema não raro apresentam uma variação inaceitável. Estes números por sua vez, também freqüentemente diferem em muito de uma contagem manual.

A resposta para essa variação está em como estas ferramentas calculam o número de pontos de função. Algumas se baseiam nos arquivos, telas, relatórios e outros elementos para derivar um número. Embora muitas vezes haja uma relação direta entre estes objetos e as funções de dados e transações da APF, deve ser lembrado que a técnica mede apenas as funções lógicas do sistema. E estas ferramentas têm dificuldades em diferenciar funções lógicas de funções físicas. Por exemplo, nem todo arquivo ou tabela de um programa corresponde a um arquivo lógico interno ou arquivo de interface externa. Ou ainda, um processo elementar pode estar implementado através de várias telas. Para que a medição fosse feita corretamente, o software teria que ter inteligência o suficiente para fazer este discernimento. Ou seja, este software teria que ter a habilidade de ler o programa e interpretar os requisitos do usuário. Ainda não há software com esta inteligência artificial.

Outras ferramentas se baseiam na técnica de backfiring, que consiste em derivar o número de pontos de função a partir da quantidade de linhas de código do programa, baseado numa relação pré-estabelecida entre LOC e PF. Contudo esta é uma técnica que tem sido muito criticada e cuja aplicação é restrita.

Existem sim softwares de apoio ao processo de contagem de pontos de função que automatizam parte do processo, porém a decisão e análise do que deve ser considerado, continua sendo responsabilidade de um usuário humano que entra com os dados e não do software.

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

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.

Com o objetivo de resolver as inconsistências existentes entre diversos métodos surgidos a partir do modelo da Análise de Pontos de Função proposto por Allan Albrecht e estabelecer um método mais rigoroso de medição de tamanho funcional, formou-se um grupo de trabalho denominado WG12 (Working Group 12), subordinado ao SC7 (Sub-Committee Seven) do JTC1 (Joint Technical Committee One) estabelecido pela ISO (International Organization for Standardization) em conjunto com o IEC (International Engineering Consortium).

Como resultado dos trabalhos do WG12 foi estabelecida a norma 14.143, que é dividida em cinco partes:
14.143-1: Definição de Conceitos;
14.143-2: Avaliação da Conformidade de Métodos de Medição de Software com Relação ao padrão ISO/IEC 14143-1;
14.143-3: Verificação de um Método de Medição de Tamanho Funcional;
14.143-4: Modelo de Referência para Medição Funcional de Tamanho;
14.143-5: Determinação de Domínios Funcionais para uso com Medição de Tamanho Funcional.

A norma ISO/IEC 14143 foi desenvolvida para garantir que todos os métodos de Medição de Tamanho Funcional sejam baseados em conceitos similares e que possam ser testados para assegurar que eles se comportam de maneira similar e da forma esperada por um método de medição, dependendo dos domínios funcionais a que se aplicam.

Ao final do ano de 2002 a técnica de análise de pontos de função, conforme definida na versão 4.x do manual do IFPUG, foi aprovada (sob a norma 20.926) como um método de Medição de Tamanho Funcional aderente à norma ISO/IEC 14.143.

Sim, existem três outros métodos padrão de medição funcional:

NESMA - A associação de métricas da Holanda mantém seu próprio manual de contagem, atualmente na versão 2.0, cuja primeira versão em 1990 foi baseada no manual do IFPUG. Utiliza a mesma filosofia, conceitos, termos e regras do IFPUG, com algumas diretrizes diferentes. A medição de um projeto de desenvolvimento ou de uma aplicação produz resultados bem próximos tanto na abordagem do IFPUG quanto da NESMA. Entretanto ambas organizações possuem abordagens distintas para a aplicação da análise de pontos de função em projetos de melhoria de software.

Mark II - foi formulado por Charles Symons em meados da década de 80. Sua disseminação foi dificultada inicialmente pelo fato do método ser propriedade da consultoria KPMG por vários anos. Atualmente é um método de domínio público mantido pela associação de métricas do Reino Unido - UKSMA. É um método de aplicação restrita ao Reino Unido.

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

O primeiro passo é identificar claramente quais os objetivos da organização. A APF pode ser empregada com várias finalidades: estimativas de projetos de software, unidade de medição de contratos, apoio ao controle de qualidade e produtividade, benchmarking e programa de métricas.

Cada enfoque específico possui suas particularidades; entretanto existem aspectos comuns a todos eles, destacados a seguir.

1. Conquiste o apoio da direção da organização. Tenha em mente que os resultados do emprego da APF na organização nem sempre serão imediatos e que o sucesso de sua utilização dependerá de dedicação e do emprego de recursos humanos e financeiros, assim como em qualquer programa que objetive a melhoria de processos.

2. Aproveite as oportunidades já existentes na organização e que possam ter alguns objetivos comuns. Exemplos destas iniciativas são: ISO, Six-Sigma, CMM, PMI, Balanced Scorecard. Pegando carona nestas iniciativas e sabendo relacionar (e mostrar para os patrocinadores) como a APF pode contribuir com alguns de seus objetivos a aceitação fica facilitada.

3. Capacite-se. Conhecer corretamente a técnica é fundamental. É surpreendente o número de casos que presenciamos em que a APF é aplicada incorretamente, e que invariavelmente terminam em insucesso. A referência oficial da técnica é o manual do IFPUG - o CPM (Counting Practices Manual). Ações interessantes neste sentido podem ser:

- Contratar uma turma fechada de um curso para toda equipe envolvida, podendo assim adequar a carga horária ou ementa do curso com os objetivos do processo e a realidade da organização. Neste caso a FATTO costuma realizar um pacote de serviços com duração de uma semana: dois dias para ministrar o curso Capacitação em Análise de Pontos de Função e três dias para consultoria no início do processo e mentoring na aplicação da técnica em casos práticos da organização.

- Inscrever pessoas chave no processo em cursos abertos sobre a técnica de pontos de função. A FATTO ministra cursos abertos regularmente em várias cidades no Brasil, consulte o nosso calendário de cursos para mais informações.

4. Estabeleça objetivos iniciais modestos. Comece com um projeto piloto em um sistema simples. Avalie os resultados, efetue as correções necessárias, revise os objetivos e siga em frente.

5. Esteja ciente das limitações da técnica. Existem domínios de problema em que a APF não é indicada. Por exemplo, em sistemas de otimização, a técnica não é adequada para medir as partes com alta complexidade algorítmica.

6. Na dúvida, faça a analogia com o metro quadrado. Em geral, isto é suficiente para resolver a questão.

7. Busque ajuda se necessário. Uma consultoria externa pode evitar "cabeçadas desnecessárias" e agilizar o processo, trazendo experiências e ajudando a corrigir rumos.

8. Não compare laranjas com bananas. As comparações devem ser feitas apenas entre projetos que tenham similaridades (processo de desenvolvimento, plataforma tecnológica, área de negócio, etc).

Além das considerações gerais apresentadas na pergunta anterior, a seguir são apresentadas algumas orientações específicas para o uso de pontos de função em estimativas.

Embora alguns autores citem o uso de pontos de função para derivar diretamente estimativas iniciais de prazo, defeitos e tamanho de equipe, o mais comum é o uso para estimativas de esforço (geralmente quantidade de horas).

O processo para estimar esforço é muito simples: dada uma produtividade (horas/ponto de função) em determinado ambiente de desenvolvimento, basta multiplicá-la pelo tamanho funcional do software para se obter a estimativa desejada.

Entretanto, a questão chave é: qual produtividade empregar? Muitos utilizam os indicadores de mercado publicados por diversas organizações. Porém muitas dessas pessoas ficam frustradas com o resultado obtido.

A resposta é que não há números mágicos. A produtividade a ser empregada é a própria de cada organização e não uma média do mercado. Ela deve refletir a realidade do processo de desenvolvimento da organização em determinado contexto: ferramenta de desenvolvimento, área de negócio ou plataforma tecnológica.

Para obter seus próprios números, a organização pode recorrer aos dados de projetos anteriores e recuperar suas informações de esforço e tamanho em pontos de função. Agrupando os projetos similares, é possível obter um indicador de produtividade confiável.

Além das considerações gerais apresentadas pergunta 21, são apresentadas a seguir algumas orientações específicas para o uso de pontos de função nos três principais modelos de contratação utilizados: Homem/Hora, Preço Global Fixo e Preço Unitário.

Caso a modalidade de contratação utilizada seja homem/hora, onde a remuneração do fornecedor não é baseada nos resultados apresentados, mas sim na quantidade de horas de trabalho apuradas num período, pode-se utilizar a APF para, por exemplo, monitorar a produtividade da equipe. Para tanto, basta que os dados de resultados (pontos de função) sejam medidos juntamente com os dados de esforço (horas) e que sejam realizadas avaliações que relacionem ambas as informações.

Quando a contratação é baseada em preço global fixo, a APF pode ser utilizada como um fator de normalização de preço, visando garantir que o valor cobrado por funcionalidades adicionais não previstas ou durante a fase de manutenção, seja compatível com o valor cobrado no momento da contratação do serviço.

Mede-se o tamanho do projeto em pontos de função e, a partir do valor total cobrado pelo fornecedor para o projeto, calcula-se o valor do ponto de função. As novas propostas são medidas quanto ao seu tamanho e, então aplica-se o valor do ponto de função para se obter o valor das novas funcionalidades. Este valor pode então ser comparado ao valor proposto pelo fornecedor.

Contudo, o modelo que melhor consegue equilibrar as deficiências da contratação por homem/hora e por preço global fixo é o baseado em preço unitário (pontos de função). Caso o fornecedor tenha uma produtividade baixa, não será remunerado pelo tempo extra consumido. Caso contrário poderá usufruir de uma melhor rentabilidade do serviço. Se houver aumento de escopo do serviço, não serão necessárias negociações desgastantes para se estabelecer um valor para o serviço adicional.

Nesta modalidade, um fator importante é definir corretamente o valor do ponto de função, conforme aborda a pergunta 14.

Em qualquer das modalidades de contratação adotada deve-se ter o cuidado com os conflitos de interesse: a medição do serviço em pontos de função nunca deve ser realizada somente pelo fornecedor, pois ele será remunerado justamente pelo resultado da medição! Observa-se esta prática indesejável em algumas organizações (inclusive públicas). Pode-se utilizar pessoal interno para realizar a medição, ou na pior das hipóteses validar por amostragem as medições realizadas. Outra opção é contratar uma empresa externa para este serviço.

O processo de benchmarking da produtividade do desenvolvimento de software, assim como o de qualquer outro indicador, depende fundamentalmente do seguinte questionamento: sua organização possui internamente dados válidos, comparáveis com aqueles que serão obtidos no mercado?

Na verdade, a importância dessa pergunta pode ser percebida quando se afirma que "não se pode realizar o benchmarking de um dado que não foi coletado". Apesar de parecer óbvia, a simplicidade dessa afirmação desaparece ao se avaliar o esforço necessário para obter dados internos confiáveis, que retratem a realidade da organização.

O processo começa, então, com a coleta desses dados. Deve-se ter em mente que não é suficiente escrever um questionário e entregá-lo para que as pessoas o respondam. É necessário se ter um planejamento para garantir que as definições das variáveis de interesse e as possíveis respostas estejam claras antes de iniciar a coleta de dados. Um maior tempo gasto com tal planejamento visa reduzir o risco da coleta de dados errados e o esforço gasto na validação dos dados.

Agora, por analogia e conhecendo-se o conceito de produtividade, pode-se afirmar que não é possível realizar o benchmarking da produtividade do desenvolvimento de software sem o conhecimento dos dados de tamanho e esforço dos projetos da organização. O tamanho geralmente é medido em Pontos de Função (PF) e o esforço em Horas (H). Conforme já mencionado, a coleta desses dados deve ser realizada de forma que possam ser comparados com os indicadores obtidos no mercado. A chave para o sucesso do benchmarking é a extratificação dos dados. É fundamental que as coletas sejam realizadas segundo a similaridade dos projetos, uma vez que a produtividade pode ser altamente variável dependendo do setor de negócios do projeto, da plataforma de hardware e software, da época em que o projeto foi iniciado, etc.

O benchmarking é realizado, então, sob a mesma extratificação adotada no momento das coletas dos dados internos à organização. Contudo, nesse momento ainda é necessário observar atenciosamente algumas outras questões, na tentativa de explorar o nível de adequação do indicador a um determinado projeto ou ambiente:

a) Os critérios de coleta de horas utilizados na elaboração dos indicadores de mercado são compatíveis com os utilizados na organização?

Por exemplo: quantas horas são consideradas em um mês de trabalho (126, 160, 168, etc.)? Qual a carga horária diária de trabalho (4, 6, 8, etc.)?

b) O método de contagem do tamanho funcional utilizado na elaboração do indicador de mercado é compatível com o da organização?

Por exemplo: utilizou-se o fator de ajuste definido pelo método do IFPUG?

c) As atividades envolvidas, os produtos gerados, a metodologia adotada envolve a mesma utilização de recursos que o contexto em análise exige?

Por exemplo: quais modelos de projeto e diagramas são utilizados? Existem papéis definidos para cada atividade realizada, inclusive para implementar o controle de qualidade dos projetos?

d) Mesmo sendo diferentes, o risco desta variabilidade é aceitável?

Um outro fator a ser considerado é a importância da atualização dos dados utilizados no benchmarking. No mais, vale ressaltar que quanto mais projetos forem utilizados no processo de benchmarking, melhor. Após tomados todos os cuidados necessários, se ainda houverem dúvidas quanto aos resultados obtidos para a produtividade do desenvolvimento de software, utilize um intervalo ao invés de um valor exato para o indicador.

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.

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.

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.

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.

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.

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.

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.

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 na página de certificação de software do IFPUG. Segundo esse processo, as ferramentas podem ser classificadas em três tipos:

Tipo 1: O usuário faz a contagem de pontos função manualmente e software fornece as funcionalidades de coletas de dados e cálculos.

Tipo 2: O software fornece as funcionalidades de coletas de dados e cálculos e o usuário e o sistema fazem a contagem de pontos de função interativamente, através de perguntas apresentadas pelo sistema e ações sendo tomadas automaticamente em função das respostas fornecidas.

Tipo 3: O software produz automaticamente uma contagem de pontos de função usando várias fontes de informação, como a base de dados da aplicação, a própria aplicação e artefatos das ferramentas de desenvolvimento. O usuário pode entrar com dados interativamente, mas o seu envolvimento durante a contagem é mínimo. Importante destacar que não existem ferramentas certificadas deste tipo.

Embora existam várias opções de ferramentas no mercado para apoiar o uso de pontos de função; muitas organizações optam por desenvolver uma ferramenta própria integrada a seus sistemas de controle internos. Algumas razões para isto podem ser:
- o custo para desenvolver uma solução interna é menor que o custo de aquisição e manutenção dos pacotes disponíveis no mercado;
- a falta de suporte local para a solução, uma vez que a maioria das ferramentas disponíveis no mercado são estrangeiras;
- necessidades de integração com sistemas internos;

Quando se fala em requisitos de hardware necessários para o ambiente de execução de um determinado software, o foco da questão está em requisitos técnicos ou de qualidade do mesmo, como capacidade de processamento, volume de transações e de dados, número de usuários, segurança, etc. Os requisitos funcionais não influenciam em nada nessa questão. Portanto, não há nenhuma relação direta entre o tamanho de um software em pontos de função (seja ajustado ou não) com o hardware necessário à sua execução.

Porém o fator de ajuste, analisado de forma isolada do tamanho funcional, contempla várias características gerais de sistema (Processamento Distribuído, Performance, Configuração Altamente Utilizada, Volume de Transações) que poderiam auxiliar na definição dos requisitos de hardware de um software, mas ainda assim seria uma análise insuficiente para a definição do hardware.

Sim; porém nem todas as manutenções em um software são passíveis de serem medidas com a APF. 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.

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 https://www.fattocs.com/analise-de-pontos-de-funcao/contagem-antecipada-de-pontos-de-funcao/

A essência da APF, pregada pelo IFPUG, é que o processo de contagem de pontos de função deve ser consistente (pessoas diferentes medindo o mesmo projeto devem encontrar resultados similares) e também, mas principalmente, que a contagem seja simples o suficiente para minimizar o esforço de medição, reduzindo o impacto sobre o esforço global do projeto.

Assim como qualquer outra atividade de um projeto de desenvolvimento ou manutenção de software, realizar uma contagem de pontos de função demanda o esforço de um profissional da equipe. Logo haverá um esforço adicional no projeto para que se realize a medição.

O que se deve considerar é que os benefícios obtidos pela realização da medição compensem o esforço adicional dispendido. Em tese o software pode ser desenvolvido somente com as atividades de codificação; porém outras atividades são realizadas (como análise, planejamento, modelagem, testes, etc) que irão "onerar" o esforço do projeto mas que proporcionam benefícios que suplantam esse esforço adicional.

Traduzindo em números, o ideal seria que esse esforço ocasionado pela medição não ultrapassasse 2% do esforço total do projeto. Importante destacar que, em muitos casos onde isto não ocorre, a causa está numa deficiência da especificação dos requisitos. Nestes casos a maior parte do esforço da contagem de pontos de função acaba sendo consumido em entrevistas, revisão e detalhamento de requisitos. Atividades que deveriam ter sido realizadas na fase de especificação propriamente dita.

Basicamente todas as atividades que possuem relação direta com a construção e entrega dos requisitos funcionais: levantamento e especificação de requisitos, análise, projeto, modelagem, gerência do projeto, codificação, testes, apoio à homologação do usuário, implantação e transferência de conhecimento do serviço executado. Sendo que vários artefatos podem ser produzidos nestas atividades, como: código fonte, diagramas, modelos, casos de uso, manuais, planos, atas, etc.

Por complemento ao parágrafo anterior, quaisquer atividades não diretamente relacionadas aos requisitos funcionais do projeto de desenvolvimento/manutenção do software não estão no escopo da estimativa por PF. Exemplos: treinamento de usuários, acompanhamento do sistema em produção, administração do banco de dados, atendimento de dúvidas ou reclamações de usuários, atividades de suporte a infra-estrutura tecnológica, etc.

É possível também realizar a estimativa para apenas algumas atividades específicas do projeto. Para isto é necessário conhecer a distribuição (%) de esforço que cada fase costuma consumir do projeto todo. Conhecendo esta relação, estima-se o esforço total do projeto e aplica-se o percentual de cada fase desejada para se saber o esforço estimado para aquelas atividades.

A maioria dos erros encontrados em uma contagem de pontos de função de um sistema é causada por quatro fatores:

- Desconhecimento da técnica: ainda há um grande número de profissionais que são designados para contar pontos de função de um sistema sem o conhecimento necessário do processo de contagem. Talvez isto ocorra por haver uma idéia generalizada de que a APF seja muito simples. E na realidade ela é, porém isto não significa que seja desnecessário treinamento profissional ou um estudo mais dedicado da técnica. Com apenas um conhecimento superficial da APF é bem provável que o analista cometa erros básicos. Sobre este aspecto, o IFPUG estabeleceu o seu programa de certificação profissional CFPS, que visa garantir que o profissional certificado conhece todas as definições e regras do seu Manual de Práticas de Contagem em sua versão mais recente.

- Deixar a contagem ser "contaminada" pela implementação: a APF é uma técnica para medir requisitos funcionais de um software. Ou seja, mede o que o usuário solicita e recebe do software independente do como este foi implementado. Logo, o resultado de uma contagem de pontos de função tem que ser o mesmo, seja qual for a solução de implementação (processo, arquitetura, ferramentas, ambiente computacional, etc) adotada pelo desenvolvedor. Contar pontos de função de um sistema é um exercício de abstração do problema de negócio do usuário que o software deve atender. Porém nem sempre isto é uma tarefa fácil e mesmo analistas de pontos de função experientes podem desviar o foco da contagem para a solução de implementação do desenvolvedor. Muitas vezes o analista é induzido neste caminho por falta de documentação adequada.

- Falta de conhecimento do negócio: não adianta ser especialista na APF e não conhecer o negócio do usuário. Para que a contagem de pontos de função seja feita de forma correta, ou seja, do ponto de vista do usuário, é necessário que o analista de pontos de função busque o entendimento do negócio primeiro e somente depois realize a contagem de pontos de função. Muitas vezes não há tempo disponível para que o analista de pontos de função busque este conhecimento. Neste caso ele irá atuar em parceria com um analista de negócio ou com um usuário para poder realizar a contagem de pontos de função.

- Qualidade dos requisitos disponíveis: muito se fala na engenharia de software sobre a importância do levantamento de requisitos e do impacto que isto tem em todo o projeto quando esta tarefa não é bem executada. Para a contagem de pontos de função isto não é diferente. Se os documentos de onde o analista de pontos de função extrai os requisitos do usuário para realizar a contagem estão ambíguos, incompletos ou mal escritos, certamente o resultado da contagem será afetado.

Esta relação de fatores não está apresentada em nenhuma ordem específica, mas é bastante representativa dos principais fatores que causam contagem de pontos de função incorretas.

Não há um documento específico de uso obrigatório para se medir um software (ou contar pontos de função). Qualquer documento no qual seja possível extrair informações dos requisitos do usuário pode ser usado em uma contagem de pontos de função. Sejam eles casos de uso, manuais, protótipos, documentos de visão, modelo de dados, modelo de classes, etc. Isto é coerente com o próprio objetivo da APF que é ser uma técnica independente da implementação do software. Pode-se implementar um software através de diferentes métodos e ferramentas para análise, modelagem e construção, para diversas plataformas computacionais; mas nada disso afeta a medição do mesmo em pontos de função.

É claro que determinados tipos de documentos podem trazer a informação necessária para uma contagem de pontos de função de maneira mais fácil. Outros documentos podem conter apenas parte da informação necessária para a contagem de PFs, sendo necessário a análise conjunta de mais documentos para se efetuar a medição. Assim como também outros documentos, por terem um caráter mais técnico para o processo de desenvolvimento de software, podem dar mais trabalho para se extrair os requisitos do usuário. O melhor documento para se utilizar numa contagem de PFs é aquele que contém os requisitos do usuário explicitados na linguagem do seu negócio, e não num linguajar de TI.

Cada organização possui o seu processo de desenvolvimento particular, produzindo uma quantidade de documentos (ou artefatos) distintos em determinadas fases do processo. Logo, o momento no qual a medição é feita acaba determinando também quais documentos estarão disponíveis para se efetuar o trabalho de medição (ou estimativa) do tamanho funcional do projeto.

Os requisitos do software são fundamentais para a APF, pois o processo de medição é baseado exclusivamente neles. O insumo básico da medição são os requisitos do sistema. Convém destacar que a APF mede apenas uma parte dos requisitos do usuário para o sistema: os requisitos funcionais. Os requisitos não funcionais não são medidos pela APF. Porém num modelo de estimativa de custo baseado em PF (custo = tamanho x $/PF), ambos os tipos de requisitos (funcionais e não funcionais) são considerados: o primeiro irá afetar o tamanho funcional e o segundo afetará o custo unitário ($/PF).

Devido a esta importância dos requisitos para a APF, quanto melhor a qualidade dos requisitos, mais fácil e ágil torna-se o processo de medição, e mais preciso é o resultado. Requisitos de qualidade ruim afetam negativamente todo o projeto de software, inclusive a atividade de medição. Porém um efeito colateral benéfico do processo de medição é justamente evidenciar falhas nos requisitos. Quanto mais cedo no projeto estas falhas forem identificadas, menor o custo de corrigí-las e maior a chance de sucesso do projeto.

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. Embora projetado para domínios de software como: sistemas de informação gerencial, tempo real e de infraestrutura a estes, tem uma aplicabilidade bastante ampla;
• Possui uma flexibilidade que permite o desenvolvimento de extensões locais do método para tratar problemas específicos, por exemplo: softwares com processamento matemático intensivo, 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 (PFC).

Ele oferece um nível de confiabilidade compatível por todos os tipos de software, é de 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".

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.

O processo de medição COSMIC possui três fases:

• Fase de Definição da Estratégia de Medição:

Consiste em avaliar os objetivos da medição para definir o propósito da medição de cada pedaço de software a ser medido, incluindo suas fronteiras;

• Fase de Mapeamento:

Avalia os requisitos funcionais do usuário dos artefatos do software a ser medido em termos do modelo geral de software. Este modelo define que uma função do software (ou processo funcional) é composto de dois tipos de subprocessos: movimentos e manipulação de dados. Por simplificação, apenas os movimentos de dados de um processo funcional são medidos, e há quatro tipos de movimentos: entrada, saída, leitura e gravação;

• 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, soma os movimentos de dados de cada processo funcional e em seguida o tamanho de todos os processos funcionais considerados no escopo da análise para obter o resultado final da medição.

Para mais detalhes, consulte o COSMIC Measurement Manual em http://www.cosmic-sizing.org/ ou o nosso cartão de referência rápida: COSMIC Quick Reference Card.

O custo para inscrição no exame é de US$175,00 por pessoa e pode ser feito diretamente em https://isqi-shop.org/index.php?id_product=42&controller=product&search_query=snap&results=1.

Somente pessoas filiadas ao IFPUG podem se inscrever para o exame de certificação CSP - SNAP Practitioner. Dessa maneira, os custos para a certificação devem ser analisados conjuntamente com os custos da filiação ao IFPUG.

Importante: os profissionais certificados devem manter sua filiação regular por todo o período de validade da certificação sob pena da mesma ser cancelada. Portanto,  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

Fonte: http://www.ifpug.org/membership/membership-duesfees/

Dica 1: a empresa que deseja certificar a partir de 3 profissionais, a filiação corporativa torna-se mais econômica.

Dica 2: Capacite-se no método de Medição Não Funcional - SNAP em nosso curso on-line.

Dica 3: Ao invés de formar pessoas e arcar com os custos de certificação e manutenção da certificação, contrate o nosso Escritório de Métricas, com vários profissionais certificados em SNAP.

O Programa de Extensão de Certificação (CEP) do IFPUG foi criado para àquelas pessoas que possuem uma designação CFPS na versão "Major" (colocar em negrito e itálico) do Manual de Práticas de Contagem (CPM) do IFPUG e atendam aos critérios de crédito de atividades previsto no programa. Esta extensão pode ser solicitada para de 1 a 3 anos, devendo a pessoa enviar as informações e comprovações solicitadas pelo programa, dentro do prazo previsto.

Obs: não há limitação de solicitação de extensão, sendo a única restrição que a pessoa solicitante de extensão a peça em versão "Major" (colocar em negrito e itálico) compatível à versão de sua certificação.

Mais informações em http://www.ifpug.org/certification/cfps-certification-extension-program/