Estabelece modelo para a contratação de serviços de desenvolvimento e sustentação de software, no âmbito dos órgãos e entidades integrantes do Sistema de Administração dos Recursos de Tecnologia da Informação - SISP do Poder Executivo Federal.

Art. 1º Estabelecer modelo para a Contratação de Serviços de Desenvolvimento e Sustentação de software, no âmbito dos órgãos e entidades integrantes do Sistema de Administração dos Recursos de Tecnologia da Informação - SISP do Poder Executivo Federal.

Art. 2º O modelo de contratação descrito no Anexo I desta Portaria é de utilização obrigatória para a contratação de serviços de Desenvolvimento e Sustentação de software.
Parágrafo único. Os órgãos e entidades poderão utilizar outros modelos de contratação desde que devidamente justificado pela área técnica proponente, comunicado via Ofício e aprovado previamente pela Secretaria de Governo Digital - SGD.

Art. 3º Os serviços de desenvolvimento e sustentação são considerados serviços de natureza comum dada a existência de padrões de mercado e diversos frameworks de desenvolvimento de software, que permitem a fixação de padrões de qualidade e de desempenho para o referido serviço.

Art. 4º A contratação de serviços de desenvolvimento de software deve se pautar, preferencialmente, pela adoção de metodologias de desenvolvimento ágil.

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.

Art. 6º A definição do valor de referência, do valor máximo da contratação e do patamar mínimo de presunção relativa de exequibilidade deverá utilizar como base a pesquisa salarial de preços e fator-k, previstos no Anexo II a esta Portaria.
§ 1º Os valores constantes no Anexo II, cumprem o disposto na Instrução Normativa Seges/ME nº 73, de 5 de agosto de 2020, para fins de pesquisa de preços das contratações que utilizarem os perfis e insumos do referido Anexo.
§ 2º Os órgãos e entidades poderão utilizar valores, perfis ou insumos diferentes daqueles previstos no Anexo II, seguindo as orientações previstas no Anexo I, devendo neste caso realizar pesquisa de preços nos termos da Instrução Normativa Seges/ME nº 73, de 2020, para aqueles perfis ou insumos diferentes daqueles constantes do Anexo II.

Art. 7º Deve-se utilizar as ferramentas e planilhas disponibilizadas nos anexos para subsidiar os cálculos das quantidades e valores de recursos.

Art. 8º Os casos omissos decorrentes da aplicação desta Portaria serão dirimidos pela Secretaria de Governo Digital da Secretaria Especial de Desburocratização, Gestão e Governo Digital do Ministério da Economia, que poderá expedir normas complementares, bem como disponibilizar informações adicionais em meio eletrônico.

Art. 9º O disposto nesta Portaria não se aplica às contratações cujo processo administrativo tenha sido autuado ou registrado até a data de entrada em vigor desta norma, e às renovações de contratos assinados antes da vigência desta Portaria, sendo facultada aos órgãos e entidades a aplicação do modelo.

Art. 10º Esta Portaria entra em vigor no dia XX de XXXXX de 2021.

1.1. A Secretaria de Governo Digital da Secretaria Especial de Desburocratização, Gestão e Governo Digital do Ministério da Economia, na condição de órgão central do SISP, estabelece diretrizes para contratação de serviços de desenvolvimento e sustentação de software, frente às recomendações dispostas no Acórdão nº 2.037/2019-TCU-Plenário e o Acórdão nº 1.508/2020-TCU-Plenário.

1.2. As diretrizes dispostas neste documento são de utilização obrigatória para os órgãos e entidades do SISP que estejam realizando o planejamento da contratação de serviços técnicos especializados de desenvolvimento e sustentação de software.

1.3. De forma excepcional, admite-se a não aplicação das diretrizes dispostas neste documento, desde que solicitado via ofício e obtida a autorização prévia da SGD. Devem-se observar as seguintes orientações:
a) Avaliar a viabilidade de utilização de modelos já adotados na Administração, pois aumenta o nível de padronização nas contratações no âmbito do SISP;
b) Não utilizar métrica de remuneração cuja medição não seja passível de verificação, nos termos da Súmula TCU 269;
c) Avaliar a economicidade dos preços estimados e contratados, realizando a análise crítica da composição de preços unitários e do custo total estimado da contratação; e
d) Abster-se de criar unidades de medida de forma unilateral, sem a avaliação técnica, econômica e de padronização.

1.4. Este documento prevê alguns balizadores definidos pela SGD a serem utilizados para orientar a aplicação das diretrizes apresentadas, bem como auxiliar na expansão ou adaptação dessas diretrizes a diferentes realidades.

1.4.1. Caso os órgãos e entidades do SISP façam a expansão ou adaptação do modelo proposto, é obrigatório que deem conhecimento à SGD, via ofício, com a justificativa e fundamentação da sua decisão, para posterior análise da SGD, incorporação das melhorias, quando aplicável, e disponibilização das atualizações a todos órgãos e entidades do SISP.

1.4.2. Ressalta-se que a justificativa para expansão ou adaptação do documento deve estar em conformidade com os estudos técnicos realizados pelo órgão ou entidade e de acordo com os normativos vigentes.

2.1.1. Os serviços de desenvolvimento e sustentação de software são considerados soluções de TIC e devem se orientar pelos dispositivos constantes da IN. 01/2019 SGD/ME, bem como pelas demais diretrizes constantes neste documento.

2.1.2. A prestação dos serviços de desenvolvimento e sustentação de softwares deve observar, no que couber, os padrões e normas aplicáveis à engenharia de software, a exemplo de: ABNT NBR ISO/IEC-IEEE 12.207/2021 (Processos de ciclo de vida de software), ISO/IEC-IEEE 14.764/2006 (Processo de manutenção de software) e ISO/IEC-IEEE 25.010/2017 (Qualidade de Software).

2.2.1. Para os efeitos deste documento, aplicam-se os seguintes termos e definições:

2.2.1.1. Aplicação: é um conjunto coeso de dados e procedimentos automatizados que suportam um objetivo de negócio, podendo consistir de um ou mais componentes, módulos ou subsistemas.

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;

2.2.1.3. Backlog do produto: representa tudo que é necessário para desenvolver e lançar um produto de valor agregado ao negócio. É uma lista de todos os requisitos (funcionais e não funcionais), funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para versões futuras;

2.2.1.4. Desenvolvimento ágil: abordagem de desenvolvimento de software baseada em desenvolvimento iterativo, inspeção e adaptação frequentes e entregas incrementais, nas quais os requisitos e as soluções evoluem por meio da colaboração em equipes multifuncionais e por meio de feedback contínuo dos stakeholders;

2.2.1.5. Fronteira da aplicação: A fronteira da aplicação pode ser entendida como a interface conceitual que delimita o software que será medido e seus usuários. A fronteira entre aplicações relacionadas está baseada nas áreas funcionais separadas como pode ser visto pelo usuário, não em considerações técnicas.

2.2.1.6. Níveis mínimos de serviço: são regras objetivas e fixas que estipulam valores e/ou características mínimas de atendimento a uma meta a ser cumprida pela contratada na prestação dos serviços.

2.2.1.7. Produto de Software: Conjunto de programas, procedimentos, incluindo os dados e documentação associada.

2.2.1.8. Projeto ágil: projeto de desenvolvimento de software que utiliza abordagem de desenvolvimento ágil.

2.2.1.9. Software pronto para uso: é aquele software disponibilizado (pago ou não) com um conjunto de funcionalidades pré-concebidas, também conhecido como Ready to Use Software Product (RUSP) ou comumente de "software de prateleira";

2.2.1.10. Time/Equipe ágil: pequeno grupo multifuncional de pessoas (entre 3 a 10 membros) que colaboram no desenvolvimento de um produto, dentro de uma metodologia ágil;

2.2.1.11. Time box: período de tempo, dentro do qual uma equipe ágil ou indivíduo conclui uma quantidade acordada de trabalho ou atinge um objetivo acordado;

2.2.1.12. Líder de time/equipe ágil: responsável por garantir que uma equipe ágil siga os princípios, práticas, valores e metodologia ágeis da organização. Nota: em vez de gerente, este "líder" é um facilitador;

2.2.1.13. Reunião diária: reunião diária curta, limitada a um período de tempo, usada para discutir o progresso, planos e quaisquer impedimentos com membros de um time ágil.

2.2.1.14. Sprint: conhecido como Iteração, consiste em um período (2 a 4 semanas) em que um conjunto acordado de histórias de usuário ou funcionalidades são projetadas, desenvolvidas, testadas, aceitas e se tornam aptas para implantação;

2.2.1.15. Incremento de produto: versão de um produto que pode ser liberada no final de um período de tempo (time box);

2.2.1.16. Proprietário/dono do produto: parte interessada que compartilha a visão do produto, incluindo recursos necessários e requisitos de aceitação;

2.2.1.17. Release: distribuição/liberação de um incremento de produto para um cliente ou usuários;

