Modelo de Contratação de Serviços de Desenvolvimento e Sustentação de Software

Modelo de Contratação de Serviços de Desenvolvimento e Sustentação de Software

Em 20 / 10 / 2021, a Secretaria de Governo Digital do Ministério da Economia lançou uma consulta pública sobre sua proposta de normativo para instituir o Modelo de Contratação de Serviços de Desenvolvimento e Sustentação de Software para os órgãos do Sistema de Administração dos Recursos de Tecnologia da Informação (SISP).

Acesse a consulta por aqui

O modelo aborda as diretrizes que devem ser observadas desde a definição da estratégia da adoção dos serviços até a gestão das atividades relacionadas ao desenvolvimento e sustentação de software, incluindo diferentes modalidades de remuneração e as respectivas ações para tratamento dos riscos e medidas para alcance dos resultados esperados.

Por que a consulta pública sobre o Modelo de Contratação de Serviços de Desenvolvimento e Sustentação de Software é importante

Nos últimos 20 anos demos passos enormes em direção a uma maior maturidade nas contratações públicas. O uso de uma métrica cujo objeto de medição é a intercessão do software com o fluxo operacional dos processos de negócio foi chave para isso. Estamos falando da Análise de Pontos de Função. Um método simples para medir software na visão do usuário.

Por melhor definida ou simples, que seja uma solução de medição, a partir do momento em que ela é usada para fins de remuneração, surgirá um tecnocrata esticando a técnica além de seus limites em determinado contexto com o objetivo de maximizar seus resultados; ou melhor, a medição de seus resultados.

Como a APF não foi diferente; principalmente considerando:

• A irresponsabilidade na determinação de preços inexequíveis;
• A falta de instrumentos para a administração lidar com esses preços;
• O desafio da qualificação do profissional de TI em habilidades de gestão.

Há o que aperfeiçoar na tecnologia de medição? Sem dúvida. Por isso, o IFPUG lançou o Simple Function Point ou Ponto de Função Simples. Com ele, vários dos pontos de atenção relativos à incompatibilidade dos requisitos disponíveis e das necessidades para uma medição detalhada em pontos de função são abordados na medição.

Há o que aperfeiçoar no modelo de contratação?  Sem dúvida.  Enquanto estatísticas do Gartner Group apontam para um preço unitário médio na ordem de R$  2.200,00, os dados históricos na própria administração pública apontam para um ponto de função com um preço unitário na ordem de R$ 800,00. Por fim, se você consultar hoje o preço médio de fábricas de software nas licitações, esse preço é de cerca de R$ 400,00!

O novo modelo de contratação aborda esse ponto de atenção ao colocar no item 5.1.2.b a definição da inexequibilidade antes do resultado da licitação e não depois dele.

As mudanças com a adoção de uma métrica mais simples – nós sugerimos o Simple Function Point – e a definição prévia de um piso de inexequibilidade, já previsto no modelo proposto, são passos em direção à solução. No entanto, a adoção de medidas retrogradas como a contratação de postos de trabalho não são. Isso levará inevitavelmente à administração pública a colocar um serviço central para o Governo Digital no mesmo patamar dos serviços de conservação predial

Em resumo, o uso de métricas padrão de software resolveu ou minimizou o problema do crescimento exponencial de despesas com desenvolvimento sem um vínculo estreito com os resultados entregues. Resolveu-se ou se minimizou aqueles contratos onde dificilmente se conseguia avaliar a razoabilidade dos preços.

Por outro lado, o gestor mais próximo do “chão de fábrica” deixa de ser apenas um “roteador de serviço” e passar a necessitar de ferramentas para gestão da produção. Um grande desafio considerando o cenário descrito e; portanto, temos um problema a ser resolvido.

Vemos como um ponto de atenção parte da solução desse problema ser como “culpar o termômetro pela febre”.

Webinar: Não culpe o termômetro pela febre

Colaborações sobre o Modelo de Contratação de Serviços de Desenvolvimento e Sustentação de Software

Dada a importância do tema, a extensão do documento e a complexidade intrínseca aos assuntos abordados, conforme avançamos na análise do documento, vamos atualizando esta página.

Em alguns temas, diferentes profissionais de nossa equipe colaboraram. E vamos organizar as manifestações conforme o item. A seguir nossas colaborações à consulta pública:

