Contratação de Contratos de

Fábrica de Software

Os desafios impostos pelo uso de métodos ágeis em contratos

de Fábrica de Software

Marcelo Santiago Guedes1

RESUMO

Propósito

Apresentar algumas dificuldades enfrentadas na contratação de fábricas de

software, em especial pela Administração Pública Federal, e elencar pontos de atenção

para a gestão de contratos de desenvolvimento que utilizem métricas de Pontos de

Função e prescrevam processo de desenvolvimento baseado em métodos ágeis. O

objetivo é que gestores públicos de TI e Fábricas de Software possam melhor se preparar

para gerir estes tipos de contratos.

Utilidade

O uso de métodos ágeis por fábricas de software traz desafios importantes aos

contratantes que utilizam Pontos de Função como objeto de contratação. São desafios

oriundos principalmente da diferença de paradigma entre essas duas ferramentas de

gestão que podem gerar dificuldades na relação entre as Fábricas de Software e a

Administração Pública Federal.

Palavras-Chave: Fábricas de Software; Contratações; Administração Pública; Métodos

ágeis; Pontos de Função; Práticas de Gestão.

1 Perito em Tecnologia da Informação do Conselho Nacional do Ministério Público – CNMP. Mestre em

Gerenciamento de Projetos de Software pelo CIn/UFPE. Profissional com 17 anos de experiência atuando

na área de Tecnologia da Informação, sendo os últimos quatro no setor público, tendo sido Coordenador-

Geral de Sistemas do Ministério do Desenvolvimento Social e Combate à Fome. Atualmente atua na área

de Gestão Estratégica do CNMP. Contato: - mguedes@gmail.com.

O uso de métodos ágeis por equipes de desenvolvimento de software já é prática

consolidada no mercado, principalmente em organizações privadas. Os resultados são

visíveis e estão vinculados principalmente a entregas mais rápidas quando comparados

aos métodos tradicionais.

No entanto, o objetivo aqui não é engrossar as apaixonadas discussões e os

inúmeros artigos já escritos sobre a eficácia dos métodos ágeis, mas trazer uma visão

mais pragmática sobre vários aspectos que envolvem a contratação de uma fábrica de

software na Administração Pública Federal – APF, e os desafios que devem ser

enfrentados por nós profissionais de Tecnologia da Informação no sentido de evoluirmos

mais nossa engenharia de software para atender aos requisitos que o interesse público

impõe.

O desafio central orbita em torno de como mudanças são tratadas. Os paradigmas

tradicionais da engenharia de software entendem que mudanças no escopo de um projeto

podem ser minimizadas em função de um bom processo de planejamento. Por esta razão,

observa-se nas metodologias em geral uma forte ênfase no gerenciamento de requisitos.

Uma vez fechado o escopo, a mudança é vista como algo indesejado que deve ser gerido

por um processo a parte. Já o paradigma ágil vê a mudança como algo intrínseco ao

próprio requisito e à natureza humana do cliente. Os métodos ágeis buscaram

desenvolver formas de minimizar os impactos estruturais e procedimentais das constantes

solicitações de mudanças ao longo de um projeto.

Entretanto, sob a ótica financeira isto tem um preço. Do ponto de vista do

contratante, que planeja suas ações baseadas em orçamentos, é necessário ter uma forma

de estimar o valor do que será entregue antes de decidir sobre a contratação. Aí começam

os problemas!

O cenário de contratação de fábrica de software na APF

A APF vem modificando a sua forma de contratar o desenvolvimento de software

na última década. Na primeira metade da década passada, este tipo de serviço era

contratado por técnica e preço, onde se pontuava a técnica pela apresentação de

certificações de qualidade da empresa, como CMMi e MPS-Br, e dos profissionais

envolvidos.

Essa abordagem gerou distorções que foram atacadas no ano de 2007 pelo TCU –

Tribunal de Contas da União – através dos Acórdãos TCU 1.782/2007, 1.910/2007,

1.125/2009 e 1.274/2010. As sinalizações dos acórdãos apontavam para a necessidade de