2.2.1.18. História de usuário: descrição em linguagem natural de um recurso de produto, exigida por um usuário ou outras partes interessadas;

2.2.1.19. Requisitos funcionais: conjunto de requisitos do usuário que descrevem o que o software deve fazer em termos de tarefas e serviços;

2.2.1.20. Requisitos não funcionais: conjunto de requisitos relacionados a como deve ser construído ou manutenido o software, como deve ser o desempenho em operação, aspectos relacionados às tecnologias, à qualidade do software e ao ambiente tecnológico que suporta ao software. Não estão incluídos os aspectos relacionados às funções ou tarefas previstas no software;

2.2.1.21. Softwares de atividades-meio: aqueles que são utilizados para apoio de atividades de gestão ou administração operacional, como, por exemplo, softwares de recursos humanos, ponto eletrônico, portaria, biblioteca, gestão de patrimônio, controle de frotas, gestão eletrônica de documentos, e que não têm por objetivo o atendimento às áreas finalísticas para a consecução de políticas públicas ou programas temáticos.

2.3.1. São abrangidos por esse modelo, serviços de:
a) Desenvolvimento, manutenção ou sustentação de software, portais, aplicativos móveis;
b) Testes, mensuração e controle de qualidade de software;
c) Projeto, elicitação de requisitos, codificação, prototipação, implementação, implantação, correção, adaptação e inspeção de software.

2.3.2. Não são abrangidos por esse modelo:
a) Serviços de suporte e operação de infraestrutura de TIC;
b) Soluções comercializadas sob o modelo de Software as a Service (SaaS);
c) Soluções de software embarcadas em equipamentos e dispositivos.

3.1. No intuito de simplificar o modelo para aplicação pelos órgãos ou entidades, definem-se as seguintes bases:
3.1.1. Entrega de valor: entrega contínua de valor à organização, preferencialmente, por meio de processos ágeis de desenvolvimento de software;
3.1.2. Objetividade: adoção de métricas objetivas de aferição de qualidade e produtividade;
3.1.3. Qualidade: garantia de qualidade dos produtos entregues e dos serviços executados;
3.1.4. Segurança da informação: adoção de processos de desenvolvimento seguro de software;
3.1.5. Padronização: aderência às modalidades de remuneração previstas neste documento.

4.1.1. Os sistemas a serem desenvolvidos devem constar do Plano Diretor de Tecnologia da Informação e Comunicação do órgão.

4.1.2. Deve-se avaliar a existência de software pronto para uso (RUSP) que atenda a necessidade do sistema a ser desenvolvido, avaliando-se técnica e economicamente a utilização do software pronto para uso, em detrimento do desenvolvimento de novo software.

4.1.2.1. A avaliação de software pronto para uso (RUSP) quanto ao atendimento das necessidades de negócio deve ser realizada pela área de negócio do órgão ou entidade.

4.1.3. É vedada a contratação de desenvolvimento de softwares de atividades de área meio, salvo nos casos em que o órgão ou entidade tenha obtido autorização do órgão central do SISP ou do Órgão Central do respectivo sistema estruturador.

4.1.3.1. Tal vedação não se aplica a otimização de atividades de área meio por meio de ambientes low-code ou no-code.

4.2.1. O órgão deve analisar, durante a fase de Planejamento da Contratação, a possibilidade de dividir o objeto em lotes, a exemplo de divisão por área de negócio, por agrupamento de áreas de negócio, por volume de demandas, por tecnologia ou outro critério que permita a definição de fronteiras.

4.2.2. Para os casos em que a divisão do objeto é possível, deve-se analisar a viabilidade de contratação simultânea de mais de um fornecedor de serviços de desenvolvimento de softwares, com vistas a mitigar riscos de indisponibilidade dos serviços ou dependência de fornecedor exclusivo.

4.2.2.1. Admite-se a contratação simultânea de mais de um fornecedor de serviços de desenvolvimento de software, desde que se assegure, durante a gestão do contrato, a não sobreposição da realização de atividades em um mesmo escopo de item de software simultaneamente, conforme Acórdão TCU 2362/2015-P.

4.2.2.2. A análise de que trata o caput deve considerar a capacidade de gestão e fiscalização de contratos do órgão.

4.3.1. O órgão deve avaliar, durante a fase de Planejamento da Contratação, se dispõe de servidores em quantidade e capacidade suficientes para a fiscalização de todos os controles, acompanhamento processual e demais atividades necessárias à aferição das exigências contratuais. Caso não haja servidores suficientes, o órgão deverá adotar medidas de mitigação de riscos, a exemplo de:

4.3.1.1. Adequar o escopo a ser contratado à capacidade de fiscalização e gerenciamento dos projetos;

4.3.1.2. Estabelecer critérios de priorização de projetos de desenvolvimento de software. Por se tratar de alocação de investimentos e impactar diretamente a execução de ações do Plano Diretor de Tecnologia da Informação e Comunicação, o Comitê de Governança Digital ou instância colegiada equivalente deve avaliar a aprovar tais critérios;

4.3.1.3. Promover ações para criação de capacidade de gerenciamento e fiscalização dos contratos de desenvolvimento e sustentação de software, seja por meio de aumento do quadro efetivo de servidores, seja por meio da contratação de serviços de apoio a fiscalização;

4.3.1.4. Automatizar os processos de gerenciamento da demanda, fiscalização, inspeção e controle de qualidade, com vistas a assegurar maior eficiência e segurança na fiscalização e monitoramento do contrato.

4.3.2. A área de TI deve definir previamente sua capacidade de produção e gestão contratual, considerando os recursos disponíveis. Devem ser avaliados, por exemplo, quantidades e perfis profissionais de fiscais de contrato, donos de produto e gerentes de projeto, bem como diretrizes e priorizações de negócio, ferramentas de gestão e automação necessárias ou implantadas, processos de gerenciamento de demanda e controle de qualidade implantados, entre outros elementos que impactem a capacidade de gerenciamento e fiscalização do volume de demandas de serviços de desenvolvimento e sustentação de software.

4.3.3. Deve-se utilizar o histórico de demandas relacionadas ao desenvolvimento e sustentação de softwares para aferir a capacidade de gerenciamento e fiscalização. Caso não haja histórico no órgão, a área de TI deve realizar uma análise comparativa com outros órgãos que possuam características semelhantes e dar início ao registro de demandas com o objetivo de construir sua própria base histórica.

4.3.4. O órgão deve assegurar a adequada capacitação de seus servidores para a fiscalização e gestão dos contratos e para o monitoramento da execução de atividades do seu processo de desenvolvimento de software.

4.3.5. Deve-se promover o gerenciamento do backlog do produto e das iterações de um projeto ágil. Para isso, o órgão deve prover profissionais, preferencialmente servidores, nos papéis de dono do produto e de gerente de projeto. Caso o órgão não disponha de servidores em quantidade suficiente para atuar nesses papéis, admitem-se algumas ações para assegurar a relação demanda/capacidade de equipe em patamares adequados, como:

4.3.5.1. Contratação em separado de serviços de apoio a gestão e fiscalização de contratos.

4.3.5.2. Redução da quantidade e/ou volume de projetos para adequação da capacidade, desde que autorizado pelo Comitê de Governança Digital ou instância colegiada equivalente.

4.3.5.3. Estabelecer processos de gerenciamento de demanda, preferencialmente, suportados por ferramentas de automação.

4.4.1. Deve-se adotar um Processo de Desenvolvimento de Software, referenciando-o no instrumento convocatório.

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 para o SISP, para a customização interna de um processo ágil.

4.4.3. As metodologias ágeis são um conjunto de práticas que visam a entrega rápida e de alta qualidade do produto ou serviço e que promovem um processo de gerenciamento de projetos que incentiva a inspeção e adaptação frequente, beneficiando a eficiência e efetividade dos gestores públicos no controle da prestação dos serviços de TI, haja vista que o foco passa a ser realmente nas atividades que entregam valor para as áreas de negócios.

4.4.4. 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.5. 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 do 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
e) Verificação e implantação.

4.4.6. 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 na codificação e padronização dos aspectos técnicos da codificação.

4.4.6.1. Caso não haja diretrizes ou códigos de práticas de construção de softwares previstos no processo de desenvolvimento de softwares, deve-se prever no instrumento convocatório anexo específico contendo os requisitos mínimos de qualidade na codificação e padronização dos aspectos técnicos da codificação.

5.1.1. A contratação de serviços de desenvolvimento e sustentação de software pode ser realizada por meio de diferentes abordagens, denominadas modalidades de remuneração.

5.1.1.1. Uma única contratação pode utilizar, simultaneamente, 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.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.

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;

5.2.1.1. A modalidade de contratação por unidade funcional e não funcional consiste em remunerar o serviço demandado a partir da entrega de resultados aferíveis por meio de métricas que possam refletir os aspectos funcionais e não funcionais do produto entregue.

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.

5.2.1.3. Deve-se distinguir o escopo das atividades abrangidas pela métrica de 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.

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.

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

