61 — Pontos de função em sistemas GIS

O perigo da abordagem utilitarista dos pontos de função em sistemas GIS

Venho convivendo com tecnologia a quase 30 anos, com construção de sistemas GIS a quase 20 anos e a praticamente dois tenho me aprofundado com esta métrica de software. Seu propósito é quase que exclusivamente dimensionar o “tamanho” de um software e tentar esquivar-se da famigerada hora técnica ou software de caixinha, que em nenhum dos casos, é bem aceita por governos.

Não sou especialista em contagem, nem de longe me certifiquei nesta abordagem, apenas trago aqui meu entendimento até o momento a cerca desta métrica perigosa de software que até um tempo atrás eu defendia.


A estratégia de dizer que o software “não está pronto” e que não irá pagá-lo até que esteja é comumente utilizada por gestores públicos das mais diferentes circunscrições causou essa incrível demanda por métricas que façam-os pagar por pedaços de software.

O problema da comunicação se apresenta fortemente quando eles não se envolvem suficientemente em projetos de software pelos três principais motivos:

  • Desconhecimento técnico;
  • Desinteresse político;
  • Preguiça.

Dado o desinteresse qie se levante requisitos de software mais efetivamente desenvolve-se uma metodologia de contagem de software que tente resolver parte dos problemas.

Mas o que está por trás desta estratégia de melhoria da “qualidade” da gestão pública? Será que a ideia seria apenas estimar o esforço utilizado ou a ser utilizado por uma empresa prestadora de serviço ou há algo muito maior por trás disso?

Mas voltando ao nosso tema, porque utilizar a APF em provimento de sistemas é um risco em sí mesmo? Vamos ao ponto:

Vamos exercitar a seguinte questão: Por que que uma empresa pública contrata uma empresa de pequeno ou médio porte para construir um software especialista. O que ela quer?

  1. Resolver o seu problema?
  2. Ser mais produtiva?
  3. Aprofundar-se no mercado tirar proveito dessas demandas reprimidas?
  4. Encontrar uma nicho na qual pode produzir e realizar mais negociações políticas?

Pode haver uma lógica perversa nestas negociações entre uma empresa de contagem e uma fornecedora de software. Essas empresas podem especializar tanto em contagem quanto em sugar o business dos verdadeiros criadores de inovação e desenvolvimento. A quem mais interessaria uma métrica na qual o seu concorrente tem que dar todas as informações sobre o produto desenvolvido em nome de uma métrica bem apurada?

Em sistemas especialistas como sistemas GIS a aplicação desta métrica é bastante danosa. A contagem desenvolvida pelo IFPUG certamente não foi baseada em sistemas especialistas mas sim em sistemas tradicionais (CRUD). Sistemas GIS serão sempre nivelados para baixo dada a completa ignorância acerca do grau de complexidade que uma solução GIS demanda.

Apenas lembrando que em muitos casos ter um mapinha na tela pode demandar que se levante um avião e que o sobrevoe pela cidade inteira.

Sistemas GIS serão sempre nivelados para baixo dada a completa ignorância acerca do grau de complexidade que uma solução GIS demanda.

Este know-how é altamente buscado pelas empresas de contagem. Em um mercado bilionário conhecer as entranhas do desenvolvimento de um software GIS é um ponto de extremo valor. Posto isso eu pontuo: “Cuidado ao entrar em uma contratação por pontos de função”. Não há vantagens tecnológicas se todo o conhecimento (Documentação, Código Fonte, Implantação e Treinamento) vai ser repassado para um profissional de contagem.

Atente-se caso esteja, em virtude de estar querendo entregar uma contagem de extrema qualidade, a entregar todo seu business para um terceiro. Você nunca irá se recuperar desta falha estratégica.

Há casos que a “chantagem”, melhor dizendo, “contagem” se dá por meio do que o manual diz: “o que é um processo elementar ou função de transação para o usuário?”.

Características de um processo elementar

A imagem acima exemplifica o risco que é entregar ao usuário o poder de definir o que é valor, não só para toda a sua aplicação mas para cada uma das partes. Isso equivaleria a dizer que um gerente de projeto iria encontrar uma data correta para cada uma das atividades listadas no seu cronograma, ou que um legislador iria encontrar o valor correto de uma tarifa de modo que todos sejam penalizados da mesma forma pelo Estado.

A menor unidade pode ser uma ativação de uma consulta, uma tela de cadastro com inclusão, alteração e exclusão ou pode ser na pior das hipóteses um processo de análise de dados altamente complexo que roda em um único webservice. Tudo depende de quão significativo cada processo é entendido pelo usuário.


Entendo o usuário tenha o poder de decidir o que tem valor para ele mas há um problema de concepção na abordagem econômica aí. Visto que o usuário queira sempre pagar menos pela função implantada, esta métrica torna-se perversa por privilegiar o software menor, mais quebrado e com menos valor agregado. O cliente irá sempre buscar um software com maior valor agregado e encapsulado ao seu extremo e o fornecedor de software criar sistemas quebrados, burocráticos e com menos valor agregado, tudo em busca de mais pontos de função.

O cliente irá sempre buscar um software com maior valor agregado e encapsulado ao seu extremo e o fornecedor de software criar sistemas quebrados, burocráticos e com menos valor agregado, tudo em busca de mais pontos de função.
Dilema: Maior encapsulamento vs menor encapsulamento

Quando se outorga o que é um processo elementar (processo que motiva a ação do usuário para um determinado fim) ao usuário, a empresa desenvolvedora de software fica de mãos atadas quando o mesmo diz que abrir uma janela, identificar um elemento de pesquisa, filtrar este elemento de pesquisa, calcular um valor para esta pesquisa e gerar um relatório com base nestes dados pesquisados são a mesma coisa então, das duas uma:

  • Você tem uma relação de parceria muito forte com o cliente;
  • Você tem uma relação de submissão com seu cliente e ele vai aplicar as mesmas técnicas utilizadas no século passado (ainda não está pronto) com você.

Não há como escapar de clientes dos infernos. Não há nada como clientes dos infernos. Eles destroem sua capacidade produtiva e criativa. Fuja de armadilhas. Não seja um tolo no mercado de software.

Sempre utilizo a referência ao David de Michelangelo para exemplificar distorções. Suponha que ao ser encomendada para fazer parte da governadoria de Florença, Michelangelo recebesse por função entregada (há quem defenda que software não seja arte, no qual discordo peremptoriamente).

Como Michelangelo deveria proceder com sua obra? E se seu contratante ao final do processo de desenvolvimento entendesse que seria pago por apenas pela seguinte fórmula:

Vc = fd + ft

onde Vc é o valor da contagem, ∑fd é o total das funções de dados e ∑ft a somatória das funções de transação que referenciam estas funções de dados, ou seja:

  • 01 Arquivo lógico interno - ALI (o mármore);
  • 01 Função de transação que referencia este ALI (o próprio David).
Pobre Michelangelo.