padronização dos serviços de tecnologia, para que assim pudessem ser objeto de

contratação por um processo mais objetivo e isonômico. Em consequência disto, foi

determinado que as contratações de desenvolvimento de software deveriam ser por

Pregão e utilizando métricas de Ponto de Função para o pagamento dos serviços

contratados. Observemos, então, que o uso de Pontos de Função na APF tem origem no

interesse público e buscou substituir a discutível métrica então vigente: homem-hora.

Por outro lado, os quadros de servidores efetivos especializados em Tecnologia da

Informação na APF, em especial nos órgãos do Poder Executivo, era praticamente

inexistente. Tal fato levou o TCU a recomendar ao MPOG – Ministério do Planejamento,

Orçamento e Gestão – o desenvolvimento de recursos humanos especializados em TI,

através da criação de carreira específica para esta área, a fim de que os processos de TI

fossem geridos por profissionais qualificados dos próprios quadros.

A partir destas e de outras provocações, o Poder Executivo deu nova roupagem ao

SISP, cujos trabalhos geraram normativos como a IN4/2010, o Manual de Contagem de

Pontos de Função e as especificações EPing e EMag.

Dessa forma, atualmente a contratação de serviços de desenvolvimento de

software deve ter seu pagamento baseado na métrica Pontos de Função.

Pontos de Função

Inúmeros foram os artigos que descreveram os conceitos de ponto de função, por

isso não o faremos aqui. Descreveremos apenas algumas definições importantes para

análise proposta.

O Ponto de Função é uma técnica, definida em 1977 por Alan Albrecht na IBM,

que busca estimar o tamanho de projetos de desenvolvimento e melhoria de software.

Sua unidade de medida baseia-se na funcionalidade percebida pelo usuário. O benefício

imediato desta técnica é que, a partir desta medida inicial, é possível derivar estimativas

de esforço e custo para o seu desenvolvimento.

O International Function Point Users Group (IFPUG) define um conjunto de

regras e técnicas para se chegar a essa estimativa, chamada de Análise por Pontos de

Função, no Manual de Práticas de Contagem de Pontos de Função. O elemento primário

para a técnica é a especificação que é produzida nas fases iniciais do ciclo de vida.

De forma geral, o processo de contagem dá-se da seguinte forma: tem-se

inicialmente a identificação dos componentes, seguida da definição de sua complexidade

e consequente contribuição ao total da contagem. A soma de todas as contribuições

resulta no total de pontos de função não ajustados. Em seguida é aplicado um fator de

ajuste, obtido a partir das Características Gerais dos Sistemas (ver Box 1), que pode

alterar o tamanho não ajustado em -35% a +35%. Este último valor é chamado de pontos

de função ajustados. O fator de ajuste representa a influência dos requisitos técnicos e de

qualidade no tamanho do software.

Box 1. Exemplo/Características Gerais dos Sistemas

Característica Gerais dos Sistemas

As Características Gerais de Sistemas representam categorias de requisitos não funcionais que

podem afetar o tamanho do software. Cada uma dessas características deve ser analisada com

relação ao seu nível de influência sobre o sistema e pontuada de 0 (nenhuma influência) a 5

(grande influência).

( 1) Comunicação de Dados

( 2) Processamento Distribuído

( 3) Performance

( 4) Configuração Altamente Utilizada

( 5) Volume de Transações

( 6) Entrada de Dados On-Line

( 7) Eficiência do Usuário Final

( 8) Atualização On-Line

( 9) Complexidade de Processamento

(10) Reutilização

(11) Facilidade de Instalação

(12) Facilidade de Operação

(13) Múltiplos Locais

(14) Facilidade de Mudanças

Aqui cabe o registro que o acórdão TCU 1.910/2007 recomendou o não uso dos

fatores de ajuste, dada a subjetividade na atribuição dos níveis de influência de cada

categoria. Recomendou, ainda, que fossem feitas formas diferentes de cálculos para

demandas de desenvolvimento de novas funcionalidades, de alterações em

funcionalidades já desenvolvidas e para suprimir funcionalidades.

O objetivo da técnica de Análise de Pontos de Função não é medir apenas o