5.2.1.6. A contratada deverá empregar os esforços e recursos necessários para assegurar a entrega funcional dos produtos demandados e aferíveis em pontos de função.

5.2.1.7. Deve-se adotar roteiro de métricas que complemente a técnica de contagem de Pontos de Função previstas na ISO/IEC 14143-1:2007 ou framework de mensuração de software equivalente.

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.

5.2.1.9. Na aplicação da 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 pelo modelo.

5.2.1.10. A alteração do catálogo de serviços somente poderá ocorrer mediante aditamento contratual, desde que se observe as seguintes vedações:
a) Inclusão de serviços não relacionados à natureza ou objeto da contratação;
b) Alteração da formação de preços original que orientou a realização do certame.

5.2.1.11. Na aplicação da modalidade de horas de serviço técnico, o valor da métrica é aplicado a um perfil de referência combinado a multiplicadores (fatores de ajuste) para cada perfil profissional, a exemplo de:

5.2.2.1. A execução dos serviços está condicionada a emissão de ordem de serviço, contendo no mínimo o escopo das funcionalidades e o prazo de atendimento.

5.2.2.2. O processo de desenvolvimento deve estar definido e segmentado em "evoluções de pequeno porte" e "projetos com escopos delimitados".

5.2.2.3. Devem ser descritas regras de composição e alocação de times ou equipes, conforme diretrizes previstas na seção 6 deste documento.

5.2.2.4. Caso o órgão não possua servidor capacitado na métrica de análise por pontos de função, deve-se avaliar a contratação de serviços especializados de métricas de software aferidos por meio de pontos de função inspecionados, ou previsão de contratação de profissional de métricas, assegurando-se que:
a) O serviço de contagem não seja realizado pela mesma empresa que executou os serviços de desenvolvimento de software;
b) Os profissionais de métricas possuam as qualificações necessárias para assegurar a verificação adequada da contagem.

5.2.3.1. O dimensionamento do volume a ser contratado, em termos de pontos de função, deve se pautar em bases históricas mantidas pelo órgão ou em técnicas de estimativa de contagem de pontos de função (contagem indicativa ou estimativa).
a) A memória de cálculo que justificará o volume a ser contratado deve integrar os estudos técnicos preliminares.

5.2.3.2. O dimensionamento do volume a ser contratado, em termos de horas de serviço técnico para aspectos não funcionais varia de acordo com o volume em pontos de função estimado.
a) A quantidade deve ser estimada utilizando-se como referência a base histórica do volume de serviços relacionados aos aspectos não funcionais demandados pela organização;
b) Na ausência de base histórica, deve-se documentar a memória de cálculo e premissas utilizadas para a estimativa do volume de horas de serviço técnico.

5.2.4.1. Em projetos ágeis, deve-se estabelecer critérios específicos para pagamento por pontos de função, de modo a adequar a dinâmica da metodologia ao mecanismo de remuneração, conforme descrito a seguir:
a) Para garantir a sustentabilidade econômica dos serviços prestados pela CONTRATADA, com relação às equipes alocadas nos projetos e evoluções ágeis durante as sprints, haverá pagamento provisório de valor médio de sprint (a ser definido no termo de referência).
b) O valor total do produto construído será aferido apenas na Release (convencionada preferencialmente em 3 sprints), onde será feito o balanço para pagamento ou devolução de valores. A quantidade de sprints de uma release deve ser definida no TR.
c) De forma a acelerar o processo de desenvolvimento, diminuindo a sobrecarga relacionada à duração de reuniões de preparação, rituais intermediários e volume de documentação a ser feita, não haverá pagamento de mudanças ocorridas dentro da release.
d) Os roteiros de métricas aplicados a projetos ágeis não devem considerar mecanismos de pagamento por exclusão de funções ou alterações de funções em uma mesma release. Para comportar a dinâmica ágil de forma a incorporar as mudanças entre as sprints deve ser aplicado um fator ágil de 25% às contagens de ponto de função aferidas na release.

5.2.4.2. O pagamento por horas de serviço técnico deve ser baseado em catálogo previamente estabelecido no Termo de Referência, conforme descrito a seguir:
a) Admite-se a adoção de fator de ajuste da hora de serviço técnico com vistas a adequar o valor da remuneração ao perfil executor da atividade, desde que previamente definido no catálogo.
b) O cálculo do fator de ajuste deve se basear na diferença percentual entre o salário do perfil de referência definido para fins de definição do valor da Hora de serviço técnico e o perfil executor da ação previsto no catálogo. Deve-se utilizar os valores constantes do Anexo II.

5.2.5.1. Deve-se manter registro estruturado das contagens de pontos de função, de forma a possibilitar o controle de baselines de contagens por sistema e de fronteiras de aplicações, com vistas a mitigar o risco de contagem duplicada, admitindo-se:
a) O uso de ferramentas especializadas para a manutenção e atualização da baseline;

5.2.5.2. Deve-se estabelecer, de forma clara, para fins de mensuração de pontos de função, as fronteiras das aplicações, considerando que:
a) A correta identificação da fronteira de uma aplicação é fundamental para o emprego consistente da métrica de análise de pontos de função, evitando-se contagens superdimensionadas ou subdimensionadas.
b) O posicionamento incorreto da fronteira pode alterar a perspectiva da medição de uma visão lógica (visão funcional) para uma visão física.
c) As principais consequências da não definição de fronteiras das aplicações são a contagem duplicada de transações e arquivos de dados, a contagem incorreta de funções de transferência de dados e dificuldade na contagem de arquivos.
d) Uma fronteira de aplicação não pode ser subdivida por contextos gerenciais de desenvolvimento, por exemplo, interno e externo ao órgão, ou baseada em diferenças de plataformas ou tecnologias.

5.2.5.3. Deve-se estabelecer processo de atualização da baseline durante a evolução do sistema.

5.3.1.1. A modalidade de contratação por sprint baseia-se no pagamento por sprint executada.

5.3.1.2. Considera-se uma sprint executada, quando o produto entregue ao final da sprint corresponde ao conjunto de itens acordados no planejamento da sprint.

5.3.1.3. A premissa para adoção dessa modalidade é possuir um Processo de Desenvolvimento de Software definido e baseado em métodos ágeis, com especificação de critérios para aceitação e rejeição de sprints.

5.3.1.4. A modalidade admite prever diferentes tipos de sprints, que podem variar em função da composição mínima do time (quantidade e perfis) e do tipo de tecnologia (linguagens e ambientes como web ou aplicativos móveis.

5.3.2.1. O processo de desenvolvimento de software deverá prever uma fase inicial para o planejamento do projeto, que envolve a captura da visão do usuário, das necessidades e regras negociais e a definição do escopo do projeto e das principais funcionalidades do produto a ser desenvolvido (backlog do produto).

5.3.2.2. O resultado a ser entregue nessa fase inicial deverá prever, pelo menos: Documento de Visão; Regras de Negócio; Plano de Releases e Sprints e Backlog do Produto.

5.3.2.3. Para cada projeto, devem ser definidos os 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 V;
b) duração mínima da sprint.
c) meta de velocidade da sprint, como a quantidade de pontos de função ou linhas de código entregues a cada sprint;
d) meta de escopo planejado x realizado, que indica o percentual realizado a cada sprint em comparação ao escopo planejado;
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.3.2.4. Cada tipo de sprint deve estar associada a uma capacidade de entrega funcional e não funcional.

5.3.3.1. A modalidade de contratação por sprints requer que o órgão seja capaz de estabelecer, para cada projeto, uma visão (roadmap) do produto com granularidade suficiente para se estimar a quantidade de sprints necessária para se alcançar o produto final esperado.

5.3.4.1. O pagamento deve ser um valor fixo por sprint executada, que pode variar por tipo de sprint, associado a níveis mínimos de serviço e vinculado a metas de produtividade.

5.3.4.2. Deve-se implementar mecanismo progressivo de glosas no caso da rejeição 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 associada ao grau de rejeição do backlog da sprint.

5.3.5.1. Recomenda-se implantar ferramenta de gestão de projetos ágeis que permita calcular os níveis de serviço de forma automática.

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

5.3.5.3. Deve-se definir critérios objetivos para aceitação ou rejeição de sprints, conforme exemplo constante do Anexo VI.

5.4.1.1. Nesta modalidade de contratação, a empresa especializada provê equipe para a prestação do serviço de desenvolvimento e sustentação de sistemas de informação.

5.4.1.2. As demandas para alocação dos postos se darão por meio Ordem de Serviço (OS), com quantitativo máximo estimado, sem compromisso de demanda mínima, com composição e qualificação mínimas exigidas.

5.4.1.3. A contratada será remunerada pelos postos de trabalho efetivamente ocupados com a possibilidade de aplicação de ajuste no pagamento a depender da aferição dos indicadores de níveis mínimos de serviços.

5.4.1.4. A prestação do serviço pelos postos de trabalho alocados pela contratada se dará em conformidade com a metodologia ágil adotada pela contratante.

