O modelo brasileiro para a contratação de serviços de software por pontos de função

O modelo brasileiro para a contratação de serviços de software por pontos de função

Xxxxxx Xxxxxxx Xxxxxxx, Xxxxxxxxx Xxxxxxxx Xxxxxx, Xxxxxxx Xxxxxxxx Xxxxxx

Fatto Consultoria e Sistemas (xxx.xxxxxxx.xxx.xx) Vitória, Brasil

{xxxxxx.xxxxxxx, xxxxxxxxx.xxxxxx, xxxxxxx.xxxxxx}@xxxxxxx.xxx.xx

Abstract — O modelo de contratação de serviços de desenvolvimento e manutenção de software que mais tem sido adotado no Brasil nos últimos anos estabelece a remuneração do fornecedor com base em uma unidade medida de uma perspectiva de negócio, e não técnica: pontos de função. Este trabalho apresenta a motivação para a busca no Brasil de um novo modelo para contratação de serviços de software, os problemas existentes nos modelos de contratação usados até então, explicando este novo modelo de contratação e o que é a Análise de Pontos de Função, as dificuldades associadas a este modelo e perspectivas de evolução.

Keywords: análise de pontos de função, aquisição de software, medição funcional de software.

I. Introdução

O modelo de contratação de serviços de desenvolvimento e manutenção de software cujo uso mais tem se intensificado no Brasil nos últimos dez anos é a remuneração do fornecedor por preço unitário, usando uma unidade de medição de uma perspectiva externa ao trabalho; no caso pontos de função (PFs). Ponto de função é a unidade de medida do método de medição funcional de software chamado APF - Análise de Pontos de Função (ou FPA – Function Point Analisys), criado na IBM por Xxxx Xxxxxxxx em meados da década de 70 [1]. Atualmente este método é de domínio público e é mantido e evoluído pelo IFPUG (International Function Point Users Group) através do seu Manual de Práticas de Contagem [2]. Outros métodos de medição funcional de software também surgiram derivados de [1], tais como Mark-II [5], COSMIC [6] e NESMA [7]; porém o método de maior difusão no mundo é o método IFPUG.

Embora o governo federal do Brasil tenha sido uma das principais molas propulsoras para a adoção de pontos de função na contratação de serviços de software, esta prática hoje está disseminada também entre as empresas privadas e nas outras esferas de governo (estadual e municipal) e esferas de poder (legislativo e judiciário, além do poder executivo). Organizações como Banco do Brasil, Banco Central do Brasil, BNDES, Bradesco, Brasilprev, Caixa, OI, TAM, Petrobras, Correios, Porto Seguro, Polícia Federal compõem uma pequena parte do conjunto de empresas que usam pontos de função em contratos no Brasil. Em [3] e [4] é possível encontrar uma lista mais extensa das organizações públicas brasileiras que adotam pontos de função na contratação de serviços de software.

Embora a APF tenha sido criada para suportar estudos de produtividade no desenvolvimento de software, seu uso acabou sendo expandido para outras finalidades como: estimativa de custo e esforço de projetos de software, geração de indicadores de qualidade e produtividade do processo de desenvolvimento, apoio à gestão de escopo e do projeto de software, medição do software produto e medição de contratos, conforme [2] e [3].

Até o início da década passada, o uso de pontos de função nas empresas brasileiras estava mais restrito à estimativa de projetos de software e ao suporte de iniciativas de melhoria de processo de software, como a adoção de modelos de maturidade CMMI e XXX.XX.

II. MOTIVAÇÃO

Os anos 90 foram caracterizados por diversos modismos de gestão empresarial, dentre eles a terceirização, e no Brasil este foi adotado talvez com mais intensidade que em outros países. O setor de Tecnologia da Informação foi bastante impactado por este movimento da terceirização nas empresas. Boa parte do desenvolvimento e manutenção de sistemas deixou de ser feito internamente pela equipe da casa e passou a ser feito por equipes terceirizadas, seja sob a forma de outsourcing de mão de obra ou sob a contratação de projetos executados por fábricas de software.