tamanho funcional do software, mas o tamanho funcional do projeto, que pode ser de

desenvolvimento ou de melhoria. O projeto de desenvolvimento é a criação da primeira

versão e considera as funcionalidades incluídas e de carga de dados. Já os projetos de

melhoria consideram a manutenção do software, podendo ser corretiva, evolutiva ou

perfectiva.

Para os projetos de manutenção/melhoria de software há, além da prescrita pelo

IFPUG, outra forma de dimensionar o tamanho funcional, a técnica EFP – Enhanced

Function Points – publicada pela NESMA – Netherlands Software Metrics Users

Association – que pode ser utilizada quando já se tem disponível uma base histórica de

projetos concluídos.

De uma forma geral, as técnicas de contagem de ponto de função possuem fatores

de correção que são aplicados sobre os pontos de função não ajustados, os quais

procuram mensurar várias situações como: inclusão, supressão, alteração, carga,

redesenho de banco de dados, atualização na documentação, entre outros. Isso decorre do

fato de que ao buscar mensurar o esforço do projeto a técnica de APF entende que cada

situação requer um esforço diferenciado. Na medida em que a Fábrica de Software quer

ser remunerada por seu esforço, o uso de APF para medir este esforço é ferramenta

fundamental para definir o critério remuneratório da empresa contratada pela

Administração Pública.

Métodos Ágeis

As metodologias ágeis de desenvolvimento e gerenciamento se baseiam em

alguns princípios que criam um novo paradigma de desenvolvimento de sistemas, quando

comparados aos princípios tradicionais, cujos pilares são declarados no Manifesto Ágil:

Indivíduos e Interações entre eles mais do que processos e ferramentas;

Software em funcionamento mais que documentação abrangente;

Colaboração com o cliente mais que negociação de contratos;

Responder a mudanças mais que seguir um plano.

Notadamente, este novo paradigma se baseia em uma crítica a uma forma

tradicional de se desenvolver software, sobretudo a burocracia gerada por serem mais

voltadas a processos e documentação do que a código executável.

Na atualidade, há várias práticas de desenvolvimento de software que são

consideradas ágeis, entre elas o Scrum e o eXtreme Programming – XP, que refletem de

alguma forma a aplicação dos princípios do manifesto ágil, em especial àqueles que

focam a colaboração, interação e foco na criação de código.

O Scrum não é propriamente uma metodologia de desenvolvimento, mas um

framework de gerenciamento de projetos. Suas práticas ajudam a organizar o processo de

trabalho da equipe do projeto, voltando-o para entregas rápidas e frequentes de resultado.

O elemento central deste framework é dividir o projeto em entregas menores que sejam

passíveis de serem desenvolvidas dentro de interações curtas e de tamanho fixo,

chamadas Sprints. O escopo total do software é organizado no product backlog e a cada

Sprint é destacada uma parte do backlog para formar o Sprint Backlog. Para o Scrum, o

detentor da informação necessária criação do product backlog e do sprint backlog é

chamado de Product Owner, que possui a visão do todo e que posteriormente será o

responsável por validar o resultado do produto entregue. A ideia é simples: ciclo menor,

escopo menor, menos sobrecarga de gerenciamento, menos burocracia, mais tempo para

engenharia.

O Scrum define as suas práticas de gestão a partir da ótica da equipe de

desenvolvimento, desenhando-a de forma mais simplificada, a fim de que a equipe esteja

livre para focar na construção do produto. Outro papel importante surge nesse contexto, o

Scrum Master, que é o responsável por criar estas condições de trabalho para a equipe.

Um dos fatores críticos para o sucesso de um projeto Scrum é a disponibilidade

total do cliente para tirar dúvidas, alterar escopo e definir prioridades. Desta forma, as

informações necessárias à atuação rápida da equipe estariam sempre disponíveis,

reduzindo a necessidade de grandes ciclos de análise de negócio, escrita de casos de uso,

validações, revisões, etc., pois a equipe tem fácil acesso a este conhecimento. Outro

ponto positivo desta aproximação é que a comunicação direta evita os erros de

