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 05152023032200041
41
Nº 56, quarta-feira, 22 de março de 2023
ISSN 1677-7042
Seção 1
5.5.1.3 As atividades ou serviços técnicos adicionais que não forem incluídos no valor fixo mensal do serviço de sustentação deverão ser remunerados por meio de outra
modalidade constante neste documento.
5.5.1.4 O portfólio inicial de produtos de software a ser sustentado deve estar detalhado no Termo de Referência, de modo que seja possível avaliar a volumetria de demandas
de sustentação, caso haja base histórica, ou o tamanho funcional para cada sistema.
5.5.1.5 Deve ser definido um período de atendimento padrão para o serviço (segunda à sexta, de 8 às 20h, por exemplo) e se o portfólio possui softwares com necessidade de
regime de sustentação especial, que implique em atendimento 7x24h, por meio de sobreaviso.
5.5.2 Mecanismos de Gestão
5.5.2.1 Para essa modalidade de remuneração, devem-se assegurar os seguintes mecanismos de gestão:
a) Definir perfis profissionais mínimos para atuar na sustentação dos produtos de software;
b) Implantar ferramenta de gestão de demandas;
c)Estabelecer níveis mínimos de serviço que possam ser evidenciados por meio da ferramenta de gestão de demandas;
d) Definir critérios e processo para inclusão de novos itens no portfólio de produtos de software;
e) Definir períodos de carência para glosas/descontos a partir da absorção de um novo software no portfólio de produtos de software.
5.5.2.2 Admite-se o uso de outras modalidades de remuneração, constantes neste documento, para comportar demandas avulsas de sustentação, isto é, demandas eventuais para
softwares que - em razão de desuso, processo de desativação ou pouca relevância - não estiverem no catálogo de softwares sustentados por pagamento fixo.
5.5.2.3 A execução dos serviços está condicionada à emissão de ordem de serviço, contendo no mínimo: o objetivo da OS, os produtos/resultados a serem entregues e o prazo
de atendimento.
5.5.3 Dimensionamento
5.5.3.1 O dimensionamento da quantidade de softwares sustentados deve levar em consideração o portfólio de softwares corporativos em produção, a previsão de desativação
de softwares e a estimativa de novos softwares a serem sustentados nos 60 meses após a contratação.
5.5.3.2 O dimensionamento do valor para cada escopo (software ou conjuntos de softwares) consiste na identificação do quantitativo de profissionais por tipo de perfil que deverá
ser utilizado como referência para estimativa do preço de referência de cada escopo.
5.5.3.3 Deve-se prever nos estudos técnicos preliminares, a memória de cálculo adotada para estimativa da quantidade de perfis que embasou o dimensionamento do valor do
preço fixo mensal.
5.5.3.4 Deve ser apresentada uma estimativa para o volume anual de serviços técnicos adicionais, não contemplados no valor fixo mensal, a serem demandados por meio de outra
modalidade.
5.5.3.5 Caso haja necessidade de adoção de um regime de sustentação especial que implique atendimento 7x24h, por meio de sobreaviso, deve-se contabilizar, para fins de
dimensionamento do valor de referência, os turnos e quantitativos de pessoal necessário na estimativa, observando-se os limites legais de jornada de trabalho e registrando as informações
utilizadas na estimativa para orientar a formulação das propostas de preços.
5.5.3.6 O dimensionamento para a estimativa inicial das equipes e a seleção dos perfis profissionais que balizarão a formação do preço de referência deve considerar:
a) o histórico de quantitativo de pessoal dos contratos atual e anteriores que atuam na sustentação dos softwares;
b) o quadro atual do órgão, seja de pessoal próprio ou de terceirizados, cuidando para justificar eventuais mudanças, de acordo com o seu entendimento do serviço
prestado;
c) projetos similares realizados por outros órgãos ou entidades da administração pública.
5.5.3.7 As estimativas realizadas devem ser alvo de análise crítica da equipe de planejamento da contratação e do registro das memórias de cálculo e das justificativas.
5.5.3.8 Considerando que não se trata de alocação de posto de trabalho, a gestão dos profissionais compete à contratada, podendo a seu critério também compartilhar os
recursos simultaneamente em contratos diversos ou projetos de um mesmo contrato, desde que não haja prejuízo ao cumprimento dos níveis mínimos de serviços.
5.5.4 Forma de pagamento
5.5.4.1 O valor a ser pago deve ser fixo e definido por sistema sustentado, conforme orientações para dimensionamento descritas na seção 5.5.3.
5.5.4.2 A estimativa da quantidade de profissionais de referência ou métrica de referência equivalente para definir o preço fixo por sistema, deve observar a volumetria de
demandas e a complexidade e/ou criticidade do sistema, devendo ser registrada a memória de cálculo adotada para a definição de cada valor.
5.5.4.3 Mecanismos de controle
5.5.4.4 Deve-se implantar ferramenta de gestão de demandas que permita calcular os níveis de serviço de forma automática.
5.5.4.5 Não se deve permitir o atendimento de demanda sem a correspondente abertura de chamado na ferramenta de gestão de demandas, de modo a garantir a correta
aferição dos níveis de serviço.
5.5.4.6 O equilíbrio do portfólio de softwares sustentados deve ser avaliado ao menos semestralmente.
5.5 A remuneração de serviços de sustentação de software por alocação de profissionais de TI deve seguir as mesmas diretrizes constantes do subitem 5.4 - Remuneração por
alocação de profissionais de TI vinculada a resultado.
6 DAS DIRETRIZES PARA A SELEÇÃO DA MODALIDADE DE CONTRATAÇÃO
6.1 Há diferentes condições, capacidades e características que possibilitam a seleção da modalidade mais adequada, em termos de mitigação de riscos e aderência à maturidade
de gestão de serviços de desenvolvimento, manutenção e sustentação de softwares para cada organização.
6.2 A justificativa de escolha da modalidade de contratação deve constar na justificativa da solução escolhida, no Estudo Técnico Preliminar (ETP), nos termos do art. 11 da
Instrução Normativa SGD/ME nº 94, de 23 de dezembro de 2022, ou posterior.
6.3 Ao escolher uma ou mais modalidades de remuneração entre as alternativas trazidas neste modelo, cada órgão deve observar suas características, sua capacidade de
fiscalização e grau de maturidade no desenvolvimento e manutenção de software. Deve implementar controles e mecanismos, além daqueles recomendados neste modelo, que evitem ou
mitiguem o risco de que a contratada adote comportamentos indesejados capazes de causar eventuais desequilíbrios na relação contratual entre as partes.
7 DOS CRITÉRIOS DE FORMAÇÃO DE TIMES OU EQUIPES
7.1 Independentemente da modalidade de remuneração adotada, deve-se especificar os requisitos mínimos de experiência profissional e a formação da equipe que executará os
serviços, incluindo a identificação de perfis compatíveis com a natureza e especificidade do ambiente tecnológico do órgão ou entidade.
7.2 Para as modalidades em que não há alocação de profissionais de TI, deve-se prever limites e condições de compartilhamento de profissionais em diferentes times ou projetos,
a exemplo do Anexo IV.
8 VERIFICAÇÃO DA QUALIDADE DOS SERVIÇOS
8.1 Aspectos gerais sobre qualidade de software
8.1.1 A verificação da qualidade constitui-se em procedimento indispensável para a fiscalização e a gestão de contratos de serviços de desenvolvimento, manutenção e
sustentação de software. Essa atividade proporciona a verificação do produto entregue em relação aos resultados esperados.
8.2 Dos critérios de aceitação dos serviços
8.2.1 Deve-se estabelecer critérios objetivos para a aceitação dos produtos e serviços prestados, a exemplo dos seguintes critérios mínimos:
a) Cobertura integral do escopo de funcionalidades planejadas;
b) Cobertura mínima de testes automatizados realizadas;
c) Qualidade mínima de código aferida por meio de ferramenta, conforme critérios previamente estabelecidos;
d) Aderência aos padrões arquiteturais e tecnológicos pré-estabelecidos;
e) Observância aos padrões de segurança da informação e aos processos de desenvolvimento seguro de software pré-estabelecidos.
8.3 Do gerenciamento de níveis mínimos de serviço
8.3.1 O gerenciamento dos níveis mínimos de serviço consiste no monitoramento e controle da qualidade na execução dos serviços em função dos resultados pretendidos, por
meio de um conjunto de procedimentos preestabelecidos pelo órgão ou entidade contratante.
8.3.2 Com vistas a assegurar a efetiva prestação de serviço com a qualidade esperada, os indicadores de níveis de serviço devem adotar preferencialmente métricas associadas
a resultado e abranger, no mínimo, as dimensões de produtividade, qualidade e desempenho do produto e prazo de entrega.
8.3.3 Os indicadores são instrumentos práticos de aferição do cumprimento do alcance dos níveis mínimos de serviço, evidenciando de maneira objetiva e mensurável o
desempenho e as tendências de um serviço demandado. Devem ser objetivamente mensuráveis e compreensíveis, de preferência facilmente coletáveis, relevantes e adequados à natureza
e características do serviço.
8.3.4 Recomenda-se que o órgão realize a aferição dos indicadores de níveis de serviço por meio de ferramenta automatizada, que não esteja sob gestão da contratada, de modo
a otimizar a rotina de fiscalização e a gestão do contrato.
8.3.5 É vedada a aferição de indicadores de níveis de serviço baseada exclusivamente em dados fornecidos pela própria contratada.
8.3.6 A definição dos indicadores de níveis de serviço deve considerar as necessidades de negócio, os riscos associados ao processo e a criticidade dos serviços. A seguir,
apresenta-se uma lista exemplificativa desses indicadores:
a) Indicador de Aceitação da Sprint/Entrega (IAS), com o objetivo de aferir se as demandas planejadas nas sprints foram executadas no timebox e com qualidade, conforme
quadro exemplificativo a seguir:
. Finalidade
Garantir a qualidade na entrega das sprints.
. Meta a cumprir
IAS igual ou superior a 75%.
. Forma de acompanhamento
São apuradas a quantidade total de sprints entregues no período, a quantidade de sprints que foram aceitas integralmente e a quantidade de sprints
aceitas parcialmente.
. Periodicidade
Mensal.
. Mecanismo de cálculo (%)
É feita uma relação de proporção entre a quantidade de sprints aceitas integralmente e parcialmente junto ao total chegando a um valor percentual:
IAS = (Qi + Qp/3) x 100
______________
Qt
.
Onde:
IAS = Indicador de Aceitação da Sprint/Entrega;
Qi = Quantidade de sprints aceitas integralmente;
Qp = Quantidade de sprints aceitas parcialmente;
Qt = Quantidade total de sprints enviadas para aceite.
. Início da vigência
A partir da emissão da ordem de serviço.
. Sanções/ faixas de ajuste
IAS >= 75%: sem descontos sobre o valor da OS.
IAS >= 65% e < 75%: 10% de desconto sobre o valor da OS.
IAS >= 55% e < 65%: 20% de desconto sobre o valor da OS.
IAS < 55%: 30% de desconto sobre o valor da OS.
. Observações
O peso das sprints aceitas integralmente deve ser maior que o das aceitas parcialmente. Nessa fórmula específica, o peso das sprints aceitas
integralmente é três vezes maior que o das aceitas parcialmente.
Para efeitos desse indicador, não são contabilizadas sprints rejeitadas, pois não atendem aos critérios mínimos de aceitação previamente estabelecidos.
b) Indicador de Produtividade Ágil (IPA), que deve estabelecer e monitorar o alcance das metas de produtividade, conforme quadro exemplificativo a seguir:
. Finalidade
Garantir a produtividade das equipes ágeis, em termos do alcance de metas aferidas por meio de métricas de software, observando os critérios de
qualidade e de aceitação definidos, bem como mensuração em termo de produto ou resultado entregue.
. Meta a cumprir
IPA igual ou superior a 75%.