Portaria SGD/ME nº 5.651, de 28 de junho de 2022
MINISTÉRIO DA ECONOMIA
PORTARIA SGD/ME Nº 5.651, DE 28 DE JUNHO DE 2022
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 DA SECRETARIA ESPECIAL DE DESBUROCRATIZAÇÃO, GESTÃO E GOVERNO DIGITAL DO MINISTÉRIO DA ECONOMIA, no uso das atribuições que lhe conferem o art. 132, incisos II e XVII, do Anexo I do Decreto nº 9.745, de 8 de abril de 2019, e tendo em vista o disposto no Decreto nº 7.579, de 11 de outubro de 2011, e arts. 39 e 40 da Instrução Normativa SGD/ME nº 1, de 4 de abril de 2019, 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 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º 73, de 5 de agosto de 2020, 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º 73, de 2020, 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 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.
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. Fica revogada a Portaria SLTI/MP nº 4, de 28 de março de 2017.
Vigência
Art. 11. Esta Portaria entra em vigor no dia 1º de agosto de 2022.
FERNANDO ANDRE COELHO MITKIEWICZ
Secretário
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, 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, 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 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º 1, de 4 de abril de 2019, 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.3.6.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 IN SGD/ME nº 1, de 4 de abril de 2019.
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 Economia 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.1. Para 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 |
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 |
|
|
|
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) |
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 |
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 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. A fiscalização das obrigações trabalhistas, sociais e previdenciárias deverá ser realizada em consonância com os termos da Instrução Normativa Seges/MP Nº 5, de 26 de maio de 2017, e seus anexos e alterações posteriores.
5.4.5.4. 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.5. 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.6. 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.7. 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.6. 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º 1, de 4 de abril de 2019, 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. |
|
Observações |
|
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>= 75%: sem descontos sobre o valor da OS |
|
Observações |
|
c) Indicador de atendimento aos prazos de chamados de sustentação (IAP), com o objetivo de assegurar a resposta tempestiva dos chamados relacionados à sustentação das aplicações e incentivar a atuação preventiva na execução dos serviços, conforme quadro exemplificativo a seguir:
|
Finalidade |
Assegurar a resposta tempestiva aos chamados relacionados à sustentação das aplicações e incentivar a atuação preventiva na execução dos serviços de sustentação. |
|
Meta a cumprir |
IAP igual ou superior a 90% |
|
Forma de acompanhamento |
É apurada a quantidade de chamados atendidos dentro do prazo máximo estabelecido em relação a quantidade total de chamados atendidos no período de referência. |
|
Periodicidade: |
Mensal |
|
Instrumentos de medição |
Deve ser aferido por meio de ferramentas, procedimentos de amostragem ou outros procedimentos de inspeção. |
|
Mecanismo de cálculo (%) |
IAP = 100 * soma(Qcap / Qctot) Onde: IAP = Indicador de atendimento aos prazos de chamados de sustentação; Qcap = Quantidade de chamados atendidos no prazo máximo estabelecido no TR com previsão de encerramento para o período de referência; Qctot = Quantidade total de chamados registrados com previsão de encerramento para o período de referência. |
|
Início da vigência |
<indicar o marco de início da aferição do indicador> |
|
Sanções/ faixas de ajuste: |
IAP >= 90%: sem descontos sobre o valor da fatura mensal. |
|
Observações: |
<incluir as observações complementares> |
d) 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:
|
Finalidade |
Incentivar ações proativas de testes de qualidade do código. |
|
Meta a cumprir |
100% |
|
Forma de acompanhamento |
< Indicar se a aferição será realizada exclusivamente por meio de ferramentas ou por meio de procedimentos de amostragem ou outros procedimentos de inspeção > |
|
Periodicidade: |
Mensal |
|
Instrumentos de medição |
< indicar as ferramentas automatizadas para extração dos dados > |
|
Mecanismo de cálculo (%) |
ICT = I / Tlic Onde: ICT= Indicador de cobertura de testes; I = número de itens executados (instruções, ramificações e caminhos de código, pontos de decisão do estado de dados ou nomes de elementos de dados); Tlic = é o número total de itens no código. |
|
Início da vigência |
<indicar o marco de início da aferição do indicador> |
|
Sanções/ faixas de ajuste: |
ICT>= 75%: sem descontos sobre o valor da OS |
|
Observações: |
|
e) 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:
|
Finalidade |
Incentivar que a contratada assegure a manutenção da equipe alocada na execução da sprint, ou que crie mecanismos e estratégias para realizar uma substituição transparente (sem prejuízos à execução da sprint), promover a comunicação e transferência de conhecimento efetivas |
|
Meta a cumprir |
IDE = 0 |
|
Forma de acompanhamento |
Para cada projeto que teve uma sprint rejeitada ou aceita parcialmente, é apurado o somatório de desligamento de pessoas das equipes ágeis nas 2 Sprints anteriores. |
|
Periodicidade |
A cada sprint rejeitada ou aceita parcialmente, por projeto |
|
Mecanismo de cálculo (%) |
O índice total é o somatório de todos os fatores parciais levantados por projeto: Para Sprints rejeitadas: 0,005% para cada desligamento. Para Sprints aceitas parcialmente: 0,002% para cada desligamento. IDE = soma(Qsr * 0,005) + soma(Qsp * 0,002) Onde: IDE= Indicador de desmobilização de equipe; 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. |
|
Início da vigência |
<indicar o marco de início da aferição do indicador> |
|
Exemplo: |
Projeto 1: Sprint rejeitada - 1 desligamento (1 x 0,005) em sprint anterior. Projeto 2: Sprint rejeitada - 2 desligamentos (2 x 0,005) em sprints anteriores. Projeto 3: Sprint aceita parcial - 3 desligamentos (3 x 0,002) em sprints anteriores. IDE = (1 x 0,005) + (2 x 0,005) + (3 x 0,002) = 1,5% + 0,006% = 2,1% de redução no faturamento do mês de aferição |
|
Sanções/ faixas de ajuste |
O índice IDE representa diretamente o percentual de desconto sobre a fatura mensal |
|
Observações |
|
f) 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:
|
Finalidade |
Assegurar a qualidade do código em projetos de desenvolvimento e/ou sustentação e diminuir a ocorrência de defeitos |
|
Meta a cumprir |
Medir o nível de adequação do código fonte a características de qualidade determinadas pela contratante |
|
Forma de acompanhamento |
< Indicar se a aferição será realizada exclusivamente por meio de ferramentas ou por meio de procedimentos de amostragem ou outros procedimentos de inspeção > |
|
Periodicidade: |
Por período previamente definido seja em termos de sprints executadas ou releases homologadas. |
|
Instrumentos de medição |
< indicar as ferramentas automatizadas para extração dos dados > |
|
Mecanismo de cálculo (%) |
IQC = 100 * soma(Qrc / Qtr) Onde: IQC = Indicador de qualidade de código; Qrc = Quantidade de requisitos de qualidade de código atendidos; Qtr = Quantidade total de requisitos de qualidade de código avaliados. |
|
Início da vigência |
<indicar o marco de início da aferição do indicador> |
|
Sanções/ faixas de ajuste: |
IQC >= 75%: sem descontos sobre o valor da OS. |
|
Observações: |
|
g) Indicador de Satisfação do Dono do Produto (ISP) com o objetivo de assegurar a qualidade na execução dos processos de entrega dos produtos em termos de satisfação das partes interessadas segundo critérios pré-estabelecidos:
|
Finalidade |
Assegurar a qualidade na execução dos processos de entrega dos produtos em termos de satisfação das partes interessadas, segundo critérios pré-estabelecidos. |
|
Meta a cumprir |
ISP igual ou superior de 80%. |
|
Forma de acompanhamento |
Avaliação periódica junto aos donos de produtos por meio de questionário estruturado baseado em critérios e pontuações previamente definidas. |
|
Periodicidade: |
Mensalmente |
|
Instrumentos de medição |
Ordem de Serviço e questionários de avaliação da satisfação |
|
Mecanismo de cálculo (%) |
ISP = 100 * soma(Pafr / Ptot) Onde: ISP = Indicador de satisfação do Dono de Produto; Pafr = Pontuação aferida; Ptot = Pontuação total máxima possível para todos os critérios estabelecidos. |
|
Início da vigência |
<indicar o marco de início da aferição do indicador> |
|
Sanções/ faixas de ajuste: |
ISP >= 80%: sem descontos sobre o valor da OS. |
|
Observações: |
Recomenda-se automatizar a avaliação em ferramenta de homologação da demanda pelo gestor/dono do produto. |
h) Indicador de avaliação individual do Perfil Profissional (IPP) com o objetivo de avaliar individualmente os profissionais de TI alocados:
|
Finalidade |
Assegurar que os profissionais alocados nos perfis profissionais agreguem valor ao time por meio de contribuições técnicas e participação ativa no processo. |
|
Meta a cumprir |
Recomenda-se um IPP mínimo de 70%. |
|
Forma de acompanhamento |
Avaliação periódica por meio de questionário estruturado baseado em critérios e pontuações previamente definidas com enfoque nas seguintes dimensões: |
|
Periodicidade: |
Mensalmente por perfil alocado |
|
Instrumentos de medição |
Ordem de Serviço e questionários de avaliação |
|
Mecanismo de cálculo (%) |
IPP = 100 * soma(Pafr / Ptot) Onde: IPP = Indicador de avaliação individual do Perfil Profissional Pafr = Pontuação aferida. Ptot = Pontuação total máxima possível para todos os critérios estabelecidos. |
|
Início da vigência |
<indicar o marco de início da aferição do indicador> |
|
Sanções/ faixas de ajuste: |
IPP >= 70%: sem descontos sobre o valor da OS. |
|
Observações: |
A avaliação dos perfis profissionais deve ser realizada pela equipe de fiscalização e gestão do contrato com o apoio do respectivo dono de produto ou representantes técnicos da contratante que acompanharam a execução dos serviços. |
8.3.7. Deve-se adotar, no mínimo, os seguintes indicadores por modalidade de remuneração.
8.3.7.1. Remuneração por pontos de função complementado por horas de serviço técnico:
a) Indicador de Aceitação da Sprint/Entrega (IAS),
b) Indicador de cobertura de testes (ICT),
c) Indicador de qualidade de código (IQC).
8.3.7.2. Remuneração por alocação de profissionais de TI:
a) Indicador de Aceitação da Sprint/Entrega (IAS),
b) Indicador de Produtividade Ágil (IPA),
c) Indicador de avaliação individual do Perfil Profissional (IPP),
d) Indicador de qualidade de código (IQC).
8.3.7.3. Remuneração com pagamento fixo por sprint executada:
a) Indicador de Aceitação da Sprint/Entrega (IAS),
b) Indicador de Produtividade Ágil (IPA),
c) Indicador de qualidade de código (IQC),
d) Indicador de cobertura de testes (ICT).
8.3.7.4. Remuneração baseada em valor fixo mensal por sistema sustentado:
a) Indicador de atendimento aos prazos de chamados de sustentação (IAP),
b) Indicador de cobertura de testes (ICT),
c) Indicador de qualidade de código (IQC).
8.4. Das glosas e sanções
8.4.1. As glosas e sanções devem ser proporcionais à relevância ou significância de cada indicador de Nível Mínimo de Serviço (NMS), de modo a assegurar o alcance da qualidade, segurança e tempestividade na prestação dos serviços de desenvolvimento, manutenção e sustentação de software.
8.4.2. Há duas abordagens na definição dos mecanismos de glosas que podem ser adotadas:
a) Abordagem fixa, baseada na definição de faixas fixas de ajuste no pagamento, de forma independente entre os Níveis Mínimos de Serviço;
b) Abordagem ponderada, baseada na definição de um valor máximo de desconto possível, em conjunto com a adoção de um mecanismo de ponderação de acordo com a relevância de cada Nível Mínimo de Serviço.
8.4.3. Na abordagem fixa, a definição do nível de desconto para cada faixa de ajuste por nível de serviço deve ser dimensionada em função do risco associado ao descumprimento do NMS e o respectivo impacto para o alcance dos resultados, assegurando-se a proporcionalidade entre o ajuste e o impacto da ação ou comportamento que se deseja coibir.
8.4.4. Na abordagem ponderada, deve-se atribuir pesos percentuais para cada NMS que, somados, não ultrapassem um valor situado no intervalo de 250 a 300%, além de se fixar um limite máximo de desconto. Assim, durante a aplicação de uma penalidade, se o limite aplicável de glosa sobre as faturas for de 30%, tem-se a seguinte fórmula: peso do NMS descumprido x 30%. Caso o somatório dos pesos dos NMS descumpridos ultrapasse 100%, aplica-se o desconto máximo previsto, a exemplo de 30%.
8.4.5. As condições passíveis de aplicação de sanções devem ser apresentadas de forma detalhada em quadro específico, a exemplo do quadro constante no template de Termo de Referência de TIC do SISP.
8.5. Da planilha de custos e formação de preços
8.5.1. Deve-se adotar, para objetos que utilizam a modalidade de remuneração baseada em alocação de profissionais de TI, o modelo de planilha de custos e formação de preços definida pela Instrução Normativa Seges/MP nº 5, de 2017, ou posterior, individualizada por perfil previsto, incluindo as orientações relacionadas ao preenchimento e análise, admitindo-se adaptações ao contexto de serviços de Tecnologia da Informação amparadas pela legislação vigente, a exemplo de:
a) Exigência ou não de declaração de custos de Férias e Terço Constitucional de Férias para reposição de profissional ausente;
b) Exigência ou não de declaração de custos de Substituto no Intervalo para repouso ou alimentação.
c) Entre outras condições aplicadas a serviços de Tecnologia da Informação.
8.5.2. Deve-se adotar, para objetos que utilizam as demais modalidades de remuneração (exceto a modalidade de remuneração baseada em alocação de profissionais de TI), os modelos de planilhas de custos e formação de preços apresentados no Anexo VI e de forma complementar, quando necessário, para fins de análise de exequibilidade de proposta de preços, o modelo de planilha de custos e formação de preços definida pela Instrução Normativa Seges/MP nº 5, de 2017, incluindo as orientações relacionadas ao preenchimento e análise.
8.6. Da definição de critérios de qualificação técnica
8.6.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 previstos na Lei Geral de Licitações.
8.6.2. As exigências relativas à qualificação técnica devem ser motivadas, limitando-se ao mínimo necessário à execução dos serviços, assegurando-se de que os parâmetros fixados são necessários, suficientes e pertinentes ao objeto licitado. 8.6.3. Não se deve exigir para fins de habilitação, certificados de qualidade de processo de software (CMMI, MPS.BR etc.).
8.7. Da análise de exequibilidade das propostas
8.7.1. O termo de referência pode estabelecer procedimentos e critérios para análise da planilha de formação de custos, observando o disposto na Súmula nº 262 TCU, em relação a necessidade de assegurar à licitante a oportunidade de demonstrar a exequibilidade da sua proposta.
8.7.2. Segundo Acórdão nº 2.362/2015 - Plenário, admite-se o estabelecimento de um patamar de preço abaixo do qual há presunção relativa de inexequibilidade, situação em que a licitante deverá demonstrar a exequibilidade do preço apresentado.
8.7.3. Se houver indícios de inexequibilidade da proposta de preço, ou em caso da necessidade de esclarecimentos complementares, poderão ser efetuadas diligências, na forma do § 3º do art. 43 da Lei nº 8.666, de 1993, para que a empresa comprove a exequibilidade da proposta.
8.7.4. São exemplos de critérios de presunção relativa de inexequibilidade: a) valor global da proposta inferior ao patamar de preço definido; b) ausência ou valores irrisórios nos elementos de custos relacionados à cobertura tributária.
8.7.5. A definição do patamar de preço abaixo do qual há presunção relativa de inexequibilidade deve ser documentada e utilizar critérios objetivos.
8.7.6. Para a modalidade baseada no pagamento por Ponto de Função, o cálculo do patamar mínimo do valor do Ponto de Função deve considerar os parâmetros de composição do time e de produtividade esperada, relacionados a seguir:
a) A produtividade máxima considerada para projetos ágeis de TI (em geral, tem-se 10 horas por Ponto de Função);
b) A composição mínima da equipe ágil, em termos dos perfis profissionais e suas respectivas taxas de alocação;
c) A média dos salários de referência (Anexo II) dos perfis que integram a composição mínima da equipe ágil;
d) A duração máxima da sprint;
e) O custo mensal médio estimado do time ágil.
8.7.7. Para a modalidade baseada em Horas de Serviço Técnico, deve-se definir o patamar de inexequibilidade considerando o salário constante no Anexo II para o perfil de referência.
8.7.8. Para a modalidade baseada em sprint, deve-se definir o patamar de inexequibilidade considerando a composição do time previsto para cada tipo de sprint, a duração das sprints e o salário dos perfis profissionais previstos para a execução das sprints, conforme Anexo II.
8.7.9. Para a modalidade de alocação de profissionais de TI, deve-se definir o patamar de inexequibilidade considerando o salário constante do Anexo II para cada perfil profissional.
8.7.10. Para a modalidade de valor fixo mensal, deve-se definir o patamar de inexequibilidade considerando o salário constante no Anexo II para o conjunto mínimo de profissionais estimados para execução dos serviços.
9. DA VIGÊNCIA DOS CONTRATOS DE DESENVOLVIMENTO, MANUTENÇÃO E SUSTENTAÇÃO DE SOFTWARE
9.1. Conforme previsto na Orientação Normativa nº 38, de 13 de dezembro de 2011, da Advocacia-Geral da União, em regra o prazo de vigência é de até 12 meses, entretanto admite-se período superior em função da complexidade e peculiaridade do objeto, observando-se os limites legais estabelecidos e justificando-se no Termo de Referência a adoção do prazo de vigência.
10. DA SUBCONTRATAÇÃO NOS SERVIÇOS DE DESENVOLVIMENTO, MANUTENÇÃO DE SOFTWARE
10.1. Admite-se prever a subcontratação de etapas específicas do processo e desenvolvimento, manutenção e sustentação de software, a exemplo das etapas de testes, prototipação, codificação, provisionamento de ambientes, entre outras.
11. DAS FERRAMENTAS
11.1. De gestão de demanda
11.1.1. Pode-se considerar ferramenta de gestão de demanda (ITSM) como solução de TIC distinta do serviço de desenvolvimento, manutenção e sustentação de software, ou permitir que sejam fornecidas pela contratada. Entretanto, caso seja necessário prever o fornecimento de ferramentas de ITSM ou outras específicas, faz-se necessário observar eventuais riscos descritos nesta seção.
11.1.2. A contratação de ferramenta distinta da contratação do serviço de desenvolvimento, manutenção e sustentação de software permite que o órgão planeje e execute com mais eficiência e estabilidade o gerenciamento de demandas, incidentes, problemas e requisições, além de permitir maior controle sobre as melhorias e aperfeiçoamentos necessários nos processos, contribuindo assim para o aumento da maturidade da área de TI no tocante ao gerenciamento de seus serviços.
11.1.3. O uso de ferramenta sob gestão do órgão permite ainda uma maior proteção ao histórico do gerenciamento do contrato (essencial para a gestão e renovação contratuais), pois a manutenção e a salvaguarda desses dados encontram-se sob a responsabilidade direta da área de TI do órgão, que acompanha e monitora processos internos de gestão e de governança de TI.
11.1.4. Além disso, permite minimizar riscos de manipulações indevidas e adulterações de dados, principalmente, no que se refere aos dados utilizados na aferição dos indicadores de níveis de serviço, tais como o tempo de atendimento dos chamados. Consequentemente, evita-se também a ocorrência de pagamentos incorretos ou indevidos.
11.2. Da análise de código
11.2.1. A contratação e gestão dos serviços de desenvolvimento, manutenção e sustentação de software deve ser apoiado pelo uso de recursos tecnológicos de análise da qualidade de códigos.
11.2.2. As ferramentas de análise de código devem ser parametrizadas com base em critérios de qualidade estabelecidos pelo órgão.
12. MENSURAÇÃO DE SOFTWARE
12.1. Nas contratações de serviços de desenvolvimento, manutenção e sustentação de software devem ser definidas métricas objetivas que permitam a gestão contratual, a mensuração e a devida remuneração dos serviços e produtos efetivamente entregues pela empresa contratada no contexto do processo de desenvolvimento de software adotado pelo órgão ou entidade.
12.2. O processo de medição de software visa coletar, analisar e relatar dados e informações objetivas para apoiar um gerenciamento eficaz e demonstrar a qualidade dos produtos, serviços e processos.
12.3. Independente da modalidade de contratação, deve-se aferir a entrega de produtos por meio de métricas de software, mantendo-se uma base histórica, a exemplo de:
a) Pontos de Função (IFPUG, NESMA, COSMIC, Simple Function Point - SFP);
b) Linhas de código implementadas;
c) Pontos de história (Story Point);
12.4. A métrica de software deve estar prevista no processo de desenvolvimento de software da organização. Deve-se descrever no instrumento convocatório ou no processo de software da organização as regras de uso, a forma de mensuração, o mecanismo de cálculo, o escopo de aplicação e eventuais recursos ou procedimentos padronizados para realização das medições, devendo-se assegurar:
12.4.1. Caso seja adotada a mensuração por pontos de função, a vinculação a roteiro de métricas que descreva o procedimento e as condições de contagem do tamanho funcional, observando preferencialmente o Roteiro de Métricas de Software do SISP.
12.4.2. Caso seja adotada a mensuração por linhas de código, a vinculação a guia ou roteiro de codificação de softwares que contenha as melhores práticas de codificação com vistas a assegurar uma codificação enxuta, limpa, clara e eficiente, observando as diretrizes de codificação segura publicadas pela SGD. Deve-se prever mecanismos automatizados de verificação do cumprimento das diretrizes constantes nesses guias ou roteiros.
12.4.3. Caso seja adotada a mensuração por história de usuário, deve-se vincular a roteiro de métricas que descreva o procedimento e as condições de contagem, padronização das histórias de usuário por meio de modelos (templates), sistema de pontuação para dimensionamento e terminologia comum a todas as áreas de negócio.
12.4.4. Caso seja adotada outra métrica, deve-se assegurar que o objeto de aferição está vinculado a entrega de produtos de software, evitando-se a utilização de métricas exclusivamente baseadas em esforço, além de vincular a roteiro de métricas que descreva o procedimento e as condições de contagem, sistema de pontuação para dimensionamento e terminologia comum a todas as áreas de negócio.
12.5. A Secretaria de Governo Digital do Ministério da Economia poderá publicar orientações complementares acerca do uso de métricas de software.
13. GERENCIAMENTO DE RISCOS
13.1. Independentemente da modalidade adotada, o órgão deve realizar o mapeamento de riscos da contratação detalhando a identificação, a classificação e o tratamento dos riscos associados às contratações públicas. De forma complementar, deve-se considerar os seguintes riscos a seguir, específicos para contratação de serviços de desenvolvimento, manutenção e/ou sustentação de softwares:
13.1.1. Capacidade Técnica inadequada dos profissionais:
a) Descrição: Durante a execução do contrato, pode-se receber profissionais sem as capacidades técnicas mínimas esperadas pela Contratante.
b) Sugestões para tratamento: Definir no Termo de Referência os perfis profissionais mínimos, incluindo requisitos de experiência e formação acadêmica. Prever que a contratada realize testes ou avaliações técnicas para aferir se o recurso humano a ser apresentado à contratante possui as capacidades técnicas esperadas. Deve-se definir critérios objetivos para verificação das capacidades.
13.1.2. Estabelecimento de critérios de remuneração e de níveis mínimos de serviço complexos e subjetivos:
a) Descrição: A definição dos critérios de remuneração e respectivos níveis de serviços devem estar associadas aos produtos efetivamente entregues ou a fatores determinantes da qualidade do software produzido ou sustentado. Porém, ao se definir indicadores desassociados do produto final, ou cuja dificuldade de mensuração é elevada ou altamente subjetiva (baseada em avaliação intuitiva ou meramente qualitativa sem parâmetros pré-definidos) pode-se comprometer o processo de aferição da qualidade dos produtos.
b) Sugestões para tratamento: Estabelecer métricas e indicadores claros e objetivos para aferição da produtividade e qualidade, vinculados - sempre que possível - a ferramentas automatizadas de aferição e extração de dados.
13.1.3. Complexidade na gestão de recursos humanos ou na contabilização da métrica adotada:
a) Descrição: A modalidade selecionada combinada com determinadas características da natureza da demanda ou da organização pode resultar em uma gestão de recursos complexa que demanda um esforço significativo, resultando em um gargalo na fiscalização ou no gerenciamento do contrato.
b) Sugestões para tratamento: A especificação e utilização de ferramentas automatizadas de gerenciamento e controle de demandas, bem como ferramentas de contabilização ou estimativa de métricas poderá mitigar o risco de sobrecarga nas funções de gerenciamento e fiscalização do contrato. O estabelecimento de processos otimizados de controle e gerenciamento possuem capacidade de reduzir a execução de atividades desnecessárias.
13.1.4. Desmobilização frequente de recursos:
a) Descrição: A desmobilização frequente de recurso pode ser provocada por deficiência de gestão por parte da contratada ou oriunda de fatores externos às ações da contratada, derivados de efeitos de mercado ou conjunturais. Contudo, independentemente das causas, há medidas que podem ser adotadas para mitigar os impactos desse risco.
b) Sugestões para tratamento: Prever métricas de equipes que estimule a contratada a manter mecanismos de gestão do conhecimento capazes de mitigar a dependência de funcionários específicos ou ainda reduza o tempo ou mitigue impactos decorrentes da troca de profissionais na execução das demandas.
13.1.5. Ociosidade da capacidade de trabalho alocada, em situações de baixa demanda:
a) Descrição: A interrupção no fluxo de demandas ou falhas na gestão de demandas à contratada poderá resultar em ociosidade na capacidade alocada, a depender da modalidade adotada.
b) Sugestões para tratamento: Realizar planejamento de consumo do contrato com vistas a evitar a ociosidade, por meio da realocação dos recursos em outros projetos previstos no contrato.
13.1.6. Variações no volume de demanda
a) Descrição: O aumento ou redução significativos no volume de demandas poderá resultar em desequilíbrio para a contratada (aumento significativo) ou uma situação de antieconomicidade para contratante (redução significativa).
b) Sugestões de tratamento: Avaliar modalidades baseadas em pagamento sob demanda, em detrimento de modalidades a preço fixo ou por alocação fixa de profissionais.
13.2. Além dos riscos apresentados nesta seção, cada órgão deverá realizar o mapeamento de riscos completo da contratação, conforme previsto na Instrução Normativa SGD/ME nº 1, de 2019.
14. DO REGISTRO DE PREÇOS
14.1. Quando for conveniente a contratação de serviços de desenvolvimento e manutenção de software para atendimento a mais de um órgão ou entidade, a participação de todos os órgãos integrantes na fase de Planejamento da Contratação é obrigatória.
14.2. O órgão gerenciador deverá incluir, no instrumento convocatório, cláusula que vede a adesão posterior por órgão não participante.
14.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.
14.3.1. A exceção a essa vedação aplica-se à adesão a atas publicadas pelo órgão central do SISP, desde que:
a) O órgão interessado comprove que o processo de desenvolvimento de software adotado pelo órgão central esteja formalizado, internalizado e em uso no órgão interessado;
b) O órgão interessado apresente um processo de planejamento da contratação explicitando, no mínimo: análise de custos entre a adesão e a condução de processo próprio, adequação do objeto registrado às reais necessidades do órgão, comprovação da similaridade entre os objetos a serem contratados e a demanda do órgão, memória de cálculo detalhada da estimativa do volume a ser contratado;
c) Seja avaliado e autorizado pelo órgão Central do SISP.
15. CONTRATAÇÃO DE SERVIÇOS DE MENSURAÇÃO DE SOFTWARE
15.1. A contratação de serviço especializado de apoio à mensuração de software deve seguir as orientações constantes nesta seção.
15.2. A empresa contratada para mensuração de software não deve atuar na prestação de serviços de desenvolvimento, manutenção ou sustentação de software objeto da atividade de mensuração.
15.3. A abertura da Ordem de Serviço especializado de métricas de software deve ser formalizada com a apresentação de um conjunto pré-definido de artefatos a serem definidos pelo órgão no Termo de Referência.
15.4. Como resultado do serviço devem ser apresentados, no mínimo, os seguintes produtos: o(s) documento(s) com os resultados das contagens e pareceres técnicos que sejam necessários para justificar e esclarecer os resultados contados.
15.4.1. Entende-se como documento da contagem e parecer técnico os artefatos que informem, pelo menos: o propósito da contagem, tipo da contagem, escopo da contagem, fronteira da contagem, data da contagem, planilha de contagem (gerada manualmente ou por sistema) com memória de cálculo, identificação das informações e artefatos recebidos e que embasaram a contagem, nome da equipe/contador envolvido(s), premissas adotadas pela equipe/contador baseadas nas informações recebidas e observações sobre os artefatos disponibilizados para a contagem.
15.5. O nível de detalhes e a quantidade dos artefatos definidos pelo órgão para as contagens deve ser dimensionado de modo a se equilibrar o propósito da contagem e o esforço que será investido na contagem.
15.6. Todos os resultados das contagens realizadas no órgão devem ser gerados e registrados em formato aberto, conforme a versão mais recente das especificações dos Padrões de Interoperabilidade de Governo Eletrônico (ePING).
15.7. O órgão deve definir o roteiro ou manual técnico e normativo que servirá de referência para a prestação do serviço de métricas de software no Termo de Referência.
15.8. O órgão deve validar os artefatos a serem entregues antes de realizar a abertura da ordem de serviço e submetê-los ao serviço de métricas de software.
15.9. Nos casos em que a empresa prestadora de serviços de desenvolvimento e manutenção de software discordar das contagens apresentadas pelo órgão, ela pode solicitar a abertura de uma avaliação da divergência a ser conduzida, preferencialmente, pelos Fiscais Técnicos dos contratos das empresas que discordaram das contagens.
15.10. A decisão final caberá ao gestor do contrato do serviço a ser remunerado com base na métrica aferida, devidamente justificada e subsidiada por parecer dos servidores técnicos que conduziram a avaliação da divergência.
15.11. Nos casos em que ficar comprovada a existência de erro na contagem apresentada, devem ser aplicadas as regras de garantia do serviço e demais sanções definidas no contrato para esse tipo de situação.
15.12. Recomenda-se que os órgãos elaborem mecanismos contratuais inibindo o acionamento reiterado, indevido ou protelatório dos questionamentos de divergência sem as devidas justificativas.
15.13. Deve-se evitar que os serviços de métrica de software sejam remunerados única e exclusivamente pela quantidade de métricas avaliadas, o que pode caracterizar conflito de interesse entre o órgão contratante e a contratada.
15.14. Para evitar um possível conflito de interesses na prestação desse serviço, recomenda-se que os órgãos avaliem formas alternativas de remuneração a exemplo de tabelas de pagamento escalonado por faixas de valores ou por meio de pagamento de valor mensal ou alocação de perfil profissional com base em produtividade de mensuração previamente estabelecida.
15.15. Caso o órgão opte pelo pagamento de um valor fixo mensal, é necessário vincular o pagamento mensal ao volume de demanda estimada e à produtividade da contratada. O órgão deve rever os valores contratados sempre que houver redimensionamento do volume de demanda.
15.16. Para a gestão dos contratos de serviços de métricas de software, recomenda-se a adoção dos seguintes controles, preferencialmente apoiados por ferramentas automatizadas capazes de armazenar, gerar relatórios e exportar seus dados em formato aberto:
a) Definição de um processo devidamente formalizado no órgão para a execução do serviço de métricas.
b) Todas a interações formais entre a empresa responsável pela contagem de Pontos de Função e quaisquer outras que sejam remuneradas por esta métrica devem ser intermediadas pelos fiscais dos respectivos contratos nos órgãos.
c) A empresa contratada para prestar o serviço de contagem deverá realizar suas contagens sem influência e sem fazer o uso das contagens apresentadas por outras empresas;
d) Armazenar base histórica com todas as contagens realizadas durante a execução dos serviços, de preferência em solução que permita consultas e geração de relatórios em meio eletrônico e adotando padrões abertos;
e) Manter atualizados os registros dos tamanhos funcionais em Pontos de Função dos softwares em uso no órgão (baseline) que tenham sido desenvolvidos internamente ou por serviços de desenvolvimento de software;
15.17. Recomenda-se a adequada capacitação dos servidores responsáveis pelas atividades de auditoria e aferição nas métricas de softwares adotadas pelo órgão, de modo a viabilizar a correta fiscalização e gestão dos contratos e serviços.
15.18. Recomenda-se que o órgão estabeleça critérios para se definir quando as contagens serão realizadas pela equipe interna de servidores, e quando realizada pelo serviço terceirizado de apoio à contagem de Pontos de Função. Tal definição visa à economia de recursos, evitando que todas as contagens sejam efetuadas a partir da contratação de serviços adicionais.
16. DISPOSIÇÕES FINAIS
16.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 relacionadas a contratações de bens e serviços de TIC.
16.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.
ANEXO II
MAPA DE PESQUISA SALARIAL DE REFERÊNCIA PARA SERVIÇOS DE DESENVOLVIMENTO E SUSTENTAÇÃO DE SOFTWARE
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 inexequibilidade 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 tabela a seguir:
|
Cód. Identificação do Perfil |
Descrição do Perfil |
Valor Salarial (R$) |
|
ARQSOF-01 |
Arquiteto de Software – Pleno |
R$ 10.498,73 |
|
ARQSOF-02 |
Arquiteto de Software – Sênior |
R$ 15.779,17 |
|
ATQ-01 |
Analista de Testes/Qualidade – Junior |
R$ 5.200,46 |
|
ATQ-02 |
Analista de Testes/Qualidade – Pleno |
R$ 6.550,32 |
|
ATQ-03 |
Analista de Testes/Qualidade – Sênior |
R$ 9.671,80 |
|
DESENV-01 |
Desenvolvedor de Software – Junior |
R$ 5.611,32 |
|
DESENV-02 |
Desenvolvedor de Software – Pleno |
R$ 8.622,30 |
|
DESENV-03 |
Desenvolvedor de Software – Sênior |
R$ 11.669,09 |
|
LDESENV |
Líder Técnico de Desenvolvimento |
R$ 13.389,21 |
|
ANR-01 |
Analista de Negócios/Requisitos Júnior |
R$ 5.838,48 |
|
ANR-02 |
Analista de Negócios/Requisitos Pleno |
R$ 7.407,49 |
|
ANR-03 |
Analista de Negócios/Requisitos Sênior |
R$ 9.664,58 |
|
ABI-01 |
Analista de BI Júnior |
R$ 6.683,31 |
|
ABI-02 |
Analista de BI Pleno |
R$ 9.967,63 |
|
ABI-03 |
Analista de BI Sênior |
R$ 12.816,73 |
|
ADADOS-02 |
Administrador de Dados Pleno |
R$ 7.816,50 |
|
ADADOS-03 |
Administrador de Dados Sênior |
R$ 9.946,67 |
|
SCRUM |
Scrum Master |
R$ 11.488,00 |
|
GEPRO |
Gerente de projetos de tecnologia da informação |
R$ 13.896,33 |
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, dados do Cadastro Geral de Empregados e Desempregados (CAGED) e dados da Relação Anual de Informações Sociais (RAIS) dos últimos 12 meses.
4. Para fins de estimativa do valor de referência da contratação, deve-se adotar um fator-k de 2,01. Admite-se a adoção de outro valor, desde que seja justificado com a respectiva memória de cálculo e não seja superior a 3.
5. Para fins de análise crítica da composição de preços unitários propostos no certame, deve-se considerar um Fator-k igual ou inferior a 3. Valores acima desse limite devem ser objeto de diligência e análise pormenorizada dos componentes ou das causas que levaram ao avanço do limite estabelecido como referência.
6. O custo total estimado de cada perfil é definido por meio do produto do valor salarial e o fator-k.
7. Os perfis profissionais constantes do mapa salarial possuem campos de atuação distintos, a exemplo do descrito a seguir:
|
Descrição do Perfil |
Descrição da Atuação |
|
Arquiteto de Software (Pleno e Sênior) |
Atua no apoio à tomada de decisão técnica em relação as diferentes arquiteturas de software, na análise e garantia do máximo de retorno esperado de uma arquitetura de software em termos de performance, segurança e relação custo/benefício, no acompanhamento da construção do software atuando proativamente na proposição de soluções técnicas, no diagnóstico de problemas e na superação de obstáculos relacionados à codificação e implementação dos frameworks e componentes. |
|
Analista de Testes/Qualidade (Junior, Pleno e Sênior) |
Atua na garantia da entrega de software com alta qualidade, planejando, implementando e automatizando os testes de software e de garantia de qualidade de software. O analista de Teste e Qualidade busca desenvolver planos de teste, criar casos de teste, escrever código de automação de teste e relatar resultados, avaliar a qualidade técnica e funcional dos produtos, identificar riscos e possíveis falhas relacionadas aos códigos e funcionalidades entregues. |
|
Desenvolvedor de Software (Junior, Pleno e Sênior) |
Atua na codificação, design de componentes, testes unitários, construção de aplicações, implementação e manutenção de software em busca de alta qualidade na aplicação de técnicas, normas e procedimentos atualizados de codificação e construção de software. O desenvolvedor de software busca escrever códigos de alta qualidade para atender as funcionalidades das partes interessadas assegurando otimização de recursos computacionais, segurança e desempenho. |
|
Líder Técnico de Desenvolvimento |
Atua na organização da entrega contínua dos produtos de software, conduzindo os times de desenvolvedores na aplicação das melhores práticas e técnicas de codificação, observando os padrões de projetos de software e metas a serem alcançadas na execução das sprints. |
|
Analista de Negócios/Requisitos (Junior, Pleno e Sênior) |
Atua na identificação, definição e documentação de processos de negócios e de requisitos de software a serem implementados. O analista de negócio busca assegurar uma ligação consistente entre as equipes de negócios e a equipe de desenvolvedores, facilitando a comunicação e auxiliando no aprofundamento do domínio do negócio objeto da implementação. Atua, também, na propositura de funcionalidades e na organização das informações, no comportamento e fluxo do processo da aplicação satisfazendo as necessidades de negócio declaradas e não declaradas. |
|
Analista de BI (Junior, Pleno e Sênior) |
Atua na modelagem de repositórios de dados de apoio à tomada de decisão, da implementação de processos de extração, transformação e carga de dados, no projeto e implementação de aplicações de automação e inteligência artificial, no processamento de dados massivos, na análise da qualidade de dados, na criação e evolução de painéis de business intelligence. |
|
Administrador de Dados (Pleno e Sênior) |
Atua na garantia da qualidade das estruturas dos metadados das soluções alinhadas aos padrões de arquitetura de dados da organização, apoia na organização da informação corporativa objeto das aplicações em desenvolvimento, na garantia da integração e na aplicação das melhores práticas de administração de dados corporativos. |
|
Scrum Master |
Atua na facilitação do processo de desenvolvimento ágil de software, orientando as equipes de desenvolvimento, acompanhando, identificando e eliminando impedimentos e promovendo o uso de padrões e melhores práticas ágeis. O scrum master busca garantir o bom funcionamento de processos e atividades ágeis e é responsável por liderar reuniões previstas no processo de desenvolvimento. |
|
Gerente de projetos de tecnologia da informação |
Atua na organização das atividades dos times, no monitoramento e solução de conflitos, no apoio à tomada de decisão técnica, na aplicação das melhores práticas de gerenciamento de projetos para assegurar a entrega de uma ou mais soluções em conjunto. |
ANEXO III
LISTA EXEMPLIFICATIVA DE ATIVIDADES INCLUÍDAS NO SERVIÇO DE SUSTENTAÇÃO POR PAGAMENTO FIXO MENSAL
1. 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.
2. O presente anexo apresenta lista exemplificativa de atividades a serem incluídas em serviços de sustentação para a modalidade de remuneração baseada em valor fixo mensal:
2.1. Manutenção corretiva: Consiste na eliminação de comportamentos do software que diferem de suas especificações ou que provoquem a interrupção inesperada de seu funcionamento;
2.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:
2.2.1. Atualização de versão de navegadores internet;
2.2.2. Atualização de versão de servidor de aplicação;
2.2.3. Atualização de versão de servidor de banco de dados;
2.2.4. Atualização de versão de linguagem de programação;
2.2.5. Atualização de versões de frameworks e/ou bibliotecas.
2.3. Manutenção cosmética localizada: consiste em 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:
2.3.1. Fontes de letra, cores, logotipos, mudanças de botões, alteração na posição de campos e texto na tela;
2.3.2. Mudanças de texto em mensagens do sistema, título de um relatório ou labels de uma tela de consulta;
2.3.3. Mudanças de texto estático em e-mail enviado pelo sistema;
2.3.4. Adição ou reestruturação de menus de navegação estáticos;
2.3.5. Adição ou reestruturação de Ajuda (help estático);
2.3.6. Criação, alteração ou exclusão de páginas estáticas.
2.4. 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;
2.5. Diagnóstico: Apoio à identificação e isolamento de falhas e problemas em potencial na execução do software;
2.6. 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;
2.7. Análise de viabilidade: verificação de viabilidade de desenvolvimento para soluções propostas ou problemas e oportunidades de melhoria apresentados;
2.8. 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;
2.9. Atendimento:
2.9.1. 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;
2.9.2. Execução de quaisquer procedimentos operacionais rotineiramente requeridos por sistema em função de suas regras de negócio ou forma de construção;
2.9.3. Outras atividades correlatas à sustentação.
ANEXO IV
EXEMPLO DE COMPOSIÇÃO E ALOCAÇÃO DE TIMES
1. Independente da modalidade adotada, deve-se especificar a formação da equipe que executará os serviços de desenvolvimento e manutenção de software, incluindo a identificação de perfis compatíveis com a natureza e especificidade do ambiente tecnológico da organização.
2. O presente anexo dispõe sobre diretrizes para composição e alocação de profissionais aos times ágeis, a saber:
2.1. Os times ágeis deverão ser declarados no início do projeto e eventuais trocas de profissionais deverão ser comunicadas à contratada.
2.2. A organização deve prever que 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 a aferição de indicadores de nível mínimo de serviço, a exemplo do Indicador de desmobilização de equipe (IDE) - descrito no Anexo I - capaz de monitorar e incentivar a manutenção dos membros das equipes durante a execução das sprints.
2.3. Deve-se prever que a violação das regras estabelecidas pela organização ensejará aplicação de sanções, conforme critérios de nível de serviço previamente estabelecidos.
2.4. O risco de ociosidade da capacidade de trabalho alocada instalada em situações de baixa demanda deve ser mapeado.
2.5. Deve-se prever, conforme tabela exemplificativa a seguir:
a) A composição mínima dos times, incluindo a identificação dos perfis profissionais e quantidades;
b) Regras para compartilhamento/alocação dos profissionais, obedecendo limites pré-estabelecidos;
|
Perfis Profissionais |
Quantidade |
Compartilhamento / Alocação |
|
Scrum Master |
1 |
Até 3 projetos |
|
Desenvolvedor Pleno |
2 |
Não pode ser compartilhado entre projetos |
|
Desenvolvedor Sênior |
1 |
Não pode ser compartilhado entre projetos |
|
Arquiteto Sênior |
1 |
Até 3 projetos |
|
Analista de Negócios/Requisitos Sênior |
1 |
Até 2 projetos |
|
Administrador/Projetista de Dados Sênior |
1 |
Até 5 projetos |
|
Analista de Testes/Qualidade Sênior |
1 |
Até 5 projetos |
ANEXO V
EXEMPLO DE DEFINIÇÃO DE PRONTO (CHECKLIST DE ADMISSÃO DO PRODUTO)
1. O presente anexo apresenta exemplos de critérios para admissão de um produto.
2. Esses critérios devem ser observados quando um produto é enviado para homologação por parte da contratada, para admissão à implantação em ambiente de homologação.
3. A Definição de Pronto é uma descrição formal do estado do incremento, quando ele atende aos níveis de serviço exigidos para o produto; todo o time ágil deve estar em conformidade com a definição de pronto.
4. A organização deve estabelecer critérios sem os quais o produto é rejeitado de imediato.
5. Para admissibilidade do produto: a organização deve estabelecer critérios objetivos para aceitação dos produtos e serviços prestados, a exemplo:
a) Código-fonte submetido ao controle de versões da contratada;
b) Existência de testes unitários e do Relatório de Testes;
c) 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);
d) Existência de arquivo para geração de Build (ex: Arquivo de projeto Maven);
e) Disponibilização de processos prontos para execução na ferramenta de CI/CD adotada, juntamente com a entrega e configuração de containers configurados pela ferramenta orquestração adotada;
f) Existência de Manual de Implantação, conforme modelo disponível no PDS;
g) Existência de Manual do Usuário, conforme modelo disponível no PDS.
6. Para aceitação da demanda: após realizar a inspeção do produto quanto à sua admissibilidade, a contratada deverá:
a) 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;
b) Executar testes unitários ou verificar relatórios de execução destes que possam envolver porções críticas do produto;
c) Realizar alguns testes funcionais, pelo menos nos principais fluxos do produto entregue.
7. Após a realização dos testes, a organização deve proceder a uma das ações a seguir:
a) 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;
b) 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;
c) 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.
8. A contratada deve registrar todos os aspectos relevantes. 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.
ANEXO VI
EXEMPLOS DE PLANILHAS DE CUSTOS E FORMAÇÃO DE PREÇOS POR MODALIDADE DE REMUNERAÇÃO
1. Orientações Gerais Sobre a Planilha de Custos e Formação de Preços
1.1. A Planilha de Custos e Formação de Preços é uma importante ferramenta que contribui para a análise crítica da composição dos preços unitários e total, com vistas a mitigar a assimetria de informações e auxiliar na eventual realização de diligência destinada a esclarecer ou a complementar a instrução do processo.
1.2. A Planilha de Custos e Formação de preços deve ser entregue pelo licitante durante a fase de recebimento de propostas e não se vincula à estimativa apresentada pelo órgão contratante na fase de planejamento da contratação.
2. Os componentes de custos que integram a planilha são:
2.1. Custo de Pessoal: Consolida todos os custos incorridos com a utilização de serviços de profissionais independente do regime ou modalidade de vínculo com a empresa. Deverá ser computado o somatório de todos os custos acrescidos dos encargos aprovisionados que afetem a composição do preço final ofertado, a exemplo da remuneração, encargos sociais, auxílios e benefícios dos recursos humanos relacionados à prestação do serviço.
2.2. Custos com software: Equivale ao somatório de todos os custos de disponibilização e utilização de recursos de software que integrarão a prestação dos serviços e que afetem a composição do preço final ofertado, a exemplo de ferramentas de automação, ferramentas de monitoramento, ferramenta de desenvolvimento, softwares de analytics ou de inteligência artificial, dentre outras.
2.3. Custos com recursos de computação: Equivale ao somatório de todos os custos de disponibilização e utilização de recursos físicos ou virtuais de computação que integrarão a prestação dos serviços e que afetem a composição do preço final ofertado, a exemplo de instâncias de computação, plataformas, middlewares, centrais de processamento de dados, entre outros recursos de computação.
2.4. Custos com equipamentos: Equivale ao somatório de todos os custos de disponibilização e utilização de equipamentos, utilitários e dispositivos diversos que serão utilizados diretamente na prestação dos serviços e que afetem a composição do preço final ofertado, a exemplo de equipamentos de comunicação, ferramentas de medição eletrônica, tokens, mídias, gerador de sinal, dentre outros.
2.5. Custos com serviços de informações: Equivale ao somatório de todos os custos de fornecimento de informações técnicas especializadas às equipes que prestam os serviços e que afetem a composição do preço final ofertado, a exemplo de plataformas digitais de fornecimento de conteúdo técnico especializado, serviços de mentoring, plataformas de suporte especializado, entre outros soluções de fornecimento de informações técnicas especializadas.
3. Contratação por Pontos de Função complementado por Horas de Serviço Técnico
3.1. Para contratações realizadas por meio da modalidade de remuneração baseada em Pontos de Função complementado por Horas de Serviço Técnico, deve-se utilizar como referência o modelo de planilha descrito a seguir, admitindo-se adaptações se necessário.
|
Contratação por Pontos de Função complementado por Horas de Serviço Técnico |
||||||||||
|
|
||||||||||
|
MODELO DE PLANILHA DE COMPOSIÇÃO DE CUSTOS E FORMAÇÃO DE PREÇOS DO PONTO DE FUNÇÃO |
||||||||||
|
|
||||||||||
|
Identificação da Licitação |
|
|||||||||
|
Nº do Processo |
|
|||||||||
|
Nº da Licitação |
|
|||||||||
|
Nome da Empresa |
|
|||||||||
|
CNPJ |
|
|||||||||
|
|
||||||||||
|
GRUPO XX - <descrição do grupo> |
|
|||||||||
|
ITEM XX - <descrição do Item> |
|
|||||||||
|
|
||||||||||
|
Componentes de Custo do Time |
||||||||||
|
Identificação do Perfil Profissional |
Salário (S) |
Custo Perfil (Cp = S x Fator-k) |
Custo Adicionais por perfil (Ca) |
Custo total por perfil (Ct = Cp + Ca) |
Taxa de Alocação (Ta) |
Alocação em horas (A = Ta x 160) |
Qtde. profissionais por perfil (Q) |
Horas por perfil (Hp = A x Q) |
Custo por Hora (Ch = Ct / 160) |
Custo Mensal do Perfil (Cm = A x Q x Ch) |
|
|
|
|
|
|
|
0 |
|
0 |
|
|
|
|
|
|
|
|
|
0 |
|
0 |
|
|
|
|
|
|
|
|
|
0 |
|
0 |
|
|
|
|
|
|
|
|
|
0 |
|
0 |
|
|
|
|
|
|
|
|
|
0 |
|
0 |
|
|
|
Total |
|
|
|
|
|
|
0 |
0 |
R$ - |
R$ - |
|
|
||||||||||
|
Produtividade Mínima Declarada no TR: |
|
hora/PF |
||||||||
|
Total de horas/Time/Mês: |
0 |
horas/mês |
||||||||
|
Produtividade Mínima esperada PF/Mês: |
|
PF/Mês |
||||||||
|
Custo mensal do Time: |
R$ - |
R$/Mês |
||||||||
|
|
||||||||||
|
Componentes de Custos Adicionais |
||||||||||
|
Descrição |
Valor Mensal |
|||||||||
|
Custos com software |
|
|||||||||
|
Custos com recursos de computação |
|
|||||||||
|
Custos com equipamentos |
|
|||||||||
|
Custos com serviços de informações |
|
|||||||||
|
Outros custos (especificar) |
|
|||||||||
|
Custos Adicionais por perfil/mês |
|
|||||||||
|
|
||||||||||
|
Custo por ponto de Função |
|
|||||||||
|
MODELO DE PLANILHA DE COMPOSIÇÃO DE CUSTOS E FORMAÇÃO DE PREÇOS DA HORA DE SERVIÇO TÉCNICO |
||||||||||
|
|
||||||||||
|
GRUPO XX - <descrição do grupo> |
|
|||||||||
|
ITEM XX - <descrição do Item> |
|
|||||||||
|
|
||||||||||
|
Componentes de Custo do Profissional de Referência |
||||||||||
|
Identificação do Perfil Profissional de Referência |
Salário (S) |
Custo Perfil (Cp = S x Fator-k) |
Custo Adicionais por perfil (Ca) |
Custo total por perfil (Ct = Cp + Ca) |
Taxa de Alocação (Ta) |
Alocação em horas (A = Ta x 160) |
Qtde. profissionais por perfil (Q) |
Horas por perfil (Hp = A x Q) |
Custo por Hora (Ch = Ct / 160) |
Custo Mensal do Perfil (Cm = A x Q x Ch) |
|
|
|
|
|
|
|
0 |
|
0 |
|
|
|
Total |
|
|
|
|
|
|
0 |
0 |
R$ - |
R$ - |
|
|
||||||||||
|
|
||||||||||
|
Componentes de Custos Adicionais |
||||||||||
|
Descrição |
Valor Mensal |
|||||||||
|
Custos com software |
|
|||||||||
|
Custos com recursos de computação |
|
|||||||||
|
Custos com equipamentos |
|
|||||||||
|
Custos com serviços de informações |
|
|||||||||
|
Outros custos (especificar) |
|
|||||||||
|
Custos Adicionais do perfil do profissional de referência/mês |
|
|||||||||
|
|
||||||||||
|
Custo da Hora de Serviço Técnico (Perfil profissional de Referência) |
|
|||||||||
4. Contratação por sprint executada.
4.1. Para contratações realizadas por meio da modalidade de remuneração baseada em Sprints executadas, deve-se utilizar como referência o modelo de planilha descrito a seguir, admitindo-se adaptações se necessário.
|
Contratação por Sprint executada |
||||||||||
|
|
||||||||||
|
MODELO DE PLANILHA DE COMPOSIÇÃO DE CUSTOS E FORMAÇÃO DE PREÇOS |
||||||||||
|
|
||||||||||
|
Identificação da Licitação |
|
|||||||||
|
Nº do Processo |
|
|||||||||
|
Nº da Licitação |
|
|||||||||
|
Nome da Empresa |
|
|||||||||
|
CNPJ |
|
|||||||||
|
|
||||||||||
|
GRUPO XX - <descrição do grupo> |
|
|||||||||
|
ITEM XX - <descrição do Item> |
|
|||||||||
|
|
||||||||||
|
Componentes de Custo do Time |
||||||||||
|
Identificação do Perfil Profissional |
Salário (S) |
Custo Perfil (Cp = S x Fator-k) |
Custo Adicionais por perfil (Ca) |
Custo total por perfil (Ct = Cp + Ca) |
Taxa de Alocação (Ta) |
Alocação em horas ( A = Ta x 160) |
Qtde. profissionais por perfil (Q) |
Horas por perfil (Hp = A x Q) |
Custo por Hora (Ch = Ct / 160) |
Custo Mensal do Perfil (Cm = A x Q x Ch) |
|
|
|
|
|
|
||||||
|
|
|
|
|
|
||||||
|
|
|
|
|
|
||||||
|
|
|
|
|
|
||||||
|
|
|
|
|
|
||||||
|
Total |
|
|
|
|
||||||
|
|
||||||||||
|
Componentes de Custos Adicionais |
||||||||||
|
Descrição |
Valor Mensal |
|||||||||
|
Custos com software |
|
|||||||||
|
Custos com recursos de computação |
|
|||||||||
|
Custos com equipamentos |
|
|||||||||
|
Custos com serviços de informações |
|
|||||||||
|
Outros custos (especificar) |
|
|||||||||
|
Custos Adicionais por perfil/mês |
||||||||||
|
|
||||||||||
|
Custo por Sprint |
|
|||||||||
5. Contratação de Serviços de Sustentação de Software por preço fixo mensal
5.1. Para contratações realizadas por meio da modalidade de remuneração baseada em Sustentação de Software por preço fixo mensal, deve-se utilizar como referência o modelo de planilha descrito a seguir, admitindo-se adaptações se necessário.
|
Contratação de Serviços de Sustentação de Software por preço fixo mensal |
||||||||||
|
|
||||||||||
|
MODELO DE PLANILHA DE COMPOSIÇÃO DE CUSTOS E FORMAÇÃO DE PREÇOS |
||||||||||
|
|
||||||||||
|
Identificação da Licitação |
|
|||||||||
|
Nº do Processo |
|
|||||||||
|
Nº da Licitação |
|
|||||||||
|
Nome da Empresa |
|
|||||||||
|
CNPJ |
|
|||||||||
|
|
||||||||||
|
GRUPO XX - <descrição do grupo> |
|
|||||||||
|
ITEM XX - <descrição do Item> |
|
|||||||||
|
|
||||||||||
|
Componentes de Custo do Time |
||||||||||
|
Identificação do Perfil Profissional |
Salário (S) |
Custo Perfil (Cp = S x Fator-k) |
Custo Adicionais por perfil (Ca) |
Custo total por perfil (Ct = Cp + Ca) |
Taxa de Alocação (Ta) |
Alocação em horas ( A = Ta x 160) |
Qtde. profissionais por perfil (Q) |
Horas por perfil (Hp = A x Q) |
Custo por Hora (Ch = Ct / 160) |
Custo Mensal do Perfil (Cm = A x Q x Ch) |
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|||
|
Total |
|
|
||||||||
|
|
||||||||||
|
Componentes de Custos Adicionais |
||||||||||
|
Descrição |
Valor Mensal |
|||||||||
|
Custos com software |
|
|||||||||
|
Custos com recursos de computação |
|
|||||||||
|
Custos com equipamentos |
|
|||||||||
|
Custos com serviços de informações |
|
|||||||||
|
Outros custos (especificar) |
|
|||||||||
|
Custos Adicionais por perfil/mês |
||||||||||
|
|
||||||||||
|
Custo Fixo por Mês |
||||||||||
6. Contratação de Serviços de desenvolvimento e/ou manutenção e/ou sustentação de Software por alocação de profissionais de TIC.
6.1. Deve-se adotar, o modelo de planilha de custos e formação de preços definida pela Instrução Normativa Seges/MP nº 5, de 2017, ou posterior, individualizada por perfil previsto, incluindo as orientações relacionadas ao preenchimento e análise, admitindo-se adaptações ao contexto de serviços de Tecnologia da Informação amparadas pela legislação vigente, conforme templates disponibilizados na página gov.br pela Secretaria de Governo Digital.