comunicação causados entre a escrita dos requisitos, a geração de modelos de análise, o

projeto e, posteriormente, a implementação. Normalmente, perde-se informação neste

processo e se gasta um esforço considerável em validações e correções posteriores.

Diferentemente do Scrum, que focou suas práticas na forma de gerenciar o

projeto, o eXtreme Programmig (ou XP) voltou-se para práticas mais especificas de

engenharia de software e programação. Trata-se de uma metodologia de desenvolvimento

de software desenvolvida para equipes pequenas e parte do princípio de que a melhor

documentação é o código-fonte. Para o XP, a arquitetura do sistema é construída ao longo

do projeto, no qual o código-fonte é continuamente reconstruído. O XP baseia-se na

definição de valores e – comunicação, simplicidade, feedback, coragem e respeito -

princípios – feedback rápido, presunção de simplicidade, mudanças incrementais, abraçar

mudanças. Estes valores e princípios refletem a crença que levarão a definição de práticas

de trabalho e engenharia que serão utilizadas na prática pelas equipes, tais como: o

cliente está sempre disponível; metáforas; releases pequenas; testes de aceitação;

desenvolvimento orientado a testes; integração contínua; projeto simples; refatoração;

programação em pares; propriedade coletiva do código; aplicação de padrões de projeto e

codificação; semana de 40 horas.

Assim como o Scrum, o XP volta seu foco à criação do produto e o seu código,

em detrimento das práticas de gestão, criando, entretanto, práticas adicionais para

resolver questões próprias do desenvolvimento de software, como por exemplo enfoque

dado aos testes, com o uso do Test Driven Development e a importância dos testes de

aceitação. Temos ainda a questão estrutural ou arquitetural envolvida na uso de padrões,

no projeto simples, na integração contínua e principalmente na refatoração.

No entanto, se a simplificação conceitual dos métodos ágeis apresenta ideias

importantes, a aplicação prática nas organizações, em especial nas públicas, oferece um

ambiente adverso à manutenção de várias de suas premissas. Por exemplo, ao centrar o

foco na engenharia do produto, o Scrum joga para fora dele uma boa parte da

complexidade dos problemas da engenharia de software. Neste ponto grande parte da

comunidade ágil comete equívoco ao achar que a abordagem mais simplificada de gestão

tornou tudo mais simples, afinal a complexidade inerente ao processo de transformar

necessidades em produto de software de qualidade não deixa de existir. Apenas

transferiu-se o problema de lugar. Observem que toda a responsabilidade sobre a visão do

projeto, sobre o todo, foi transferido para o Product Owner, pois é da responsabilidade

deste ator a definição de todas as regras de negócio (estórias), backlog, tirar dúvidas, etc.

A complexidade que antes era tratada pela engenharia de requisitos e suas técnicas de

levantamentos de dados agora são confiadas a definição de apenas um ator. Por outro

lado, o XP também gera o requisito de presença contínua do Product Owner e sua

engenharia é fortemente baseada na construção de código-fonte e refatoração, o que gera

requisitos importantes de maturidade para o contratante. É importante notar que a

presença contínua do Product Owner junto a equipe de desenvolvimento é um problema

significativo para o uso de métodos ágeis na Administração Pública, uma vez que, via de

regra, não é possível ao demandante estar disponível integralmente à equipe pois tem

outras atribuições.

Encontro ou choque de paradigmas?

Em uma primeira vista, observa-se uma grande disparidade entre as abordagens

tradicionais e as ágeis, especialmente se for considerado o ponto de vista de um

contratante. No entanto, uma análise mais detalhada mostra que não se trata de um

choque, mas de um encontro que pode oferecer bons resultados, desde que sejam

consideradas algumas questões que veremos abaixo:

O que está sendo contratado: Produto ou Processo?

Esta é uma questão base. O que se quer é um produto de software desenvolvido, a

fim de atender requisitos específicos que não são atendidos por softwares de prateleira,

ou um processo rápido de entregas de software?

Este direcionamento gera consequências importantes sobre como lidar com as