5.4.1.5. Nessa modalidade, todos os serviços são prestados por meio da alocação de profissionais da contratada, seja de forma presencial ou remota, conforme condições previamente previstas em instrumento convocatório.

5.4.1.6. Os profissionais a serem alocados nos postos de trabalho devem ser disponibilizados exclusivamente para a contratante, de modo que não podem ser compartilhados para a execução de outros contratos, mantendo o foco e o compromisso efetivo nas necessidades da contratante.

5.4.1.7. A modalidade deve possibilitar que a contratante promova o intercâmbio de informações diretamente com os prestadores de serviço para a execução de tarefas, ensejando e possibilitando que a contratante exerça a fiscalização quanto à distribuição, controle e supervisão dos serviços solicitados, sem que haja a subordinação dos profissionais alocados a quaisquer servidores da contratante.

5.4.1.8. O objeto da contratação deverá ser dividido em itens por tipo de perfil ou posto necessário à execução dos serviços. Devendo-se prever a quantidade máxima de postos a serem alocados para cada item, a exemplo:

5.4.1.9. No que diz respeito à organização da forma de trabalho, em equipes mistas compostas por profissionais da contratada e servidores da contratante, as atribuições devem ser distintas, sem sobreposição.

5.4.2.1. A gestão dos serviços consiste na verificação da conformidade da prestação dos serviços, de forma a assegurar o perfeito cumprimento das condições previstas no Termo de Referência, que serão exercidos por representantes da contratante, especialmente designados para esse fim.

5.4.2.2. A equipe de gestão e fiscalização do contrato deverá avaliar constantemente a execução do objeto e utilizará os índices definidos como Níveis Mínimos de Serviço - NMS, devendo haver o redimensionamento no pagamento com base nos indicadores estabelecidos, sempre que a contratada:
a) Não produzir os resultados, deixar de executar ou não executar com a qualidade mínima exigida as atividades contratadas; ou
b) Deixar de utilizar materiais e recursos humanos exigidos para a execução do serviço ou utilizá-los com qualidade ou quantidade inferior à demandada.

5.4.2.3. Durante a execução do objeto, a fiscalização do contrato deverá:
a) Monitorar constantemente o nível de qualidade dos serviços para evitar a sua degeneração;
b) Intervir para requerer à contratada a correção das faltas, falhas e irregularidades constatadas.

5.4.2.4. A equipe de gestão e fiscalização do contrato deverá apresentar ao preposto da contratada a avaliação da execução do objeto ou, se for o caso, a avaliação de desempenho e qualidade da prestação dos serviços realizada.

5.4.2.5. Cada posto de trabalho possui funções referentes a um único e exclusivo perfil e deverá ser alocado por meio de emissão de ordem de serviço, de acordo com os requisitos para os perfis profissionais estabelecidos no Termo de Referência.

5.4.2.6. Cada ordem de serviço deverá indicar a quantidade e os perfis dos profissionais a serem disponibilizados conforme a previsão de postos de trabalhos, além do período específico de alocação do posto.

5.4.2.7. O quantitativo dos postos de trabalho demandados está limitado a quantidade máxima prevista para cada item que compõe o objeto, independentemente do número de ordens de serviço abertas.

5.4.2.8. Deve-se prever um período máximo para que a contratada aloque os postos de trabalho.
a) Exaurido esse prazo, em caso de eventual não-ocupação dos postos de trabalho correspondentes, deve-se prever a aplicação de sansões.
b) A contratada poderá iniciar a execução da OS em prazo inferior ao estabelecido, desde que acordado entre as partes.

5.4.2.9. A contratante deve prever mecanismos de avaliação da qualificação do funcionário em momentos distintos:
a) Na fase de sua apresentação: pela análise da documentação relativa ao adimplemento dos requisitos técnico-profissionais;
b) Na fase de execução dos serviços: por sua capacidade de execução bem-sucedida de tarefas concretas por meio da aferição de indicadores de níveis mínimos de serviços.

5.4.2.10. Critérios objetivos devem ser estabelecidos para eventual solicitação de substituição de funcionário alocado em posto de trabalho.
a) Também se enquadra neste item pedido de substituição, motivado por postura inadequada com as atribuições do posto de trabalho.

5.4.2.11. Cabe ainda, prever mecanismos para sansão da contratada caso seja feita, repetidamente, a alocação de profissionais que não atendam aos requisitos dos perfis profissionais exigidos.

5.4.3.1. O dimensionamento do volume dos serviços consiste na identificação do quantitativo de profissionais por tipo de perfil, considerando o histórico de quantitativo de pessoal dos contratos atual e anteriores e/ou o quantitativo de servidores que atuam nos serviços de desenvolvimento e sustentação de software, incluindo a estimativa de novos projetos previstos para o período de vigência do Contrato.

5.4.3.2. No dimensionamento do quantitativo necessário de profissionais para atender as demandas de serviços de desenvolvimento e sustentação de sistemas de informação é necessário:
a) Levantar o portfólio de projetos do órgão;
b) Organizar os projetos por características, peculiaridades, complexidade e criticidade que servirão de base para determinação da qualificação da equipe que irá atuar nesses projetos;
c) Considerar a complexidade e criticidade das plataformas tecnológicas usadas para desenvolvimento dos sistemas da organização;
d) Considerar a sustentação dos sistemas já desenvolvidos pelo órgão e que estão em produção;
e) Considerar a base histórica e a experiência prática do órgão no desenvolvimento de seus projetos e na sustentação de seus sistemas de informação;
f) Considerar a capacidade gerencial do órgão/unidade, pois o tamanho da equipe a ser contratada precisa estar de acordo com a capacidade do órgão em gerenciar os projetos concomitantemente.

5.4.4.1. A contratada será remunerada pelo serviço prestado no âmbito da Ordem de Serviço de acordo com os postos de trabalho efetivamente ocupados no período, observando os níveis mínimos de serviços definidos.
a) Quando não houver OS aberta, não deverá haver disponibilização de funcionários pela contratada e, consequentemente, não haverá prestação de serviço a ser remunerado.

5.4.4.2. Deve-se prever que qualquer tipo de ausência descaracteriza a efetiva ocupação do posto de trabalho, implicando no não pagamento correspondente à proporção das ausências. As faltas decorrentes de ausências legais não devem ser contabilizadas para efeito de apuração.

5.4.4.3. A contratante deve realizar mensalmente a aferição da taxa efetiva de ocupação de postos de trabalho previstos no contrato, os quais serão remunerados pelo serviço prestado no período, considerando os níveis mínimos de serviço.

5.4.4.4. No cálculo da taxa efetiva de ocupação dos postos de trabalho demandados para efeito de desconto em virtude de não-ocupação de posto de trabalho, não serão considerados os dias dentro do prazo dado à empresa para disponibilização de profissional após solicitação da contratante.

5.4.5.1. As atividades de controle e fiscalização da execução contratual devem ser realizadas de forma preventiva, rotineira e sistemática pela equipe de gestão e fiscalização do contrato.

5.4.5.2. Deve-se promover a fiscalização do cumprimento das obrigações trabalhistas, sociais e previdenciárias:
a) No início da execução dos serviços contratados
b) Durante a execução das Ordens de Serviços,
c) Quando da rescisão do contratado

5.4.5.3. No início da execução dos serviços contratados, deve-se exigir da contratada a apresentação de:
a) Relação dos funcionários, contendo nome completo, cargo ou função, horário do posto de trabalho, números da carteira de identidade (RG) e da inscrição no Cadastro de Pessoas Físicas (CPF), com indicação dos responsáveis técnicos pela execução dos serviços, quando for o caso;
b) Carteira de Trabalho e Previdência Social (CTPS) dos funcionários admitidos e dos responsáveis técnicos pela execução dos serviços, quando for o caso, devidamente assinada pela contratada; e
c) Exames médicos admissionais dos funcionários da CONTRATADA que prestarão os serviços.

5.4.5.4. Durante a execução das Ordens de Serviços, deve-se exigir da contratada a entrega até o dia 30 (trinta) do mês seguinte ao da prestação dos serviços ao setor responsável pela fiscalização do contrato dos seguintes documentos, quando não for possível a verificação da regularidade destes no Sistema de Cadastro de Fornecedores (SICAF):
a) Certidão Negativa de Débitos relativos a Créditos Tributários Federais e à Dívida Ativa da União (CND);
b) Certidões que comprovem a regularidade perante as Fazendas Estadual, Distrital e Municipal do domicílio ou sede do contratado;
c) Certidão de Regularidade do FGTS (CRF); e
d) Certidão Negativa de Débitos Trabalhistas (CNDT).