Mas este movimento trouxe efeitos colaterais inesperados (e indesejados) para muitas organizações que adotaram esta iniciativa. Um dos problemas diz respeito à forma de contratação destes serviços terceirizados. Nas próximas duas subseções são comentadas as formas de contratação mais comuns no Brasil para serviços de desenvolvimento de software até então.

A. Contratação por alocação de mão de obra

Nesta modalidade, também conhecida como body shopping ou time and material, o cliente contrata profissionais para alocação no desenvolvimento do software, usualmente conjuntamente com sua equipe própria, nem sempre com apenas um fornecedor de mão de obra, e utilização de sua própria infraestrutura logística. A remuneração do fornecedor é calculada com base no nível de qualificação e experiência dos profissionais alocados, nas horas apuradas e em outras eventuais despesas. Na prática, o profissional contratado atua como um funcionário do cliente.

Esta é uma modalidade de contratação onde a remuneração do fornecedor é orientada ao processo "interno" à produção de software. O preço final é determinado a partir de considerações como: quanto trabalho ele envolve; qual o perfil e quantidade de profissionais mobilizados em sua execução; e a sua complexidade de gestão. O controle do preço está nas mãos do fornecedor, que em tese tem maior competência sobre esses aspectos técnicos do projeto em relação ao cliente, cujo negócio costuma ser outro que não o desenvolvimento ou manutenção de software.

Esse modelo é de simples administração e apresenta grande flexibilidade tanto para o cliente quanto para o fornecedor. Uma vez estabelecida a relação comercial, o cliente tem a possibilidade de ser mais ágil no atendimento aos picos de demanda de serviço. No caso da mudança dos requisitos, não é necessária uma nova renegociação de contrato com o fornecedor. Porém, um aumento de escopo acarretará um aumento de esforço (horas) e também de custo do projeto. E é justo que o fornecedor seja remunerado por esse esforço adicional, uma vez que a gerência do escopo e dos requisitos é responsabilidade direta do cliente.

O aspecto mais crítico dessa modalidade de contratação é que o cliente é responsável por gerenciar toda a equipe do serviço, inclusive a produtividade do fornecedor. Isso exige um nível de competência que pode não estar disponível internamente. Além disso, a remuneração do fornecedor não está vinculada aos resultados produzidos, mas apenas à quantidade de horas executadas. Não há nenhum estímulo ao fornecedor para a manutenção ou o aumento dos níveis de produtividade e qualidade; o que deveria ser uma responsabilidade exclusiva sua. O estímulo é negativo: quanto mais esforço o fornecedor demandar, maior será a remuneração. É a antítese da produtividade!

Outro obstáculo é com relação às garantias do serviço prestado. Caso a execução do serviço envolva mais de uma empresa, é muito difícil isolar as responsabilidades de cada empresa e exigir a garantia. Na prática o cliente paga por um serviço e também pelas eventuais manutenções corretivas associadas a ele.

B. Contratação por preço global fixo

Esta modalidade, também conhecida como fixed price, privilegia a abordagem de projeto, com um início e fim bem definidos (além é claro, do escopo). Exige maior nível de organização tanto do cliente quanto do fornecedor. Quanto melhor definidos estiverem os requisitos, menor a chance de atritos entre as partes.

Contudo, em geral, o fornecedor não dispõe de muita informação sobre o domínio do problema ou não dispõe de tempo para a análise detalhada dos requisitos para a elaboração da sua proposta comercial. Como consequência, haverá um subdimensionamento ou superdimensionamento do orçamento proposto. Quando a concorrência é intensa, é mais provável que o primeiro caso ocorra.

Ambos os casos anteriores são indesejáveis. No primeiro, o fornecedor terá dificuldades em atender ao cliente. Se os requisitos não foram bem definidos, é provável que haja um