entregas e como tratar o processo de mudanças. Inicialmente, é preciso entender que o

produto de software não é apenas o código que é executado propriamente, mas também

os artefatos gerados ao longo do processo.

Aqui ocorre a primeira armadilha da contratação, a baixa compreensão do valor

do software a ser contatado para a cadeia de valor da organização e na estratégia

corporativa, em outras palavras, o software será crítico ou acessório para a organização?

As contratações devem acontecer para que as organizações atinjam seus objetivos

estratégicos. Normalmente, um software está vinculado à execução de um processo

organizacional que está mapeado em uma cadeia de valor. Quando pensamos desta

forma, olhamos para o longo prazo, para a cadeia de valor, para o produto e para o seu

ciclo de vida dentro da organização. A partir daí é possível conhecer o contexto da

volatilidade dos requisitos, dos timings das entregas, da criticidade dos problemas a

serem resolvidos. A equação é simples: quanto mais instável é o terreno, maior é o custo

do prédio a ser construído nele.

Estabilidade dos Requisitos

Essa questão é muito importante, pois normalmente os produtos que estão

vinculados a processos estruturantes na base da cadeia de valor têm requisitos mais

estáveis, ciclo de vida longo, quantidades maiores de manutenções evolutivas e

perfectivas. Nestes casos, ter um software melhor documentado, no qual as regras de

negócio são explicitadas e os modelos arquiteturais são bem detalhados, é de fundamental

importância, pois o custo de manutenção deste produto deve ser considerado. Produtos

deste tipo têm várias fábricas de software ao longo de seu ciclo de vida.

Por outro lado, produtos vinculados a áreas de inovação, de marketing, de vendas

ou entrega direta de serviço, que possuem requisitos instáveis, tendem a necessitar de

respostas de mais curto prazo, envolvendo muitos protótipos e provas de conceito. Nestes

casos, não há necessidade de documentação detalhada, ou manutenção de modelos

intermediários, pois o ciclo de vida será menor. Logo, a demanda por manutenção

também. A regra aqui também é simples: maior instabilidade, menor o ciclo de vida,

menor o investimento, menor impacto do insucesso.

O importante deste argumento é que a organização entenda o que ela está

comprando, pois ao comprar o processo ágil tem que ter a ciência de que o código-fonte

entregue está em contínua evolução, ou seja, apesar de em cada entrega haver um código

funcional em execução já entregando valor para a organização, não quer dizer que este

código seja de qualidade, sob a ótica da aplicação completa. Este código será revisitado

várias vezes e será aprimorado.

Como mensurar o impacto das refatorações

A refatoração, ou refactoring, é o trabalho de redesenho do código, dada a

inserção de uma nova funcionalidade, de forma que ele volte a sua forma mais simples.

Este princípio, aliado ao princípio do projeto simples, ou seja, a busca por evitar os

excessos de engenharia, é considerado uma boa prática de desenvolvimento, pois permite

que várias pessoas entendam o código criado e, consequentemente, o mantenham

futuramente.

Aqui surge uma importante questão: qual a natureza da refatoração? Ela é

intrínseca ao processo de desenvolvimento, ou uma ação disparada a partir de um

processo de mudança? Responder esta questão tem consequências importantes do ponto

de vista de quem contrata. Vejamos! Os adeptos do XP sempre atacaram o excesso de

engenharia das abordagens centradas na arquitetura, todavia para chegar a uma

arquitetura mais adequada e estável, do ponto de vista da completude do escopo, as

equipes XP gastam considerável esforço em refatorações. Nenhum problema até aqui, a

não ser o fato de que retrabalho, alterações e exclusões de código são parte do processo

de engenharia do código. Por outro lado, a refatoração é uma ação que também é

disparada a partir de processo de mudança, pois a mudança em um requisito pode

implicar uma forma totalmente distinta de implementação.

De quem é a conta?

Agora sim toda esta discussão fará sentido: quem deve arcar com os custos

gerados pelo esforço das refatorações? Esta é fácil: de ambos, depende do que a gerou.

Mas não é esta a resposta que mais importa. O que realmente interessa é: há uma conta, e