5.4.5.5. Deve-se prever que a contratante exija da contratada, a qualquer momento, a entrega de qualquer dos seguintes documentos:
a) Extrato da conta do INSS e do FGTS de qualquer funcionário, a critério da contratante;
b) Cópia da folha de pagamento analítica de qualquer mês da prestação dos serviços, em que conste como tomador contratante;
c) Cópia dos contracheques dos funcionários relativos a qualquer mês da prestação dos serviços ou, ainda, quando necessário, cópia de recibos de depósitos bancários;
d) Comprovantes de entrega de benefícios suplementares (vale-transporte, vale-alimentação, entre outros), a que estiver obrigada por força de lei ou de Convenção ou Acordo Coletivo de Trabalho, relativos a qualquer mês da prestação dos serviços e de qualquer funcionário; e
e) Comprovantes de realização de eventuais cursos de treinamento e reciclagem que forem exigidos por lei ou pelo contrato.

5.4.5.6. Quando da rescisão do contratado, a contratante deve exigir a entrega de cópia da documentação abaixo relacionada, após o último mês de prestação dos serviços, no prazo definido a ser definido no termo de referência:
a) Termos de rescisão dos contratos de trabalho dos funcionários prestadores de serviço, devidamente homologados, quando exigível pelo sindicato da categoria;
b) Guias de recolhimento da contribuição previdenciária e do FGTS, referentes às rescisões contratuais;
c) Extratos dos depósitos efetuados nas contas vinculadas individuais do FGTS de cada funcionário dispensado;
d) Exames médicos demissionais dos funcionários dispensados

5.4.5.7. O descumprimento total ou parcial das obrigações e responsabilidades assumidas pela contratada, incluindo o descumprimento das obrigações trabalhistas, não recolhimento das contribuições sociais, previdenciárias ou para com o FGTS ou a não manutenção das condições de habilitação, resultará na aplicação de sanções administrativas, previstas no instrumento convocatório e na legislação vigente.

5.4.5.8. Deve-se promover, no momento em que a prestação de serviços é iniciada por meio da emissão da Ordem de Serviço, a fiscalização inicial da alocação dos postos de trabalho que consiste na:
a) Apresentação por parte da contratada de planilha-resumo com informações sobre todos os empregados terceirizados que prestarão serviços, com ao menos os seguintes dados: nome completo, número de inscrição no CPF, função exercida, salário, adicionais, gratificações, benefícios recebidos, sua especificação e quantidade, horário de trabalho, férias, licenças, faltas, ocorrências e horas extras trabalhadas;
b) Verificação de todas as anotações contidas na CTPS dos empregados, a fim de que se possa constatar se as informações nelas inseridas coincidem com as informações fornecidas pela contratada e pelo empregado;
c) Verificação do número de terceirizados por função de acordo com previsto no contrato administrativo;
d) Verificação se o salário atende ao mínimo previsto no contrato administrativo e na Convenção Coletiva de Trabalho da Categoria (CCT), observados as regras de remuneração mínima dos profissionais;
e) Verificação de eventuais obrigações adicionais constantes na CCT para a contratada.

5.4.5.9. A cada pagamento de fatura, deve-se promover previamente a fiscalização mensal que consiste na:
a) Verificação da retenção da contribuição previdenciária sobre o valor da fatura e dos impostos incidentes sobre a prestação do serviço;
b) consulta a situação da empresa junto ao SICAF;
c) exigência da Certidão Negativa de Débito (CND) relativa a Créditos Tributários Federais e à Dívida Ativa da União, do Certificado de Regularidade do FGTS (CRF) e da Certidão Negativa de Débitos Trabalhistas (CNDT), caso esses documentos não estejam regularizados no Sicaf;
d) exigência, quando couber, da comprovação de que a empresa mantém reserva de cargos para pessoa com deficiência ou para reabilitado da Previdência Social, conforme disposto no art. 66-A da Lei nº 8.666, de 1993.

5.4.5.10. Deve-se promover a Fiscalização diária da execução dos serviços, que consiste na verificação se os empregados terceirizados que estão prestando os serviços nas funções previstas e se estão cumprindo jornada de trabalho.

5.4.5.11. Cabe ainda, à fiscalização do contrato, verificar se a contratada observa a legislação relativa à concessão de férias e licenças aos funcionários, respeita a estabilidade provisória de seus funcionários e observa a data-base da categoria prevista na CCT, concedendo os reajustes dos funcionários no dia e percentual previstos.

5.4.5.12. Deve-se solicitar, por amostragem, aos funcionários da contratada, seus extratos da conta do FGTS e que verifiquem se as contribuições previdenciárias e do FGTS estão sendo recolhidas em seus nomes. Ao final de um ano, todos os funcionários devem ter seus extratos avaliados.

5.4.5.13. Caso não seja apresentada a documentação comprobatória do cumprimento das obrigações trabalhistas, previdenciárias e para com o FGTS, deve-se prever que a contratante comunique o fato à contratada, aplicando a retenção do pagamento da fatura mensal, em valor proporcional ao inadimplemento até que a situação seja regularizada.
a) Tais pagamentos não configuram vínculo empregatício ou implicam a assunção de responsabilidade por quaisquer obrigações dele decorrentes entre a contratante e os funcionários da contratada.

5.4.5.14. Para esse modelo, deve-se considerar o contrato cumprido integralmente, após a comprovação - pela empresa contratada - do pagamento de todas as obrigações trabalhistas, sociais e previdenciárias e para com o FGTS, referentes à mão de obra alocada em sua execução, inclusive quanto às verbas rescisórias.

5.4.5.15. Ao término da prestação do serviço, deve-se promover a fiscalização do serviço que consiste em:
a) Verificar se a empresa contratada continua prestando o serviço regularmente, até o término efetivo da OS, atendendo as demandas restantes e efetuando a transferência de conhecimento para a equipe da contratante.
b) Garantir que a empresa contratada promova o repasse de todo o conhecimento adquirido ou produzido na execução dos serviços para os técnicos da contratante ou para a vencedora do novo certame.

5.4.5.16. Deve-se verificar o cumprimento das seguintes vedações:
a) Praticar atos de ingerência na administração da contratada, tais como:
i. Emitir ordens diretas do contratante aos terceirizados que configure grau de subordinação;
ii. Eventuais reclamações ou cobranças diretamente aos empregados terceirizados;
iii. Subordinação dos profissionais alocados a quaisquer servidores da contratante;
iv. Direcionar a contratação de pessoas para trabalhar na contratada;
v. Promover ou aceitar o desvio de funções dos funcionários da contratada;
vi. Considerar os funcionários da contratada como colaboradores eventuais do próprio órgão;
vii. Promover a negociação de folgas ou a compensação de jornada, uma vez que essa conduta é exclusiva da contratada.
b) Contabilizar como perfis profissionais, para efeito do dimensionamento, funções administrativas, comerciais, estratégicas ou negociais das empresas, a exemplo de: prepostos, secretárias, assistentes, representantes comerciais, gerentes de contas, pontos focais, auxiliares administrativos, diretores, executivos, entre outros de mesma natureza.
c) Prever que a própria contratada materialize a avaliação de desempenho e qualidade da prestação dos serviços realizada.
d) Utilização de funcionário que seja familiar de agente público ocupante de cargo em comissão ou função de confiança na contratante para a execução dos serviços.

5.5.1.1. Essa modalidade baseia-se em pagamento fixo mensal pela prestação de serviços de sustentação de sistemas.

5.5.1.2. Deve-se definir de forma clara as atividades de sustentação que estão incluídas no valor fixo mensal, conforme relação exemplificativa constante do Anexo III.

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, a exemplo da modalidade por unidade funcional e não funcional.

5.5.1.4. O portfólio inicial de sistemas a ser sustentado deve estar detalhado no Termo de Referência, de modo que a contratada possa 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 sistemas com necessidade de regime de sustentação especial, que implique em atendimento 7x24h, por meio de sobreaviso da contratada.

5.5.2.1. Deve-se definir os perfis profissionais mínimos para atuar na sustentação de sistemas.

5.5.2.2. Deve-se implantar ferramenta de gestão de demandas de sustentação.

5.5.2.3. Deve-se estabelecer níveis mínimos de serviço que possam ser evidenciados por meio da ferramenta de gestão de demandas de sustentação.

5.5.2.4. Deve-se definir critérios e processo para inclusão de novos sistemas no portfólio da contratada.

5.5.2.5. Deve-se definir período de carência para glosas/descontos a partir da absorção de um novo sistema no portfólio da contratada.

5.5.2.6. Admite-se o uso de outras modalidades para comportar demandas avulsas de sustentação, isto é, demandas de sustentação eventual para sistemas que, em razão de desuso, processo de desativação ou pouca relevância, não estiverem no catálogo de sistemas sustentados por pagamento fixo.

5.5.3.1. O dimensionamento da quantidade de sistemas sustentados deve levar em consideração o portfólio de sistemas corporativos em produção e a estimativa de novos sistemas a serem sustentados nos próximos 60 meses.

5.5.3.2. Deve ser apresentada uma estimativa para o volume anual de serviços técnicos adicionais, não contemplados dentro do pagamento fixo mensal, a serem demandados por meio de outra modalidade.

