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 05152023032200038
38
Nº 56, quarta-feira, 22 de março de 2023
ISSN 1677-7042
Seção 1
4.4.2 Deve-se, preferencialmente, adotar Metodologias Ágeis no processo de desenvolvimento de software, considerando, no que couber, as orientações contidas no Guia de
Projetos de Software com Práticas de Métodos Ágeis do SISP, para a customização interna de um processo ágil.
4.4.3 Recomenda-se que o processo de desenvolvimento de software adotado observe, no que couber, as orientações constantes da ABNT NBR 12.207/2021, que trata dos
processos de ciclo de vida de software.
4.4.4 O processo de desenvolvimento de software aborda diferentes dimensões relacionadas ao ciclo de vida de construção e utilização de software. Entre as diferentes
dimensões, deve-se prever, no que couber, diretrizes e procedimentos sobre:
a) O fluxo de valor do produto, que envolve, ao menos, as atividades de planejamento, construção da release e transição dos produtos para o ambiente de produção;
b) A construção da visão do produto;
c) O planejamento do roadmap do produto;
d) Definição dos papéis e métodos de iteração;
e) Codificação limpa;
f) Codificação segura;
g) Implementação baseada em técnicas ágeis;
h) Testes (a exemplo de testes unitários, de integração, de release, de sistema, de componentes, de desempenho operacional);
i) Validação das funcionalidades junto ao solicitante;
j) Verificação e implantação;
k) Sustentação de Software; e
l) Manutenção Evolutiva ou Corretivas ou Adaptativas.
4.4.5 O processo de desenvolvimento de software deve estar amparado por diretrizes ou códigos de práticas de construção de softwares que incluem as definições técnicas e
orientações de requisitos mínimos de qualidade e padronização dos aspectos técnicos da codificação.
4.4.5.1 Caso não haja diretrizes ou códigos de práticas de construção de softwares previstos no processo de desenvolvimento de software, deve-se prever no instrumento
convocatório um anexo específico contendo os requisitos mínimos de qualidade e padronização dos aspectos técnicos da codificação.
4.4.6 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 processo de
desenvolvimento, manutenção e sustentação de software.
4.5 Da adoção de métodos ágeis
4.5.1Para adoção de métodos ágeis na execução dos serviços, independentemente da modalidade de remuneração adotada, o instrumento convocatório ou o processo de
desenvolvimento de software do órgão deve abranger as condições constantes nesta seção.
4.5.2 O processo de desenvolvimento de software deve prever uma fase inicial para o planejamento do projeto, que envolve a captura da visão do usuário, das necessidades e
regras negociais, da definição do escopo do projeto e das principais funcionalidades do produto a ser desenvolvido (backlog do produto).
4.5.3 Os projetos ágeis devem ser elaborados com a participação de servidor ou profissional contratado com conhecimentos em metodologias ágeis.
4.5.4 O resultado a ser entregue nessa fase inicial deve prever, pelo menos:
a) Documento de Visão;
b) Regras de Negócio;
c) Plano de Releases; e
d) Sprints e Backlog do Produto.
4.5.5 Recomenda-se implantar ferramenta de gestão de projetos ágeis que permita calcular os níveis de serviço de forma automática.
4.5.6 Deve-se evitar o início de projetos sem o correspondente planejamento do produto a ser desenvolvido.
4.5.7 Deve-se implementar mecanismo progressivo de glosas no caso de rejeição recorrente de sprints ou associado ao grau de rejeição do backlog da sprint, sem prejuízo da
aplicação de sanções pelo inadimplemento dos serviços, a depender das condições previstas no termo de referência.
4.5.8 Independentemente das sanções aplicadas, compete a equipe de fiscalização e a gestão contratual investigar e melhorar o processo com o objetivo de corrigir
descumprimentos reiterados dos parâmetros inicialmente definidos nas sprints.
4.5.9 Na definição do backlog da sprint, deve-se monitorar a relação quantitativa entre itens planejados e itens não planejados, com vistas a assegurar que o maior esforço esteja
sendo empreendido na entrega de valor.
4.5.10 Para cada projeto, devem ser definidos parâmetros para a execução das sprints, tais como:
a) configuração mínima do time que irá executar o conjunto de sprints, indicando perfis profissionais mínimos e nível de compartilhamento aceitável para determinados perfis,
conforme exemplo constante do Anexo IV;
b) duração máxima da sprint;
c) meta de velocidade da sprint, como a quantidade de histórias de usuário e pontos de função;
d) meta de escopo planejado x realizado, que indica o percentual realizado a cada sprint em comparação ao escopo planejado; e
e) meta de itens de backlog planejados x não planejados, que mapeia se o esforço, a cada sprint, está sendo gasto com novas funcionalidades planejadas ou com refatorações
de código, dívidas técnicas e correções de falhas.
5. MODALIDADES DE REMUNERAÇÃO
5.1 Definição
5.1.1 A contratação de serviços de desenvolvimento, manutenção e sustentação de software pode ser realizada por meio de diferentes abordagens, denominadas modalidades
de remuneração.
5.1.1.1 Admite-se a adoção de mais de uma modalidade para diferentes itens ou lotes, a depender da seleção da estratégia de contratação dos serviços pelo órgão.
5.1.1.2 Cada modalidade apresenta vantagens, desvantagens, bem como diferentes níveis de riscos que podem variar em decorrência da realidade de cada organização, natureza
das aplicações, capacidade de gerenciamento, entre outros fatores internos e externos às organizações.
5.1.2 As modalidades padronizadas por este modelo para contratação de serviços de desenvolvimento e manutenção são:
a) remuneração por pontos de função complementado por horas de serviço técnico;
b) remuneração com pagamento fixo por sprint executada;
c) remuneração por alocação de profissionais de TI, com pagamento vinculado a resultados.
5.1.3 As modalidades padronizadas por este modelo para contratação de serviços de sustentação são:
a) remuneração por alocação de profissionais de TI, com pagamento vinculado a resultados;
b) remuneração baseada em valor fixo mensal por sistema sustentado.
5.1.4 São premissas que devem ser observadas na construção do Termo de Referência, independentemente da modalidade adotada:
a) exigência de qualificação ou experiência mínima dos profissionais que irão prestar os serviços técnicos especializados;
b) fixação de patamar de preço mínimo para presunção relativa de inexequibilidade;
c)definição de metas de produtividade;
d) fixação dos critérios de aceitação dos serviços prestados;
e) definição dos níveis mínimos de serviço e de qualidade;
f) utilização, preferencialmente, de metodologia ágil para a prestação dos serviços;
g) pagamento vinculado ao alcance de resultados;
h) escolha do modelo adequado de precificação ou pagamento pelo serviço, e os devidos controles com vistas a mitigar riscos;
i) clareza quanto à definição do escopo dos serviços e seus entregáveis;
j) uso preferencial de métricas de software orientadas a entregas de produtos de software;
k) previsão de faixas de valores de ajustes nas metas dos indicadores de níveis de serviço;
l) adoção dos mecanismos adequados de penalidades objetivando punir o mau desempenho;
m) possibilidade de rescisão contratual antecipada motivada por falhas sistêmicas de desempenho;
n) definição do local de prestação dos serviços (presencial ou remota);
o) definição de infraestrutura e recursos computacionais necessários à prestação dos serviços.
5.2 Remuneração por pontos de função complementados por horas de serviço técnico
5.2.1 Conceito da modalidade
5.2.1.1 A modalidade de remuneração por Pontos de Função complementados por Horas de Serviço Técnico - HST consiste em remunerar o serviço contratado a partir da entrega
de resultados aferíveis por meio de métricas que possam refletir os aspectos funcionais e não funcionais dos produtos e serviços entregues.
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 atividades previamente definidas.
5.2.1.3 Deve-se distinguir o escopo das macroatividades abrangidas pela métrica Ponto de Função e das atividades a serem remuneradas por meio de Horas de Serviço Técnico,
relacionadas em catálogo específico, conforme diretrizes constantes no Roteiro de métricas de Software do SISP.
5.2.1.4 As macroatividades relacionadas ao processo de desenvolvimento a serem aferidas pela métrica de Ponto de Função devem estar documentadas na metodologia do órgão
(especificada contratualmente) ou formalizadas diretamente no termo de referência, a exemplo de:
a) Engenharia de Requisitos;
b) Design / Arquitetura;
c) Implementação;
d) Testes funcionais e unitários;
e) Homologação;
f) Implantação.
5.2.1.5 As atividades necessárias à prestação dos serviços de desenvolvimento, manutenção e sustentação de software que não sejam mensuráveis pela técnica de Análise de
Pontos de Função devem ser remuneradas por meio de Horas de Serviço Técnico (HST) e relacionadas em catálogo específico.
5.2.1.6 O catálogo de atividades remuneradas pela métrica HST deve conter, no mínimo, para cada atividade:
a) a descrição da atividade;
b) o volume de unidades de HST a ser remunerado;
c) os perfis profissionais aptos a executarem a atividade;
d) os produtos e os resultados esperados;
e) o prazo máximo de execução;
f) os critérios de aceitação.
5.2.1.7 Deve-se prever no termo de referência que cabe ao prestador do serviço empregar os esforços e recursos necessários para assegurar a entrega funcional dos produtos
demandados e aferíveis por meio da métrica Ponto de Função, descrita em roteiros de métricas, a exemplo do Roteiro de Métricas de Software do SISP.
5.2.1.8 Deve-se avaliar a viabilidade de desenvolver um roteiro de métricas de software complementar, contendo cláusulas que elucidem os pontos não abordados pelo Manual
de Práticas de Contagem de Ponto de Função (CPM) ou pelas normas internacionais de Análise de Ponto de Função.
5.2.1.9 Deve-se avaliar a viabilidade de adoção do Roteiro de Métricas de Software do SISP, utilizando-se preferencialmente o método Simple Function Point - SFP.
5.2.1.10 Na aplicação da técnica de Análise de Pontos de Função, deve-se evitar a utilização de fatores de ponderação ou de ajuste baseados em complexidade ou outra
característica temporal. Tal vedação não se confunde com a aplicação do "fator ágil", utilizado por este modelo.
5.2.1.11 A alteração do catálogo de atividades somente poderá ocorrer mediante aditamento contratual, desde que se observe as seguintes vedações:
a) Inclusão de atividades não relacionadas à natureza ou objeto da contratação.
b) Alteração da formação de preços original, que orientou a realização do certame.