DOU 22/03/2023 - Diário Oficial da União - Brasil

                            Documento assinado digitalmente conforme MP nº 2.200-2 de 24/08/2001,
que institui a Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil.
Este documento pode ser verificado no endereço eletrônico
http://www.in.gov.br/autenticidade.html, pelo código 05152023032200044
44
Nº 56, quarta-feira, 22 de março de 2023
ISSN 1677-7042
Seção 1
8.7 Da análise de exequibilidade das propostas
8.7.1 O termo de referência pode estabelecer procedimentos e critérios para análise da planilha de formação de custos, observando o disposto na Súmula nº 262 TCU, em relação
a necessidade de assegurar à licitante a oportunidade de demonstrar a exequibilidade da sua proposta.
8.7.2 Segundo Acórdão nº 2.362/2015 - Plenário, admite-se o estabelecimento de um patamar de preço abaixo do qual há presunção relativa de inexequibilidade, situação em
que a licitante deverá demonstrar a exequibilidade do preço apresentado.
8.7.3 Se houver indícios de inexequibilidade da proposta de preço, ou em caso da necessidade de esclarecimentos complementares, poderão ser efetuadas diligências, na forma
do §2º do art. 59 da Lei nº 14.133, de 2021, para que a empresa comprove a exequibilidade da proposta.
8.7.4 São exemplos de critérios de presunção relativa de inexequibilidade:
a) valor global da proposta inferior ao patamar de preço definido;
b) ausência ou valores irrisórios nos elementos de custos relacionados à cobertura tributária.
8.7.5 A definição do patamar de preço abaixo do qual há presunção relativa de inexequibilidade deve ser documentada e utilizar critérios objetivos.
8.7.6 Para a modalidade baseada no pagamento por Ponto de Função, o cálculo do patamar mínimo do valor do Ponto de Função deve considerar os parâmetros de composição
do time e de produtividade esperada, relacionados a seguir:
a) A produtividade considerada para projetos ágeis de TI (em geral, tem-se 10 horas por Ponto de Função);
b) A composição mínima da equipe ágil, em termos dos perfis profissionais e suas respectivas taxas de alocação;
c) A média dos salários de referência (Anexo II) dos perfis que integram a composição mínima da equipe ágil;
d) A duração máxima da sprint;
e) O custo mensal médio estimado do time ágil.
8.7.7 Para a modalidade baseada em Horas de Serviço Técnico, deve-se definir o patamar de inexequibilidade considerando o salário constante no Anexo II para o perfil de
referência.
8.7.8 Para a modalidade baseada em sprint, deve-se definir o patamar de inexequibilidade considerando a composição do time previsto para cada tipo de sprint, a duração das
sprints e o salário dos perfis profissionais previstos para a execução das sprints, conforme Anexo II.
8.7.9 Para a modalidade de alocação de profissionais de TI, deve-se definir o patamar de inexequibilidade considerando o salário constante do Anexo II para cada perfil
profissional.
8.7.10 Para a modalidade de valor fixo mensal, deve-se definir o patamar de inexequibilidade considerando o salário constante no Anexo II para o conjunto mínimo de
profissionais estimados para execução dos serviços.
9. DA VIGÊNCIA DOS CONTRATOS DE DESENVOLVIMENTO, MANUTENÇÃO E SUSTENTAÇÃO DE SOFTWARE
9.1 Conforme previsto na Orientação Normativa nº 38, de 13 de dezembro de 2011, da Advocacia-Geral da União, em regra o prazo de vigência é de até 12 meses, entretanto
admite-se período superior em função da complexidade e peculiaridade do objeto, observando-se os limites legais estabelecidos e justificando-se no Termo de Referência a adoção do prazo
de vigência.
10. DA SUBCONTRATAÇÃO NOS SERVIÇOS DE DESENVOLVIMENTO, MANUTENÇÃO DE SOFTWARE
10.1 Admite-se prever a subcontratação de etapas específicas do processo e desenvolvimento, manutenção e sustentação de software, a exemplo das etapas de testes,
prototipação, codificação, provisionamento de ambientes, entre outras.
11. DAS FERRAMENTAS
11.1 De gestão de demanda
11.1.1 Pode-se considerar ferramenta de gestão de demanda (ITSM) como solução de TIC distinta do serviço de desenvolvimento, manutenção e sustentação de software, ou
permitir que sejam fornecidas pela contratada. Entretanto, caso seja necessário prever o fornecimento de ferramentas de ITSM ou outras específicas, faz-se necessário observar eventuais
riscos descritos nesta seção.
11.1.2 A contratação de ferramenta distinta da contratação do serviço de desenvolvimento, manutenção e sustentação de software permite que o órgão planeje e execute com
mais eficiência e estabilidade o gerenciamento de demandas, incidentes, problemas e requisições, além de permitir maior controle sobre as melhorias e aperfeiçoamentos necessários nos
processos, contribuindo assim para o aumento da maturidade da área de TI no tocante ao gerenciamento de seus serviços.
11.1.3 O uso de ferramenta sob gestão do órgão permite ainda uma maior proteção ao histórico do gerenciamento do contrato (essencial para a gestão e renovação contratuais),
pois a manutenção e a salvaguarda desses dados encontram-se sob a responsabilidade direta da área de TI do órgão, que acompanha e monitora processos internos de gestão e de
governança de TI.
11.1.4 Além disso, permite minimizar riscos de manipulações indevidas e adulterações de dados, principalmente, no que se refere aos dados utilizados na aferição dos indicadores
de níveis de serviço, tais como o tempo de atendimento dos chamados. Consequentemente, evita-se também a ocorrência de pagamentos incorretos ou indevidos.
11.2 Da análise de código
11.2.1 A contratação e gestão dos serviços de desenvolvimento, manutenção e sustentação de software deve ser apoiado pelo uso de recursos tecnológicos de análise da
qualidade de códigos.
11.2.2 As ferramentas de análise de código devem ser parametrizadas com base em critérios de qualidade estabelecidos pelo órgão.
12 MENSURAÇÃO DE SOFTWARE
12.1 Nas contratações de serviços de desenvolvimento, manutenção e sustentação de software devem ser definidas métricas objetivas que permitam a gestão contratual, a
mensuração e a devida remuneração dos serviços e produtos efetivamente entregues pela empresa contratada no contexto do processo de desenvolvimento de software adotado pelo órgão
ou entidade.
12.2 O processo de medição de software visa coletar, analisar e relatar dados e informações objetivas para apoiar um gerenciamento eficaz e demonstrar a qualidade dos
produtos, serviços e processos.
12.3 Independente da modalidade de contratação, deve-se aferir a entrega de produtos por meio de métricas de produto de software, mantendo-se uma base histórica, a
exemplo de:
a) Pontos de Função (IFPUG, NESMA, COSMIC, Simple Function Point - SFP);
b) Linhas de código implementadas;
c) Pontos de história (Story Point).
12.4 A métrica de software deve estar prevista no processo de desenvolvimento de software da organização. Deve-se descrever no instrumento convocatório ou no processo de
software da organização as regras de uso, a forma de mensuração, o mecanismo de cálculo, o escopo de aplicação e eventuais recursos ou procedimentos padronizados para realização das
medições, devendo-se assegurar:
12.4.1 Caso seja adotada a mensuração por pontos de função, a vinculação a roteiro de métricas que descreva o procedimento e as condições de contagem do tamanho funcional,
observando preferencialmente o Roteiro de Métricas de Software do SISP.
12.4.2 Caso seja adotada a mensuração por linhas de código, a vinculação a guia ou roteiro de codificação de softwares que contenha as melhores práticas de codificação com
vistas a assegurar uma codificação enxuta, limpa, clara e eficiente, observando as diretrizes de codificação segura publicadas pela SGD. Deve-se prever mecanismos automatizados de
verificação do cumprimento das diretrizes constantes nesses guias ou roteiros.
12.4.3 Caso seja adotada a mensuração por história de usuário, deve-se vincular a roteiro de métricas que descreva o procedimento e as condições de contagem, padronização
das histórias de usuário por meio de modelos (templates), sistema de pontuação para dimensionamento e terminologia comum a todas as áreas de negócio.
12.4.4 Caso seja adotada outra métrica, deve-se assegurar que o objeto de aferição está vinculado a entrega de produtos de software, evitando-se a utilização de métricas
exclusivamente baseadas em esforço, além de vincular a roteiro de métricas que descreva o procedimento e as condições de contagem, sistema de pontuação para dimensionamento e
terminologia comum a todas as áreas de negócio.
12.5 A Secretaria de Governo Digital do Ministério da Gestão e da Inovação em Serviços Públicos poderá publicar orientações complementares acerca do uso de métricas de
software.
13 GERENCIAMENTO DE RISCOS
13.1 Independentemente da modalidade adotada, o órgão deve realizar o mapeamento de riscos da contratação detalhando a identificação, a classificação e o tratamento dos
riscos associados às contratações públicas. De forma complementar, deve-se considerar os seguintes riscos a seguir, específicos para contratação de serviços de desenvolvimento,
manutenção e/ou sustentação de softwares:
13.1.1 Capacidade Técnica inadequada dos profissionais:
a) Descrição: Durante a execução do contrato, pode-se receber profissionais sem as capacidades técnicas mínimas esperadas pela Contratante.
b) Sugestões para tratamento: Definir no Termo de Referência os perfis profissionais mínimos, incluindo requisitos de experiência e formação acadêmica. Prever que a contratada
realize testes ou avaliações técnicas para aferir se o recurso humano a ser apresentado à contratante possui as capacidades técnicas esperadas. Deve-se definir critérios objetivos para
verificação das capacidades.
13.1.2 Estabelecimento de critérios de remuneração e de níveis mínimos de serviço complexos e subjetivos:
a) Descrição: A definição dos critérios de remuneração e respectivos níveis de serviços devem estar associadas aos produtos efetivamente entregues ou a fatores determinantes
da qualidade do software produzido ou sustentado. Porém, ao se definir indicadores desassociados do produto final, ou cuja dificuldade de mensuração é elevada ou altamente subjetiva
(baseada em avaliação intuitiva ou meramente qualitativa sem parâmetros pré-definidos) pode-se comprometer o processo de aferição da qualidade dos produtos.
b) Sugestões para tratamento: Estabelecer métricas e indicadores claros e objetivos para aferição da produtividade e qualidade, vinculados - sempre que possível - a ferramentas
automatizadas de aferição e extração de dados.
13.1.3 Complexidade na gestão de recursos humanos ou na contabilização da métrica adotada:
a) Descrição: A modalidade selecionada combinada com determinadas características da natureza da demanda ou da organização pode resultar em uma gestão de recursos
complexa que demanda um esforço significativo, resultando em um gargalo na fiscalização ou no gerenciamento do contrato.
b) Sugestões para tratamento: A especificação e utilização de ferramentas automatizadas de gerenciamento e controle de demandas, bem como ferramentas de contabilização
ou estimativa de métricas poderá mitigar o risco de sobrecarga nas funções de gerenciamento e fiscalização do contrato. O estabelecimento de processos otimizados de controle e
gerenciamento possuem capacidade de reduzir a execução de atividades desnecessárias.
13.1.4 Desmobilização frequente de recursos:
a) Descrição: A desmobilização frequente de recurso pode ser provocada por deficiência de gestão por parte da contratada ou oriunda de fatores externos às ações da contratada,
derivados de efeitos de mercado ou conjunturais. Contudo, independentemente das causas, há medidas que podem ser adotadas para mitigar os impactos desse risco.
b) Sugestões para tratamento: Prever métricas de equipes que estimule a contratada a manter mecanismos de gestão do conhecimento capazes de mitigar a dependência de
funcionários específicos ou ainda reduza o tempo ou mitigue impactos decorrentes da troca de profissionais na execução das demandas.
13.1.5 Ociosidade da capacidade de trabalho alocada, em situações de baixa demanda:
a) Descrição: A interrupção no fluxo de demandas ou falhas na gestão de demandas à contratada poderá resultar em ociosidade na capacidade alocada, a depender da
modalidade adotada.
b) Sugestões para tratamento: Realizar planejamento de consumo do contrato com vistas a evitar a ociosidade, por meio da realocação dos recursos em outros projetos previstos
no contrato.
13.1.6 Variações no volume de demanda
a) Descrição: O aumento ou redução significativos no volume de demandas poderá resultar em desequilíbrio para a contratada (aumento significativo) ou uma situação de
antieconomicidade para contratante (redução significativa).
b) Sugestões de tratamento: Avaliar modalidades baseadas em pagamento sob demanda, em detrimento de modalidades a preço fixo ou por alocação fixa de profissionais.
Além dos riscos apresentados nesta seção, cada órgão deverá realizar o mapeamento de riscos completo da contratação, conforme previsto na Instrução Normativa SGD/ME nº
94, de 23 de dezembro de 2022.
14 DO REGISTRO DE PREÇOS
14.1 Quando for conveniente a contratação de serviços de desenvolvimento e manutenção de software para atendimento a mais de um órgão ou entidade, a participação de
todos os órgãos integrantes na fase de Planejamento da Contratação é obrigatória.
14.2 O órgão gerenciador deverá incluir, no instrumento convocatório, cláusula que vede a adesão posterior por órgão não participante.

                            

Fechar