PORTARIA SGD/MGI Nº 750, DE 20 DE MARÇO DE 2023

Estabelece modelo para a contratação de serviços de desenvolvimento, manutenção 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.

O SECRETÁRIO DE GOVERNO DIGITAL DO MINISTÉRIO DA GESTÃO E DA INOVAÇÃO EM SERVIÇOS PÚBLICOS, no uso das atribuições que lhe conferem o art. 29, inciso XII, do Anexo I ao Decreto nº 11.345, de 1º de janeiro de 2023, e tendo em vista o disposto na Lei nº 14.133, de 1º de abril de 2021, no Decreto nº 7.579, de 11 de outubro de 2011, §2º do art. 8º, e §4º do art. 20 da Instrução Normativa SGD/ME nº 94, de 23 de dezembro de 2022, resolve:

Art. 1º Estabelecer modelo para a Contratação de Serviços de Desenvolvimento, Manutenção 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.

CAPÍTULO I

DAS DISPOSIÇÕES PRELIMINARES

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, Manutenção e Sustentação de Software.

Parágrafo único. Os órgãos e as entidades poderão utilizar outros modelos de contratação desde que devidamente justificados pela área técnica proponente, comunicado via Ofício e aprovado previamente pela Secretaria de Governo Digital - SGD.

CAPÍTULO II

DOS SERVIÇOS DE DESENVOLVIMENTO, MANUTENÇÃO E SUSTENTAÇÃO DE SOFTWARE

Art. 3º Os serviços de desenvolvimento, manutenção 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, manutenção e sustentação 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, manutenção e sustentação de software admite, em uma mesma contratação ou em diferentes contratações, a adoção de uma ou mais modalidades padronizadas de remuneração, entre as descritas a seguir:

I - para serviços de desenvolvimento e/ou manutenção, o Pagamento aferido por Pontos de Função e complementado por Horas de Serviço Técnico, vinculado ao alcance de resultados e ao atendimento de níveis mínimos de serviço;

II - para serviços de desenvolvimento e/ou manutenção, o Pagamento de valor fixo por sprint executada, vinculado a níveis mínimos de serviço;

III - para serviços de desenvolvimento e/ou manutenção e/ou sustentação, o Pagamento por alocação de profissionais de TI, vinculado ao alcance de resultados e ao atendimento de níveis mínimos de serviço;

IV - para serviços de sustentação, o Pagamento de valor fixo mensal por portfólio de softwares, vinculado ao atendimento de níveis mínimos de serviço.

CAPÍTULO III

DA DEFINIÇÃO DOS VALORES DA CONTRATAÇÃO

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 inexequibilidade deverá utilizar como base a pesquisa salarial de preços, bem como os limites para utilização do fator-k, previstos no Anexo II desta Portaria.

§ 1º Os valores constantes no Anexo II cumprem o disposto na Instrução Normativa Seges/ME nº 65, de 7 de julho de 2021, para fins de pesquisa de preços das contratações que utilizarem os perfis profissionais e insumos do referido Anexo.

§ 2º Os órgãos e entidades poderão utilizar valores, perfis profissionais 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º 65, de 7 de julho de 2021, para aqueles perfis ou insumos diferentes daqueles constantes no Anexo II.

§ 3º O Anexo II será atualizado periodicamente pela Secretaria de Governo Digital.

Art. 7º A Secretaria de Governo Digital disponibilizará planilhas e material complementar para subsidiar os cálculos das quantidades e valores de recursos.

CAPÍTULO IV

DISPOSIÇÕES FINAIS E TRANSITÓRIAS

Orientações Gerais

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

Disposições Transitórias

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, nem às renovações de contratos assinados antes da vigência desta Portaria, sendo facultada aos órgãos e entidades a aplicação do modelo.

Revogação

Art. 10. Revoga-se a Portaria SGD/ME nº 5.651, de 28 de junho de 2022.

Parágrafo único. Permanecem regidos pela Portaria SGD/ME nº 5.651, de 28 de junho de 2022, todos os procedimentos administrativos autuados ou registrados sob a égide da Lei nº 8.666, de 21 de junho de 1993, e da Lei nº 10.520, de 17 de junho de 2001.

Vigência

Art. 11. Esta Portaria entra em vigor no dia 3 de abril de 2023.

ANEXO I

MODELO DE CONTRATAÇÃO DE SERVIÇOS DE DESENVOLVIMENTO E SUSTENTAÇÃO DE SOFTWARE

1. INTRODUÇÃO

1.1 A Secretaria de Governo Digital - SGD do Ministério da Gestão e da Inovação em Serviços Públicos, na condição de órgão central do SISP, estabelece diretrizes para contratação de serviços de desenvolvimento, manutenção e/ou sustentação de software, frente às recomendações dispostas no Acórdão nº 2.037/2019-TCU-Plenário e no 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, manutenção e/ou sustentação de software.

1.3 De forma excepcional, admite-se a não aplicação das diretrizes dispostas neste documento, desde que solicitado por meio de 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 prévia 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 as entidades do SISP façam a expansão ou adaptação do modelo proposto, é obrigatório que deem conhecimento à SGD, por meio de 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. OS SERVIÇOS DE DESENVOLVIMENTO, MANUTENÇÃO E SUSTENTAÇÃO DE SOFTWARE

2.1 Dos serviços

2.1.1 Os serviços de desenvolvimento e manutenção de software correspondem ao conjunto de atividades executadas com a finalidade de atender às necessidades do órgão ou entidade por meio da implementação de um novo software, de uma nova funcionalidade ou manutenção de funcionalidades já existentes, em conformidade com o processo de desenvolvimento de software por ele estabelecido e aplicados os procedimentos necessários à garantia da qualidade do software.