se, neste caso, deve haver gestão sobre seus fatores. Partindo do princípio de que a

fábrica de software tem o domínio da engenharia do produto, nos ateremos a discutir a

necessidade do contratante em controlar o que está sendo criado e entregue como produto

em cada release.

Para a devida gestão do impacto das mudanças é importante lembrar que ao

falarmos de custo, retomamos o contexto dos Pontos de Função, pois é a métrica que

permite a derivação do custo relacionado a uma demanda de software.

As solicitações de mudanças e melhorias em funcionalidades já desenvolvidas

resultam na aplicação de redutores na quantidade de pontos de função daquela demanda,

se comparado a um desenvolvimento novo, pois pressupõem que o código não será

escrito do zero, mas alterado ou suprimido. Em regra, o que define se uma demanda é

uma melhoria é o fato de ela recair sobre um código entregue e colocado em produção,

caso contrário aquele código ainda estará em desenvolvimento. Ou seja, para

considerarmos que uma demanda, fruto de uma mudança, terá seu valor reduzido temos a

necessidade de que o código anterior tenha sido recebido, homologado, aceito,

contabilizado e colocado em produção.

Aqui temos uma grande armadilha: ao fatiarmos o escopo do projeto maior nas

Sprints, temos que observar que o produto de cada entrega deve ser coeso e independente,

de forma que possa ser colocado em produção e utilizado pelo usuário antes do

desenvolvimento dos demais. Esta preocupação é simples: o início do período de

garantia. O recebimento da release implica no início do período de garantia. É a garantia

que dá cobertura de demandas corretivas devido a erros e bugs. Por outro lado, quando

não consideramos o desenvolvimento do módulo anterior, o qual se deseja alterar, pode-

se pagar na integralidade dos pontos de função, sem a aplicação de deflatores, por

demandas que, por sua natureza, não geram este custo. Ou seja, estar-se-ia pagando o

desenvolvimento de uma funcionalidade por completo, quando na verdade só foi

necessário alterar a implementação de um método ou query no banco de dados. Em

resumo, o terror para qualquer gestor público: pagar por um serviço que não foi

executado.

Conclusões

A conclusão mais importante deste artigo é a necessidade de que o contratante

tenha um mínimo de maturidade em software, ou seja, contratar desenvolvimento de

software sem ter conhecimento, processos e ambientes adequados para receber este

produto é não ter controle sobre o produto entregue. Este é um equívoco que a APF vem

cometendo em muitos casos, nos quais a contratação de uma fábrica de software é vista

como a solução para dar vazão às necessidades de desenvolvimento de sistemas e para a

falta de pessoal interno capacitado. A Administração Pública deve ter conhecimento e

processos que a permitam aferir a materialidade e a qualidade da entrega. Para tanto, deve

dominar as disciplinas que envolvem a definição de escopos e requisitos não ambíguos e

a recepção do produto solicitado. Neste caso, deve ser dado grande foco nas disciplinas

de Gerência de Configuração e na Garantia da Qualidade.

Destacamos ainda outras necessidades fundamentais:

Arquitetura de referência: Observem que não tratamos aqui da necessidade de

arquiteturas complexas, rebuscadas e adaptáveis, mas da importância de que a

arquitetura final não seja fruto exclusivo de um processo indutivo, construído

iteração a iteração. É importante que haja uma estrutura básica, um kernell, que

seja capaz de responder os requisitos funcionais que serão desenvolvidos em cada

ciclo. O objetivo aqui é limitar o impacto das refatorações de forma a não gerar

impactos sistêmicos e custos maiores com mudanças;

Tabela de Requisitos Não Funcionais: Esta é uma consequência do mesmo

raciocínio do item anterior. No entanto, esta tem implicações mais diretas no

processo de homologação e aceitação. A validação dos itens desta tabela

constituirá em item obrigatório para a aceitação de cada entrega e deve refletir o

conjunto de requisitos que garantem a estabilidade estrutural da aplicação. Este é

outro ponto em que as organizações falham com certa frequência, pois, dado a

baixa experiência em desenvolvimento de software, têm tabelas de requisitos não