impasse e uma nova negociação comercial tenha que ser conduzida, quase sempre com desgaste para ambas as partes. Ainda que os requisitos tenham sido bem definidos, o orçamento proposto pelo fornecedor pode ter sido tão subdimensionado que a qualidade do produto seja seriamente afetada ou que o projeto sequer seja concluído.

Neste modelo há uma transferência de riscos do cliente para o fornecedor; no caso risco de escopo (mudanças deverão ser acomodadas sem custo adicional?) e produtividade (qual o nível de controle sobre os vetores que oneram o trabalho?). O fornecedor forma seu preço considerando estes riscos.

Um complicador ao uso desta abordagem é assumir que os requisitos não mudarão (ou mudarão pouco) após o início do projeto. Assim como o ambiente no qual a organização está inserido é dinâmico, os requisitos também o são. Quanto maior a duração do projeto, mais provável que haja alteração nos requisitos. E é difícil estimar quanto essas alterações afetam o orçamento proposto originalmente pelo fornecedor. Segundo

[8] mais de 2% dos requisitos mudam mensalmente após a fase de requisitos. Neste caso, é provável que seja necessária uma nova negociação. Se este for o caso, dificilmente o cliente irá obter as mesmas condições originais, pois dependendo do momento em que o projeto estiver, não haverá concorrência e tampouco uma unidade para comparar o preço originalmente cobrado com o preço cobrado pelas novas características solicitadas.

Nesta modalidade, o controle sobre quanto se paga também está sob o controle do fornecedor. É muito comum que o racional de formação do preço esteja estruturado em termos da estrutura analítica de projeto e da quantidade horas e perfil do profissional alocado à realização da atividade. O mesmo acontecendo nas mudanças (ou alegadas mudanças) que acontecem durante o projeto. Na medida em que a estrutura de preços é feita dessa forma, tal qual na contratação por alocação de mão de obra, o controle está com aquele que detém o conhecimento técnico da engenharia de software e aplicação das suas disciplinas.

C. A busca por um modelo alternativo de contratação

Com o passar do tempo, algumas organizações passaram a experimentar formas alternativas de contratação de serviços de software que promovessem melhor distribuição de riscos e resultados. No modelo de alocação de mão de obra a gestão da produtividade é ônus do cliente, quando o justo seria ser preocupação do fornecedor. A gestão do escopo também é responsabilidade do cliente, porém é justo que seja assim, pois o fornecedor não tem domínio sobre os requisitos. No modelo de preço global fixo, a produtividade é de responsabilidade do fornecedor, o que é justo, uma vez que ele é responsável pelo processo de trabalho. Porém, qualquer mudança ou indefinição dos requisitos, que são responsabilidade do cliente, fragilizam este modelo de contrato.

Portanto, um modelo de contratação ideal seria a remuneração do fornecedor com base em unidades de resultado do serviço executado. Isto promove o equilíbrio de riscos e responsabilidades entre cliente e fornecedor. Nesse caso, a produtividade é atribuição do fornecedor, pois há o risco de prejuízo caso haja demora na produção das unidades. Por outro

lado, no caso de um aumento de escopo, mais unidades deverão ser construídas para o serviço e o fornecedor será remunerado por isso.

O grande desafio dessa abordagem é encontrar uma unidade que possa ser reconhecida de maneira inequívoca, uniforme e consistente por ambos, cliente e fornecedor. Exemplos de unidades poderiam ser: telas, relatórios, tabelas, casos de uso, linhas de código, stored procedures, ponto de função, dentre outras. Mas nem todas estas unidades atendem ao critério de serem reconhecidas tanto pelo cliente quanto pelo fornecedor de forma uniforme e consistente.