2.1.2 O serviço de sustentação de software corresponde ao conjunto de atividades necessárias para manter a disponibilidade, estabilidade e desempenho do software em produção, dentro dos níveis de serviço estabelecidos pelo órgão ou entidade. Admite-se, no escopo desse serviço, a previsão de manutenções de pequeno porte, cujos limites, baseados em métricas de software, devem estar previamente definidos.

2.1.3 Os serviços de desenvolvimento, manutenção e sustentação de software são considerados soluções de TIC e devem se orientar pelos dispositivos constantes da Instrução Normativa SGD/ME nº 94, de 23 de dezembro de 2022, bem como pelas demais diretrizes constantes neste documento.

2.1.4 A prestação dos serviços de desenvolvimento, manutenção e sustentação de software 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 Termos e Definições

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

a) Análise de Ponto de Função: método de medida de tamanho funcional de software definido pela ISO/IEC 14143-1:2007, ISO/IEC 20926:2009, COSMIC (ISO/IEC 19761:2011), ou por métricas derivadas desses padrões internacionais como as contagens da Netherlands Software Metrics Association (NESMA) ou Simple Function Point (SFP) do International Function Point Users Group (IFPUG).

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

c) Backlog do produto: representa tudo que é necessário para desenvolver e lançar um produto de valor agregado ao negócio. É uma lista priorizada 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.

d) Desenvolvimento ágil: abordagem de desenvolvimento de software baseada em metodologias ágeis, 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. Há diferentes métodos capazes de prover um desenvolvimento ágil de software, a exemplo de: Scrum, Extreme Programming (XP), Kanban, Lean, Crystal Clear, Feature Driven Development, entre outros.

e) Dívida Técnica: consiste em decisões de codificação que atendem o projeto a curto prazo, mas que podem comprometer ou encarecer mudanças futuras, ou até mesmo inviabilizá-las.

f) 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 conforme visão do usuário, não em considerações técnicas.

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

h) Horas de Serviço Técnico (HST): métrica baseada na quantidade de horas necessárias para se alcançar um resultado ou entregar um produto, por meio de atividades executadas por um ou mais perfis profissionais, e aferidas por meio de indicadores de níveis mínimos de serviço e critérios de aceitação previamente estabelecidos.

i) Implantação: tornar o sistema ou o conjunto de funcionalidades disponível para os usuários, transferir dados dos softwares existentes e estabelecer comunicações com outros softwares no ambiente.

j) Implementação: processo que transforma requisitos, arquitetura e design, incluindo interfaces, em ações que criam um elemento ou componente de software de acordo com as práticas de codificação previamente estabelecidas, usando técnicas, especialidades ou disciplinas de desenvolvimento de software. Esse processo resulta em um elemento software que segue uma arquitetura e design estabelecidos.

k) Incremento de produto: versão de um produto que pode ser liberada no final de um período de tempo (timebox).

l) 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.

m) 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.

n) Produto de Software ou Software: conjunto de programas, procedimentos, rotinas ou scripts, componentes, Application Programming Interface - API, webservices, incluindo os dados e documentação associada.

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

p) Proprietário/dono do produto (product owner): servidor e/ou representante da Contratante que compartilha a visão do produto, incluindo funcionalidades necessárias e critérios de aceitação.

q) Qualidade de software: é a capacidade do software satisfazer as necessidades declaradas e implícitas das partes interessadas.

r) Release: distribuição/liberação de um incremento de produto para um cliente ou usuários. A quantidade de sprints por release deve ser definida previamente à execução dos serviços.

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

t) 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 o software. Os requisitos não funcionais podem ser descritos como atributos de qualidade, de desempenho, de segurança ou como uma restrição geral em um sistema. Não estão incluídos os aspectos relacionados às funções ou tarefas previstas no software.

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

v) 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".

w) Roadmap ou Visão do produto: é um plano de ação de como um produto evoluirá ao longo do tempo. Esse plano apresenta uma linha do tempo com marcos de alto nível para um ciclo de vida do produto, particularmente o cronograma para implantação de funcionalidades do produto, com vistas a orientar o progresso em direção a uma meta definida.

x) 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.

y) Sprint: consiste em um ciclo de iteração por um período de até 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.

z) 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.

aa) Timebox: período de tempo fixo, previamente estabelecido, durante o qual um indivíduo ou equipe trabalha constantemente para a conclusão de um objetivo acordado.

2.3 Escopo do modelo

2.3.1 São abrangidas por este modelo, as atividades de:

a) Desenvolvimento, manutenção ou sustentação de software, inclusive portais e aplicativos móveis, data warehouse, big data, Business Intelligence e Administração e Governança de Dados;

b) Testes, mensuração, segurança e controle de qualidade de software;

c) Projeto, elicitação e análise de requisitos, design, arquitetura, codificação, prototipação, implementação, implantação, correção, adaptação, evolução, sustentação e inspeção de software;

d) Projeto, modelagem e implantação de ambiente de banco de dados, automação de processos baseados em software e criação e atualização de design system e componentes de interface e experiência do usuário (UX).

2.3.2 Não são abrangidos por este 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;

d) Contratação de licenciamento ou subscrição de software pronto para uso (Software de prateleira).

3. BALIZADORES DO MODELO

3.1 O modelo está orientado a partir das seguintes bases:

a) Entrega de valor: atendimento às expectativas e necessidades dos usuários dos serviços públicos prestados pela Organização, os quais são apoiados por softwares que devem estar em funcionamento com qualidade, segurança e usabilidade adequadas as suas finalidades;

b) Objetividade: adoção de métricas objetivas de aferição de qualidade e produtividade;

c) Qualidade: capacidade do produto de software em satisfazer necessidades declaradas e implícitas dos usuários para que estes alcancem seus objetivos específicos com eficácia, eficiência, segurança e satisfação. A avaliação da qualidade deve ser um requisito necessário para se efetuar o pagamento pela prestação do serviço;