CAPÍTULO II – DOS SERVIÇOS DE DESENVOLVIMENTO E SUSTENTAÇÃO DE SOFTWARE

Art. 5º O modelo de contratação de serviços de desenvolvimento e sustentação de software admite a adoção de uma ou mais modalidades padronizadas de remuneração, descritas a seguir:

I – Pagamento por unidade funcional, aferido por meio da análise de Pontos de Função, combinado ou não ao pagamento por Horas de Serviço Técnico destinadas à cobertura de requisitos não funcionais, vinculados ao alcance de resultados e ao atendimento a níveis mínimos de serviços;
II – Pagamento por alocação de postos de trabalho, vinculado ao alcance de resultados;
III – Pagamento de valor fixo mensal para sustentação de portfólio de sistemas, vinculado ao atendimento de níveis mínimos de serviços;
IV – Pagamento de valor fixo por sprint executada, vinculado a níveis mínimos de serviços.

Em 28 / 10 / 2021, o Grupo Internacional de Usuários de Pontos de Função liberou o Ponto de Função Simples ou Simple Function Point. Apesar do recém lançamento, não se trata de uma novidade e o método tem amadurecido ao longo de 10 anos.

É uma solução de medição:

• Mantendo o benefício de sua base estar em como a administração define os seus fluxos operacionais e de sua intercessão com o produto de software em análise; e
• Eliminando etapas do processo de medição, cujo nível de detalhe exige uma maior interpretação dos requisitos – nem sempre bem descritos – o que promove divergências e aumenta a sobrecarga de gestão.

A métrica traz o benefício de:

• Uma maior comparabilidade em relação à UST ou HST;
• Permitir âncoras com os valores em pontos de função – ou seja referências de sobre preço com os dados atualmente disponíveis; e
• Permitir aos órgãos de controle mais facilmente identificar pontos de atenção em todos os ciclos da contratação.

Todos os vícios apontados pelo acórdão 1508/2020 do TCU se potencializam (ao invés de serem contidos ou minimizados) pela medição não padrão com base em UST e HST.

Um exemplo de contingenciamento para os efeitos danosos à administração pelo uso de “métricas” como o UST ou o HST é a sua limitação a um % máximo em comparação ao serviço global.

Para mais informações sobre o Ponto de Função Simples:

Simple Function Point ou como medir software sem onerar o desenvolvimento

2. OS SERVIÇOS DE DESENVOLVIMENTO E SUSTENTAÇÃO DE SOFTWARE.

2.2.1.2. Análise de Ponto de função: método de medida de tamanho funcional de software definido pela ISO/IEC 14143-1:2007 e ISO/IEC 20926:2009;

Vemos que não é benéfico limitar Análise de Pontos de Função no contexto do domínio em questão à norma ISO/IEC 20926:2009. Há contratações feitas pela Administração Pública onde a métrica de medição do contrato é com sucesso a Contagem Estimativa da NESMA (uma simplificação da ISO/IEC 20926:2009) e atualmente há uma simplificação ainda maior e sem um caráter de aproximação do tamanho por meio do Ponto de Função Simples.

Nossa sugestão de redação é:

Sobre os demais métodos, também aderentes à ISO/IEC 20926:2009, apenas o método do COSMIC (ISO/IEC 19761:2011) tem alguma relevância – ainda assim fora do Brasil – e promove um maior esforço de gestão em uma época em que se busca mais agilidade.

5. MODALIDADES DE REMUNERAÇÃO

5.1. DEFINIÇÃO

5.1.1.3. As modalidades padronizadas por este modelo são:
a) contratação baseada em pagamento por unidade funcional e não funcional;
b) contratação com pagamento fixo por sprint executada;
c) contratação por posto de trabalho, com pagamento vinculado a resultados;
d) contratação baseada em valor fixo mensal por sistema sustentado, destinada exclusivamente ao serviço de sustentação de software.

A administração pública deve se atentar aos objetivos de Eficiência Operacional e de Transparência em suas ações. Considerando o Sprint ser uma janela de tempo fixo, a contratação com pagamento fixo por Sprint vincula, em termos práticos, a remuneração da contratada à passagem do tempo, inexorável, e independente de qualquer desempenho da contratada. É fundamental para os dois objetivos citados a medição da produção.