Quando se analisa unidades de caráter mais técnico, peca-se pela falta de visibilidade destas unidades por parte do cliente. A relação (se é que há alguma) entre linhas de código, por exemplo, e algo de valor tangível para o cliente é muito fraca. Nem sempre o cliente tem a total competência técnica para atribuir valor a um serviço que implicou escrever um determinado número de linhas de código. Muitas vezes, um dos motivos para a terceirização é justamente a busca por um fornecedor com competência mais especializada em um assunto que não é de interesse do cliente despender tanta energia para ter este domínio.

Quando se analisa unidades de caráter menos técnico, como telas, tabelas, relatórios, casos de uso ou pontos de função, têm-se unidades que são facilmente reconhecidas e entendidas por ambas as partes. A questão agora é encontrar uma definição uniforme e consistente para esta unidade. No caso de telas, tabelas, relatórios e casos de uso não há esta definição padronizada. Embora existam boas práticas e o senso comum ditando o que deveria ser ou não um caso de uso ou uma tela; isto não é suficiente para se usar estas unidades como medição de contratos. Levando ao limite, o cliente poderia direcionar o serviço para que o sistema inteiro seja especificado em um único caso de uso para minimizar custo; assim como o contrário poderia ocorrer: o fornecedor dividir a especificação do sistema em tantos casos de uso quanto queira para aumentar a sua remuneração.

A unidade pontos de função passou a ser considerada em contratos justamente por ser uma medida de caráter não técnico, com uma definição padronizada, uniforme e consistente.

Além disto, a contratação do serviço com base nos resultados entregues possibilita que o cliente tenha mais controle sobre os custos que o fornecedor [9].

III. A Análise de Pontos de Função

A Análise de Pontos de Função, conforme o padrão IFPUG, mede o software quantificando as tarefas e serviços (isto é, funcionalidades) que o software fornece ao usuário, primordialmente com base no projeto lógico [2]. Os objetivos deste método são medir:

• A funcionalidade implementada no software, que o usuário solicita e recebe;

• A funcionalidade impactada pelo desenvolvimento, melhoria e manutenção de

software, independentemente da tecnologia utilizada na implementação.

Este processo de medição busca ser:

• Suficientemente simples para minimizar o custo adicional introduzido pelo processo de medição;

• Uma medida consistente entre diversos projetos e organizações.

As funcionalidades do software medidas por pontos de função são de duas naturezas distintas:

• Processamento: representam os requisitos de processos do usuário, ou seja, transações.

• Armazenamento: representam os requisitos de armazenamento do usuário, ou seja, dados.

Resumidamente, o processo de medição consiste em identificar todas as funcionalidades do projeto ou da aplicação analisada, classificar estas funcionalidades conforme as regras estabelecidas no manual de práticas de contagem e avaliar a complexidade de cada funcionalidade identificada e classificada para atribuir de forma objetiva um peso em pontos de função. O tamanho funcional é apurado através do somatório de todas as funções identificadas, classificadas e ponderadas do projeto ou aplicação analisada.

Todo este processo de medição usa como insumo apenas os requisitos do software estabelecidos pelo usuário. Portanto, o tamanho funcional é uma representação numérica direta de algo que está no pleno domínio do usuário: os requisitos.

Visando garantir consistência nas medições, o IFPUG publica o manual de práticas de contagem, que tem os seguintes objetivos [2]:

• Manter conformidade com a norma ISO/IEC 14143-1:2007 Information technology – Software measurement – Functional size measurement – Definition of concepts;

• Prover uma descrição clara e detalhada da contagem de pontos de função;

• Garantir que as contagens sejam consistentes com as práticas de contagem dos membros do IFPUG;

• Fornecer um guia para permitir a contagem de pontos de função a partir dos entregáveis das metodologias e técnicas mais conhecidas;

• Prover um entendimento comum para permitir que os fornecedores de ferramentas forneçam suporte automatizado para a contagem de pontos de função.