d) Segurança da informação: adoção de processos de desenvolvimento seguro de software;

e) Padronização: aderência às modalidades de remuneração previstas neste documento;

f) Foco no alcance a resultados: assegurar que o pagamento seja vinculado à entrega de produto de software com qualidade, por meio da aferição de métricas de software, observando metas de produtividade, critérios de aceitação dos produtos e níveis mínimos de serviço previamente estabelecidos.

4. DIRETRIZES ESTRATÉGICAS

4.1 Da seleção do portfólio de produtos de software

4.1.1 Os softwares a serem desenvolvidos (projetos de novos softwares) devem estar alinhados ao 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 Preliminarmente à apresentação de demanda por desenvolvimento de novo software, a área de negócio deve prospectar a existência de software pronto para uso (RUSP) que atenda a sua necessidade.

4.1.2.2 A área de TI do órgão, em conjunto com a área de negócio demandante, deve avaliar técnica e economicamente a utilização do software pronto para uso, em detrimento do desenvolvimento de novo software.

4.1.3 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.4 É vedada a utilização dos serviços contratados para o 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.2 Da divisão do objeto

4.2.1 O órgão deve analisar, durante a fase de Planejamento da Contratação, a possibilidade de divisão do objeto em lotes. Para isso, podem ser utilizados critérios como: área de negócio, volume de demandas, tecnologia ou outro critério que permita a definição clara dos limites de cada lote.

4.2.2 Para os casos em que a divisão do objeto é possível, deve-se analisar a viabilidade de contratação de mais de um fornecedor de serviços de desenvolvimento, manutenção e sustentação 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, manutenção e sustentação de software em lotes distintos, com vistas a possibilitar a adjudicação para cada lote, em consonância com o definido no subitem 4.2.1. Para isso, deve-se assegurar durante o planejamento da contratação e 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 2.362/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 Da gestão da capacidade

4.3.1 O órgão deve avaliar, durante a fase de Planejamento da Contratação, se dispõe de servidores com a qualificação necessária e em quantidade suficiente 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 deve 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 e 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, manutenção 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 à fiscalização;

4.3.1.4 Automatizar os processos de gerenciamento das demandas de serviço, incluindo coleta e aferição de indicadores de nível de serviço, inspeção e controle de qualidade das entregas, 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, manutenção e sustentação de software.

4.3.3 Recomenda-se utilizar o histórico de demandas relacionadas ao desenvolvimento, manutenção e sustentação de software 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, no que couber. 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, a exemplo de:

4.3.5.1 Contratação em separado de serviços de apoio a utilização/adoção de metodologias ágeis, gestão de serviços e/ou gestão de projetos.

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.3.6 Recomenda-se avaliar a contratação de serviços técnicos especializados complementares aos contratos de desenvolvimento, manutenção e sustentação de softwares, a exemplo de:

4.3.6.1 Serviços especializados de mensuração de software;

4.3.6.2 Serviços especializados de controle qualidade de software;

4.6.3.3 Serviços especializados de avaliação de segurança de software.

4.3.7 Caso seja necessária a contratação de serviços complementares, deve-se estabelecer condições no Termo de Referência com vistas a não permitir que a empresa contratada para realizar os serviços de desenvolvimento, manutenção e sustentação de softwares seja a mesma contratada para a executar os serviços complementares, conforme preconizado no art. 4º da Instrução Normativa SGD/ME nº 94, de 23 de dezembro de 2022.

4.4 Do processo de desenvolvimento, manutenção e sustentação de software

4.4.1 Deve-se adotar um Processo de Desenvolvimento de Software segmentado em iterações curtas, entregas frequentes e projetos com escopos delimitados, referenciando-o no instrumento convocatório, observando-se preferencialmente o processo de desenvolvimento de software do SISP.

4.4.2 Deve-se, preferencialmente, adotar Metodologias Ágeis no processo de desenvolvimento de software, considerando, no que couber, as orientações contidas no Guia de Projetos de Software com Práticas de Métodos Ágeis do SISP, para a customização interna de um processo ágil.

4.4.3 Recomenda-se que o processo de desenvolvimento de software adotado observe, no que couber, as orientações constantes da ABNT NBR 12.207/2021, que trata dos processos de ciclo de vida de software.

4.4.4 O processo de desenvolvimento de software aborda diferentes dimensões relacionadas ao ciclo de vida de construção e utilização de software. Entre as diferentes dimensões, deve-se prever, no que couber, diretrizes e procedimentos sobre:

a) O fluxo de valor do produto, que envolve, ao menos, as atividades de planejamento, construção da release e transição dos produtos para o ambiente de produção;

b) A construção da visão do produto;

c) O planejamento do roadmap do produto;

d) Definição dos papéis e métodos de iteração;

e) Codificação limpa;

f) Codificação segura;

g) Implementação baseada em técnicas ágeis;

h) Testes (a exemplo de testes unitários, de integração, de release, de sistema, de componentes, de desempenho operacional);

i) Validação das funcionalidades junto ao solicitante;

j) Verificação e implantação;

k) Sustentação de Software; e

l) Manutenção Evolutiva ou Corretivas ou Adaptativas.

4.4.5 O processo de desenvolvimento de software deve estar amparado por diretrizes ou códigos de práticas de construção de softwares que incluem as definições técnicas e orientações de requisitos mínimos de qualidade e padronização dos aspectos técnicos da codificação.

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

4.4.6 A Secretaria de Governo Digital do Ministério da Gestão e da Inovação em Serviços Públicos poderá publicar orientações complementares acerca do processo de desenvolvimento, manutenção e sustentação de software.

4.5 Da adoção de métodos ágeis

4.5.1Para adoção de métodos ágeis na execução dos serviços, independentemente da modalidade de remuneração adotada, o instrumento convocatório ou o processo de desenvolvimento de software do órgão deve abranger as condições constantes nesta seção.

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