Paradoxo do Lucro Incompetência: “Na hipótese de desenvolvimento de projeto, por exemplo, a contratação por “homens-hora” conduz ao paradoxo do lucro-incompetência. Ou seja, quanto menor a qualificação e capacitação dos prestadores do serviço, maior o número de horas necessário para executá-lo e, portanto, maior o custo para a Administração-contratante e maior o lucro da empresa contratada.” Revista do TCU – jan / abr 2010, página 119.

Chamo a atenção de que a medição da produção pode estar em níveis mais alto do que a própria Sprint. Por exemplo, todas as Sprints em um mês ou trimestre. Sem uma medição da produção, se dá mais de uma década de passos para traz em direção ao paradoxo do lucro incompetência.

A maneira como, em geral, atualmente a medição tem sido feita a cada Sprint ou Release como escopo de medição pode (e deve em minha opinião) ser simplificada e já existem soluções no mercado para esse fim; como por exemplo, o Ponto de Função Simples do IFPUG e o uso de cada cartão ou história de usuário como escopo de medição.

5.1.2. São premissas que devem ser observadas na construção do Termo de Referência, independentemente da modalidade adotada:
a) A exigência de qualificação mínima dos profissionais que irão prestar os serviços técnicos especializados;
b) A fixação de patamar de preço mínimo para presunção relativa de inexequibilidade;
c) A definição de metas de produtividade;
d) A fixação dos critérios de aceitação dos serviços prestados;
e) A definição dos níveis mínimos de serviço e de qualidade;
f) A utilização, preferencialmente, de metodologia ágil durante a prestação dos serviços requeridos;

Várias das mudanças propostas no novo modelo no que se refere à medição são, de fato, resolvidas com o item 5.1.2.b exigindo a fixação de patamar de preço mínimo para presunção relativa de inexequibilidade.

Vejo várias críticas à medição da produção em geral e ao uso da Análise de Pontos de Função em particular como tendo uma causa raiz em preços inexequíveis resultantes do certam. Contratada e administração tentam resolver na medição durante a execução do contrato. Resolvendo esse problema raiz, os demais tendem a deixar de existir ou têm os seus efeitos diminuídos.

5.2. CONTRATAÇÃO POR UNIDADE FUNCIONAL (ANÁLISE DE PONTO DE FUNÇÃO) E NÃO FUNCIONAL (HORA DE SERVIÇO TÉCNICO)

5.2.1.2. Nessa modalidade, a remuneração do serviço deve ser feita por meio da métrica Ponto de Função, combinada, quando couber, ao pagamento por Horas de Serviço Técnico baseado em catálogos de serviços não funcionais previamente definidos.

Caso haja o interesse em uma medição diferente do proposto no Roteiro de Métricas do SISP; onde o atendimento a requisitos não funcionais é medido por meio de seu impacto na funcionalidade da aplicação, chamo a atenção para o Processo de Avaliação não Funcional de Software como base para a definição da sistemática de medição.

O SNAP apresenta a vantagem de:

• Ser altamente configurável;
• Resolver a questão do desenvolvimento onde a produtividade é baixa não por problemas de desempenho, mas por questões de produtividade;

Acoplar-se perfeitamente à medição das funcionalidades como já é maduro em nosso mercado conforme a Análise de Pontos de Função.

Um exemplo de caso de uso do SNAP é a Caixa Econômica Federal.

Webinar – SNAP: Medição não funcional de software

5.2.1.4. Todas as atividades relacionadas ao desenvolvimento de funcionalidades de software devem estar incluídas na métrica de pagamento por Ponto de Função. São atividades abrangidas pela métrica de Ponto de Função:
a) elicitação de requisitos;
b) codificação de software;
c) testes funcionais e unitários;
d) implantação em ambiente de homologação.

Não está claro se os 04 itens indicados representam um escopo exaustivo para o escopo de atividades, considerado nas horas ou reais investidos em cada ponto de função; ou se tem um caráter de exemplo não exaustivo.

De acordo com o ISBSG (Grupo Internacional de Padrões Benchmarking de Software), seus dados consideram também o desenho de arquitetura e a iniciação de um desenvolvimento.

Na mesma linha, o Gartner Group também o faz, considerando em seu escopo de atividades:

• Gerência de Projetos;
• Análise e Gerência de Requisitos;
• Projeto;
• Desenvolvimento e Testes Unitários;
• Teste de Sistema;
• Remoção de Defeitos;
• Implementação e Liberação;
• Gerência de Qualidade;
• Treinamento de multiplicadores e outras ações de transição.

Nada impede um modelo de negócio mais restrito; contudo, seria importante estabelecer um % de cobertura entre o modelo de negócio proposto em relação ao escopo de atividades completo com o objetivo de avaliar o desempenho de cada órgão do SISP e do próprio SISP como um todo em relação a referências externas.

5.2.1.5. O pagamento de Horas de Serviço Técnico deve abranger exclusivamente os aspectos não funcionais que escapam do escopo da análise de ponto de função. São atividades abrangidas pela métrica de Horas de Serviço Técnico:
a) Iniciação de projeto, que inclui atividades de planejamento do projeto, como a elaboração de documento de visão, entre outros;
b) Definição de arquitetura da solução;
c) Aplicação de procedimentos e técnicas de mapeamento de processos;
d) Elaboração de pesquisas e levantamentos de expectativas de usuários;
e) Realização de testes especializados, a exemplo de: testes de desempenho (carga, stress e estabilidade), testes de usabilidade e testes de segurança;
f) Configuração, construção ou operação de processos de implementação automatizada (deployment pipeline);
g) Implantação assistida em ambiente de produção;
h) Outras atividades não relacionadas ao desenvolvimento das funcionalidades do software

Há atividades de requisitos (cito o documento de visão) já previstas no item 5.2.1.4 como parte do escopo de atividades a ser considerado na avaliação da produtividade ( PF / HH ou PF / R$ ) sendo medido também como HH complementares. Adicionalmente, há conflito com o Roteiro de Métricas de Software do SISP.

Caso de fato seja essa a intenção, destaco meu comentário no item 5.2.1.5 da importância de qualificar o percentual de cobertura no novo modelo proposto em relação ao escopo de atividade completo (100%) e da atualização do Roteiro de Métricas de Software para refletir o novo modelo.

Por fim, chamo a atenção para limitar o que se mede sem vínculo a alguma funcionalidade em relação ao total do contrato. Por exemplo, algo em torno de 10% ou 20%.

5.2.1.8. Os aspectos não funcionais devem ser objeto de item separado e aferíveis por meio de hora de serviço técnico prevista em catálogo que contenha, no mínimo:
a) a identificação do serviço não funcional;
b) o volume máximo de horas correspondente ao serviço;
c) o tipo de perfil que está apto a desempenhar o serviço;
d) os produtos e resultados esperados para cada serviço;
e) prazo máximo de execução dos serviços;
f) os critérios de aceitação de cada serviço.

O Processo de Avaliação não Funcional de Software – ou SNAP – desenvolvido pelo Grupo Internacional de Usuários de Pontos de Função (IFPUG) é um excelente framework a partir do qual podem se escolher subcategorias para enquadrar os mais variados tipos de desenvolvimento e se acopla perfeitamente à funcionalidades medidas pela Análise de Pontos de Função, a Contagem Estimativa da NESMA ou o Ponto de Função Simples,

Recomendo avaliar alguns casos de uso como o da CAIXA; a documentação do próprio SNAP – que é gratuita; e publicações sobre o mesmo.

5.3. CONTRATAÇÃO POR SPRINTS

5.3.5.2. Deve-se evitar o início de projetos ágeis sem o correspondente planejamento do produto a ser desenvolvido.

Comento que se um backlog de Sprint não consegue ser medido pela Contagem Estimativa da NESMA ou pelo Ponto de Função Simples, então seus itens deveriam ter sido melhor refinados anteriormente ao Sprint no qual foi incluído. Consequentemente, a pena é ter problemas para a entrega como consequência de causas logo no berço.

Nisso vemos a Análise de Pontos de Função não só entregando referências de medição do desempenho na dimensão da eficiência operacional, mas também como um instrumento simples e objetivo de avaliação da qualidade do backlog.

Muitos dos problemas apontados por gestores públicos de contratos de desenvolvimento e sustentação de software quanto ao uso da APF são similares a culpar o termômetro pela febre.

Conclusão

Ainda há bastante do normativo a ser avaliado. Eu peço a colaboração dos demais colegas nessa empreitada. Conforme formos amadurecendo nessa crítica, vamos atualizando essa página. Seus comentários são muito bem vindos.