Outra iniciativa do IFPUG para promoção de medições consistentes é o programa de certificação de especialistas em pontos de função (CFPS/CFPP) que visa reconhecer formalmente o profissional que demonstra um conhecimento especializado no conteúdo (e sua aplicação) do manual de práticas de contagem.

IV. Modelo de Custeio por Ponto de Função

O modelo de custo para contratação de serviços de software por ponto de função adotado no Brasil pode ser representado pelas seguintes fórmulas, que na prática são similares.

(1)

Nesta primeira fórmula, mais usada no mercado privado brasileiro, calcula-se o esforço (em horas) do projeto a ser executado levando-se em conta o tamanho (em pontos de função) e uma taxa de entrega pré-definida (horas por pontos de função). Esta taxa de entrega é definida, e acordada com o fornecedor, através de um estudo de produtividade em uma amostra de projetos já executados no cliente. O custo do projeto é derivado pela simples multiplicação do esforço apurado por um valor-hora acordado comercialmente entre cliente e fornecedor.

(2)

A segunda fórmula é mais usada nos contratos públicos; o custo do projeto é calculado diretamente pelo tamanho em pontos de função multiplicado por um preço unitário do ponto de função. Este preço é o que foi ofertado pelo fornecedor vencedor da concorrência. Para definir o preço a ser ofertado, os concorrentes devem levar em consideração todo o processo de trabalho definido pelo cliente no edital da concorrência.

Ambas as fórmulas são equivalentes, pois o esforço pode ser convertido em custo; assim como o preço unitário é (ou deveria ser) definido em função da produtividade esperada para o contrato.

Conforme as características dos serviços a serem demandados no contrato, o modelo pode ser refinado (e normalmente faz-se isto) com o uso de diferentes indicadores de taxa de entrega (H/PF) ou preço unitário ($/PF), calibrados às especificidades de cada tipo de serviço.

Para grandes organizações e no setor público brasileiro, os processos de aquisição costumam ser demorados e onerosos. Portanto o modelo descrito acima costuma ser aplicado para a contratação, não de um projeto individual, mas de um volume pré-definido de pontos de função a ser usado em vários projetos num período usualmente de 12 a 60 meses. E este volume costuma ser definido com base nos projetos previstos para a área de sistemas no planejamento estratégico.

Como a análise de pontos de função é realizada com base na visão externa do usuário, em contraste com uma visão interna da engenharia de software, o cliente passa a ter o efetivo controle e a gestão do escopo. Não se entra no mérito (a cada momento) quanto à complexidade do trabalho, o perfil dos profissionais mobilizados ou a sua quantidade. É um modelo onde a análise de pontos de função não cumpre o papel de estimar esforço ou custo, mas de prescrever o quanto se pagará independentemente de seu custo ou do esforço efetivos.

Como nos contratos de preço global fixo, é um negócio de risco; contudo, melhor distribuído. As considerações sobre a complexidade do trabalho em suas mais diversas dimensões (exceto escopo das funções solicitadas e entregues pelo usuário), quanto ao perfil e quantidade dos profissionais alocadas devem ser feitas em um momento preliminar: quando

da definição do preço unitário ($/PF) ou taxa de entrega (H/PF).

Uma vez determinado o preço unitário, ele, conjuntamente com a quantidade de pontos de função medidos, prescreve o quanto será pago ao fornecedor para cada serviço entregue.

Numa análise pontual de cada serviço/projeto entregue, o valor (ou esforço) pago geralmente varia tanto para cima quanto para baixo quando comparado ao efetivamente realizado. Isto é esperado, pois o modelo usa como base um preço médio (ou produtividade média) para a derivação do custo. Desde que haja uma boa definição dos parâmetros de preço para o modelo, estas variações entre os projetos tendem a se compensar quando se analisa o conjunto de projetos executados no contrato em um horizonte de tempo maior (por exemplo, um ano).

A. Por que usar pontos de função neste modelo?