4.5.3 Os projetos ágeis devem ser elaborados com a participação de servidor ou profissional contratado com conhecimentos em metodologias ágeis.

4.5.4 O resultado a ser entregue nessa fase inicial deve prever, pelo menos:

a) Documento de Visão;

b) Regras de Negócio;

c) Plano de Releases; e

d) Sprints e Backlog do Produto.

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

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

4.5.7 Deve-se implementar mecanismo progressivo de glosas no caso de rejeição recorrente de sprints ou associado ao grau de rejeição do backlog da sprint, sem prejuízo da aplicação de sanções pelo inadimplemento dos serviços, a depender das condições previstas no termo de referência.

4.5.8 Independentemente das sanções aplicadas, compete a equipe de fiscalização e a gestão contratual investigar e melhorar o processo com o objetivo de corrigir descumprimentos reiterados dos parâmetros inicialmente definidos nas sprints.

4.5.9 Na definição do backlog da sprint, deve-se monitorar a relação quantitativa entre itens planejados e itens não planejados, com vistas a assegurar que o maior esforço esteja sendo empreendido na entrega de valor.

4.5.10 Para cada projeto, devem ser definidos parâmetros para a execução das sprints, tais como:

a) configuração mínima do time que irá executar o conjunto de sprints, indicando perfis profissionais mínimos e nível de compartilhamento aceitável para determinados perfis, conforme exemplo constante do Anexo IV;

b) duração máxima da sprint;

c) meta de velocidade da sprint, como a quantidade de histórias de usuário e pontos de função;

d) meta de escopo planejado x realizado, que indica o percentual realizado a cada sprint em comparação ao escopo planejado; e

e) meta de itens de backlog planejados x não planejados, que mapeia se o esforço, a cada sprint, está sendo gasto com novas funcionalidades planejadas ou com refatorações de código, dívidas técnicas e correções de falhas.

5. MODALIDADES DE REMUNERAÇÃO

5.1 Definição

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

5.1.1.1 Admite-se a adoção de mais de uma modalidade para diferentes itens ou lotes, a depender da seleção da estratégia de contratação dos serviços pelo órgão.

5.1.1.2 Cada modalidade apresenta vantagens, desvantagens, bem como diferentes níveis de riscos que podem variar em decorrência da realidade de cada organização, natureza das aplicações, capacidade de gerenciamento, entre outros fatores internos e externos às organizações.

5.1.2 As modalidades padronizadas por este modelo para contratação de serviços de desenvolvimento e manutenção são:

a) remuneração por pontos de função complementado por horas de serviço técnico;

b) remuneração com pagamento fixo por sprint executada;

c) remuneração por alocação de profissionais de TI, com pagamento vinculado a resultados.

5.1.3 As modalidades padronizadas por este modelo para contratação de serviços de sustentação são:

a) remuneração por alocação de profissionais de TI, com pagamento vinculado a resultados;

b) remuneração baseada em valor fixo mensal por sistema sustentado.

5.1.4 São premissas que devem ser observadas na construção do Termo de Referência, independentemente da modalidade adotada:

a) exigência de qualificação ou experiência mínima dos profissionais que irão prestar os serviços técnicos especializados;

b) fixação de patamar de preço mínimo para presunção relativa de inexequibilidade;

c)definição de metas de produtividade;

d) fixação dos critérios de aceitação dos serviços prestados;

e) definição dos níveis mínimos de serviço e de qualidade;

f) utilização, preferencialmente, de metodologia ágil para a prestação dos serviços;

g) pagamento vinculado ao alcance de resultados;

h) escolha do modelo adequado de precificação ou pagamento pelo serviço, e os devidos controles com vistas a mitigar riscos;

i) clareza quanto à definição do escopo dos serviços e seus entregáveis;

j) uso preferencial de métricas de software orientadas a entregas de produtos de software;

k) previsão de faixas de valores de ajustes nas metas dos indicadores de níveis de serviço;

l) adoção dos mecanismos adequados de penalidades objetivando punir o mau desempenho;

m) possibilidade de rescisão contratual antecipada motivada por falhas sistêmicas de desempenho;

n) definição do local de prestação dos serviços (presencial ou remota);

o) definição de infraestrutura e recursos computacionais necessários à prestação dos serviços.

5.2 Remuneração por pontos de função complementados por horas de serviço técnico

5.2.1 Conceito da modalidade

5.2.1.1 A modalidade de remuneração por Pontos de Função complementados por Horas de Serviço Técnico - HST consiste em remunerar o serviço contratado a partir da entrega de resultados aferíveis por meio de métricas que possam refletir os aspectos funcionais e não funcionais dos produtos e serviços entregues.

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

5.2.1.3 Deve-se distinguir o escopo das macroatividades abrangidas pela métrica Ponto de Função e das atividades a serem remuneradas por meio de Horas de Serviço Técnico, relacionadas em catálogo específico, conforme diretrizes constantes no Roteiro de métricas de Software do SISP.

5.2.1.4 As macroatividades relacionadas ao processo de desenvolvimento a serem aferidas pela métrica de Ponto de Função devem estar documentadas na metodologia do órgão (especificada contratualmente) ou formalizadas diretamente no termo de referência, a exemplo de:

a) Engenharia de Requisitos;

b) Design / Arquitetura;

c) Implementação;

d) Testes funcionais e unitários;

e) Homologação;

f) Implantação.

5.2.1.5 As atividades necessárias à prestação dos serviços de desenvolvimento, manutenção e sustentação de software que não sejam mensuráveis pela técnica de Análise de Pontos de Função devem ser remuneradas por meio de Horas de Serviço Técnico (HST) e relacionadas em catálogo específico.

5.2.1.6 O catálogo de atividades remuneradas pela métrica HST deve conter, no mínimo, para cada atividade:

a) a descrição da atividade;

b) o volume de unidades de HST a ser remunerado;

c) os perfis profissionais aptos a executarem a atividade;

d) os produtos e os resultados esperados;

e) o prazo máximo de execução;

f) os critérios de aceitação.

5.2.1.7 Deve-se prever no termo de referência que cabe ao prestador do serviço empregar os esforços e recursos necessários para assegurar a entrega funcional dos produtos demandados e aferíveis por meio da métrica Ponto de Função, descrita em roteiros de métricas, a exemplo do Roteiro de Métricas de Software do SISP.

5.2.1.8 Deve-se avaliar a viabilidade de desenvolver um roteiro de métricas de software complementar, contendo cláusulas que elucidem os pontos não abordados pelo Manual de Práticas de Contagem de Ponto de Função (CPM) ou pelas normas internacionais de Análise de Ponto de Função.

5.2.1.9 Deve-se avaliar a viabilidade de adoção do Roteiro de Métricas de Software do SISP, utilizando-se preferencialmente o método Simple Function Point - SFP.

5.2.1.10 Na aplicação da técnica de Análise de Pontos de Função, deve-se evitar a utilização de fatores de ponderação ou de ajuste baseados em complexidade ou outra característica temporal. Tal vedação não se confunde com a aplicação do "fator ágil", utilizado por este modelo.

5.2.1.11 A alteração do catálogo de atividades somente poderá ocorrer mediante aditamento contratual, desde que se observe as seguintes vedações:

a) Inclusão de atividades não relacionadas à natureza ou objeto da contratação.

b) Alteração da formação de preços original, que orientou a realização do certame.

5.2.1.12 Na aplicação da modalidade de horas de serviço técnico, o valor estimado da contratação é obtido por meio do produto entre o valor da hora de serviço, aplicado a um perfil de referência, e a quantidade horas estimadas, considerando aplicação dos fatores de ajuste previamente definidos de acordo com o perfil profissional necessário, a execução de cada serviço.

5.2.1.13 A estimativa da quantidade de horas deve ser calculada conforme diretrizes constantes do Roteiro de Métricas de Software do SISP.

5.2.1.14 O objeto da contratação deverá ser dividido em itens aferidos por meio de Pontos de função por tecnologia predominante e item aferido por HST, conforme quadro exemplificativo:

Grupo	Item	Descrição	Métrica	Custo unitário (A)	Quantidade Máxima (B)	Valor total (C) = A x B
1	1	Serviços de Desenvolvimento e manutenção de Software - Python	Ponto de Função
	2	Serviços de Desenvolvimento e manutenção de Software - Java	Ponto de Função
	3	Serviços Complementares de Desenvolvimento e manutenção de Software	Hora de serviço Técnico - Perfil de referência Desenvolvedor Junior

Grupo

Item

Descrição

Métrica

Custo unitário

(A)

Quantidade Máxima

(B)

Valor total

Serviços de Desenvolvimento e manutenção de Software - Python

Ponto de Função

Serviços de Desenvolvimento e manutenção de Software - Java

Ponto de Função

Serviços Complementares de Desenvolvimento e manutenção de Software

Hora de serviço Técnico - Perfil de referência Desenvolvedor Junior

Grupo

Item

Descrição

Métrica

Custo unitário

(A)

Quantidade Máxima

(B)

Valor total

Grupo

Item

Descrição

Métrica

Custo unitário

(A)

Custo unitário

(A)

Quantidade Máxima

(B)

Quantidade Máxima

(B)

Valor total

Serviços de Desenvolvimento e manutenção de Software - Python

Ponto de Função

Serviços de Desenvolvimento e manutenção de Software - Python

Ponto de Função

Serviços de Desenvolvimento e manutenção de Software - Java

Ponto de Função

Serviços de Desenvolvimento e manutenção de Software - Java

Ponto de Função

Serviços Complementares de Desenvolvimento e manutenção de Software

Hora de serviço Técnico - Perfil de referência Desenvolvedor Junior

Serviços Complementares de Desenvolvimento e manutenção de Software

Hora de serviço Técnico - Perfil de referência Desenvolvedor Junior

5.2.2 Mecanismos de gestão

5.2.2.1 A execução dos serviços está condicionada à emissão de ordem de serviço, contendo no mínimo o objetivo da OS, a descrição do que deve ser executado, os produtos/resultados a serem entregues, o prazo de atendimento e os requisitos não funcionais a exemplo (critérios mínimos de desempenho operacional da solução, critérios de segurança da informação, critérios de identidade visual e usabilidade).

5.2.2.2 A identificação dos requisitos funcionais na Ordem de Serviço pode ser realizada por meio de apontamento a roteiros, guias de codificação e outros padrões estabelecidos pela Contratante e previstos no instrumento convocatório.

5.2.2.3 Devem ser descritas regras de composição e alocação de times ou equipes, conforme diretrizes previstas no Anexo IV 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, ou previsão de contratação de profissional de métricas, assegurando-se que:

a) o serviço de métricas 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;

c) o serviço de métricas não seja remunerado exclusivamente pela quantidade de pontos de função contados;

d) o serviço de métricas possua metas de produtividade e indicadores de qualidade previamente definidos.

5.2.3 Dimensionamento

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, estimativa, detalhada ou simplificada - SFP).

5.2.3.2 A memória de cálculo que justificará o volume a ser contratado deve integrar os estudos técnicos preliminares.

5.2.3.3 Para se estimar a quantidade total de HST a ser contratada, deve-se primeiramente estimar a demanda esperada para as atividades constantes no catálogo, baseando-se em histórico recente, caso exista, e projeções para o período de vigência do contrato.