funcionais genéricas que não refletem a realidade do software que será

desenvolvido;

Processo de Homologação e Aceitação bem definido: É importante que a

organização se prepare para a contratação. Processos de homologação mal

definidos ou não definidos são frutos de grande dor de cabeça para gestores de

contrato e prepostos em contratações públicas. É preciso que o contratante se

prepare para disponibilizar seus servidores para os testes de aceitação. É preciso

que as etapas do processo de homologação evidenciem não apenas a aceitação

funcional, mas também a não funcional.

O processo de homologação deve prever a auditoria sobre os pontos de função

efetivamente entregues, para que seja feita a contagem correta dos produtos

entregues, com a devida aplicação dos deflatores que se fizerem necessários, sob

pena de se pagar mais do que se deveria pelos produtos entregues;

Processo de Gestão de Mudanças e de Configuração: É necessário que o

contratante tenha um processo de GCM – Gestão de Controle de Mudança, para

que possa ter gestão sobre as mudanças nos artefatos e códigos de software

entregues. Somente desta forma será possível evidenciar e medir o que foi

entregue, além de posteriormente separar manutenções evolutivas ou perfectivas,

que implicam em novos pagamentos, das manutenções corretivas;

Necessidade de manutenção do ambiente de integração contínua no

contratante: Este é um ponto meio controverso, dado que este é um ambiente

normalmente vinculado à equipe de desenvolvimento e à sua plataforma de

trabalho. É muito comum que estes ambientes só existam nas redes da fábricas

contratadas, pois normalmente muitos contratantes não têm sequer ambiente de

desenvolvimento. No entanto, o ambiente de integração contínua gera saídas

importantes para a contratada, como os relatórios de execução de testes. Para um

contratante que não domina a disciplina de testes e em cenários em que os testes

não sejam automatizados, o que é relativamente comum, é importante ter o

domínio sobre como se comporta o processo de identificação e resolução de erros,

se os testes unitários e sistêmicos estão sendo efetivos. Esta informação é

importante no desenho e dimensionamento do processo de homologação, pois se

as evidências de execução de testes e garantia da qualidade são poucas, mais

criterioso deverá ser o processo de homologação e aceitação do produto.

Normalmente, quando este ambiente é fisicamente localizado na fábrica de

software, o acesso a este nível de informação é mais difícil.

Observa-se assim que contratar o desenvolvimento de software na APF é um

desafio enorme, pois por um lado há a obrigação normativa advinda dos acórdãos do

TCU de uso de Pontos de Função e, por outro, a necessidade de uso de paradigmas que

gerem resultados e entregas mais rápidas e alinhadas ao seu negócio. No entanto, a

questão é mais sistêmica e complexa, pois o aumento da demanda de TI é crescente e as

equipes internas não crescem na proporção necessária. A única forma de resolver esta

equação é com conhecimento e tecnologia: conhecimento sobre o seu negócio, sobre sua

cadeia de valor, sobre como melhor organizar seus recursos para atender o que realmente

agrega valor; tecnologia para armazenar e transformar este conhecimento em processos,

para que se possa ganhar escala sem depender do aumento proporcional nos recursos

humanos.

As metodologias ágeis trazem muitas respostas, mas seu uso implica em muitos

desafios. Desafios estes que o gestor público de TI tem que conhecer e se preparar para

enfrentá-los, entendendo que esta preparação representa ter o conhecimento e maturidade

em engenharia de software, bem como a preparação de servidores e de ambientes de

software para receber os produtos.

Links

SISP - Sistema de Administração dos Recursos de Tecnologia da Informação;

http://www.governoeletronico.gov.br/sisp-conteudo;

Manual de Contagem de Pontos de Função

http://www.ifpug.org/ e http://www.bfpug.com.br/

Enhanced Function Points – publicada pela NESMA – Netherlands Software Metrics Users

Association

http://www.fattocs.com.br/traduzido/earlyfpa.asp

Manifesto Ágil

http://manifestoagil.com.br/

Scrum Guide – Portuguese

www.scrum.org/scrumguides