Um motivo é que o vocabulário da análise de pontos de função utiliza terminologia e define elementos de análise que independem da tecnologia utilizada para o desenvolvimento do software. Todo o processo de medição considera apenas a perspectiva do negócio como entendido e validado pelo cliente. A eliminação dessas tecnicidades facilita a compreensão entre as partes e é um importante impulsionador da comunicação entre cliente e fornecedor.

Outro motivo é que se trata de um método padrão de medição funcional. Aliás, existem cinco métodos padrão de medição funcional possíveis de se usar: IFPUG (ISO/IEC 20926), NESMA (ISO/IEC 24570), Mark II (ISO/IEC 20968), COSMIC (ISO/IEC 19761) e FISMA (ISO/IEC 29881).

A escolha pelo padrão IFPUG no caso do Brasil deve-se ao fato deste ser o de maior difusão mundial e também por ser o mais antigo e maduro. Como organização, o IFPUG possui mais de três mil filiados nos cinco continentes. Porém o número de usuários de pontos de função é bem superior ao de filiados.

Um motivo, mais específico do setor público, porém também relevante é que a contratação de serviços por pontos de função possibilita a auditoria externa dos contratos; algo que não é possível com tanto rigor em um contrato por alocação de mão de obra. Suponha que um órgão público pagou um determinado montante para um serviço contratado. Num contrato pago por hora, a auditoria externa iria apurar se há registro de apontamento de horas compatível com o volume pago. Porém este registro é fácil de forjar, o que possibilita fraudes no sentido de pagar mais horas do que efetivamente foram executadas. E de fato, fraudes em contratos de Tecnologia da Informação foram assuntos frequentes no noticiário brasileiro nos últimos anos.

Para contratos baseados em pontos de função, eventuais fraudes no intuito de pagar mais PFs do que efetivamente foram entregues são facilmente detectadas pela auditoria. Como os PFs refletem funcionalidades entregues pelos projetos, não há como eles serem forjados.

B. Nem tudo é mensurável em pontos de função

Considerando que a APF mede os requisitos funcionais do usuário, percebe-se que apenas parte dos requisitos de um projeto são capturados na medição. Todo e qualquer requisito não funcional do projeto é ignorado na medição em pontos de função. De acordo com [2], exemplos de requisitos do usuário que são Requisitos Não-Funcionais do Usuário incluem, mas não estão limitados aos seguintes:

• Restrições de qualidade (por exemplo, usabilidade, confiabilidade, eficiência e portabilidade);

• Restrições Organizacionais (por exemplo, locais de operação, hardware alvo e aderência a padrões);

• Restrições Ambientais (por exemplo, interoperabilidade, segurança, privacidade e sigilo);

• Restrições de Implementação (por exemplo, linguagem de desenvolvimento, cronograma de entrega).

Porém, o projeto deve atender tanto aos requisitos funcionais quanto aos requisitos não funcionais. E para atender a qualquer destes tipos de requisitos há esforço envolvido. Como o modelo de custo trata os requisitos não funcionais? Eles são tratados indiretamente pela produtividade ou preço adotado. Ou seja, quanto mais trabalho houver associado ao atendimento destes requisitos, menor a produtividade e mais caro tende a ser o $/PF.

Esta abordagem funciona quando o serviço envolve requisitos funcionais e não funcionais. Porém quando há a necessidade de se executar um serviço que envolva apenas mudança de requisitos não funcionais (por exemplo, melhoria de performance ou usabilidade) ou manutenção corretiva, não há pontos de função a se medir.

Portanto há a necessidade de se complementar o modelo para tratar como remunerar os serviços que não possuem pontos de função associados. Não há uma prática padronizada entre as organizações brasileiras para estas situações, mas o mais comum é a elaboração de métricas específicas para elas. Deve-se ressaltar que estas situações constituem uma fração pequena do conjunto de serviços demandados ao longo do contrato. Tipicamente mais de 80% dos serviços são medidos por pontos de função.

C. Acordos de Nível de Serviço (SLAs)