5.5.3.3. Caso haja necessidade de regime de sustentação especial que implique atendimento 7x24h, por meio de sobreaviso, deve ser apresentada estimativa de quantidade de sistemas e volume de acionamentos mensais.

5.5.4.1. O valor a ser pago deve ser definido por sistema sustentado, em razão de tamanho, volumetria de demandas, complexidade e/ou criticidade do sistema.

5.5.4.2. Para sistemas com necessidade de atendimento diferenciado, 7x24h, deve ser estabelecida remuneração adicional.

5.5.5.1. Implantar ferramenta de gestão de demandas que permita calcular os níveis de serviço de forma automática.

5.5.5.2. Não permitir atendimento de demanda sem a correspondente abertura de chamado na ferramenta de gestão de demandas.

5.5.5.3. Avaliar semestralmente o equilíbrio do portfólio de sistemas sustentados.

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 e sustentação de softwares para cada organização. Nesse sentido, a tabela a seguir estabelece diretrizes e condições para adoção de cada modalidade.

6.2. O quadro 1 apresenta para cada modalidade, uma avaliação qualitativa de riscos baseada na relação entre as características da modalidade e diversos aspectos do ambiente da contratante. Há três classificações possíveis:
a) Baixo risco: A modalidade mostra-se compatível à característica relacionada.
b) Risco Moderado: A adoção da modalidade para órgãos com essa característica pode apresentar riscos moderados relacionados à incompatibilidade da modalidade com a capacidade do órgão na gestão dos serviços. Deve-se mapear eventuais riscos e realizar o tratamento com vistas a mitigá-los e assegurar maior compatibilidade.
c) Elevado risco: A adoção da modalidade para órgãos com essas características apresenta elevado risco de comprometimento dos resultados pretendidos com a contratação, ou ainda a modalidade mostra-se incompatível com a característica frente a outras modalidades. Deve-se mapear os riscos de incompatibilidade e realizar o tratamento com vistas a eliminá-los e assegurar maior compatibilidade.

7.1. Independente da modalidade adotada, deve-se especificar os requisitos mínimos de experiência profissional e 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 e entidade.

7.2. Para as modalidades em que não há a fixação do posto de trabalho, deve-se identificar aqueles perfis que não podem ser atribuídos a um mesmo indivíduo simultaneamente, por exemplo, um mesmo individuo não atuar como desenvolvedor e testador simultaneamente.

8.1.1. A qualidade de um software é a capacidade desse sistema satisfazer as necessidades declaradas e implícitas de suas várias partes interessadas, e, portanto, entregar valor.

8.1.2. A verificação da qualidade constitui-se em procedimento indispensável para a fiscalização e a gestão de contratos de serviços da Administração Pública. Proporciona a devida verificação da medida em que o que está sendo entregue ao longo do contrato efetivamente corresponde ao resultado esperado (ou planejado).

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.

8.3.1. O gerenciamento dos níveis de serviço perfaz-se no monitoramento, que evidenciará a qualidade e a tendência dos serviços prestados, e no controle, que alinhará a execução dos serviços aos resultados pretendidos, por meio de um conjunto de procedimentos rotineiros e de regras preestabelecidos pelo órgão ou entidade contratante.

8.3.2. O tipo e grau de exigência dos níveis mínimos de serviço pode comprometer a qualidade dos serviços e o alcance dos resultados pretendidos com a contratação, se não houver um alinhamento às necessidades de negócios e aos riscos identificados.

8.3.3. Os indicadores de níveis de serviços devem abranger as diferentes dimensões de avaliação, com vistas a assegurar a efetiva prestação de serviço com a qualidade esperada.

8.3.4. 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.5. Recomenda-se que o órgão realize a aferição dos indicadores por meio de ferramenta automatizada que não esteja sob gestão da contratada, otimizando a rotina da fiscalização e gestão do contrato e fazendo com que as informações e erros não passem despercebidos.

8.3.6. É vedada a aferição baseada exclusivamente em relatório ou outro artefato produzido pela própria contratada.

8.3.7. A definição dos indicadores deve considerar as necessidades de negócio, riscos e criticidades dos serviços. A seguir apresenta-se uma lista exemplificativa de indicadores. Porém, no mínimo os indicadores de Aceitação da Sprint/Entrega (IAS), de Produtividade Ágil (IPA) e de qualidade de código (IQC) devem ser previstos nos serviços de desenvolvimento de software com metodologia ágeis, bem como, no mínimo, o indicador de ocorrência de incidentes (IOA), de cobertura de testes (ICT) e de qualidade de código (IQC) devem estar presentes em serviços de sustentação de software.

a) Indicador de Aceitação da Sprint/Entrega (IAS) com o objetivo de aferir se as demandas planejadas nas sprints foram executadas no prazo e com qualidade, conforme quadro exemplificativo a seguir.

b) Indicador de Produtividade Ágil (IPA) que deve estabelecer e monitorar o alcance das metas de produtividade, conforme quadro exemplificativo a seguir.

c) Indicador de tempo de execução da Sprint (ITE) com o objetivo de monitorar a tempestividade na execução e entrega dos serviços, conforme quadro exemplificativo a seguir:

d) Indicador de ocorrência de incidentes (IOA) com o objetivo de monitorar a ocorrência de incidentes nas aplicações e incentivar a atuação preventiva na execução dos serviços, conforme quadro exemplificativo a seguir.

e) Indicador de cobertura de testes (ICT) com o objetivo de incentivar ações proativas de mitigação de risco da ocorrência de erros, conforme quadro exemplificativo a seguir:

f) Indicador de desmobilização de equipe (IDE) capaz de monitorar e incentivar a manutenção dos membros das equipes durante a execução das sprints, conforme quadro exemplificativo.

g) Indicador de qualidade de código (IQC) com o objetivo de assegurar a qualidade técnica dos serviços prestados baseada em padrões pré-estabelecidos, conforme quadro exemplificativo a seguir:

h) Indicador de Registro Diário de Atividade (IRDA) com o objetivo de medir o percentual de falta de registro diário de atividades por parte dos funcionários alocados pela contratada, na modalidade de postos de trabalho:

8.4.1. Deve-se adotar, para todas as modalidades descritas neste documento, o modelo de planilha de custos e formação de preços definida pela Instrução Normativa n° 05/2017 Seges/ME, incluindo as orientações relacionadas ao preenchimento e análise.

8.5.1. Deve-se prever no instrumento convocatório requisitos mínimos de capacidade técnica para fins de habilitação técnica da proposta, com vistas a assegurar que a licitante comprove ter executado serviço similar nos termos do previsto na Lei Geral de Licitações.

8.5.2. O termo de referência pode estabelecer procedimentos e critérios para análise da planilha de formação de custos, observando-se a 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.5.3. 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.5.4. 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 § 3° do artigo 43 da Lei n° 8.666, de 1993, para que a empresa comprove a exequibilidade da proposta.

8.5.5. 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 a Cobertura Tributária.

8.5.6. Ressalta-se que, segundo Acórdão 325/2007-TCU-Plenário, não há vedação legal à atuação, por parte de empresas contratadas pela Administração Pública Federal, sem margem de lucro ou com margem de lucro mínima, pois tal fato depende da estratégia comercial da empresa e não conduz, necessariamente, à inexecução da proposta.

8.5.7. 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.5.8. 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, a seguir:
a) A produtividade máxima considerada para projetos ágeis de TI deve ser definida no Termo de Referência (em geral, tem-se 10 horas por Ponto de Função);
b) A composição mínima da equipe ágil exigida no termo de referência, em termos dos perfis profissionais;
c) A média dos salários de referência (Anexo I) dos perfis que integram a composição mínima da equipe ágil;
d) A duração máxima da sprint em horas definida no Termo de referência;
e) O custo mensal do time ágil;

8.5.9. Para a modalidade baseada em horas de serviço técnico, deve-se definir o patamar de exequibilidade considerando o salário constante no Anexo I para o perfil de referência.

8.5.10. Para a modalidade baseada em sprint, deve-se definir o patamar de exequibilidade considerando a composição do time previsto para cada tipo de sprint, a duração das sprints e o salário constante no Anexo I para os perfis previstos na execução das sprints.

8.5.11. Para a modalidade de postos de trabalho, deve-se definir o patamar de exequibilidade considerando o salário constante do Anexo I para cada perfil.

8.5.12. Para a modalidade de valor fixo mensal, deve-se definir o patamar de exequibilidade considerando o salário constante no Anexo I para o conjunto mínimo de profissionais estimados para execução dos serviços.

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.

9.2. Apresentação de serviços de desenvolvimento e sustentação de software demandam a internalização de processos, práticas e tecnologias. Um tempo de vigência superior a 12 meses permite a diluição desses encargos e custos, criando-se condições para redução do preço médio dos serviços.

9.3. Diante desta peculiaridade dos serviços de desenvolvimento e sustentação de software, recomenda-se adotar um prazo de vigência contratual mínimo de 24 meses para o contrato de desenvolvimento e sustentação de software.