5.2.3.4 Para cada atividade do catálogo, a remuneração associada deve levar em consideração o esforço necessário e os perfis profissionais envolvidos na sua execução. Cada um desses perfis deve ter seu custo unitário de hora expresso como uma fração da hora de um perfil escolhido como referência, permitindo que todas as atividades tenham sua remuneração correspondente a um múltiplo da hora desse perfil de referência, equivalente à HST.

5.2.3.5 A partir da estimativa da demanda por atividade e da construção do catálogo, o valor estimado da contratação pode ser obtido por meio do produto entre o valor estimado da HST e a quantidade de HST a ser contratada.

5.2.4 Forma de pagamento

5.2.4.1 O pagamento será feito por produto de software implementado conforme critérios de aceitação definidos e aferição de níveis mínimos de serviço, aferidos a cada sprint aceita, adotando-se preferencialmente a métrica Ponto de Função Simples (Simple Function Point - SFP) sobre as funcionalidades efetivamente implementadas.

5.2.4.2 Para comportar a dinâmica ágil de forma a incorporar as mudanças entre as sprints, admite-se a aplicação de um fator ágil a ser definido no Termo de Referência seguindo as diretrizes constantes do roteiro de métricas do SISP, não sendo superior a 30%.

5.2.4.3 A adoção do fator ágil consiste na substituição da contabilização de exclusões e alterações de processos elementares entre as sprints de uma mesma release pela aplicação de um percentual sobre o tamanho contabilizado da release. A quantidade de sprints de uma release deve ser definida no TR.

5.2.4.4 A aplicação do fator ágil é adequada para processos em que há necessidade de grande volume de reconstruções entre sprints de uma mesma release.

5.2.4.5 O pagamento por horas de serviço técnico deve ser baseado em catálogo, previamente estabelecido no Termo de Referência, conforme diretrizes constantes do Roteiro de métricas de software do SISP.

5.2.5 Mecanismos de controle

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, recomendando-se 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 Remuneração por sprints

5.3.1 Conceito da modalidade

5.3.1.1 A modalidade de remuneraçã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.1.5 Para cada tipo de sprint, o valor a ser remunerado por sprint deve variar conforme sua capacidade de execução, devendo ser calculado a partir da composição de equipe mínima definida para o projeto e da duração da sprint (timebox).

5.3.1.6 A capacidade alocada para um determinado tipo de sprint deve ser atribuída por meio de uma unidade de medida como, por exemplo, Hora de Serviço Técnico - HST.

5.3.1.7 Para calcular a capacidade total alocada a um tipo de sprint, deve-se definir a composição da equipe que atuará no projeto e atribuir a cada perfil a sua capacidade diária em função da unidade de medida escolhida, a exemplo de:

	Sprint Tipo A	Sprint Tipo B
Composição da equipe	1 SM (5 HST/dia) 1 DEV_SR (8 HST/dia) 1 DEV_PL (7 HST/dia) Total = 20 HST/dia	1 SM (5 HST/dia) 1 DEV_SR (8 HST/dia) 2 DEV_PL (14 HST/dia) Total = 27 HST/dia
Timebox	15 dias	15 dias
Capacidade alocada por Sprint	= 300 HST (15d * 20 HST)	= 405 HST (15d * 27 HST)

Sprint Tipo A

Sprint Tipo B

Composição da equipe

1 SM (5 HST/dia)

1 DEV_SR (8 HST/dia)

1 DEV_PL (7 HST/dia)

Total = 20 HST/dia

1 SM (5 HST/dia)

1 DEV_SR (8 HST/dia)

2 DEV_PL (14 HST/dia)

Total = 27 HST/dia

Timebox

15 dias

Capacidade alocada por Sprint

= 300 HST (15d * 20 HST)

= 405 HST (15d * 27 HST)

Sprint Tipo A

Sprint Tipo B

Sprint Tipo A

Sprint Tipo B

Composição da equipe

1 SM (5 HST/dia)

1 DEV_SR (8 HST/dia)

1 DEV_PL (7 HST/dia)

Total = 20 HST/dia

1 SM (5 HST/dia)

1 DEV_SR (8 HST/dia)

2 DEV_PL (14 HST/dia)

Total = 27 HST/dia

Composição da equipe

1 SM (5 HST/dia)

1 DEV_SR (8 HST/dia)

1 DEV_PL (7 HST/dia)

Total = 20 HST/dia

1 SM (5 HST/dia)

1 DEV_SR (8 HST/dia)

1 DEV_PL (7 HST/dia)

Total = 20 HST/dia

1 SM (5 HST/dia)

1 DEV_SR (8 HST/dia)

2 DEV_PL (14 HST/dia)

Total = 27 HST/dia

1 SM (5 HST/dia)

1 DEV_SR (8 HST/dia)

2 DEV_PL (14 HST/dia)

Total = 27 HST/dia

Timebox

15 dias

Timebox

15 dias

Capacidade alocada por Sprint

= 300 HST (15d * 20 HST)

= 405 HST (15d * 27 HST)

Capacidade alocada por Sprint

= 300 HST (15d * 20 HST)

= 405 HST (15d * 27 HST)

5.3.2 Mecanismos de gestão

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, definição do escopo macro do projeto e das principais funcionalidades do produto a ser desenvolvido (backlog do produto).

5.3.2.2 A execução dos serviços está condicionada à emissão de ordem de serviço, contendo no mínimo: o objetivo da OS, a composição do time ágil (perfil, quantidade e taxa de alocação), os produtos/resultados a serem entregues e o prazo de atendimento.

5.3.2.3 Cada tipo de sprint deve estar associada a entrega de resultados aferidos por meio de métricas de tamanho de software previstas na seção 12.

5.3.2.4 É vedada a previsão de sprints restritas a fases específicas do ciclo de desenvolvimento ou que caracterizem meros pontos de controle ou paradas artificiais para reportar a situação ou o andamento do projeto.

5.3.3 Dimensionamento