Em um modelo de contratação baseado em resultados, há o interesse direto do fornecedor em maximizar a vazão das demandas atendidas, pois isto implica em aumentar a receita. Para o cliente isto também é benéfico, pois provê mais agilidade nas respostas às necessidades de software da organização.

Assim como também há interesse do fornecedor em entregar serviço de qualidade, pois eventuais correções implicam retrabalho, mas sem receita associada; ou seja, custo a prejudicar a rentabilidade do contrato.

Logo percebe-se uma convergência de interesses em ambas as partes para entregas ágeis e com qualidade no contrato. Porém, este modelo de contratação não pode prescindir de Acordos de Níveis de Serviço (Service Level Agreements – SLAs), em específico relativo a prazo e qualidade.

Quando há demora na entrega de um serviço, mesmo que o cliente tenha previsibilidade do valor a ser pago, este atraso pode implicar em perdas de oportunidade para o seu negócio. O mesmo se aplica aos defeitos, embora não haja custo adicional para suas correções, isto pode impactar o prazo da entrega de uma solução ou mesmo implicar em prejuízo significativo se o defeito se manifestar após a implantação da solução.

Portanto, é boa prática, o uso de SLAs em contratos por ponto de função. Inclusive alguns dos indicadores de SLAs são derivados do tamanho funcional. Por exemplo, [10] usa a fórmula de prazo do COCOMOII, calibrada para o seu contexto, cujo parâmetro de entrada é o tamanho em pontos de função do projeto a ser executado. Assim como também usa o tamanho em PFs associado à quantidade de defeitos para estabelecer o indicador nível de densidade de defeitos (defeitos/PF) que irá nortear o SLA de qualidade.

V. Dificuldades para o Novo Modelo

A maior dificuldade para a adoção ao modelo de contratação por pontos de função é a baixa maturidade nas práticas da TI e a falta de cultura de projetos em muitas organizações. Para aqueles que estão num modelo de contratação por alocação de mão de obra, há um impacto grande para promover esta mudança. A contratação por PF consiste na sua essência em trabalhar no regime de projetos, o que implica em planejamento e boa definição de escopo. Porém, ausência de planejamento, documentação e visibilidade dos resultados produzidos costuma ser a tônica nos contratos por alocação.

Outra dificuldade está relacionada ao jogo de poderes dentro da organização. No contrato por alocação de mão de obra, os profissionais alocados muitas vezes atuam como funcionários, não do departamento de TI, mas dos departamentos usuários. Para estes gestores é muito cômodo ter profissionais à disposição para uso conforme a necessidade. Não costuma haver grandes necessidades de planejamento e a sensação de agilidade na resolução de problemas é grande.

Quando se muda o modelo de contrato, estes gestores “perdem” estes profissionais e passam a precisar formalizar suas necessidades, com um mínimo de escopo documentado, para que o departamento de TI possa atendê-los. Logo, é comum a reclamação de aumento de burocracia e perda de agilidade.

E um motivo para fracasso na transição deste modelo de contratação é o uso de modelos de custeio copiados de outras organizações, porém sem as devidas calibrações locais. Algumas organizações optam pela via fácil de copiar o que funciona em outra organização, porém, sem ter o trabalho de estudar as diferenças de contexto entre ambas. Na prática, usam-se os mesmos parâmetros de produtividade (ou preço unitário) de outra organização. Em geral isto resulta em um

contrato que pode elevar demais o custo dos serviços de software ou oprimir o fornecedor ao ponto dele desistir do contrato.

Outra dificuldade está relacionada às medições em PFs. A medição funcional é um exercício de abstração de todo aspecto de implementação, focando exclusivamente necessidades do negócio. Para os profissionais que estão envolvidos diretamente na implementação, costuma haver uma dificuldade em abstrair da implementação quando se faz a medição funcional e isto se reflete em um número de PFs muitas vezes incorreto (e normalmente a maior), contaminado por aspectos técnicos.