9.4. Os órgãos e entidades devem incluir as justificativas no Termo de Referência para a adoção do prazo de vigência que podem levar em consideração a necessidade de adequação dos recursos humanos e tecnológicos, procedimentos e processos à execução dos serviços, assegurando a estabilidade mínima necessária para que a contratada execute adequadamente os serviços esperados.

10.1. Além das competências previstas na Instrução normativa n° 01/2019 SGD/ME, as equipes de planejamento da contratação e fiscalização do contrato devem seguir a divisão de responsabilidades prevista nessa seção.

10.2. Compete ao Integrante requisitante:
10.2.1. Estabelecer os requisitos funcionais e não funcionais associados às necessidades de negócio a serem atendidas com o apoio do integrante técnico.

10.3. Compete ao Integrante técnico:
10.3.1. Definir as características técnicas dos serviços assegurando o alinhamento ao processo de desenvolvimento de software do órgão e demais normas e padrões relacionados ao desenvolvimento de sustentação de software
10.3.2. Avaliar as características técnicas das propostas de preços na fase de seleção do fornecedor

10.4. Compete ao Integrante administrativo:
10.4.1. Elaborar o modelo de planilha de custos e formação de preços observando as disposições constantes da Instrução Normativa n° 05/2017 SEGES/ME no tocante as planilhas e demonstrativos de custos.
10.4.2. Avaliar a compatibilidade das planilhas de custo e formação na fase de seleção do fornecedor.

10.5. Compete ao Fiscal Requisitante:
10.5.1. Monitorar e avaliar o atendimento às necessidades de negócio, em especial o alcance dos resultados esperados com os produtos e serviços realizados.

10.6. Compete ao Fiscal Técnico:
10.6.1. Monitorar e avaliar a qualidade técnica e atendimento aos requisitos e padrões estabelecidos.

10.7. Compete ao Fiscal Administrativo:
10.7.1. Monitorar e avaliar o atendimento aos aspectos trabalhista e de regularidade administrativa.

11.1.1. Como boa prática, pode-se tratar ferramentas de gestão de demanda (ITSM) como solução de TIC distinta da solução de operação de infraestrutura, 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 nessa seção.

11.1.2. A contratação de ferramenta distinta da contratação do serviço operações e atendimento ao usuário de TIC 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 destes 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.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 previamente estabelecidos pelo órgão.

11.3.1. O processo de medição de software visa coletar, analisar e relatar dados e informações objetivos para apoiar um gerenciamento eficaz e demonstrar a qualidade dos produtos serviços e processos.

11.3.2. Independente da modalidade de contratação, deve-se aferir a produtividade por meio de métricas de tamanho de software, a exemplo de:
a) Pontos de Função implementados;
b) Linhas de código implementadas;

11.3.3. A métrica de tamanho 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 a forma de mensuração e eventuais recursos ou procedimentos padronizados para realização das medições, devendo-se assegurar:

11.3.3.1. Caso seja adotado 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

11.3.3.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. Deve-se prever mecanismos automatizados de verificação do cumprimento das diretrizes constantes desses guias ou roteiros.

12.1. A identificação, classificação e tratamento dos riscos associados a contratação de serviços de desenvolvimento e sustentação de software deve considerar ao menos os seguintes riscos, independentemente da modalidade adotada:

12.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. Definir e realizar testes ou avaliações técnicas para aferir se o recurso humano a atuar junto à contratante possui as capacidades técnicas esperadas. Deve-se definir critérios objetivos para verificação das capacidades.

12.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 associados aos produtos efetivamente entregues ou a fatores determinantes da qualidade do software produzidos 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, sempre que possível, vinculados a ferramentas automatizadas de aferição e extração de dados.

12.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 demandam 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 ou fiscalização do contrato. O estabelecimento de processos otimizados de controle e gerenciamento possuem capacidade de reduzir a execução de atividades desnecessárias.

12.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 sobre a troca de funcionários na execução das demandas.

12.1.5. Ociosidade da capacidade de trabalho alocada instalada 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: Criação de mecanismos que permita desalocar ou alocar profissionais nos modelos de alocação de capacidade, com vistas a comportar períodos de baixa ou elevada demanda.

12.1.6. Variações no volume de demanda
a) Descrição: O aumento ou redução significativos no volume de demandas poderá resultar e desequilíbrio econômico-financeiro 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 mão de obra.

13.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.

13.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.

13.3. É vedada a contratação de serviços de desenvolvimento e manutenção de software por meio de adesão a atas de registro de preços, salvo quando autorizado pela SGD.

14.1. O presente modelo busca proporcionar à comunidade SISP um instrumento abrangente, flexível e eficaz que assegure e aprimore a qualidade da contratação de serviços de desenvolvimento e sustentação de software pela Administração Pública, alinhada ao estabelecido nas normas e legislação relacionados a contratações de bens e serviços de TIC.

14.2. Este modelo abrange tanto os serviços de desenvolvimento quanto de sustentação de software. Nesse sentido, o presente modelo substitui as Diretrizes para a Contratação de Serviços de Desenvolvimento e Manutenção de Sistemas (Fábrica de Software) - publicado em 27 de maio de 2019 vinculada à Portaria MP/STI nº 20, de 14 de junho de 2016.

1. O Mapa de pesquisa salarial deve ser utilizado na definição do preço de referência da licitação, na definição do patamar mínimo de presunção relativa de exequibilidade e na definição de parâmetros a serem utilizados na aplicação das modalidades de remuneração previstas nesse modelo.

2. Os custos unitários de referência dos perfis profissionais constam da a seguir:

3. Os dados analisados para composição do Mapa de Pesquisa Salarial foram extraídos das últimas publicações de guias salariais de TIC em mídia especializada, contratações de órgãos do SISP dos últimos 12 meses e dados do Cadastro Geral de Empregados e Desempregados (CAGED) e da Relação Anual de Informações Sociais (RAIS) dos últimos 12 meses.

4. O Fator-k a ser utilizado deve ser de 2,28.

5. O custo total estimado de cada perfil é definido por meio do produto do valor salarial e o fator-k.

1. Manutenção corretiva: Consiste na eliminação de comportamentos do software que divirjam de suas especificações ou que provoquem a interrupção inesperada de seu funcionamento

2. Manutenção adaptativa de pequeno porte: São exigíveis, a título de sustentação e consequentemente sem provocar acréscimo ao pagamento fixo, até uma adaptação não-disruptiva (de pequeno porte) do ambiente computacional a cada ano. Considera-se adaptação de pequeno porte aquela cujo objetivo encontra-se em uma das hipóteses abaixo:
a) Atualização de versão de navegadores internet;
b) Atualização de versão de servidor de aplicação;
c) Atualização de versão de servidor de banco de dados;
d) Atualização de versão de linguagem de programação;
e) Atualização de versões de frameworks e/ou bibliotecas.

3. Manutenção cosmética localizada: consiste de alteração de interface de usuário que não implique alteração das regras de negócio e que seja realizada de forma localizada, isto é, pela intervenção em um único arquivo ou em um pequeno conjunto de arquivos. Tal manutenção pode ser exemplificada da forma que se segue:
a) Fontes de letra, cores, logotipos, mudanças de botões, alteração na posição de campos e texto na tela;
b) Mudanças de texto em mensagens do sistema, título de um relatório ou labels de uma tela de consulta;
c) Mudanças de texto estático em e-mail enviado pelo sistema;
d) Adição ou reestruturação de menus de navegação estáticos;
e) Adição ou reestruturação de Ajuda (help estático);
f) Criação, alteração ou exclusão de páginas estáticas.
g) Apurações especiais: Consiste na preparação de roteiros de execução em linguagem SQL, ou outra adequada ao caso, destinados às extrações de dados não cobertas pelos relatórios do sistema, à correção de inconsistências nos dados mantidos pelo sistema e não realizáveis por meio das interfaces de usuário disponíveis (ou cujo volume inviabilize a sua execução de forma manual), ou à inserção de dados não automatizada no sistema.

4. Diagnóstico: Apoio à identificação e isolamento de falhas e problemas em potencial na execução do software;

5. Suporte técnico: Prestação de esclarecimentos quanto à forma como foram implementados requisitos de sistema, procedimentos requeridos ao seu correto funcionamento ou aos dados mantidos por ele.

6. Análise de viabilidade: verificação de viabilidade de desenvolvimento para soluções propostas ou problemas e oportunidades de melhoria apresentados;

7. Homologação assistida: apoio nos procedimentos de homologação, incluindo configuração de parâmetros, saneamento de dúvidas, depuração de problemas e apoio à equipe de infraestrutura;

8. Atendimento:
a) Participação em reuniões com usuários ou áreas de negócio, além de discussões técnicas e/ou alinhamento de processos e técnicas com áreas correlatas tais como infraestrutura e projetos;
b) Execução de quaisquer procedimentos operacionais rotineiramente requeridos por sistema em função de suas regras de negócio ou forma de construção;
c) Outras atividades correlatas à sustentação.