5.3.3.1 O dimensionamento do volume a ser contratado deve partir de uma estimativa para a quantidade máxima de sprints a ser executada em 12 meses, que está diretamente relacionada à capacidade de gestão de projetos de desenvolvimento de software pelo órgão. Para isso, devem ser utilizados dados recentes relativos à quantidade de projetos dessa natureza já executados pelo órgão, considerando ainda a necessidade de eventual incremento na capacidade de gestão de projetos do órgão projetada para um período de 60 meses, para comportar o atendimento às necessidades negociais e objetivos estratégicos do órgão.

5.3.3.2 A partir da estimativa da demanda por sprints de projetos de desenvolvimento de software, o valor estimado da contratação pode ser obtido por meio do produto entre o valor estimado por sprint e a quantidade de sprints a ser contratada.

5.3.3.3 A memória de cálculo que evidencie o roadmap do produto e a estimativa da quantidade de sprints relacionadas deve integrar os estudos técnicos preliminares.

5.3.4 Forma de pagamento

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, associado ao grau de rejeição do backlog da sprint ou a descumprimento reiterado das metas definidas inicialmente para a execução das sprints.

5.3.5 Mecanismos de controle

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

5.3.5.4 O planejamento do projeto ágil, em especial quanto ao escopo e quantidade de sprints, deve ser aprovado pela Contratante.

5.3.5.5 As histórias de usuário devem ser padronizadas mediante templates.

5.3.5.6 Devem-se prever mecanismos, baseados em indicadores e glosas, que evitem que o trabalho incompleto realizado em uma sprint seja, com frequência, carreado para a sprint seguinte.

5.4 Remuneração por alocação de profissionais de TI vinculada a resultado

5.4.1 Conceito da modalidade

5.4.1.1 Nesta modalidade de remuneração, a empresa especializada provê equipe para a prestação do serviço de desenvolvimento, manutenção e sustentação de softwares.

5.4.1.2 A contratada será remunerada pela alocação efetiva de profissionais de TI 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.3 A prestação do serviço de alocação de profissionais de TI se dará em conformidade com a metodologia ágil adotada pela contratante.

5.4.1.4 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.5 Os profissionais de TI a serem alocados devem ser avaliados por meio de metas de produtividade aferidas pelos indicadores de níveis mínimos de serviços.

5.4.1.6 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.7 O objeto da contratação deverá ser dividido em itens por tipo de perfil necessário à execução dos serviços. Devendo-se prever a quantidade máxima de profissionais de TI a serem alocados para cada item, a exemplo:

Grupo	Item	Perfil Profissional	Custo unitário mensal (A)	Quantidade Máxima de profissionais de TI (B)	Valor máximo mensal (C) = A x B	Valor máximo anual (D) = C x 12
1	1	Perfil 1 - Desenvolvedor Pleno
	2	Perfil 2 - Desenvolvedor Sênior
	3	Perfil 3 - Scrum Master

Grupo

Item

Perfil Profissional

Custo unitário mensal

(A)

Quantidade Máxima de profissionais de TI (B)

Valor máximo mensal

Valor máximo anual

(D) = C x 12

Perfil 1 - Desenvolvedor Pleno

Perfil 2 - Desenvolvedor Sênior

Perfil 3 - Scrum Master

Grupo

Item

Perfil Profissional

Custo unitário mensal

(A)

Quantidade Máxima de profissionais de TI (B)

Valor máximo mensal

Valor máximo anual

(D) = C x 12

Grupo

Item

Perfil Profissional

Custo unitário mensal

(A)

Custo unitário mensal

(A)

Quantidade Máxima de profissionais de TI (B)

Valor máximo mensal

Valor máximo anual

(D) = C x 12

Valor máximo anual

(D) = C x 12

Perfil 1 - Desenvolvedor Pleno

Perfil 2 - Desenvolvedor Sênior

Perfil 3 - Scrum Master

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

5.4.2 Mecanismos de gestão

5.4.2.1 O modelo de gestão deverá conter mecanismos que assegurem, não apenas a qualidade do serviço prestado, como também a produtividade de cada profissional alocado.

5.4.2.2 A produtividade deverá ser aferida por meio de métricas de software, conforme descrito na seção 12.

5.4.2.3 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.4 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 conforme metas de produtividade previamente definidas, a serem aferidas conforme orientações da seção 12;

b) Deixar de executar ou não executar as atividades contratadas com a qualidade mínima exigida;

c) 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.5 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.6 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.7 Cada perfil profissional 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.8 Cada ordem de serviço deverá indicar o objetivo a ser alcançado, em termos de produto a ser entregue observando-se metas de produtividade estabelecidas, detalhando a quantidade e os perfis dos profissionais necessários, a memória de cálculo para o dimensionamento dos profissionais, além do período específico de alocação dos profissionais.

5.4.2.9 Em virtude de fatores como prazo do projeto, volume e ritmo de demandas, poderá ser solicitada a redução ou o acréscimo de perfis de trabalho na ordem de serviço, respeitando os limites máximos permitidos e a produtividade esperada.

5.4.2.10 A organização deve definir metas de produtividade a partir de seu próprio histórico, conforme métrica de software adotada ou por meio de benchmark com outros órgãos ou fontes especializadas.

5.4.2.11 As metas de produtividade constantes da Ordem de Serviço devem observar as métricas de software previstas na seção 12.

5.4.2.12 O quantitativo dos profissionais de TI 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.13 Sugere-se um prazo máximo de 30 dias para que a contratada aloque os profissionais de TI:

a) Exaurido esse prazo, em caso de eventual não-alocação dos profissionais de TI necessários, deve-se prever a aplicação de sançõ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.14 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.15 Critérios objetivos devem ser estabelecidos para eventual solicitação de substituição de profissional de TI, além do estabelecimento de processo de avaliação mensal dos profissionais por meio de indicador de nível de serviço específico.