VI. Perspectivas e Conclusão

O modelo de contratação de serviços de software por resultado vem sendo amadurecido no Brasil ao longo dos últimos quinze anos. Inicialmente restrito a poucas empresas que se dispuseram a ser pioneiras neste modelo, pouco a pouco ele foi sendo adotado por outras organizações que observaram o sucesso desta iniciativa. No governo federal, a partir de 2008, a contratação de serviços por alocação de mão de obra passou a ser praticamente vetada com a publicação a Instrução Normativa 04 (revisada posteriormente em 2010) [11]. Isto estimulou ainda mais a difusão deste modelo de contratação.

Embora no governo federal o uso de pontos de função seja mais intenso, os principais governos estaduais e municipais também já fazem uso deste modelo; porém ainda com menos ênfase. No mercado privado, alguns dos principais compradores de serviços de software também contratam por pontos de função, o que cria uma tendência para o restante do mercado seguir o mesmo caminho.

Em suma, o modelo de contratação por pontos de função, embora bastante difundido, ainda se encontra em expansão no Brasil. E ainda que esteja em expansão, isto já foi suficiente para torná-lo o país com a maior quantidade de usuários de pontos de função no mundo. O Brasil é o país com a maior

quantidade de filiados ao IFPUG e também possui a maior quantidade de especialistas certificados no assunto.

Os autores deste trabalho participaram do processo de transição do modelo de contratação de alocação de mão de obra para pontos de função em várias empresas, e, vencidas as barreiras iniciais, constata-se que há um aumento da vazão das demandas de sistemas (o aumento de produtividade agora beneficia o fornecedor), melhoria da qualidade da documentação de requisitos (pois sem isto não é possível medir PFs) e visibilidade dos resultados que são entregues.

Referências bibliográficas

[1] Xxxxxxxx, X. X. “Measuring Application Development Productivity”, Proceedings of Joint SHARE/GUIDE/IBM Application Development Symposium, out. 1979.

[2] IFPUG - International Function Point Users Group, “Function Point Counting Practices Manual”, Release 4.3.1, 2009.

[3] Xxxxxxx, X. X.; Xxxxxx, X. S; Xxxxxx, R. M., “Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software”. 12ª ed., São Paulo: Editora Érica, 2012.

[4] Fatto Consultoria e Sistemas, “Editais de Serviços de Software por Ponto de Função”, xxxx://xxx.xxxxxxx.xxx.xx/xxxxxxx.xxx, maio de 2012.

[5] UKSMA. “Mk II Function Point Analysis Counting Practices Manual” versão 1.3.1 . United Kingdom Software Metrics Association, set. 1998.

[6] COSMIC. “COSMIC Measurement Manual”, versão 3.0.1. Common Software Measurement International Consor tium. mai, 2009.

[7] NESMA. “Function Point Analysis for Software Enhancement”, versão

2.2.1. Netherlands Software Metrics Users Association, 2001

[8] Xxxxx, X. “Conflict and Litigation Between Software Clients and Developers”, Software Productivity Research, Versão 10 . abr. 2001.

[9] Xxxxxx, X.; Xxxxxxxx, D., “Fazendo Negócios com Pontos de Função: Modelos de Negócio Baseados em Pontos de Função”, ISMA Cinco - International Software Measurement & Analysis Conference, 2010.

[10] Caixa Econômica Federal. “Concorrência 1/2006”. xxxx://xxx.xxxxxxx.xxx.xx/xxxxxxx/xxxxx/xxxxxxxxxxxx0000000000000.xxx

[11] Secretaria de Logística e Tecnologia da Informação do Ministério do Orçamento, Planejamento e Gestão. “Instrução Normativa 04”. Brasil, novembro de 2010.

xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxx/xxxxxxxx/xxxxxxxxx- normativa-no-04-de-12-de-novembro-de-2010/download