1. Neste anexo são listadas outras atividades que permeiam todo o espectro dos serviços englobados no presente contrato, a serem utilizadas na eventualidade de necessidade compatível com o serviço disponível.

a. Suporte especializado: consiste na execução de procedimentos de alta especialização não mensuráveis eventualmente requeridos em projeto, evolução e/ou sustentação de sistemas, tais como prospecção tecnológica e construção de provas de conceito, apoio no mapeamento e estruturação de cenários de governança corporativa e também construção e definição de soluções arquiteturais, de middleware e interoperabilidade, além do diagnóstico de problemas em cenários de alta complexidade e apoio em soluções de gestão de dados, dentre outros.

b. Treinamento de usuários: consiste no apoio à confecção de material de treinamento para usuários de sistemas, bem como instrução presencial ou remota em treinamentos respectivos.

c. Assessoria de experiência e usabilidade (UX/UI): consiste na análise, prospecção e projeto de melhoria de experiência de usuário, com o objetivo de incrementar aspectos cognitivos e ambientais, otimização dos processos de interface gráfica e padronização da identidade visual.

d. Mapeamento de Problemas, Cenários e Soluções com Design Thinking: apoio na identificação de problemas, oportunidades e cenários possíveis por meio de imersão junto aos usuários, com a definição de estratégias e soluções potenciais através de prototipação e validação de hipóteses, com a utilização das técnicas de Design Thinking.

e. Testes não funcionais: consiste no planejamento, especificação, execução e registro dos resultados de testes de software não funcionais, tais como testes de carga, desempenho, segurança e stress, entre outros.

f. Modelagem de processo de negócio: consiste no apoio ao mapeamento e aperfeiçoamento de processo de negócio, através de discussões, estudos e diagramação de processos junto às áreas de negócio conforme padrões estabelecidos.

g. Documentação de legado: consiste na criação e/ou manutenção de documentação de sistemas legados conforme padrões estabelecidos na MDS vigente, desde que não haja manutenção associada, cuja documentação já é obrigatória.

h. Manutenção de tabelas estáticas (Code Table): Alterações referentes à DDL em tabelas de atributos do tipo CODE TABLE e respectivas funcionalidades de sistemas em produção (não se aplica ao desenvolvimento de novos sistemas nem envolve atividades de população de tabela).

i. Atualização de arquitetura de deploy de legado: construção, configuração e adaptação de scripts e pacotes de sistemas legados para o padrão de deployment de acordo com a arquitetura de entrega contínua definida na MDS. O desenvolvimento de scripts de build (Ex: Maven) não faz parte do escopo do serviço.

j. Implantação com assistência especial: disponibilização de profissional(s) em tempo integral para o acompanhamento de implantação de sistema em ambiente de produção juntamente com a equipe de infraestrutura e demais envolvidos, para apoio no diagnóstico de problemas de execução, integração e configuração, dentre outros.

k. Manutenção adaptativa de médio porte: alteração não-funcional de sistema com impacto localizado, necessária para adaptá-lo a determinados tipos de mudanças que não impliquem em reescrita de várias camadas, restringindo-se a porções arquiteturais específicas, tais como uso de novos componentes corporativos, mecanismos de autenticação com single sign-on ou de acesso a funcionalidades de autorização, motores de busca, mudança de hardware dedicado, mecanismos de auditoria automática, entre outros.

l. Iniciação de projetos: fase inicial da produção de um projeto de software, envolvendo a captação da visão do usuário para o produto pretendido e o reconhecimento do cenário atual do processo de negócio abordado, a captação das macro-necessidades do usuário e a determinação do escopo do projeto, realizando-se com a entrega dos artefatos previstos na MDS da CONTRATANTE.

1. Uma das principais causas de insucesso em projetos de desenvolvimento de sistemas corresponde à composição incorreta ou compartilhamento excessivo de profissionais entre times ágeis distintos. Esta seção descreve medidas para aumentar a taxa de sucesso desses projetos, por meio de regras para composição e alocação de profissionais aos times ágeis.

2. Os times ágeis deverão ser declarados no início do projeto e eventuais trocas de profissionais deverão ser comunicadas à CONTRATADA.

2.1. Projetos que sofrerem desligamento/mudança de integrantes de times ágeis e subsequente insucesso total ou parcial na aceitação de sprints estarão sujeitos ao Índice de Desmobilização de Equipe, descrito a seguir.

2.2. IDE - Índice de Desmobilização de Equipes
2.2.1. Finalidade: Estimular o esforço por parte do prestador de serviços no sentido de manter o desempenho constante nos projetos de desenvolvimento, seja por meio da manutenção do pessoal já empregado, ou pela substituição transparente (sem prejuízos) deste pessoal. Ao final, tal índice representa medida de manutenção do conhecimento acumulado no projeto.
2.2.2. Forma de aferição: Para cada projeto que teve uma sprint rejeitada ou aceita parcialmente, é apurado o somatório de desligamento de pessoas das equipes ágeis nas últimas 02 sprints anteriores. O índice total é o somatório de todos os fatores parciais levantados por projeto.
- Para sprints rejeitadas: 0,5% para cada desligamento
- Para sprints aceitas parcialmente: 0,2% para cada desligamento
2.2.3. Fórmula: (Aplicado apenas nas sprints com aceitação parcial e/ou rejeição)
 
2.2.4. Legenda:
- Qsr = Número de desligamentos de pessoal (por projeto) da respectiva equipe ágil nas últimas 2 sprints anteriores à sprint atual rejeitada
- Qsp = Número de desligamentos de pessoal (por projeto) da respectiva equipe ágil nas últimas 2 sprints anteriores à sprint atual aceita parcialmente

3. Composição mínima de times:
3.1. O Time mínimo aceito é de 8 (oito) integrantes, sendo:
- 1 scrum master
- 2 desenvolvedores perfil I (pleno)
- 1 desenvolvedor perfil II (sênior)
- 1 arquiteto
- 1 analista de requisitos
- 1 administrador/projetista de dados
- 1 testador

4. Alocação de times:
4.1. As funções de Scrum Master, Arquiteto e Analista de Requisitos poderão ser compartilhadas entre projetos, obedecendo aos seguintes limites:
- 1 scrum master poderá ser compartilhado por até 3 (três) projetos
- 1 arquiteto poderá ser compartilhado por até 3 (três) projetos
- 1 analista de requisitos poderá ser compartilhado por até 2 (dois) projetos
- 1 administrador/projetista de dados poderá ser compartilhado por até 5 (cinco) projetos
- 1 testador poderá ser compartilhado por até 5 (cinco) projetos
4.2. Nenhuma das funções de desenvolvedor poderá ser compartilhada entre projetos;

5. A violação das regras anteriormente estabelecidas ensejará eventos de glosa com redução na fatura, conforme critérios gerais de nível de serviço.

1. Qualquer produto enviado para homologação por parte da CONTRATADA deve atender a uma série de critérios para sua admissão à implantação em ambiente de homologação, sem os quais o produto é rejeitado de imediato. Tais critérios estão listados a seguir:
- Código-fonte submetido ao controle de versões da CONTRATADA;
- Existência de testes unitários e do Relatório de Testes;
- Existência de scripts de banco de dados com dicionário de dados embutido nos metadados (ausência apenas quando não houver mudança no modelo de dados);
- Existência de arquivo para geração de Build (ex: Arquivo de projeto Maven);
- Disponibilização de processos prontos para execução na ferramenta Jenkins ou similar, juntamente com a entrega e configuração de containers Docker configurados pela ferramenta OpenShift ou similares;
- Existência de Manual de Implantação, conforme modelo disponível no PDS;
- Existência de Manual do Usuário, conforme modelo disponível no PDS.

2. Aceitação da Demanda
2.1. Após realizar a inspeção do produto quanto à sua admissibilidade (item anterior), a CONTRATADA deverá:
- Executar testes funcionais automatizados que tenham sido solicitados e, consequentemente, verificar se estão corretamente implementados ou mesmo se existem, além de observar os resultados da execução;
- Executar testes unitários ou verificar relatórios de execução destes, que possam envolver porções críticas do produto;
- Realizar alguns testes funcionais, pelo menos nos principais fluxos do produto entregue.

2.2 Após a realização dos testes, deve-se proceder a uma das ações a seguir:
- Rejeição: caso sejam percebidos defeitos de natureza impeditiva em alguma história implementada ou não tenha coberto o escopo planejado de tal forma que a entrega não seja passível de aceitação;
- Aceitação parcial: caso a demanda possua alguns defeitos significativos de natureza não-impeditiva ou não tenha coberto o escopo planejado de tal forma que ainda seja passível de aceitação;
- Aceitação integral: caso a demanda esteja em nível de qualidade tal que não sejam percebidos defeitos significativos, bem como envolva cumprimento do escopo planejado.

2.3. Todos os aspectos julgados relevantes devem ser registrados pela CONTRATADA. Os defeitos percebidos nos casos de rejeição ou aceitação parcial da sprint devem fazer parte de um item de backlog da próxima sprint.