5.4.2.16 Cabe ainda, prever mecanismos para sançã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 Dimensionamento

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 Deve-se prever nos estudos técnicos preliminares, a memória de cálculo que evidencie a relação entre a quantidade de perfis previstos e a produtividade esperada em termos de produtos/resultados esperados.

5.4.3.3 No dimensionamento do quantitativo necessário de profissionais para atender as demandas de serviços de desenvolvimento e sustentação de softwares é 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 c) 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 softwares da organização;

d) Considerar a sustentação dos softwares 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 softwares;

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 Forma de pagamento

5.4.4.1 A contratada será remunerada pelo serviço prestado no âmbito da Ordem de Serviço de acordo com os profissionais de TI efetivamente alocados no período, observando os níveis mínimos de serviços definidos.

5.4.4.2 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.3 Deve-se prever que qualquer tipo de ausência descaracteriza a efetiva alocação do profissional de TI, 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 de indicadores de níveis de serviços, devendo se abster do pagamento do dia não trabalhado.

5.4.4.4 A contratante deve realizar mensalmente a aferição da taxa efetiva de ocupação de alocação de profissionais de TI 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.5 No cálculo da taxa efetiva de alocação dos profissionais de TI, 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 Mecanismos de controle

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 O fiscal administrativo deve 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 Deve-se promover a fiscalização técnica do objeto por meio da verificação da qualidade dos produtos entregues, do atingimento das metas de produtividade previamente estabelecidas na Ordem de Serviço, da observância aos prazos máximos definidos e da alocação dos perfis profissionais conforme qualificação mínima prevista.

5.4.5.4 Antes do 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.5 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 Remuneração de serviços de sustentação de software por preço fixo mensal

5.5.1 Conceito da modalidade

5.5.1.1 Essa modalidade baseia-se em pagamento de valor fixo mensal pela prestação de serviços de sustentação de software, vinculado ao atendimento de níveis mínimos de serviço.

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

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

______________

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.

Finalidade

Garantir a qualidade na entrega das sprints.

Finalidade

Garantir a qualidade na entrega das sprints.

Meta a cumprir

IAS igual ou superior a 75%.

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.

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.

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

______________

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

______________

É 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

______________

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.

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.

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.

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.

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.

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

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.

Observações

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%.
Forma de acompanhamento	Por períodos previamente definidos (a ex. mensal), é definida uma produtividade mínima utilizando-se as diretrizes de definição de métricas de software propostas na seção 12. Dessa forma, afere-se a produtividade realizada no período, considerando as metas de produtividade previamente estabelecidas na ordem de serviço, conforme condições a constar do Termo de Referência, que podem variar por projeto, tecnologia, modalidade ou métrica adotada.
Periodicidade	Mensal, a partir de determinada sprint a ser definida no instrumento convocatório, por exemplo: mensalmente, a partir da 4º sprint de cada projeto.
Mecanismo de cálculo (%)	IPA_Total = 100 * soma(Pr / Pp) Onde: IPA = Indicador de Produtividade Ágil; Pr = produtividade realizada no período, em função da métrica de software previamente estabelecida; Pp = produtividade prevista no período, em função da métrica de software previamente estabelecida.
Início da vigência	A partir da emissão da ordem de serviço.
Sanções/ faixas de ajuste	IPA>= 90%: sem descontos sobre o valor mensal apurado da OS IPA >= 80% e < 90%: 10% de desconto sobre o valor mensal apurado da OS. IPA >= 70% e < 80%: 20% de desconto sobre o valor mensal apurado da OS.
	IPA >= 60% e < 70%: 30% de desconto sobre o valor mensal apurado da OS. IPA >= 50% e < 60%: 40% de desconto sobre o valor mensal apurado da OS. IPA < 50%: 50% de desconto sobre o valor mensal apurado da OS.
Observações	Esse indicador é individualmente calculado para cada período previsto, mantendo-se a vinculação às Ordens de Serviço. A produtividade mínima prevista e a respectiva métrica de software a ser aferida devem constar do Termo de Referência.

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

Forma de acompanhamento

Por períodos previamente definidos (a ex. mensal), é definida uma produtividade mínima utilizando-se as diretrizes de definição de métricas de software propostas na seção 12. Dessa forma, afere-se a produtividade realizada no período, considerando as metas de produtividade previamente estabelecidas na ordem de serviço, conforme condições a constar do Termo de Referência, que podem variar por projeto, tecnologia, modalidade ou métrica adotada.

Periodicidade

Mensal, a partir de determinada sprint a ser definida no instrumento convocatório, por exemplo: mensalmente, a partir da 4º sprint de cada projeto.

Mecanismo de cálculo (%)

IPA_Total = 100 * soma(Pr / Pp)

Onde:

IPA = Indicador de Produtividade Ágil;

Pr = produtividade realizada no período, em função da métrica de software previamente estabelecida;

Pp = produtividade prevista no período, em função da métrica de software previamente estabelecida.

Início da vigência

A partir da emissão da ordem de serviço.

Sanções/ faixas de ajuste

IPA>= 90%: sem descontos sobre o valor mensal apurado da OS

IPA >= 80% e < 90%: 10% de desconto sobre o valor mensal apurado da OS.

IPA >= 70% e < 80%: 20% de desconto sobre o valor mensal apurado da OS.

IPA >= 60% e < 70%: 30% de desconto sobre o valor mensal apurado da OS.

IPA >= 50% e < 60%: 40% de desconto sobre o valor mensal apurado da OS.

IPA < 50%: 50% de desconto sobre o valor mensal apurado da OS.

Observações

Esse indicador é individualmente calculado para cada período previsto, mantendo-se a vinculação às Ordens de Serviço.

A produtividade mínima prevista e a respectiva métrica de software a ser aferida devem constar do Termo de Referência.