TERMO DE REFERÊNCIA

1. Identificação do Processo Processo: nº XXXXXXXXX

Rito na modalidade Pregão Eletrônico: nº XX/2020

2. Objeto:

Contratação de serviços especializados em desenvolvimento e sustentação de software, em conformidade com a metodologia adotada na Companhia de Tecnologia da Informação de Minas Gerais – Prodemge, aderente à dinâmica de trabalho baseada nos métodos, comportamentos e mentalidade “ágeis”.

A quantidade total de UST (Unidade de Serviço Técnico) é de 92.928 (noventa e dois mil, novecentos e vinte e oito).

3. Detalhamento do objeto

A Prodemge possui metodologia própria fundamentada nos métodos ágeis de acordo com as melhores práticas de mercado, adequada às suas necessidades e especificidades. Esta metodologia deve ser seguida pelo Prestador de Serviços, em conformidade com as diretrizes determinadas pela Prodemge.

A metodologia de desenvolvimento de software da Prodemge, fundamentada nos métodos ágeis, propõe minimamente as seguintes fases:

a) Ideação

b) Inception

c) Sprints (iterações) com duração entre 2 a 4 semanas

d) Pré-refinamento

e) Refinamento

f) Sprint Planning

g) Build

h) Sprint Review

i) Sprint Retrospective

j) Transição

O detalhamento de tais fases está descrito no item 4.2.13 deste Termo de Referência.

Versão dez/2020

A contratação do serviço deverá seguir o processo de emissão de ordens de serviço sob demanda, dimensionadas em Unidade de Serviço Técnico – UST (unidade de mensuração de esforço para a execução de um serviço que envolva prioritariamente esforço humano) conforme descrito neste Termo de Referência e seus anexos.

4. Especificação Técnica

4.1 Processo de Desenvolvimento de Software

Para atender ao objeto do serviço, o Prestador de Serviços contratado deverá conhecer e seguir a metodologia adotada pela Prodemge, observando as premissas da etapa correspondente ao serviço solicitado.

A figura 1 do item 4.2 apresenta o modelo de trabalho a ser adotado.

4.2 Fluxo do Processo de Desenvolvimento de Software

Figura 1 - Fluxo Geral de Trabalho

4.2.1 O desenvolvimento de novas soluções de software se inicia na etapa nomeada Ideação onde, através de técnicas de Design Thinking, são levantadas as necessidades do cliente, gerando a primeira versão do Backlog do produto. Esta etapa será realizada apenas pela Prodemge.

4.2.2 A partir da Inception, etapa onde é feita uma imersão nas necessidades, mapeando a jornada do usuário, as macro histórias e o MVP (Mínimo Produto Viável) é definido, o Prestador de Serviços já poderá ser envolvido, conforme a necessidade da Prodemge.

4.2.3 A partir do resultado da Inception, inicia-se o fluxo do Scrum, com todos os seus eventos e artefatos, conforme detalhado no item 4.2.13.

4.2.4 As Sprints (iterações) terão duração entre 2 a 4 semanas, a ser definido na fase de Planning. A duração da Sprint definida permanecerá até o fim do projeto. O Product Owner (PO) definirá, para cada Sprint, um “objetivo da Sprint” e, a partir deste objetivo, serão definidas, na reunião de planejamento da Sprint (Planning), as Histórias de usuário (se a demanda for para desenvolvimento) ou itens de trabalho (se a demanda for para sustentação de sistemas e puderem ser planejadas) que deverão ser entregues ao final daquela Sprint. Os itens de trabalho de atendimento rápido (demandas de manutenção que não podem esperar para entrar no fluxo de uma Sprint), no caso de sustentação de sistemas, seguirão o fluxo descrito no item 4.4 - Fluxo de Sustentação/Manutenção de Software, deste Termo de Referência.

4.2.5 Caso o Prestador de Serviços finalize as Histórias ou Itens planejados antes do prazo definido para a Sprint corrente, poderá solicitar autorização dos fiscais de contrato (ou gestor responsável pelo projeto) para iniciar a execução de outras Histórias/Itens que já estejam preparadas e priorizadas no Backlog.

4.2.6 Os serviços de desenvolvimento e sustentação dos sistemas deverão adotar as boas práticas de engenharia de software para garantir a qualidade do incremento que será entregue, a exemplo de:

a) Refactoring (melhorar o código-fonte sem alterar comportamento);

b) Teste unitário;

c) Inspeção de código;

d) Integração contínua;

e) Padrões arquiteturais de projeto;

f) Modularização das funcionalidades;

g) Baixo acoplamento e alta coesão das funcionalidades;

h) Reusabilidade de componentes.

i) Execução de testes automatizados.

4.2.7 As tecnologias e ferramentas utilizadas para o desenvolvimento e sustentação dos sistemas deverão observar a Plataforma de Desenvolvimento e Arquitetura de Referência da Prodemge, detalhados no Anexo VI - Ambiente Tecnológico.

4.2.8 O serviço contratado será mensurado em Unidade de Serviço Técnico - UST.

4.2.9 O Prestador de Serviços poderá atuar em todas as etapas do fluxo apresentado na Figura 1 - Fluxo geral de trabalho, com exceção da fase de Ideação. A participação do Prestador de Serviços em cada etapa será definida logo no início da execução do serviço, em um encontro de alinhamento entre as partes (reunião de kick-off do projeto).

4.2.10 O processo de gestão contratual abrange as atividades internas à Prodemge, que tratam do adimplemento técnico do contrato e têm por finalidade verificar se a Prestadora de Serviços entrega as demandas de acordo com o que foi acordado. É no âmbito desse processo que é homologado o faturamento das demandas e aplicados abatimentos em fatura e sanções à empresa. A execução de uma demanda fora dos padrões de SLA acordados gera, automaticamente, abatimentos em fatura e sanções, as quais incidem diretamente sobre o faturamento da empresa quanto à referida demanda.

4.2.11 A metodologia de desenvolvimento de software vigente poderá ser alterada durante a execução do contrato, a critério da Prodemge, e o Prestador de Serviços deverá se adequar a ela em um prazo de até 30 (trinta) dias corridos.

4.2.12 Todos os artefatos desenvolvidos pelo Prestador de Serviços durante a execução do projeto serão de total direito de propriedade da Prodemge, sendo vedado uso para qualquer fim ou comercialização por parte da Prestadora de Serviço.

4.2.13 Detalhamento do Fluxo de Processo

	Evento	Responsável	Descrição	Entregável	Perfis envolvidos	Ferramentas envolvidas
Ideação		PRODEMGE	Etapa que tem como objetivo capturar e priorizar necessidades, olhando-as com maior clareza e profundidade, imergindo no problema para compreender o contexto e a perspectiva do cliente. Este trabalho irá nortear a proposição de soluções aderentes ao negócio específico, gerando o Backlog do produto.	▪ Backlog do Produto	PRODEMGE: ▪ PO ▪ Analista ▪ Arquiteto de Software ▪ Facilitador	Não se aplica
	Inception	PRODEMGE e Prestador de Serviços	Etapa que tem como objetivo refinar as necessidades que foram levantadas na Ideação, envolvendo o cliente e a equipe técnica, para detalhamento das features que o produto deverá contemplar. As features são priorizadas e organizadas em MVP (Minimum Viable Product).	▪ Backlog do Produto ▪ Jornada de usuário ▪ Desenho da arquitetura ▪ Estimativa de UST’s para esta etapa	PRODEMGE: ▪ PO ▪ Analista ▪ Arquiteto de Software ▪ Facilitador Prestador de Serviços: ▪ Scrum Master ▪ Líder Técnico ▪ Arquiteto de Software ▪ Analista	▪ Miro ou Mural ▪ Trello

Evento

Responsável

Descrição

Entregável

Perfis envolvidos

Ferramentas envolvidas

Sprint Zero

PRODEMGE e

Prestador de Serviços

Etapa pós Inception em que o Time prepara o mínimo necessário para iniciar o primeiro Build do produto.

Nesse momento, o Time configura os ambientes, refina um pouco mais o Modelo de Banco de Dados e realiza uma POC arquitetural implementando uma ou mais histórias. Também devem ser realizados o pré-refinamento e o refinamento como preparação para a sprint 1.

▪ Desenho da arquitetura

▪ Modelo de dados inicial

▪ Identidade visual

▪ Guia de usabilidade

PRODEMGE:

▪ PO

▪ Analista

▪ Arquiteto de Software

▪ Analista

DevSecOps Prestador de Serviços:

▪ UX

▪ Arquiteto de Software

▪ Analista

▪ Analista de Dados

▪ Líder Técnico

▪ Desenvolvedores

▪ Trello

▪ Jenkins

▪ Git

▪ Artifactory

▪ Maven

▪ Junit

▪ Sonar

▪ IDEs de desenvolvimento

▪ SGBD

Pré- Refinamento (Sprint x +1)

PRODEMGE e

Prestador de Serviços

Etapa de refinamento e preparação dos itens de Backlog do produto selecionados pelo PO e que podem ser executados nas próximas Sprints.

Enquanto uma sprint está em execução, esta etapa ocorre em paralelo para preparar os itens de Backlog para a próxima sprint (x

+1).

▪ Backlog do Produto

▪ Histórias de usuário

▪ Itens de trabalho

▪ Protótipos

▪ Mapa de Histórias de usuários

▪ Modelo de dados

▪ Desenho da arquitetura

▪ Identidade visual

▪ Guia de usabilidade

PRODEMGE:

▪ PO

▪ Analista

▪ Arquiteto de Software

Prestador de Serviços:

▪ UX

▪ Arquiteto de Software

▪ Analista

▪ Analista de Dados

▪ Líder Técnico

▪ Miro ou Mural

▪ Trello

▪ InVision / Adobe XD

▪ Enterprise Architecture

Refinamento

PRODEMGE e

Prestador de Serviços

Evento em que o PO apresenta para todo o Time as Histórias de usuário ou Itens do Trabalho de usuário que deseja para a Sprint e os critérios de aceite. O UX apresenta a experiência de usuário por meio dos protótipos (já elaborados no pré refinamento) e o Time esclarece todas as dúvidas.

▪ Histórias de usuário

▪ Itens de trabalho

▪ Critérios de aceite

▪ Protótipos

▪ Mapa de Histórias de usuários

PRODEMGE:

▪ PO

▪ Analista

▪ Arquiteto de Software

▪ Analista

DevSecOps Prestador de Serviços:

▪ Scrum Master

▪ UX

▪ Analista

▪ Analista de Dados

▪ Líder Técnico

▪ Desenvolvedores

▪ Miro ou Mural

▪ Trello

▪ InVision / Adobe XD

	Evento	Responsável	Descrição	Entregável	Perfis envolvidos	Ferramentas envolvidas
Sprint Planning		PRODEMGE e Prestador de Serviços	Evento onde é feito o planejamento de uma Sprint. O propósito da Sprint Planning é alinhar o time de desenvolvimento ou sustentação e o Product Owner sobre o “quê” e como será executado o trabalho dentro da Sprint.	▪ Backlog da Sprint ▪ Definição da Sprint ▪ Termo de abertura da OS com Estimativas de UST’s	PRODEMGE: ▪ PO ▪ Analista ▪ Arquiteto de Software ▪ Analista DevSecOps Prestador de Serviços: ▪ Scrum Master ▪ UX ▪ Arquiteto de Software ▪ Analista ▪ Analista de Dados ▪ Líder Técnico ▪ Desenvolvedores	▪ Trello
	Build	PRODEMGE e Prestador de Serviços	Período em que o Time realiza o trabalho definido na Planning, de acordo com o fluxo de execução da Sprint.	▪ Código-fonte ▪ Script dos testes unitários ▪ Evidências de testes ▪ Roteiro de teste ▪ Nota de liberação	PRODEMGE: ▪ PO ▪ Analista ▪ Arquiteto de Software ▪ Analista DevSecOps Prestador de Serviços: ▪ UX ▪ Scrum Master ▪ Arquiteto de Software ▪ Analista ▪ Analista de Dados ▪ Líder Técnico ▪ Desenvolvedores	▪ Trello ▪ Jenkins ▪ Git ▪ Artifactory ▪ Maven ▪ Junit ▪ Sonar ▪ IDEs de desenvolvimento
		PRODEMGE e Prestador de Serviços
Reunião Diária		PRODEMGE e Prestador de Serviços	Evento diário de 15 minutos para verificar o andamento do trabalho no Build, onde o time responde: “o que fiz”, “o que vou fazer”, “os impedimentos que tenho”, “o que o time entregou”, “o que o time irá entregar hoje” e “quais os impedimentos para concluir a próxima entrega”. É o momento em que o time atualiza a gestão à vista.	▪ Burndown (atualizado) ▪ Gestão à vista atualizado	PRODEMGE: ▪ PO ▪ Analista ▪ Arquiteto de Software ▪ Analista DevSecOps Prestador de Serviços: ▪ Scrum Master ▪ UX ▪ Arquiteto de Software ▪ Analista ▪ Analista de Dados ▪ Líder Técnico ▪ Desenvolvedores	▪ Trello

Evento	Responsável	Descrição	Entregável	Perfis envolvidos	Ferramentas envolvidas
Sprint review	PRODEMGE e Prestador de Serviços	Evento em que o time apresenta o que foi alcançado durante a Sprint, validando todo o trabalho com o PO e gerando o aceite.	▪ Apresentação dos resultados ▪ Termo de aceite da Sprint ▪ Termo de encerramento da OS com a quantidade de UST’s realizadas.	PRODEMGE: ▪ PO ▪ Analista ▪ Arquiteto de Software ▪ Analista DevSecOps Prestador de Serviços: ▪ Scrum Master ▪ UX ▪ Arquiteto de Software ▪ Analista ▪ Analista de Dados ▪ Líder Técnico ▪ Desenvolvedores	▪ Trello
Sprint retrospective	PRODEMGE e Prestador de Serviços	Evento que ocorre ao final de uma Sprint com o objetivo de identificar o que funcionou bem, o que pode ser melhorado e quais ações serão tomadas para melhorar as próximas Sprints.	▪ Plano de ações	PRODEMGE: ▪ PO ▪ Analista ▪ Arquiteto de Software ▪ Analista DevSecOps Prestador de Serviços: ▪ Scrum Master ▪ UX ▪ Arquiteto de Software ▪ Analista ▪ Analista de Dados ▪ Líder Técnico ▪ Desenvolvedores	▪ Trello ▪ Ferramenta free de Retrospectiva
Transição	PRODEMGE e Prestador de Serviços	Liberação do incremento do produto no ambiente definido no planejamento da Sprint.	▪ Nota de liberação	PRODEMGE: ▪ Arquiteto de Software ▪ Analista DevSecOps Prestador de Serviços: ▪ Arquiteto de Software ▪ Líder Técnico	▪ Jenkins ▪ Git ▪ Artifactory ▪ Maven ▪ Junit ▪ Sonar ▪ IDEs de desenvolvimento

4.2.14 Homologação

As Sprints serão homologadas pelo Product Owner (PO), após a entrega pelo Prestador de Serviços, nos seguintes termos:

a) O Prestador de Serviços deverá implantar o sistema (funcionalidades desenvolvidas na

Sprint) no ambiente de homologação da Prodemge.

b) O aceite das entregas será definido pelos critérios estabelecidos nas histórias de usuários ou Itens de trabalho e conforme qualidade de código definida na esteira de integração

contínua, descrita no item 11 - Critérios de Aceitabilidade do Objeto, deste Termo de Referência.

4.2.15 Artefatos

O Prestador de Serviços deverá entregar, junto ao código-fonte, todos os artefatos produzidos e atualizados, durante ou após a execução da Sprint de desenvolvimento ou de sustentação ou correção de Chamados de erro, tais como:

a) Guia de usabilidade (Identidade visual, Guia de estilos, etc.)

b) Protótipos de média fidelidade

c) Histórias de usuário (conceito INVEST)

d) Itens de trabalho descritos

e) Backlog técnico (decisões arquiteturais, estratégias de implementação, débito técnico)

f) Backlog da Sprint

g) Definição da Sprint

h) Modelo de dados

i) Scripts de criação e população de banco de dados

j) Script dos testes unitários

k) Evidências de testes

l) Nota de liberação

m) Termo de aceite da Sprint

n) Plano de ações da retrospectiva

o) Documento de estudo de código fonte

4.2.15.1 A relação de artefatos a serem entregues pelo Prestador de Serviços, não se limita àqueles citados no item 4.2.15, alíneas (a) a (o). Todo e qualquer artefato produzido deverá ser entregue à Prodemge.

4.2.15.2 As estimativas de esforço, em UST´s, para a elaboração desses artefatos estão definidas no Anexo V - Repertório de USTs.

4.3 Métrica - UST e Atividades

4.3.1 Definição da Métrica

4.3.1.1 A Prodemge, visando garantir uma métrica que tecnicamente assegure que as atividades executadas sejam devidamente mensuradas e permita um controle técnico e financeiro do contrato, definiu que a unidade de medida a ser utilizada neste Termo de Referência será a Unidade de Serviço Técnico – UST.

4.3.1.2 A métrica UST é comumente utilizada em contratos que envolvem diferentes serviços de TIC com complexidade variada, permitindo o controle e a precificação de serviços preestabelecidos, assim como a mensuração do esforço em situações ou problemas previamente conhecidos.

4.3.1.3 As atividades realizadas e os entregáveis correspondentes, definidos por meio de Ordens de Serviços (OS), serão dimensionados em UST e deverão se consolidar em forma de entregáveis específicos, consubstanciados em software funcionando - quando aplicáveis - observando os critérios de aceite e demais condições definidas antes do início da execução da OS.

4.3.1.4 As atividades e entregáveis estão detalhados e dimensionados no Anexo V - Repertório de UST’s.

4.3.1.5 As atividades previstas no Repertório de UST’s poderão ser revisadas a qualquer momento, durante a execução do contrato, a critério da Prodemge, sendo passíveis de alterações, inclusões ou exclusões. Portanto, o Repertório apresenta um conjunto não exaustivo de atividades previstas.

4.3.1.6 Nos casos em que o Repertório de UST´s não ofereça estimativa em que possa ser utilizada na medição de esforço requerido por determinada demanda, a Prodemge e o Prestador de Serviços buscarão o consenso, utilizando os seguintes critérios, sucessivamente:

a) Analogia com outros itens do Repertório de UST´s;

b) Descrição detalhada dos passos necessários à execução da atividade, estimando o esforço de cada um dos passos, de forma que fique demonstrado o esforço necessário da atividade por inteiro.

4.3.1.7 O resultado advindo do processo referenciado no item 4.3.1.5 poderá, a critério da Prodemge, ser incorporado ao Repertório de UST´s para utilização em demandas futuras.

4.3.1.8 A Prodemge é a responsável final por definir a dimensão de determinada atividade em UST. As justificativas do Prestador de Serviços serão consideradas e respondidas, ainda que não acatadas.

4.4 Fluxo de Sustentação/Manutenção de Software

4.4.1 As atividades de resolução de chamados de erro, que demandem rápida atuação, deverão seguir o fluxo apresentado no item 4.5.5, figura 3 – Fluxo de chamados de erro, deste Termo de Referência.

4.4.2 Os chamados de erro poderão ser resolvidos pelo Squad, sempre que possível, dentro do processo de trabalho adotado no desenvolvimento ágil, desde que não haja prejuízo para as entregas acordadas para aquela Sprint. Caso não seja possível, a critério da Prodemge, os entregáveis previstos para a Sprint deverão ser repactuados entre a Prodemge e o Prestador de Serviços.

4.4.2.1 A remuneração das Ordens de Serviços abertas para chamados de erros deverá ocorrer em consonância com o Anexo V- Repositório de UST´s.

4.4.3 As atividades de sustentação planejadas seguirão o mesmo processo de trabalho adotado no desenvolvimento ágil, sendo essas atividades distribuídas em itens de backlog e planejadas em iterações (sprints), conforme definido no item 4.5.4.5, figura 2 - Fluxo de processo e desenvolvimento/sustentação de sistemas, deste Termo de Referência.

4.4.4 Ficará a critério da Prodemge definir quais ritos e atividades serão executadas, que levará em consideração a natureza do contexto da demanda.

Exemplo: uma Sprint planejada apenas com demandas de correção poderá exigir ou não o rito de Refinamento.

4.4.5 Ciente da dificuldade de se obter proficiência e eficiência em códigos-fonte escritos por terceiros, a Prodemge irá demandar o Estudo do Código-Fonte pelo Prestador de Serviços, com o intuito de promover a qualidade e a agilidade das manutenções nos sistemas da mesma e formar um colaborador-estudado.

4.4.5.1 A depender do tamanho e da complexidade do sistema, tal esforço será demandado por prazo variável de 1 (um) a até 20 (vinte) dias úteis de estudo de

código, tendo como limite de critério de faturamento 140 (cento e quarenta) USTs por funcionário capacitado.

4.4.6 Este Estudo do Código-Fonte deve gerar dois entregáveis:

a) Detalhamento completo por escrito; e

b) Uma apresentação presencial ou por video conferência sobre o sistema, suas funcionalidades e sua arquitetura tecnológica, incluindo dados técnicos e de regras de negócio.

4.4.7 O que se pretende medir é a capacidade dos profissionais do Prestador de Serviços em sustentar o sistema de maneira competente e eficiente.

4.4.8 O documento e a apresentação entregues pelo Prestador de Serviços serão avaliados por uma equipe técnica e negocial da Prodemge e obterão uma nota indicando “satisfatório” ou “insatisfatório”, com fundamentação.

4.4.8.1 Os conteúdos do documento escrito e da apresentação serão definidos pela Prodemge no momento da prestação do serviço, em função de cada sistema a ser sustentado.

4.4.9 A Prodemge pagará o valor contratado pelo estudo do código fonte apenas se ambos os entregáveis obtiverem a nota de “satisfatório”.

4.4.9.1 No caso de obtenção de “insatisfatório”, o Prestador de Serviços poderá readequar os entregáveis e apresentá-los novamente, em um prazo de até 10 (dez) dias úteis.

4.4.9.2 O custo de retificação, citado no item 4.4.8.1, correrá por conta do Prestador de Serviços.

4.4.9.3 Chama-se de “colaborador-estudado” o colaborador do Prestador de Serviços que passou pelo mencionado Estudo de Código-Fonte e obteve grau “satisfatório” nos entregáveis solicitados, apresentação e relatório.

4.4.10 O Estudo será contratado para toda a equipe do Prestador de Serviços alocada para sustentação na Prodemge, de acordo com as responsabilidades sobre sistemas atribuídas a cada funcionário.

4.4.11 Haja vista o investimento feito pela Prodemge com o Estudo de Código-Fonte, o Prestador de Serviços terá maior condições de prover, com qualidade, a manutenção dos sistemas. No entanto, tal investimento também traz responsabilidades.

4.4.11.1 O Prestador de Serviços deverá fazer uma gestão do conhecimento efetiva, de maneira que afastamentos e desligamentos de colaboradores-estudados não signifiquem perda do conhecimento.

4.4.11.2 Caso um dos colaboradores-estudados do Prestador de Serviços deixe de fazer parte da equipe de colaboradores que atendem à Prodemge, o Prestador de Serviços fica obrigado a arcar com um novo Estudo do Código-Fonte para o colaborador que for substituí-lo, para cada Estudo que o colaborador-estudado havia realizado;

4.4.11.3 A Prodemge não pagará por esses Estudos adicionais e não sofrerá quaisquer ônus, já que o investimento em um dos colaboradores da empresa já foi feito. O novo colaborador deverá, igualmente, apresentar os entregáveis do Estudo e passar pela mesma avaliação mencionada acima (documentos utilizados anteriormente podem ser reutilizados, com as devidas atualizações).

4.4.11.4 A perda do colaborador-estudado, sem sua pronta substituição por outro colaborador que possa, no prazo máximo de 20 (vinte) dias úteis, passar em avaliação e tornar-se colaborador-estudado, enseja ressarcimento à Prodemge no valor integral do Estudo “perdido” com a saída do colaborador-estudado.

4.4.11.5 Em eventual troca de colaborador-estudado por parte do Prestador de Serviços, a Prodemge não poderá ficar “descoberta” tecnicamente quanto aos sistemas em sustentação. O Prestador de Serviços deverá realocar outro profissional capacitado mesmo que provisoriamente, a fim de não impactar o serviço em execução de sustentação dos sistemas.

4.4.12 Vencidas as etapas de avaliação e aceite dos entregáveis do “colaborador-estudado”, a remuneração será feita em “UST’s” de acordo com o definido na Ordem de Serviço.

4.4.12.1 Para efeito de cálculo da Ordem de Serviço, será usada como base a proporção de 7 (sete) UST’s por dia de estudo do código-fonte.

4.4.13 Após o estudo e a aprovação do colaborador-estudado, este estará apto para dar manutenção nos sistemas designados pela Prodemge, incluindo atendimento de chamados de erro do cliente, em horário comercial.

4.4.14 O chamado de erro aberto pelo cliente será repassado ao analista do Prestador de Serviços pela Prodemge, via ferramenta de TIC utilizada, conforme fluxo apresentado no item 4.5.5, e

seu descumprimento poderá decorrer em abatimento em faturas por descumprimento dos níveis de serviços.

4.5 Processo de Gestão

4.5.1 O Processo de Gestão irá observar o completo adimplemento administrativo e técnico do contrato, verificando se o Prestador de Serviços entregou as demandas com qualidade e nos prazos acordados, cumprindo todos os SLA´s – Service Level Agreement – definidos neste Termo de Referência.

4.5.2 O programa mentalidade ágil da Prodemge está amparado nas melhores práticas de mercado e a gestão das demandas a serem abertas ao Prestador de Serviços dará início a dois processos em paralelo:

I. gestão contratual;

II. gestão do desenvolvimento de software.

4.5.3 A gestão contratual será de responsabilidade da área de Gestão de Controle de Níveis de Serviço da Prodemge, que buscará a garantia do seu integral cumprimento, verificando se o Prestador de Serviços entregou as demandas definidas dentro do seu prazo de execução e com a qualidade prevista em cada Ordem de Serviço (OS).

4.5.3.1 É no âmbito desse processo que é homologado o faturamento das demandas e aplicados os abatimentos em faturas e sanções ao Prestador de Serviços.

4.5.3.2 A execução de uma demanda fora do prazo e da qualidade prevista na OS gerará, automaticamente, abatimentos na fatura e sanções, as quais incidem diretamente sobre o faturamento da empresa referente à Ordem de Serviço que ampara tal demanda.

4.5.3.3 A área de Gestão e Controle de Níveis de Serviços da Prodemge será responsável pela gestão do contrato e autorização dos pagamentos dos serviços prestados, mediante ateste técnico das áreas responsáveis da Prodemge.

4.5.3.4 A prestação dos serviços deverá ocorrer nas dependências físicas da Prodemge, xxx xx Xxxxx, 0000, Lourdes ou na Cidade Administrativa. Para tanto, a Prodemge

deverá fornecer apenas o espaço físico e os pontos de rede e energia elétrica necessários para a acomodação da equipe do Prestador de Serviços.

4.5.3.5 A critério da Prodemge, os serviços poderão ser prestados remotamente. Neste caso, o Prestador de Serviços deverá se submeter à Política de Segurança da Informação da Prodemge.

4.5.3.5.1 O acesso remoto ao ambiente tecnológico da Prodemge deverá ser feito por meio do uso da infraestrutura de VPN – Virtual Private Network, da Prodemge.

4.5.3.5.2 Toda e qualquer infraestrutura de conectividade ao servidor de VPN da Prodemge será de responsabilidade do Prestador de Serviços.

4.5.3.6 As atividades de gestão sobre as equipes alocadas pelo Prestador de Serviços não serão remuneradas diretamente.

4.5.3.6.1 Somente são remuneráveis os entregáveis e atividades, conforme especificado na metodologia da Prodemge e no Anexo V - Repertório de UST’s.

4.5.3.7 Demais detalhes sobre fluxo de gestão de contrato estão explicitados no Anexo IV – Modelo de Gestão e Volumetria.

4.5.4 A gestão de desenvolvimento de software abrange as atividades de desenvolvimento de sistemas desempenhadas pelo Prestador de Serviços em conjunto com a Prodemge, seguindo orientações da metodologia ágil proposta pela Prodemge. A critério da Prodemge, este modelo de gestão poderá ser ajustado ao longo do tempo.

4.5.4.1 Cada Time deve ser organizado conforme o modelo de time multidisciplinar denominado Squad, contemplado pelos perfis elencados abaixo:

1. Product Owner (PO)

2. Scrum Master (SM);

3. Analista UX;

4. Analista de Requisitos e Testes;

5. Arquiteto de Software;

6. Analista de dados;

7. Líder Técnico;

8. Analista DevSecOps;

9. Desenvolvedor.

4.5.4.2 O Squad será formado no início da execução do serviço, onde serão definidos quais papéis do Prestador de Serviços deverão atuar naquela demanda.

4.5.4.3 Os papeis de Scrum Master, Arquiteto de Software, Analista UX e Analista de Dados poderão ser alocados, mediante anuência da Prodemge, em mais de um Squad.

4.5.4.4 Caso a equipe alocada em determinado Squad fique ociosa, o Prestador de Serviços, com a anuência da Prodemge, poderá realoca-la em outros projetos, o que não o exime da sua obrigação de repasse de conhecimento para os profissionais substitutos envolvidos no contrato.

4.5.4.5 Fluxos de trabalho e desenvolvimento/ sustentação de sistemas

TERMO DE REFERÊNCIA

Figura 2 - Fluxo de processo e desenvolvimento/sustentação de sistemas

Versão dez/2020

TERMO DE REFERÊNCIA

4.5.5 Fluxos de atendimento de chamados de erro

1 - Cliente abre chamado via ferramenta de TIC

6 - Cliente recebe a solução valida o atendimento e finaliza o chamado.

Caso o cliente não valide o atendimento, retorna para o passo 2

2 - Responsável Prodemge analisa, classifica e envia chamado para o Prestador de Serviços

5 - Responsável Prodemge valida o atendimento e envia para o cliente.

Caso a Prodemge não valide a solução, retorna para o passo 3

3 - Analista do Prestador de Serviços recebe o chamado com classificação baixa e inicia o atendimento ou procura Prodemge para avaliar possibilidade de reclassificação

4 - Analista do Prestador de Serviços soluciona o atendimento, registra a solução e envia o chamado para validação da Prodemge

Figura 3 - Fluxo de chamados de erro

5. SLA e Penalidades

5.1. Indicadores de SLA

5.1.1.Quantidade de entregas por Ordem de Serviço

Indicador de Itens de Backlog Entregues (IBE): Índice de itens de backlog (histórias de usuário e/ou itens de trabalho) entregues e que atenderam aos critérios de aceite definidos para o produto solicitado, de acordo com os entregáveis planejados para a Sprint e refletidos na Ordem de Serviço.

IBE = (Itens de Backlog Entregues / Total de Itens de Backlog da Sprint) * 100

IBE	A partir de 80%	A partir de 70% e abaixo de 80%	A partir de 60% e abaixo de 70%	Abaixo de 60%
REDUTOR	Não se aplica	4%	6%	8%

O cálculo do pagamento se dará conforme fórmula abaixo:

PG = (UST – REDUTOR), onde:

Versão dez/2020

PG é o valor a ser pago;

UST é a quantidade de Unidades de Serviço Técnico entregues multiplicado pelo fator de ajuste de complexidade, quando cabível;

REDUTOR é o percentual de abatimento a ser aplicado conforme a faixa do IBE calculado.

Simulação de aplicação da Fórmula de Pagamento:

Uma sprint composta de 12 itens de backlog, totalizando 1200 USTs (100 UST’s por item de backlog), com 3 itens de backlog não entregues/aceitos, gera um pagamento de:

IBE = [9/12] * 100 = 75%

PG = 900 – (4% (900)) = 864 USTs (redução de 4% conforme tabela) 5.1.2.Quantidade de chamados de erro por sistema em sustentação/manutenção

Índice de chamados por sistema em sustentação/manutenção transferidos pela Prodemge ao Prestador de Serviços, por meio da Ferramenta de TIC da Companhia, em horário comercial, ou seja, em regime de atendimento 8 x 5, atendidos no prazo definido.

5.1.2.1. Objetivo: Garantir que o chamado para a sustentação/manutenção de sistemas aberto seja colocado em atendimento pelo analista responsável do fornecedor dentro do prazo definido, em no máximo 1 (uma) hora, dentro do horário comercial, em dias úteis.

5.1.2.2. Premissas: Para apuração de SLA, todos os chamados abertos para o sistema em sustentação/manutenção devem ser registrados na Ferramenta de TIC, dentro do horário comercial.

5.1.2.3. Evidências: Relatório de Evidência de Chamados Atendidos pelo TDA (Tempo de Atendimento), com informações extraídas da Ferramenta de TIC da Prodemge.

5.1.2.4. O SLA de atendimento representa a relação do tempo transcorrido entre o momento em que o chamado entra na caixa de tarefas do grupo solucionador do Prestador de Serviços, na Ferramenta de TIC da Prodemge, e o momento em que o responsável pelo atendimento muda o status do chamado para “em atendimento” a fim de executar a solução.

5.1.2.5. A apuração será iniciada a partir da data de publicação da Ordem de Serviço.

Acordo de Nível de Serviço: 90%.

Prazo: retorno de atendimento em até 1 hora útil, em horário comercial.

Periodicidade da apuração: Mensal.

Onde,

PIR - Percentual de chamados colocados em atendimento no prazo

TIP - Total de chamados colocados em atendimento no prazo

TIR - Total de chamados transferidos pelo analista Prodemge na Ferramenta de TIC

PIR = (TIP / TIR) x 100

PIR	Abaixo de 90,00%
Redutor	4% (quatro por cento) do valor da Ordem de Serviço específica de sustentação/manutenção

5.1.3.Índice de solução de chamados de erro para sistemas em sustentação/manutenção

Objetivo: Garantir que os chamados para a sustentação/manutenção de sistemas abertos sejam solucionados pelo Prestador de Serviços dentro dos prazos estabelecidos no quadro 1.

5.1.3.1. Todos os chamados serão repassados ao Prestador de Serviços, por meio da ferramenta de TIC da Prodemge, com classificação de complexidade “baixa”.

5.1.3.2. O Prestador de Serviços deverá solucioná-los no tempo definido no quadro 1. Caso o Prestador de Serviços, ao fazer a análise do chamado de erro, não o classifique como de complexidade baixa, terá até 2 (duas) horas para comunicar ao responsável/gestor pelo Sistema na Prodemge, para proceder ao processo de reclassificação do chamado de erro, se for o caso.

5.1.3.3. Caso o Prestador de Serviços não formalize o seu entendimento de classificação do chamado de erro dentro do prazo estabelecido, o chamado será automaticamente contabilizado como de complexidade baixa para apuração do SLA.

5.1.3.4. Caso o chamado de erro seja reclassificado em conjunto com a Prodemge como de complexidade média ou alta, o Prestador de Serviços deverá cumprir os prazos correspondentes à nova classificação, estabelecidos no quadro 1.

5.1.3.5. Caso o chamado de erro seja reclassificado pela Prodemge como Projeto, o Prestador de Serviço deverá apresentar um planejamento com prazo para solução da demanda a ser aprovado pela Companhia. Neste caso será aberta uma nova Ordem de serviço (OS) específica para esta demanda.

5.1.3.6. Caso não haja consenso no processo de reclassificação entre a Prodemge e o Prestador de Serviços, prevalecerá o entendimento da Prodemge.

Complexidade	Tempo de solução	Definição
Baixa	Até 4 horas úteis	Chamado de erro onde a solução é conhecida e a atuação é imediata.
Média	De 4 a 20 horas úteis	Chamado de erro onde a solução é conhecida, mas o tempo para a solução é maior do que 4 horas úteis.
Alta	De 20hs a 40 hs úteis	Chamado de erro onde a solução não é conhecida de imediato e o tempo para a solução é maior do que 20 horas úteis.
Alta	Acima de 40hs úteis	Tratar como Projeto e estabelecer prazo.

Quadro 1 – Complexidade x Tempo de solução dos chamados de erro

Acordo de Nível de Serviço: 90%.

Prazo: conforme nível de complexidade estabelecido no quadro 1.

Periodicidade da apuração: Mensal.

Onde,

PCS - Percentual de chamados solucionaos dentro do prazo

TCS - Total de chamados solucionados dentro do prazo

TCT - Total de chamados transferidos pela Prodemge ao Prestador de Serviços por meio da Ferramenta de TIC

CAC – Chamados de complexidade alta, quando classificados como Projeto

PCS = (TCS / (TCT – CAC)) x 100

PCS	Abaixo de 90,00%
Redutor	4% (quatro por cento) do valor da Ordem de Serviço específica de sustentação/manutenção

5.1.4.Participações em reuniões, Encontros e Ritos

5.1.4.1. A ausência de profissionais do Prestador de Serviços convocados pela Prodemge para participarem dos “Encontros” e “Ritos” ensejará abatimento na fatura da respectiva Ordem de Serviço de igual valor ao que a Prestadora seria remunerada, caso comparecesse. Tais “Encontros”, “Ritos” e estimativas em UST, por hora de reunião por participante, estão definidos no Anexo V – Repertório UST´s.

5.1.4.2. Caso a quantidade de profissionais ausentes do Prestador de Serviços implique o cancelamento do “Encontro” ou “Rito”, o valor a ser abatido na fatura da respectiva Ordem de Serviço será equivalente ao total de UST´s, ou seja, 1 (uma) hora de reunião para toda a equipe convocada.

5.2. Disposições Gerais

5.2.1.O Prestador de Serviços, ao assinar o contrato, assumirá o compromisso, perante a Prodemge de seguir as metas de qualidade na prestação dos serviços previstas neste Termo de Referência.

5.2.2.O Prestador de Serviços será responsável pelo cumprimento dos índices estabelecidos, que serão monitorados pela área de Gestão e Controle de Níveis de Serviços durante todo o prazo de vigência do contrato de forma a garantir a qualidade dos serviços prestados.

5.2.3. O descumprimento dos níveis de serviços estabelecidos neste documento motivará a aplicação de abatimentos compensatórios.

5.2.4.O valor correspondente ao abatimento será deduzido do valor total da fatura gerado pela soma das Ordens de Serviços abertas naquele mês, nos termos definidos no SLA deste Termo de Referência para todos os critérios estabelecidos para a prestação dos serviços, que não sejam causadas por:

5.2.4.1. Caso fortuito ou força maior (entende-se como caso fortuito como sendo qualquer ocorrência que não seja proveniente de qualquer ação humana);

5.2.4.2. Operação inadequada, falha ou mau funcionamento na arquitetura tecnológica disponibilizada pela Prodemge, quando isso interferir na produtividade do Prestador de Serviços.

5.2.4.3. Impedimento, por qualquer motivo, do acesso de pessoal técnico do Prestador de Serviços às dependências da Prodemge, onde os serviços serão prestados, respeitados os critérios estabelecidos no item 17.2;

5.2.5.O abatimento dos valores por quebra de SLA na fatura não tem natureza de sanção administrativa, mas sim de remuneração proporcional por desempenho, e visa a compensar o prejuízo da Prodemge com a não entrega pelo fornecedor.

5.2.6.Os redutores serão aplicados independente do critério de aceite da entrega, definido no item 11 deste Termo de Referência.

5.2.7.Será considerado chamado de erro qualquer evento que acarrete ou possa acarretar a interrupção dos sistemas ou a redução de sua qualidade.

5.2.8.Todos os chamados de erro deverão ser registrados na Ferramenta de TIC da Prodemge.

5.2.8.1. O registro do chamado de erro se dará por quaisquer evidências de sua ocorrência, tais como reclamação registrada pelo Cliente na Central de Atendimento, relato da falha ao Prestador de serviços, dentre outros. A partir do encaminhamento do chamado pela Prodemge para o Prestador de Serviços se dará o início da contagem de prazos para resolução.

5.2.8.1.1. Quando o chamado sofrer reclassificação pela Prodemge e Prestador de Serviços, o tempo de solução terá o seu início a partir do seu reecaminhamento.

5.2.9.Procedimento para aplicação de abatimentos nas faturas

5.2.9.1. O Prestador de Serviços será notificado quando violar o acordo de nível de serviço com a Prodemge, para que apresente justificativas para tal violação.

5.2.9.2. A notificação poderá ser feita por meio eletrônico, como e-mail ou descrita através de documentação formal assinada entre ambas as partes.

5.2.9.3. Uma vez apresentada a justificativa, o gestor do projeto apresentará manifestação e o

Product Owner (PO) decidirá sobre a aplicação do abatimento.

5.2.9.4. O termo de encerramento da Sprint contemplará o detalhamento da entrega pelo Prestador de Serviços, explicitando o abatimento a ser aplicado.

5.2.10. Incidência de defeitos

5.2.10.1. Ao final de cada Sprint, no termo de encerramento, será documentada a quantidade de defeitos ainda em aberto aceitos pelo PO, a serem corrigidos conforme o prazo e critérios acordados na Review.

5.2.10.2. Defeitos de criticidade baixa poderão ser aceitos durante a construção do release, porém o Prestador de Serviços deverá saná-los até a finalização do prazo e critérios acordados na Review.

5.2.10.3. Ao final desse prazo, se ainda houver defeitos a serem corrigidos, o Prestador de Serviços estará automaticamente descumprindo o contrato de execução dos serviços, podendo sofrer sanções administrativas previstas no contrato.

6. Justificativa da contratação

A Companhia de Tecnologia da Informação do Estado de Minas Gerais, norteada pelos princípios e melhores práticas de Governança Corporativa, desenvolveu seu planejamento estratégico cujas ações visam à protagonização da empresa em soluções de Tecnologia da Informação e Comunicação – TIC que objetivam apoiar o Governo de Minas Gerais em suas políticas públicas, que em última instância, promovem a melhoria das condições de vida do cidadão mineiro.

Nesse contexto, a Prodemge criou o programa Mentalidade Ágil, que se fundamenta num modelo de trabalho em que as equipes atuam de forma colaborativa e interdisciplinar para tomar decisões e encontrar soluções na realização do trabalho.

Os princípios dessa cultura ágil aumentam a capacidade da empresa de atender às reais necessidades dos órgãos do Governo, principalmente no serviço de desenvolvimento de software, promovendo entregas parciais que antecipam a geração de valor e possibilitam eventuais ajustes com o menor impacto possível. Nesse sentido, o atendimento ágil é um diferencial e proporciona valor agregado aos serviços prestados pelos Órgãos do Governo ao cidadão.

Com o objetivo de amparar tais ações, a Prodemge deu início ao processo de especificação para contratação de serviços especializados em desenvolvimento e sustentação de software, em conformidade com metodologia aderente à dinâmica de trabalho baseada nos métodos, comportamentos e mentalidade “ágeis”, atualmente adotada pela Companhia.

Considerando que os órgãos do Governo de Minas Gerais estão procurando otimizar cada vez mais os seus processos de trabalho baseados em Sistemas de Informação com o intuito de obter maiores e melhores resultados com os recursos disponíveis, a Prodemge tem assumido importante papel neste cenário por meio da evolução dos seus processos de desenvolvimento de software tornando-os mais ágeis, adaptáveis e escaláveis.

Para suprir o crescente volume de demandas por desenvolvimento de software e evitar impactos nos processos de negócio de competência dos órgãos do Estado para a sociedade, faz-se necessário investir na estruturação da capacidade da Prodemge de entrega de serviços de desenvolvimento e sustentação de software e garantir assim o atendimento às necessidades de soluções informatizadas do Estado.

Parte do processo desta estrutura permeia, imprescindivelmente, o suprimento das carências de seu quadro próprio de profissionais para a execução dos serviços de desenvolvimento e sustentação de software. A Prodemge entende ser importante somar à sua capacidade interna de desenvolvimento e sustentação de software, que já adota as melhores práticas de mercado de desenvolvimento no modelo ágil, os serviços de um prestador externo para que seja capaz de cumprir sua missão institucional e melhoria dos serviços prestados.

Neste Termo de Referência e seus anexos são definidos processos, práticas e ferramentas técnicas de desenvolvimento e sustentação de sistemas que definem a metodologia comumente conhecida como "metodologia ágil". Essa metodologia tem ganhado mais espaço tanto no mercado privado quanto nos entes governamentais devido às suas características de entrega de resultados (sistema disponível para utilização) em menor intervalo de tempo e de ser mais flexível às eventuais alterações de escopo por parte do cliente.

Importante ressaltar que a continuidade da prestação de serviços de desenvolvimento e sustentação de software para os órgãos do Governo é preocupação perene da Prodemge, sobretudo porque a interrupção da prestação dos serviços públicos causaria transtornos internos (administrativos) e externos, aos cidadãos.

Nesse sentido, entende-se que a contratação, por meio de licitação na modalidade Pregão Eletrônico, de um Prestador de Serviços de desenvolvimento e sustentação de software é condição imperiosa para a continuidade dos serviços prestados pela Prodemge aos Entes do Estado.

6.1. Justificativa para a solução proposta e a adoção da métrica UST – Unidade de Serviço Técnico

O modelo de contratação adotado se ampara nas melhores práticas de prestação de serviços de desenvolvimento e sustentação de software de mercado e é baseado nas metodologias e práticas ágeis. Este modelo de contratação vem ao encontro do momento de transformação digital que permeia a Prodemge atualmente, uma vez que uma das ações de seu planejamento estratégico é justamente o “Programa Mentalidade Ágil”, que alinhado às diretrizes traçadas para a nova gestão da Prodemge, fundamenta um modelo de trabalho em que as equipes atuam de forma colaborativa e interdisciplinar para tomar decisões e encontrar soluções de forma ágil na realização do trabalho e entrega dos serviços. Os princípios dessa cultura ágil aumentam a capacidade de atender às reais necessidades por sistemas de informação dos órgãos do Governo, promovendo entregas parciais que antecipam a geração de valor aos serviços prestados pelo Estado aos cidadãos.

Visando garantir uma métrica que tecnicamente assegure que as atividades executadas sejam devidamente mensuradas e que permita um controle técnico e financeiro do contrato, a Prodemge optou por utilizar a Unidade de Serviço Técnico – UST, que equivale a 1 (uma) hora de esforço especializado, não individualizado e corresponde à unidade genérica usada para dimensionar de forma unitária cada uma das tarefas demandadas pela Prodemge no escopo das Ordens de Serviço – OS. A contratação se baseará no dimensionamento do volume total de UST´s considerando as demandas da Prodemge e a licitação resultará na oferta do valor de uma única UST.

6.2. Justificativa da modalidade de licitação

Conforme disposto no art. 78 do Regulamento Interno de Licitações e Contratos - RILC da Prodemge, a aquisição de bens e de serviços comuns independentemente do valor, deve ser feita, por meio do rito da modalidade pregão, preferencialmente eletrônico, nos termos do art. 4º da Lei nº 14.167, de 10 de janeiro de 2002.

Por serviços comuns entende-se aqueles cujos padrões de desempenho e qualidade podem ser objetivamente definidos no objeto do edital, por meio de especificações usuais praticadas no mercado (art. 3º, § 1º, do Decreto Estadual nº 44.786/2008).

Uma vez que foi possível neste Termo de Referência descrever os padrões de desempenho e qualidade que se espera do serviço prestado por meio de especificações usuais praticadas no mercado sem prejuízo para a compreensão daqueles que atuam no ramo, conforme explicitado neste TR e seus anexos, a utilização do pregão eletrônico torna-se imperiosa.

7. Visita ou Vistoria Técnica

A licitante poderá vistoriar as dependências da Prodemge onde serão executados os serviços com o objetivo de inteirar-se das condições e grau de dificuldade existentes, de modo a serem observadas e conferidas suas características e peculiaridades mediante prévio agendamento, posto que não serão aceitas alegações posteriores quanto ao desconhecimento dessas informações.

Local: PRODEMGE – Xxx xx Xxxxx, 0000, Xxxxxxx, Xxxx Xxxxxxxxx / XX. Contato para agendamento:

xxxxxx Email xxxxx

Telefone: xxxxx

A vistoria poderá ocorrer até 2 (dois) dias úteis antes do horário determinado para início da sessão.

A visita deverá ser realizada por profissional habilitado da interessada e será acompanhada por representante da PRODEMGE. A declaração comprobatória da vistoria efetuada, que deverá ter sido preferencialmente elaborada com antecedência pelo licitante em conformidade com o modelo constante do Anexo I deste Termo de Referência, será assinada por funcionário designado pelo fiscal deste contrato.

7.1. Conforme entendimento estabelecido pelo Tribunal de Contas da União, é facultado ao proponente deixar de realizar a vistoria técnica no local da prestação do serviço de engenharia desde que forneça, anexa à proposta comercial, uma declaração de que conhece as condições construtivas presentes no ambiente da prestação do serviço em conformidade com o modelo constante no Anexo II.

8. Qualificação Técnica

A documentação relativa à qualificação técnica consistirá em:

8.1. A licitante deverá apresentar Atestado de Capacidade Técnica fornecido por pessoa jurídica, de direito público ou privado, que comprove a execução, de forma satisfatória de serviços de Desenvolvimento de Software integralmente utilizando metodologia ágil. Este atestado, ou conjunto de atestados, deve ter, no mínimo, 45.000 UST´s de serviço prestados (ou quantidade equivalente em outra métrica de mercado) em um período de 12 meses.

8.1.1.O Atestado, ou conjunto de atestados, deverá conter de forma explícita que a licitante atendeu ou tem atendido aos níveis de serviços acordados.

8.1.2.Caso o atestado seja emitido em métrica diferente da definida no item 8.1.1 do Termo de Referência, a licitante deverá demonstrar a equivalência da métrica do atestado com a métrica UST.

8.1.3.Os atestados apresentados deverão conter, no mínimo, as seguintes informações:

a) Dados da empresa licitante: nome, CNPJ;

b) Dados da empresa cliente: nome, razão social, CNPJ, endereço;

c) Data de início e término dos serviços,

d) Descrição dos serviços realizados com dados que permitam o amplo entendimento dos trabalhos realizados e que permitam identificar a compatibilidade e semelhança com o objeto da licitação;

e) Dados do emissor do atestado: nome e contato;

f) Local, data de emissão e assinatura do emissor.

8.1.4. A Prodemge poderá realizar diligências para dirimir quaisquer dúvidas necessárias, na ausência de alguma destas informações, ou necessidade de esclarecer alguma informação prestada.

8.2. Comprovação que possui em seu corpo técnico, profissionais que atendam todos os requisitos definidos no

Anexo III – Perfil dos Profissionais, na quantidade mínima definida no quadro 1 abaixo:

PERFIS	QTDE. TOTAL ESTIMADA		QTDE. MÍNIMA EXIGIDA *
Scrum Master (SM)		3	2

Analista UX		3	1

Analista de Requisitos e Testes		7	2

Arquiteto de Software	2		1
Analista de dados	2		1
Líder Técnico	7		2
Desenvolvedor	20		6
TOTAL DE PROFISSIONAIS	44		15
(*) (para comprovação de qualificação técnica no início do contrato)

Quadro 1 – Quantidade de profissionais x perfil

8.2.1.A empresa deverá comprovar a qualificação técnica de todos os profissionais que prestarão serviços durante a execução do contrato.

8.2.1.1. A licitante deverá apresentar junto à documentação técnica exigida na habilitação, declaração afirmando que no momento da homologação, caso seja a vencedora do certame, irá comprovar a qualificação técnica da quantidade mínima de profissionais exigida conforme no Quadro 1 do item 8.2.

8.2.1.2. A comprovação da qualificação técnica do quantitativo restante de profissionais deverá ser providenciada ao longo da execução do contrato, de acordo com a necessidade da Prodemge para a formação das Equipes / Squads.

8.2.2.Para assegurar que os profissionais alocados para a execução do serviço sejam qualificados tecnicamente, deverão ser entregues, para efeitos de comprovação, os currículos e documentação de qualificação dos profissionais a serem alocados na prestação do serviço.

8.2.3.A quantidade total estimada de profissionais conforme Quadro 1 - Quantidade estimada e exigida de perfis profissionais - poderá sofrer ajustes de até 15% (quinze por cento) para mais ou para menos.

8.2.4. A capacitação dos profissionais deve ter base em programas de formação, em diligência de capacidade técnica e certificações oficiais, oferecendo indícios de capacidade técnica mínima para atender às complexidades especificadas neste Termo de Referência.

8.2.4.1. Para comprovação do nível de escolaridade exigido, será considerada a cópia do diploma ou do certificado de conclusão do curso emitidos por entidades de ensio reconhecidas pelo MEC.

8.2.4.2. A comprovação das certificações deverá ser feita através da apresentação de cópia dos certificados emitidos pelos órgãos competentes.

8.2.5.Para comprovação do vínculo empregatício do profissional com o Prestador de Serviços, serão considerados:

a) Carteira de Tabalho e Previdência Social (CTPS).

b) Ficha de Registro de Empregado (RE), devidamente registrada.

c) Contrato vigente de prestação de serviços entre a empresa e a pessoa física do profissional.

d) Estatuto ou contrato social do Prestador de Serviços (no caso de sócio da empresa).

8.2.6. O processo de comprovação técnica conforme item 8.2 será devidamente seguido para os possíveis casos de substituição de profissionais durante a execução do contrato.

8.3. DAS PROPOSTAS COMERCIAIS

0.0.0.Xx propostas comerciais deverão apresentar preço unitário e global, impressas em papel timbrado, em uma via, assinada pelo representante legal, sem emendas, acréscimos, borrões, rasuras, ressalvas, entrelinhas ou omissões, observado o modelo constante do Anexo VIII – Proposta Comercial.

0.0.0.Xx atividades de liderança sobre as equipes alocadas no contrato não serão remuneradas diretamente. Somente são remuneráveis os entregáveis, conforme especificado na metodologia da Prodemge e no Repertório de UST’s. A empresa participante do processo de licitação deverá prever os custos indiretos dos entregáveis e incluí-los na precificação da UST.

8.3.3.Para assegurar que os profissionais alocados para a execução do serviço sejam qualificados, do ponto de vista financeiro, deverá ser comprovado que a remuneração desses profissionais esteja de acordo com a referência salarial de mercado detalhada no ANEXO IX – Referência Salarial.

8.3.3.1. Para o quantitativo mínimo exigido de profissionais, conforme quadro 1 do item 8.2, o Prestador de Serviços deverá enviar toda a documentação comprobatória que comprove o vinculo empregatício do profissional com o Prestador de Serviço em conjunto com a Planilha de Custos e Formação de Preços considerando os salários dos profissionais exigidos.

8.3.3.2. A comprovação exigida no item 8.3.3.1 para o quantitativo restante de profissionais deverá ser providenciada ao longo da execução do contrato, de acordo com a necessidade da Prodemge para a formação das equipes / Squads.

8.3.4.Os licitantes deverão considerar o Anexo IX - Referência Salarial no momento da formulação das propostas comerciais.

8.3.4.1. O referido anexo será utilizado para aferição da exequibilidade da proposta por parte da Prodemge.

8.3.5.O processo de comprovação conforme item 8.3.3 será devidamente seguido para os possíveis casos de substituição de profissionais durante a execução do contrato.

9. Subcontratação

Não será aceita a subcontratação para a prestação dos serviços a serem prestados, objeto deste Termo de Referência.

10.Local de entrega/execução

10.1. Os serviços serão prestados nas dependências físicas da Prodemge em Belo Horizonte/MG, nos endereços abaixo:

a) Xxx xx Xxxxx 0000, Xxxxxx Xxxxxxx

b) Cidade Administrativa, Xxxxxxx Xxxx Xxxx. Xxxxx XX, 0.000 Xxxxx Xxxxx. XX/XX - XXX 00000-000

10.2. A Prodemge fornecerá apenas o espaço físico, mobiliário e os pontos de rede e energia elétrica necessários para a acomodação da equipe do Prestador de Serviços. Entretanto, a Prodemge obedecerá aos aspectos legais que permeiam o período de pandemia.

10.3. A Prodemge poderá, a seu critério, definir para o Prestador de Serviços o regime de teletrabalho.

10.3.1. Neste caso, será de responsabilidade do Prestador de Serviços o fornecimento aos seus profissionais, dos equipamentos necessários à execução dos serviços (notebook, monitores, periféricos, mobiliário e outros), bem como o fornecimento de toda a infraestrutura de hardware e software de acordo com as tecnologias especificadas pela Prodemge.

11.Critérios de aceitabilidade do objeto

11.1. Os processos de remuneração do Prestador de Serviços por parte da Prodemge serão feitos por meio de validação das entregas previstas para as Ordens de Serviço – OS e visam a garantir a entrega de valor agregado ao projeto, seja este por entrega de software funcionando, ou atividade realizada pela participação ativa e efetiva do Prestador de Serviços, como por exemplo, atividades de UX Design (elaboração de mapa de jornada do usuário, construção de protótipo funcional), ou documentação e artefatos resultantes de estudo de código.

11.1.1. A remuneração será feita embasada no Repertório de UST, sendo que todas as atividades que constarem da respectiva Ordem de Serviço em questão devem estar referenciadas no referido Repertório.

11.2. Os aceites e pagamentos serão avaliados da seguinte forma:

a) Aceite: Ordem de serviço sem pendências, encaminhada para faturamento.

b) Aceite com ressalvas: Ordem de serviço com pendências, porém em comum acordo entre Prodemge e Prestador de Serviços, será aceita e encaminhada para faturamento, desde que as pendências sejam registradas no backlog para serem sanadas, sem ônus para a Prodemge.

I. Neste caso, os descontos por eventuais quebras de SLA´s deverão ser debitados da fatura referente a OS.

c) Não aceite: Ordem de serviço com pendências não aceitas pela Prodemge, gerando automaticamente quebra de SLA e passível, caso aplicável, de sanções administrativas. Neste caso, o pagamento referente a esta OS não será executado e as pendências deverão ser registradas no backlog, não havendo prejuízo ao cronograma pré-estabelecido ao projeto

11.3. No caso específico em que houver cancelamento do projeto por parte do Cliente e/ou Prodemge, o Prestador de Serviços receberá o pagamento referente às atividades executadas, mesmo se essas não findarem em código funcionando.

11.3.1. Exemplo: protótipo feito e o projeto ser cancelado. O Prestador de Serviços receberá por essa atividade, de acordo com o que foi definido no Anexo V - Repertório de USTs.

11.3.2. O cancelamento do projeto por parte do Prestador do Serviço de forma unilateral acarretará em descumprimento contratual sujeito às sanções cabíveis.

12.Orçamento estimado da aquisição / contratação Conforme preço de referência constante no processo. 13.Avaliação de Custo / Classificação orçamentária Natureza orçamentária: 7.1.13.18.004.02

14.Prazo de execução/entrega:

Conforme definido nas Ordens de Serviço

15.Vigência do Contrato:

12 (doze) meses

16.Condições de Pagamento:

16.1. Processo de faturamento

16.1.1. O ciclo de faturamento praticado para a prestação dos serviços será mensal.

16.1.2. O documento de cobrança dos serviços será entregue até o dia 25 (vinte e cinco) do mês subsequente ao da efetiva prestação dos serviços e seu vencimento será programado em até 30 (trinta) dias corridos após o seu recebimento no correio central da Prodemge.

16.1.3. Quando a data de 25 não for dia útil, os documentos deverão ser emitidos e entregues até o último dia útil anterior.

16.1.4. Caso a cobrança seja através de nota fiscal eletrônica (NFS-e), esta deverá ser encaminhada para o e-mail xxx@xxxxxxxx.xxx.xx

16.2. O processo de remuneração do Prestador de Serviços praticado pela Prodemge considera o pagamento nas seguintes situações:

16.2.1. Software entregue funcionando, ou seja, o Prestador de Serviços será remunerado pela execução das atividades relacionadas em uma Ordem de Serviço quando, ao final da respectiva sprint, as atividades realizadas e os entregáveis correspondentes - quando aplicáveis - estiverem consubstanciados em software funcionando, observando os critérios de aceite e demais condições definidas antes do início da execução da OS.

16.2.2. Artefatos que forem demandados pela Prodemge em atendimento a necessidades específicas do projeto, desde que as respectivas atividades estejam previstas no Anexo V - Repertório de USTs e tenham sido previamente acordados antes do início da Sprint.

16.2.3. Em casos excepcionais em que, ocorra paralisação e/ou cancelamento do projeto, por parte da Prodemge ou cliente final, a remuneração do Prestador de Serviços poderá ser realizada mediante ateste dos artefatos concluídos até a data da efetiva paralisação / cancelamento.

16.2.4. De forma geral, é desejável que a entrega de todos os artefatos definidos no backlog de uma Sprint seja feita por completo.

16.2.5. Todas as entregas, parciais ou totais, e seus respectivos pagamentos deverão observar os critérios de aceite definidos no item 11 – Critérios de Aceitabilidade do objeto e os redutores especificados no item 5.1 – Indicadores de SLA.

16.3. Processo de Pagamento

16.3.1. Os serviços serão remunerados pela execução das atividades relacionadas em uma Ordem de Serviço (OS).

16.3.2. O Prestador de Serviços concorda que os créditos derivados do objeto ora contratado sejam depositados pela Prodemge no Banco, Agência e Conta que tenha o Prestador de Seviços como titular, a serem informados no corpo da nota fiscal a ser emitida, ou por meio de boleto bancário emitido pela mesma.

16.3.3. O desconto de títulos ou cobrança bancária somente poderá ser efetuado com a prévia autorização por escrito da Xxxxxxxx.

16.3.4. Nenhum pagamento será efetuado pela Prodemge sem que o fiscal do contrato ateste, por escrito, que os serviços correspondentes foram correta e integralmente executados.

16.3.5. A Nota Fiscal/Fatura deverá ser emitida em nome do Prestador de Serviços com o número de inscrição no Cadastro Nacional da Pessoa Jurídica – CNPJ, homologado no Modo de Disputa Aberto.

16.3.6. Caso seja emitida nota fiscal com CNPJ diverso do homologado no processo, ou seja, da FILIAL ou MATRIZ, o Prestador de Serviços deverá apresentar toda a documentação relativa ao novo CNPJ.

16.3.7. Na Nota Fiscal deverá ser discriminado o número do contrato a que se refere e o mês/período da prestação de serviço.

16.3.8. Se o documento de cobrança apresentar incorreções, o mesmo será devolvido ao Prestador de Serviços e a contagem do prazo para o pagamento previsto nesta cláusula reiniciará a partir da data da reapresentação do documento corrigido e atestado pelo fiscal.

16.3.9. O pagamento será efetuado mensalmente em até 30 (trinta) dias corridos do recebimento das faturas pela Prodemge.

17.Obrigações das partes:

17.1. Obrigações do Prestador de Serviços

17.1.1. O Prestador de Serviços se obriga e se compromete perante a Prodemge a:

17.1.1.1. Prestar os serviços atendendo integralmente às especificações técnicas, características e condições previstas no Termo de Referência constante do Edital de Licitação;

17.1.1.2. Utilizar, na prestação dos serviços, mão de obra qualificada e com certificados de acordo com Xxxxx XXX - Perfil dos Profissionais.

17.1.1.3. Respeitar e fazer com que seus representantes e prepostos respeitem as normas adotadas pela Prodemge para o controle do acesso às suas dependências, quando nelas tiver que ingressar para a execução de serviços;

17.1.1.4. Remeter, mensalmente, as respectivas Notas Fiscais/Faturas de Serviços e, se for o caso, relatórios impressos contendo todas as informações relativas ao faturamento dos serviços em cada mês, considerando o ateste dos serviços prestados emitido pela Prodemge;

17.1.1.5. Manter atualizado seu cadastro junto ao Cadastro de Fornecedores do Estado de Minas Gerais – CAGEF administrado pela Secretaria de Estado de Planejamento e Gestão – SEPLAG;

17.1.1.6. Comprometer-se a não emitir, nem fazer circular duplicatas, nem sacar letras de câmbio contra a Prodemge relativamente a todo e qualquer crédito decorrente do presente contrato;

17.1.1.7. Manter, durante a vigência deste contrato, as condições de habilitação e qualificação técnica dos profissionais alocados nos projetos da Prodemge conforme exigido no processo licitatório;

17.1.1.8. Responsabilizar-se pela gestão dos profissionais alocados para a prestação dos serviços especificados neste Termo de Referência.

17.1.1.9. Apresentar relação nominal dos profissionais que serão alocados nos Squads da Prodemge, acompanhada dos respectivos comprovantes de formação e experiência profissional, conforme definido no Anexo III - Perfil dos Profissionais.

17.1.1.10. Comunicar à Prodemge, com a antecedência máxima possível, de acordo com as regras estabelecidas no Edital, qualquer substituição de profissionais durante a prestação dos serviços.

17.1.1.10.1. A substituição de profissionais indicados somente será permitida por outros profissionais com as mesmas qualificações devidamente comprovada pelo Prestador de Serviços. A substituição só poderá ocorrer após avaliação e aprovação da Prodemge.

17.1.1.10.2. É vedada a alocação de estagiários como parte dos profissionais a serem alocados.

17.1.1.11. Garantir que o seu preposto não faça parte dos membros da equipe técnica e que trabalhará, a critério da Prodemge, presencialmente ao menos meio período por dia nas dependências da Companhia.

17.1.1.12. Responsabilizar-se pela execução dos serviços, fornecimento e gestão dos recursos técnicos a exemplo de notebook, monitores, periféricos e outros necessários à execução das tarefas, de acordo com o previsto no Termo de Referência.

17.1.1.13. Entregar, quando do recebimento no momento do recisão deste contrato, a documentação e o material, em meio físico, de propriedade da Prodemge ou de terceiros que foram repassados durante a prestação do serviço.

17.1.1.14. Destruir, no final do contrato, os produtos e documentos de propriedade da Prodemge em meio digital, dentre eles, as especificações dos produtos, códigos fontes, documentos dos negócios do cliente, biblioteca de classes, componentes e frameworks.

17.1.1.15. Participar de reuniões de alinhamento, caso necessário, com a Prodemge durante a prestação dos serviços.

17.1.1.16. Participar de todas as reuniões técnicas previstas no Anexo V – Repertório de USTs.

17.1.1.16.1. As reuniões serão previamente agendadas pela Prodemge sempre que julgar necessário, sem limite de quantidade, sem frequência predefinida e, preferencialmente, no ambiente da Prodemge.

17.1.1.17. Arcar com todas as despesas e remuneração do seu pessoal envolvido no projeto, cumprindo rigorosamente, as exigências da legislação trabalhista, previdenciária, tributária e fiscal, de seguro, higiene e segurança do trabalho, assumindo todas as obrigações e encargos legais inerentes e respondendo integralmente pelo ônus resultante pelas infrações cometidas.

17.1.1.18. Manter a qualquer época, inclusive após o término dos trabalhos, completo sigilo sobre dados e informações fornecidas pela Prodemge, não os divulgando, usando o fornecendo a terceiros, sem a prévia e expressa autorização da Prodemge.

17.1.1.19. Arcar com todos os custos necessários ao bom andamento dos trabalhos, especialmente de viagens, hospedagem, alimentação e transporte dos seus

funcionários, incluindo aqueles decorrentes da participação nas reuniões citadas no item 17.1.1.16.

17.1.1.20. Elaborar em conjunto com a Prodemge o planejamento de cada iteração e o objetivo de cada release do produto.

17.1.1.21. Implantar, nos devidos ambientes da Prodemge, os componentes do software desenvolvidos.

17.1.1.22. Disponibilizar toda a documentação do desenvolvimento do software, bem como os códigos implementados durante a prestação do serviço.

17.1.1.23. Prestar todos os serviços em conformidade com ambiente tecnológico da Prodemge descrito no Anexo VI - Ambiente Tecnológico e Processo de Integração Contínua Baixa Plataforma da Prodemge.

17.1.1.24. Prestar todos os serviços de sustentação de software em conformidade com o item 4.4 deste Termo de Referência.

17.2. Obrigações da Prodemge

17.2.1. São obrigações da Prodemge:

17.2.1.1. Exercer a gestão física e financeira do contrato.

17.2.1.2. Acompanhar e controlar o faturamento global do contrato;

17.2.1.3. Organizar e disponibilizar as informações gerenciais;

17.2.1.4. Fornecer informações técnicas sobre os sistemas e ambente tecnológico relacionado.

17.2.1.5. Acompanhar e atuar como fiscal do contrato.

17.2.1.6. Acompanhar e atuar como fiscalizadora da gestão exercida pelo Prestador de Serviço sobre os profissionais alocados.

17.2.1.7. Efetuar e/ou aferir métricas.

17.2.1.8. Analisar indicadores apresentados por meio de relatórios fornecidos pelo Prestador de Serviços ou mesmo coletá-los diretamente.

17.2.1.9. Homologar as entregas conforme critério estabelecidos no item 11 - Critérios de aceitabilidade deste Termo de Referência.

17.2.1.10. Proceder à abertura de Ordens de Serviços (OS) para cada Sprint.

17.2.1.11. Aferir os níveis de serviços especificados no contrato para cada entrega.

17.2.1.12. Treinar a equipe do Prestador de Serviços propiciando conhecimento mínimo da sua estrutura organizacional - áreas demandantes - seus processos internos e tecnologias adotadas com o propósito de capacitá-la para a execução dos serviços especificados neste Termo de Referência.

17.2.1.13. Permitir o acesso de profissionais do Prestador de Serviços às suas dependências para a realização dos serviços de testes, instalação, manutenção ou retirada de equipamentos, desde que sejam respeitadas as normas de segurança adotadas pelas mesmas;

17.2.1.14. Treinar profissionais do Prestador de Serviços para sustentação de softwares conforme item 4.4 deste Termo de Referência.

18.Procedimentos de Fiscalização e Gerenciamento do Contrato

Informação Interna.

19.Sanções Cabíveis

19.1. Em caso de atraso injustificado na execução do contrato (mora) e/ou a sua inexecução total ou parcial pela Contratada, serão aplicadas as sanções cabíveis constantes do Regulamento Interno de Licitações e Contratos – RILC da Prodemge.

19.2. São situações ensejadoras da aplicação de sanção à contratada, o atraso injustificado na execução do contrato (mora) e/ou a sua inexecução total ou parcial.

19.2.1. O atraso injustificado na execução do contrato sujeita a contratada à multa de mora, nos termos do art. 82 da Lei nº 13.303/16, limitada a 0,3% (três décimos por cento) por dia, até o trigésimo dia de atraso.

19.2.2. A inexecução total ou parcial do contrato, isto é, a inobservância de quaisquer de suas cláusulas, sujeita a contratada às seguintes sanções, nos termos do art. 83 da Lei nº 13.303/16:

I - advertência;

II - multa, observados os seguintes limites máximos:

a. Até 10% (dez por cento) sobre o valor do saldo remanescente do contrato para o caso de inexecução parcial;

b. Até 20% (vinte por cento) sobre o valor total do contrato para o caso de inexecução total.

III - Suspensão temporária do direito de licitar e de contratar com a Prodemge, por prazo não superior a dois anos.

IV - Impedimento de licitar e contratar com a Prodemge, nos termos do art. 7º da Lei Federal 10.520/2002.

19.3. As penalidades de advertência e multa serão aplicadas de ofício ou por provocação dos órgãos de controle, pelas autoridades signatárias deste contrato.

19.4. O valor da multa aplicada, nos termos do inciso II, será descontado do valor da garantia prestada.

19.5. A sanção prevista nos incisos I, III e IV do item 19.2 poderão ser aplicadas cumulativamente à prevista no inciso II, assegurado o direito de defesa prévia das partes no prazo de 5 (cinco) dias úteis.

19.6. O valor da multa prevista no inciso II do item 19.2 será retido dos pagamentos devidos pela Prodemge ou cobrado judicialmente, nos termos do § 3º do art. 38 do Decreto Estadual nº 45.902/2012.

19.7. A aplicação de qualquer das penalidades previstas realizar-se-á em processo administrativo punitivo apensado ao processo licitatório ou ao processo de execução contratual originário que assegurará o contraditório e a ampla defesa à CONTRATADA, observando-se o procedimento previsto no Decreto Estadual nº 45.902, de 27 de janeiro de 2012.

19.8. A autoridade competente, na aplicação das sanções, levará em consideração a gravidade da conduta do infrator, o caráter educativo da pena, bem como o dano causado à Administração, observado o princípio da proporcionalidade.

19.9. Não serão aplicadas sanções administrativas na ocorrência de casos fortuitos, força maior ou razões de interesse público, devidamente comprovados.

19.10. A aplicação de sanções administrativas não reduz nem isenta a obrigação da CONTRATADA de indenizar integralmente eventuais danos causados a Administração ou a terceiros, que poderão ser apurados no mesmo processo administrativo sancionatório.

19.11. As sanções relacionadas nos itens III, IV do item 19.2 serão obrigatoriamente registradas no Cadastro de Fornecedores Impedidos de Licitar e Contratar com a Administração Pública Estadual – CAFIMP.

19.12. As sanções de suspensão do direito de participar em licitações e impedimento de licitar e contratar com a Administração Pública poderão ser também aplicadas àqueles que:

19.12.1. Retardarem a execução do objeto;

19.12.2. Comportar-se de modo inidôneo;

19.12.2.1. Considera-se comportamento inidôneo, entre outros, a declaração falsa quanto às condições de participação, quanto ao enquadramento como ME/EPP ou o conluio entre os licitantes, em qualquer momento da licitação, mesmo após o encerramento da fase de lances.

19.12.3. Apresentarem documentação falsa ou cometerem fraude fiscal.

19.13. As multas não se confundem e não incidem nas variações tratadas no SLA. Entretanto, na hipótese de comportamento contínuo de desconformidade da prestação do serviço em relação à qualidade exigida, bem como ultrapassar os limites estabelecidos ou ficar abaixo dos níveis mínimos toleráveis, previstos nos

indicadores, poderão ser aplicadas sanções à CONTRATADA, de acordo com as regras previstas no edital.

20.Demais condições essenciais para a prestação do serviço demandado pela Administração:

20.1. Da Participação em Consórcio

20.1.1. Considerando que o mercado é bastante disputado e que existe uma grande gama de empresas com conhecimento técnico e operacional para atender todos serviços detalhados neste Termo de Referencia, não será permitida a participação de empresas reunidas em consórcio.

21. Da Garantia

21.1. Garantia Contratual

21.1.1. Será exigida, quando da convocação do Prestador de Serviços para assinar o contrato, prestação de garantia em qualquer das modalidades previstas no artigo 70 da Lei nº 13.303/2016 no valor de 2% (dois por cento) do valor do contrato.

21.1.2. As garantias e seus reforços responderão por todas as multas que forem impostas ao Prestador do Serviço e por todas as importâncias que, a qualquer título, forem devidas pelo Prestador de Serviços à Prodemge.

21.1.2.1. Em caso de insuficiência, será o Prestador de Serviços notificado para, no prazo de 72 (setenta e duas horas), completar o valor da garantia, sob pena de rescisão do contrato.

21.1.3. O reforço e/ou a regularização da garantia – excetuada a hipótese prevista no item 21.1.4 - deverá ser efetuado no prazo máximo de 05 (cinco) dias úteis, contados do recebimento da comunicação, feita por escrito pela Prodemge, sob pena de incorrer o Prestador de Serviços nas penalidades previstas neste edital.

21.1.3.1. O prazo acima aludido poderá ser prorrogado uma vez, por igual período, quando solicitado pela o Prestador de Serviços durante o transcurso do prazo, se ocorrer motivo justificado aceito pela Prodemge.

21.1.4. A garantia prestada deverá ser substituída automaticamente pelo Prestador de Serviços quando da ocorrência de seu vencimento, independente de comunicado da Prodemge, de modo a manter ininterruptamente garantido o contrato celebrado, sob pena de incorrer o Prestador de Serviços nas penalidades previstas neste edital.

21.1.5. Por ocasião do encerramento do contrato, o que restar da garantia da execução do contrato e seus reforços será liberado ou restituído após a liquidação das multas aplicadas ou após a dedução de eventuais valores devidos pelo Prestador de Serviços, nos termos do item 21.1.2 deste Termo de Referência.

21.1.6. A garantia prestada na modalidade seguro-garantia ou fiança bancária deve explicitar a cobertura integral do contrato, inclusive quanto ao pagamento imediato à Prodemge em quaisquer das hipóteses previstas neste item 21.

21.2. Garantia dos serviços

21.2.1. O Prestador de Serviços compromete-se a efetuar as necessárias manutenções corretivas relativas aos softwares produzidos, sem ônus adicional para a Prodemge, por 180 (cento e oitenta) dias corridos. O prazo é contado a partir do término do contrato e abrange todas as funcionalidades produzidas ou alteradas pelo Prestador de Serviços, incluindo a integração com outros sistemas conforme o projeto.

21.2.2. No período de garantia, o Prestador de Serviços deverá corrigir todos e quaisquer defeitos nos produtos entregues, que compreendem, dentre outros, as imperfeições percebidas, a ausência de artefatos ou de documentação obrigatória e qualquer outra ocorrência que impeça o funcionamento normal do serviço contratado ou que não se apresente dentro dos padrões e níveis de qualidade predefinidos.

21.2.3. O Prestador de Serviços deverá ainda corrigir erros de qualquer natureza que impeçam ou dificultem o uso e a continuidade da manutenção, devendo entregar documentos e artefatos que facilitem a manutenção do código produzido. Isto inclui a garantia de que todos os artefatos desenvolvidos e entregues estejam dentro dos padrões da Prodemge.

00.Xx Reajuste

22.1. O valor do contrato poderá ser reajustado anualmente, a contar da data de sua assinatura, pela variação acumulada do INPC dos últimos 12 (doze) meses.

Belo Horizonte, de de 2020

ANEXO I

MODELO DE DECLARAÇÃO DE VISTORIA

A empresa declara, para os devidos fins, que

no dia ......../......../......... encaminhou o Sr.(a) ,

responsável técnico da Empresa, devidamente registrado/habilitado no CREA-MG, que realizou vistoria nas instalações da PRODEMGE, situadas na Xxx xx Xxxxx 0000, Xxxxxxx, em Belo Horizonte/MG, onde o (a) referido (a) profissional especializado obteve todos os elementos e informações necessários para a elaboração da proposta que atenda ao Processo nº ............................. cujo objeto é a contratação de serviços especializados em desenvolvimento e sustentação de software.

Assinatura do Vistoriador :

Nome do Vistoriador : RG ou Registro no Conselho : Razão Social e CNPJ :

Representante Designado pela PRODEMGE :

MODELO DE DECLARAÇÃO DE RENÚNCIA À VISITA TÉCNICA VISTORIA

(Nome) ........................................................................................................................responsável legal da

empresa:..........................................................,CNPJ,nº..........................................................................................

.....................................Endereço:....................................................................................................

Fone:.....................................................Email:.............................................................................................

Declara que renuncia à Visita Técnica aos locais e as instalações para a prestação dos serviços constantes do Processo nº cujo objeto é a contratação de serviços especializados em desenvolvimento e

sustentação de software, e o quadro técnico da empresa tomou conhecimento das reais condições de execução dos serviços, bem como coletaram informações de todos os dados e elementos necessários à perfeita elaboração da proposta comercial, responsabilizando-se por manter as garantias que vincularem nossa proposta ao presente processo licitatório, em nome da empresa que represento.

Assinatura:

1. Formação dos Squads

ANEXO III

Perfil dos Profissionais

1.1. Cada Time deve ser organizado conforme o modelo de time multidisciplinar denominado Squad, contemplado pelos perfis elencados abaixo:

1. Scrum Master (SM);

2. Analista UX;

3. Analista de Requisitos e Testes;

4. Arquiteto de Software;

5. Analista de dados;

6. Líder Técnico;

7. Desenvolvedor.

1.2. O Squad será formado no início da execução do serviço, onde serão definidos quais papeis do Prestador de Serviços deverão atuar naquela demanda.

1.3. Os papeis de Scrum Master, Arquiteto de Software, Analista UX e Analista de Dados poderão ser alocados, mediante anuência da Prodemge, em mais de um Squad.

1.4. Os Desenvolvedores full stack do Prestador de Serviços deverão atuar pelo menos nas seguintes tecnologias: JAVA, PHP, IONIC, IOS, Android. Os arquitetos de software devem possuir conhecimento nas mesmas linguagens de programação e também nos bancos de dados bancos de dados Oracle, Microsoft SQLServer, PostgreSQL e MySQL.

2. Qualificação técnica

2.1. A qualificação técnica que se faz necessária aos profissionais alocados pelo Prestador de Serviços pode ser dividida em:

2.1.1.Conhecimentos técnicos

2.1.2. Competências comportamentais do profissional.

2.2. As exigências técnicas, incluindo formação acadêmica, experiência profissional e certificações exigidas do profissional, referem-se a tecnologias e metodologias de trabalho necessárias à execução do serviço, considerando a plataforma tecnológica adotada, a arquitetura de software a ser seguida, os níveis de qualidade exigidos e as práticas de desenvolvimento/manutenção em uso pela Prodemge.

2.3. Entende-se por competências comportamentais exigidas como sendo a proatividade, capacidade de trabalho em equipe, capacidade de autogerenciamento e tomada de decisão, capacidade de comunicação, inteligência e controle emocional, entre outros, essenciais para o desenvolvimento / manutenção de sistemas.

2.4. A maturidade e experiência da equipe alocada serão graduadas em “sênior”, “pleno” e “júnior”, com impactos na experiência dos profissionais. Em cada Squad deve haver pelo menos 1 perfil sênior de Desenvolvedor.

2.4.1. O número de profissionais juniores deve ser sempre menor do que o número de profissionais plenos; e o número de profissionais plenos não poderá ultrapassar o número de profissionais seniores.

Por exemplo:

Imagine-se um projeto em que são necessários cinco desenvolvedores: para que o número de plenos não ultrapasse o de seniores, deverão ser alocados, na proporcionalidade de, no mínimo 2 seniores, 2 plenos e 1 júnior.

2.5. A Prodemge poderá, a qualquer momento, avaliar que o profissional não está qualificado para o serviço e solicitar ao Prestador de Serviços a sua substituição.

2.5.1.Nos casos em que o profissional não atender às qualificações técnicas e ou comportamentais, a Prodemge poderá solicitar (sem ônus para a mesma) a troca do profissional. Visando reduzir o impacto da mudança, a troca de um profissional deverá ser feita antes de iniciar uma nova Ordem de Serviço.

3. Detalhamento dos Perfis Profissionais

3.1. No quadro 1 abaixo são informadas as exigências mínimas de formação, certificação e experiência dos perfis requisitados para atuar nos Squads durante a execução do contrato:

Perfil	Breve descrição	Formação	Qualificação exigida
SCRUM MASTER	Profissional do Prestador de Serviços que atua como líder servidor, cuja responsabilidade é ajudar o Time a se organizar para produzir melhor, removendo impedimentos e zelando pelo respeito aos valores ágeis e ao cumprimento dos ritos.	Formação superior completa (graduação e/ou pós-graduação lato sensu e/ou pós-graduação stricto sensu) na área de Tecnologia da Informação.	Uma das certificações conforme Lista de Certificações exigidas apresentada a seguir e mínimo de 5 anos de experiência profissional na área técnica de TI, sendo, no mínimo, 2 anos como Scrum Master.

Perfil	Breve descrição	Formação	Qualificação exigida
LÍDER TÉCNICO	Profissional do Prestador de Serviços que atua como referência técnica dentro do Squad. Realiza inspeção de código, repasse técnico e priorização das histórias.	Formação superior completa (graduação e/ou pós-graduação lato sensu e/ou pós-graduação stricto sensu) na área de Tecnologia da Informação.	Mínimo de 5 anos de experiência profissional na área técnica de TI, sendo, no mínimo, 2 anos como Líder Técnico em desenvolvimento ágil.
ANALISTA DE REQUISITOS E TESTES	Profissional da Prodemge e/ou do Prestador de Serviços que apoia o PO no refinamento e escrita das Histórias de usuário, na realização dos testes funcionais e na geração dos artefatos para atender às exigências contratuais.	Formação superior completa (graduação e/ou pós-graduação lato sensu e/ou pós-graduação stricto sensu) na área de Tecnologia da Informação.	Mínimo de 5 anos de experiência profissional na área técnica de TI, sendo, no mínimo, 2 anos como Analista em desenvolvimento ágil.
ANALISTA DE DADOS	Profissional do Prestador de Serviços que atua nas atividades de modelagem de dados, responsável pela criação de modelo de dados lógico e físico, com suas chaves primárias e estrangeiras, índices, “views” etc. Conhecimentos em ferramentas de visualização de dados, mineração de dados, ETL.	Formação superior completa (graduação e/ou pós-graduação lato sensu e/ou pós-graduação stricto sensu) na área de Tecnologia da Informação	Mínimo de 5 anos de experiência profissional na área técnica de TI, sendo, no mínimo, 2 anos como Analista de Dados em desenvolvimento ágil.
ARQUITETO DE SOFTWARE	Profissional da Prodemge e também do Prestador de Serviços que coordena o trabalho em relação às decisões arquiteturais de software que afetam a aplicação. Atua nas atividades de desenho da arquitetura, POC arquitetural, definição de padrões arquiteturais e de codificação de software, considerando as tecnologias e framework padrão adotados.	Formação superior completa (graduação e/ou pós-graduação lato sensu e/ou pós-graduação stricto sensu) na área de Tecnologia da Informação.	Mínimo de 5 anos de experiência profissional na área técnica de TI, sendo, no mínimo, 2 anos como Arquiteto de Software em desenvolvimento ágil.
DESENVOLVEDOR	Profissional do Prestador de Serviços responsável pela produção dos artefatos de software que o Squad deve entregar.	Formação superior completa (graduação e/ou pós-graduação lato sensu e/ou pós-graduação stricto sensu) na área de Tecnologia da Informação.	Mínimo de 5 anos de experiência profissional na área técnica de TI, sendo, no mínimo, 2 anos como Desenvolvedor full stack", nas seguintes tecnologias: Java, Mobile IONIC, Android, iOS, PHP e que conheça de analytics, APIs, BI e automação de testes.

Perfil	Breve descrição	Formação	Qualificação exigida
ANALISTA UX (USER EXPERIENCE)	Profissional do Prestador de Serviços responsável pela experiência dos usuários com as soluções fornecidas pelo Squad, atua com o time, PO e clientes e por isso está envolvido em todo o ciclo de desenvolvimento. É responsável pela realização de prototipação, benchmarking de soluções e realização de testes de usabilidade.	Formação superior completa (graduação e/ou pós-graduação lato sensu e/ou pós-graduação stricto sensu) na área de Design de Produto ou Design Gráfico ou Design de Interação (UX)	Mínimo de 2 anos de experiência profissional na área UX/UI Designer.

Quadro 1 – Perfil dos Profissionais

3.2. Lista de Certificações exigidas:

3.2.1.Lista de Certificações aceitas para o Scrum Master (apenas uma é necessária):

a) Scrum Alliance: Certified Scrum Master (CSM) ou Certified Scrum Product Owner

(CSPO);

b) Xxxxx.xxx: Professional Scrum Master (PSM) ou Professional Scrum Product Owner

(PSPO);

c) EXIN: Agile Scrum Foundation, Agile Scrum Master ou Agile Scrum Product

d) PMI: Agile Certified Practitioner (PMI-ACP).

ANEXO IV

Modelo de Gestão e Volumetria

1. Modelo de Gestão da prestação de serviços

1.1. Visando promover uma gestão com alto nível de qualidade, disponibilidade e acompanhamento dos serviços prestados, será adotado o modelo abaixo:

Integrantes do Processo de Gestão:

a) Equipe/Squad

b) Área responsável pela gestão e controle de serviços prestados

c) Prestador de Serviços

1.2. Abaixo estão elencados, minimamente, os papéis de cada ator acima citado.

1.2.1.Papéis da Equipe/Squad

1.2.1.1. Participar, a critério da Prodemge, minimamente, das seguintes fases

a) Inception

b) Sprints (iterações)

c) Pré-refinamento

d) Refinamento

e) Sprint Planning

f) Build

g) Sprint Review

h) Sprint Retrospective

i) Transição

1.2.1.2. Definir os entregáveis de cada Sprint, considerando os serviços definidos no Anexo V

- Repertório de UST´s, apontando o respectivo quantitativo parcial e total de UST´s, que deverá constar na Ordem de Serviço – OS.

1.2.1.3. Verificar junto à área responsável pela gestão e controle do serviço a existência de saldo contratual.

1.2.1.4. Solicitar a abertura da Ordem de Serviço à área responsável pela gestão e controle do serviço.

1.2.1.5. Acompanhar o desenvolvimento e a entrega do produto definido em cada Sprint.

1.2.1.6. Emitir ateste técnico que garanta o cumprimento parcial ou total dos entregáveis definidos para cada Ordem de Serviço.

1.2.1.7. Emitir pareceres de teste e termo de encerramento.

1.2.1.8. Informar, por meio de relatório para a área responsável pela gestão e controle do serviço, se houve ou não quebras dos níveis de serviço.

1.2.2.Papéis da Gerência de Controle de Nível de Serviços da Prodemge

1.2.2.1. Apoiar a Equipe/Squad na confecção de Ordens de Serviço/Termos de Encerramento.

1.2.2.2. Gerir o processo de faturamento.

1.2.2.3. Gerir os SLA’s, bem como o controle das deduções dos valores referentes níveis de serviços quebrados dos serviços prestados nas faturas.

1.2.2.4. Realizar abatimentos em faturas;

1.2.2.5. Gerir as Informações Gerenciais no âmbito do Contrato.

1.2.3.Papéis do Prestador de Serviços

1.2.3.1. Interagir com as áreas da Prodemge envolvidas no contrato.

1.2.3.2. Xxxxxxx as solicitações da Prodemge por meio das Ordens de Serviços.

1.2.3.3. Manter um preposto junto às áreas de Prodemge para acompanhamento da execução do contrato.

1.2.3.4. Liderar e gerir os recursos humanos alocados para a prestação dos serviços especificados neste Termo de Referência.

1.2.3.5. Garantir a qualificação técnica dos profissionais alocados na Prodemge.

1.2.3.6. Comprometer-se com a qualidade dos entregáveis definidos em cada Sprint.

1.2.3.7. Emitir fatura para os serviços prestados, após aprovação da Prodemge.

2. Ordens de Serviços - OS

2.1. Todos os serviços, serão demandados através de Ordens de Serviços.

2.2. Serão considerados como Ordens de Serviço as solicitações devidamente registradas em meios formais, como e-mail, documento padronizado ou por meio do uso de ferramenta de TIC a ser definida pela Prodemge.

2.3. O início efetivo dos trabalhos ocorrerá somente após a formalização por meio de Ordem de Serviço emitida pela Prodemge. Além disso, o Prestador de Serviços ao iniciar o atendimento da OS assume o compromisso de que entendeu e concorda com todas as informações presentes na referida OS.

2.4. Para o acompanhamento de gestão da qualidade, o Prestador de Serviços deverá elaborar Relatório Mensal de Atividades dos serviços prestados e demais informações relevantes que julgar importantes para a gestão contratual.

2.5. O conteúdo detalhado e a forma do Relatório Mensal de Atividades serão definidos pelas partes, devendo conter no mínimo as informações necessárias para aferir os elementos de gestão contratual.

2.6. As OS’s podem ser abertas para serviços rotineiros ou sob demanda, para execução em horas úteis, conforme cláusulas deste Termo de Referência e Repertório de UST´s vigente.

2.7. Para a prestação de serviços com Squad ágil, as OS´s poderão ser registradas, minimamente, em 3 momentos:

a) Antes do início das reuniões de Lean Inception, com a participação da fábrica;

b) no início de cada Sprint, após a realização do planejamento da Sprint;

c) para toda e qualquer sustentação de software (chamados de erro).

2.7.1.Demais situações em que a abertura de OS´s se fizer necessária serão tratadas entre o Prestador de Serviços e a Prodemge.

2.8. As informações contidas em uma OS podem variar, mas cada OS deve possuir, pelo menos, os seguintes atributos:

1. Número da OS;

2. Nome do Produto;

3. Código de identificação do Sistema;

4. Cliente;

5. Data da abertura da OS;

6. Xxxxxxxxxx e nome do responsável técnico;

7. Identificação / número do Sprint;

8. Objetivo do Sprint;

9. Assinaturas: Preposto da fábrica, Gestor Técnico do projeto na Prodemge;

10. Descrição dos serviços objeto da OS:

• Itens do backlog da Sprint:

I. Atividades previstas do catálogo de UST,

II. Grau de complexidade,

III. Estimativa em UST.

11. Quantidade total estimada de UST’s da OS;

12. Prazo de execução da Sprint.

2.9. O Termo de Encerramento da OS será emitido pela Prodemge após a realização da etapa de Revisão da Sprint, com a apresentação por parte do Squad dos itens entregues do backlog da Sprint e o aceite do Product Owner.

2.9.1.O documento contemplará os itens de backlog entregues, com suas respectivas atividades medidas em USTs, assim como a indicação dos itens não entregues ou não aceitos e seus respectivos abatimentos em fatura e sanções, caso aplicáveis.

2.10. A estrutura do Termo de Encerramento conterá, minimamente, as seguintes informações:

1. Número da OS;

2. Nome do Produto;

3. Código de identificação do Sistema;

4. Cliente;

5. Identificação / número do Sprint;

6. Data de entrega do backlog do Sprint;

7. Descrição dos serviços entregues / não entregues na Sprint Review:

• Itens do backlog do Sprint entregues:

I. Atividades executadas do catálogo de UST,

II. Grau de complexidade,

III. Quantidade de UST’s.

• Itens de backlog do Sprint não entregues / não aceitos;

8. Parecer do aceite do P.O;

9. Assinaturas dos responsáveis.

2.11. Uma vez solicitado o serviço, o Prestador de Serviços deverá alocar profissionais, de acordo com os perfis e serviços definidos no Termo de Referência e seus anexos, em tempo hábil para a consecução das atividades e condições estabelecidas na OS.

3. Emissão de Relatórios

3.1. Mensalmente, até o quinto dia útil do mês subsequente, o preposto do Prestador de Serviços encaminhará à Prodemge, no mínimo, a seguinte documentação:

3.1.1.Relatório Mensal de Atividades elaborado por meio da medição dos serviços realizados, que tomará como referência as especificações e condições contidas nas OS’s e nos resultados apurados da efetiva prestação dos serviços;

3.1.1.1. Todos os serviços de todas as OS’s concluídas no mês anterior devem constar do Relatório Mensal de Atividades, bem como os indicadores de sanções e abatimentos medidos pelo Prestador de Serviços para o período.

3.1.1.2. Relatório de Nível de Serviço que deverá conter a medição de todos os Indicadores relativos a sanções, multas e abatimentos em fatura.

3.1.1.3. Mensalmente, será feita a validação dos Relatórios de Atividades pela Prodemge.

3.1.1.4. Este Relatório trata-se de um acompanhamento de gestão e não será remunerado em UST’s.

4. Volumetria Estimada

4.1. A quantidade de USTs prevista foi calculada com base em estudo exploratório onde verificou-se que a Prodemge tem demandado, em média, o equivalente a 92.928 (noventa e dois mil, novecentos e vinte e oito).

4.2. A Previsão foi baseada na projeção de 7 (sete) Squads que absorverão um total estimado de 44 (quarenta e quatro) profissionais, conforme Quadro 1 – Quantidade de profissionais x perfil do item 8.2 do Termo de Referência. Cada profissional equivalerá a 176 (cento e setenta e seis) horas úteis trabalhadas no período de um mês.

Previsão = ((44 profissionais x 176 horas por profissional) x 12 meses)

Previsão = 92.928 USTs

ANEXO V

Repertório de UST’s

1. O Repertório de Estimativas de Unidade de Serviços Técnicos - USTs reúne o conjunto de atividades executáveis no âmbito do contrato e serve de parâmetro para estimativa de custo, conforme tabela abaixo:

Código	Área	Descrição da atividade	Estimativa em USTs
E1	Encontros	Alinhamento inicial Comunicado sobre as etapas de execução que serão contratadas e apresentação da visão do Product Backlog oriundo da Ideação.	1 UST por hora de reunião por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge).
E2	Encontros	Formação Time Ágil - Momento em que o Squad é apresentado e algumas regras são definidas (exemplo: horário da daily, ferramentas utilizadas, canvas do time, etc)	1 UST por hora de reunião por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge).
E3	Encontros	Workshop PO - Workshop realizado pela Prodemge para ensinar o PO sobre seu papel no ciclo de desenvolvimento.	1 UST por hora de reunião por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge).
R1	Ritos	Inception	1 UST por hora de reunião por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge).
R2	Ritos	Refinamento	1 UST por hora de reunião por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge).
R3	Ritos	Sprint Planning	1 UST por hora de reunião por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge).
R4	Ritos	Sprint Review	1 UST por hora de reunião por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge).

R5	Ritos	Sprint Retrospective	1 UST por hora de reunião por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge).
L1	Liderança Ágil	Acompanhamento do Scrum Master, envolvendo preparação e condução de ritos, resolução de impedimentos, atualização de métricas de acompanhamento, etc.	30 UST’s por Sprint.
H1	Histórias	Entendimento, refinamento, escrita e validação de história de usuário	16 UST’s por história
A1	Arquitetura	Definições arquiteturais	10 UST’s
AD1	Análise e desenho	Elaboração da identidade visual Para elaboração da identidade visual, envolve: Entrevista com usuário, brainstorm, busca de referências, criação de logomarca, validação com o PO, etc.	15 UST’s
AD3	Análise e desenho	Elaboração do guia de usabilidade	5 UST’s
AD4	Análise e desenho	Prototipação: Entrevista, observações e validações com o usuário para mapeamento da experiência desejada e elaboração de protótipo de média fidelidade da tela, sendo que uma tela pode envolver mais de uma história. Envolve também alterações na identidade visual por tela.	8 UST’s por tela prototipada
B1	Implementação back-end	Implementação back-end de 1 história de usuário ou item de trabalho (Codificação Completa, incluindo operações, autorizações, relatórios, validação do campo, sanitização das “strings”, integrações, serviços etc.).	21 UST’s por história
F1	Implementação front-end	Implementação front-end de 1 história de usuário (validações, elaborações de tela, etc)	21 UST’s por história
T1	Teste	Preparação e implementação de testes automatizados (testes	10 UST’s por história

		unitários, de integração, etc) por história.
EC1	Estudo	Estudo do código-fonte de sistema. Entregável: documentação e apresentação do Estudo.	1 UST por hora de estudo. Não ultrapassando 20 dias úteis de estudo e 140 UST. Será definido pela Prodemge de acordo com a complexidade do sistema.
CE1	Chamados de erro	Solução de chamados de erro em produção a serem atendidos de acordo com a complexidade definida.	Complexidade baixa: 4 UST’s Complexidade média: Até 20 UST’s Complexidade alta: Até 40 UST’s
D1	Dados	Modelagem de dados - Criação do modelo de dados base/inicial Fica a critério de a Prodemge definir se algum nível (conceitual, lógico, físico) não terá necessidade de ser construído.	10 UST’s. A UST mensurada engloba todos os níveis, porém, caso algum nível (conceitual, lógico, físico) já estiver pronto, o valor da UST permanece o mesmo.
D1	Dados	Modelagem de dados - Evolução do modelo referente à 1 história de usuário	4 UST’s por história
D2	Dados	Elaboração de procedimento de automatização para carga ou extração de dados: Este serviço consiste na criação de estrutura automatizada para execução de procedimentos de carga, devendo gerar os seguintes documentos: (i) Mapa de Carga ETL: deve conter origem dos dados, transformações executadas e destino; (ii) Manual de Operação: manual contendo todas as informações necessárias para a execução operacional da carga.	2 USTs por tabela (da fonte) No caso de utilização de planilhas de Excel: 2 por planilha

2. APLICAÇÃO DO FATOR DE COMPLEXIDADE NAS ESTIMATIVAS

2.1. As demandas cujo atendimento é pouco padronizado no mercado requerem maior qualidade no esforço de atendimento, e não maior quantidade. Reconhecendo essa necessidade, a Prodemge prevê ajuste no valor da UST baseado na complexidade da demanda. Esse ajuste somente será aplicado aos itens e esforços específicos que efetivamente o justificarem. A tabela 1 abaixo exemplifica os níveis de complexidade adotados.

Nível de Complexidade	Descrição	Fator de complexidade
C1	Demanda com requisitos de negócio simples; pouca interação com outros sistemas e/ou bancos de dados; poucas restrições apresentadas pelo legado; etc.	1
C2	Demanda com requisitos de negócio com mais regras (negócio e técnicas), maior interação com outros sistemas e/ou bancos de dados; maiores condições impostas por sistemas legados; etc.	1,5
C3	Demanda com requisitos de negócio complexos; muita interação com outros sistemas e/ou bancos de dados, a ponto de demandar alta criatividade e/ou especialidade no desenho da solução; interação com sistemas e/ou bancos de dados legados que dificultem o desenho de uma solução clara para o projeto, demandando estratégias avançadas de desenvolvimento, migração, etc.	2

Tabela 1 – Níveis de Complexidade por tipo de demanda

2.2. A definição do fator de ajuste, quando houver necessidade de aplicação, será discutida entre a Prodemge e o Prestador de Serviços, porém a definição final sobre a pertinência da aplicação do fator é exclusivamente da Prodemge.

2.3. O fator de ajuste será definido tomando por base a execução da demanda por profissionais experientes e competentes; em nenhum caso poderá ser utilizado para compensar a falta de capacidade ou de eficiência dos profissionais alocados.

2.4. A decisão da aplicação do fator de ajuste será feita no fechamento da Ordem de Serviço.

ANEXO VI

Ambiente Tecnológico e Processo de Integração Contínua Baixa Plataforma

da Prodemge

1. Ambiente Tecnológico

A Prodemge possui ambiente tecnológico diversificado. A maior parte dos sistemas atuais, que serão objeto dos maiores esforços de execução dos serviços está construída usando as tecnologias de desenvolvimento JAVA, PHP, IONIC, IOS, Android usando Sistemas de Gerenciamento de Banco de Dados – SGBD - relacionais, a exemplo do MS SQL Server, Oracle, MySQL e PostgreSQL.

1.1 A arquitetura de referência e a plataforma de desenvolvimento da Prodemge bem como o ferramental explicitado no item 2 deste Anexo estão em constante evolução. Sempre que houver mudanças de versão ou adoção de novas tecnologias, o Prestador de Serviços será comunicado e deverá se adaptar, em prazo a ser definido em comum acordo entre as partes.

1.2 Além do processo ágil e da arquitetura de referência, os produtos a serem desenvolvidos pelo Prestador de Serviços deverão:

a) Utilizar todas as ferramentas que a Prodemge utiliza em seu ciclo de desenvolvimento, ou equivalente sem que haja prejuízo em produtividade e transferência de conhecimento, desde que previamente aprovado pela Companhia.

b) Integrar-se com as bases de dados informatizadas existentes no ambiente da Prodemge. Essas bases são alimentadas por sistemas internos e de terceiros. As versões dos bancos de dados poderão ser evoluídas, devendo o Prestador de Serviços adaptar-se a tal mudança.

c) Seguir diretrizes de segurança estabelecidas pela política de segurança da informação da Prodemge e demais normas internas relacionadas ao tema.

d) Toda configuração de JOB, configuração de ambiente, concessão de permissões, possíveis alterações de regras do sonar, etc. são de responsabilidade única e exclusiva da Prodemge.

1.3 A figura 1 é uma representação geral do ambiente tecnológico e de integração contínua utilizado pela Prodemge.

1.4 Para efeitos de verificação e análise estática do código entregue pelo Prestador de Serviços, as ferramentas de inspeção de código utilizadas pela Prodemge possuem uma restrição de nível mínimo de qualidade para publicação do código denominada CRIVO.

Figura 1: Representação do processo de integração contínua da Prodemge

2. Principais ferramentas utilizadas no ciclo de desenvolvimento de software da Prodemge

2.1 Git: sistema de controle de versão distribuído.

2.2 Xxxxxxx: servidor de integração contínua.

2.3 Maven: ferramenta de automação de build.

2.4 Junit: framework open-source que suporta à criação de testes automatizados.

2.5 SonarQube: ferramenta automática de análise de código para detectar erros, vulnerabilidades e “code smell”.

2.6 Artifactory: repositório de artefatos.

3. Processo base de Integração contínua

3.1 Processo ambiente de Desenvolvimento

1 Desenvolvedor ou analista de configuração executa o job no Jenkins para publicação no ambiente de desenvolvimento;

2 O Jenkins realiza o download do código no GIT;

3 Através do maven, o build é realizado no repositório local (Jenkins). Caso haja testes criados, os mesmos serão executados nesta etapa;

4 É realizada uma inspeção no código, via sonar, para validar se não existe nenhuma violação com severidade blocker. Para saber quais são essas violações verifique o item 4.1 deste Anexo;

5 É realizada a publicação no ambiente de desenvolvimento;

6 Passo executado APENAS se informado número de versão.

a) Entrega do artefato no repositório de artefatos (Artifactory). Caso, no passo 4, não haja nenhuma violação blocker, o artefato é entregue no repositório COM CRIVO.

b) Uma tag (número da versão) é gerada e enviada para o GIT.

3.1.1 Fica única e exclusivamente a critério da Prodemge definir que, em alguns casos específicos, a entrega do código poderá ser realizada SEM CRIVO, não impactando em abatimentos em fatura por descumprimento de SLA e/ou aplicação de penalidades contratuais.

3.2 Processo ambiente de Homologação

3.2.1 O processo no ambiente de homologação consiste em recuperar o binário do artifactory (repositório COM CRIVO) e publicar no respectivo ambiente.

3.2.2 Caso o mesmo não tenha passado no CRIVO do sonar e a Prodemge entender que a publicação pode ser realizada, é necessário abrir uma ocorrência (OCR) para que a equipe de operação realize a publicação (o binário será recuperado no repositório SEM CRIVO). Uma justificativa deverá ser informada na ocorrência.

3.2.3 Somente os colaboradores das equipes cadastrados como gestores de configuração terão permissão para realizar a publicação no ambiente de homologação.

3.3 Processo ambiente de PRODUÇÃO

3.3.1 O processo no ambiente de produção consiste em recuperar o binário do artifactory e publicar no respectivo ambiente.

3.3.2 Para que seja feita a publicação do código, deverá ser observado e seguido o processo de mudanças da Prodemge.

3.3.3 Somente os colaboradores da área de operação da Prodemge terão permissão para realizar a publicação no ambiente de produção.

4. Violações Sonar

Esta seção traz um conjunto de elementos de verificação que devem ser utilizados na inspeção de código fonte e servirá de parâmetro para avaliação da qualidade do código produzido pelo Prestador de Serviços. Caso o código entregue e inspecionado não estiver de acordo com os critérios de qualidade definidos abaixo, a Prodemge poderá aplicar penalidades, conforme definido neste Termo de Referência.

As violações abaixo foram definidas para serem aplicadas aos sistemas que entrarão na esteira de integração contínua. Os casos em que os sistemas não estiverem nessa esteira, a qualidade de código também será mensurada no SONAR e os defeitos encontrados serão registrados e acordados para serem corrigidos, em prazo máximo, até a entrega do release corrente.

4.1 Cada elemento foi classificado em uma severidade, conforme classificação abaixo:

a. BLOCKER: Bug com alta probabilidade de afetar o comportamento do aplicativo em produção: vazamento de memória, conexão JDBC não fechada. O código DEVE ser corrigido imediatamente.

b. CRITICAL: Um bug com baixa probabilidade de afetar o comportamento do aplicativo em produção ou um problema que representa uma falha de segurança: bloco catch vazio, injeção de SQL. O código DEVE ser revisado imediatamente.

c. MAJOR: Falha de qualidade que pode impactar fortemente a produtividade do desenvolvedor: pedaço descoberto de código, blocos duplicados, parâmetros não utilizados.

d. MINOR: Falha de qualidade que pode impactar levemente a produtividade do desenvolvedor: as linhas não devem ser muito longas, as declarações de "troca" devem ter pelo menos 3 casos.

e. INFO: Nem um bug nem uma falha de qualidade, apenas um aviso.

4.1.1 O quadro 1 – Classificação de Severidade para JAVA e o quadro 2 – Classificação de Severidade PHP classificam minimamente os itens de verificação, podendo estas serem atualizadas ao longo da prestação dos serviços.

Quadro 1 – Classificação de severidade para JAVA

Severidade	Item de verificação
BLOCKER	Exit methods should not be called
BLOCKER	Future keywords should not be used as names
BLOCKER	Switch cases should end with an unconditional \"break\" statement
BLOCKER	Credentials should not be hard-coded
BLOCKER	Short-circuit logic should be used in boolean contexts
BLOCKER	Loops should not be infinite
BLOCKER	Printf-style format strings should not lead to unexpected behavior at runtime
BLOCKER	\"wait(...)\" should be used instead of \"Thread.sleep(...)\" when a lock is held
BLOCKER	Silly bit operations should not be performed
CRITICAL	Correctness - Impossible cast
CRITICAL	Correctness - Impossible downcast
CRITICAL	Correctness - Impossible downcast of toArray() result
CRITICAL	Security - Potential Command Injection
CRITICAL	Security - Potential LDAP Injection
CRITICAL	Security - Potential code injection when using Script Engine
CRITICAL	Security - Potential code injection when using Spring Expression
CRITICAL	Security - Potential SQL/HQL Injection (Hibernate)
CRITICAL	Security - Potential SQL/JDOQL Injection (JDO)
CRITICAL	Security - Potential SQL/JPQL Injection (JPA)
CRITICAL	Security - XMLDecoder usage
CRITICAL	Security - Potential XPath Injection
CRITICAL	Security - XML parsing vulnerable to XXE (DocumentBuilder)
CRITICAL	Security - XML parsing vulnerable to XXE (SAXParser)
CRITICAL	Security - XML parsing vulnerable to XXE (XMLReader)
CRITICAL	Useless Operation On Immutable
CRITICAL	Methods should not be too complex
CRITICAL	\"super.finalize()\" should be called at the end of \"Object.finalize()\" implementations
CRITICAL	Constant names should comply with a naming convention
CRITICAL	Control structures should use curly braces
CRITICAL	Expressions should not be too complex
CRITICAL	\"Object.finalize()\" should remain protected (versus public) when overriding
CRITICAL	The signature of \"finalize()\" should match that of \"Object.finalize()\"
CRITICAL	Methods should not be empty
CRITICAL	String literals should not be duplicated

CRITICAL	Execution of the Garbage Collector should be triggered only by the JVM
CRITICAL	Constructors should only call non-overridable methods
CRITICAL	Fields in a \"Serializable\" class should either be transient or serializable
CRITICAL	\"for\" loop increment clauses should modify the loops' counters
CRITICAL	\"Serializable\" classes should have a version id
CRITICAL	Comparators should be \"Serializable\"
CRITICAL	SQL binding mechanisms should be used
CRITICAL	\"ScheduledThreadPoolExecutor\" should not have 0 core threads
CRITICAL	\"runFinalizersOnExit\" should not be called
CRITICAL	\"Cloneables\" should implement \"clone\"
CRITICAL	Class names should not shadow interfaces or superclasses
CRITICAL	Modulus results should not be checked for direct equality
CRITICAL	IllegalMonitorStateException should not be caught
CRITICAL	\"Object.wait(...)\" and \"Condition.await(...)\" should be called inside a \"while\" loop
CRITICAL	Lazy initialization of \"static\" fields should be \"synchronized\"
CRITICAL	Null should not be returned from a \"Boolean\" method
CRITICAL	\"switch\" statements should end with \"default\" clauses
MAJOR	Final Class
MAJOR	Bad practice - Creates an empty jar file entry
MAJOR	Bad practice - Creates an empty zip file entry
MAJOR	Multi-threading - Sequence of calls to concurrent abstraction may not be atomic
MAJOR	Bad practice - Equals method should not assume anything about the type of its argument
MAJOR	Correctness - Bitwise add of signed byte value
MAJOR	Correctness - Incompatible bit masks
MAJOR	Correctness - Check to see if ((...) & 0) == 0
MAJOR	Correctness - Incompatible bit masks
MAJOR	Correctness - Bitwise OR of signed byte value
MAJOR	Bad practice - Check for sign of bitwise operation
MAJOR	Correctness - Check for sign of bitwise operation involving negative number
MAJOR	Correctness - Class overrides a method implemented in super class Adapter wrongly
MAJOR	Bad practice - Abstract class defines covariant compareTo() method
MAJOR	Bad practice - Covariant compareTo() method defined
MAJOR	Multi-threading - Possible double check of field
MAJOR	Correctness - Dead store of class literal
MAJOR	Performance - Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead
MAJOR	Performance - Method invokes inefficient floating-point Number constructor; use static valueOf instead
MAJOR	Performance - Use the nextInt method of Random rather than nextDouble to generate a random integer

MAJOR	Performance - Method invokes inefficient Number constructor; use static valueOf instead
MAJOR	Performance - Method invokes inefficient new String(String) constructor
MAJOR	Performance - Method invokes toString() method on a String
MAJOR	Performance - Method invokes inefficient new String() constructor
MAJOR	Correctness - Reversed method arguments
MAJOR	Performance - The equals and hashCode methods of URL are blocking
MAJOR	Performance - Maps and sets of URLs can be performance hogs
MAJOR	Correctness - D'oh! A nonsensical method invocation
MAJOR	Security - Empty database password
MAJOR	Bad practice - Adding elements of an entry set may fail due to reuse of Entry objects
MAJOR	Correctness - Futile attempt to change max pool size of ScheduledThreadPoolExecutor
MAJOR	Bad practice - Random object created and used only once
MAJOR	Correctness - equals() used to compare array and nonarray
MAJOR	Correctness - Call to equals() comparing unrelated class and interface
MAJOR	Correctness - Call to equals() comparing different interface types
MAJOR	Correctness - Call to equals() comparing different types
MAJOR	Correctness - equals method always returns false
MAJOR	Correctness - equals method always returns true
MAJOR	Bad practice - equals method fails for subtypes
MAJOR	Bad practice - Class inherits equals() and uses Object.hashCode()
MAJOR	Correctness - Signature declares use of unhashable class in hashed construct
MAJOR	Correctness - Use of class without a hashCode() method in a hashed data structure
MAJOR	Security - HTTP cookie formed from untrusted input
MAJOR	Security - HTTP Response splitting vulnerability
MAJOR	Performance - Huge string constants is duplicated across multiple class files
MAJOR	Bad practice - Superclass uses subclass during initialization
MAJOR	Correctness - Integral value cast to double and then passed to Math.ceil
MAJOR	Correctness - int value cast to float and then passed to Math.round
MAJOR	Correctness - JUnit assertion in run method will not be noticed by XXxxx
MAJOR	Correctness - TestCase declares a bad suite method
MAJOR	Correctness - TestCase has no tests
MAJOR	Correctness - TestCase defines setUp that doesn't call super.setUp()
MAJOR	Correctness - TestCase implements a non-static suite method
MAJOR	Correctness - TestCase defines tearDown that doesn't call super.tearDown()
MAJOR	Correctness - An apparent infinite loop
MAJOR	Correctness - An apparent infinite recursive loop
MAJOR	Correctness - Integer multiply of result of integer remainder

MAJOR	Correctness - Bad comparison of int value with long constant
MAJOR	Correctness - Bad comparison of nonnegative value with negative constant or zero
MAJOR	Correctness - Bad comparison of signed byte
MAJOR	Correctness - Doomed attempt to append to an object output stream
MAJOR	Correctness - A parameter is dead upon entry to a method but overwritten
MAJOR	Multi-threading - Inconsistent synchronization
MAJOR	Multi-threading - Field not guarded against concurrent access
MAJOR	Multi-threading - Inconsistent synchronization
MAJOR	Performance - Method uses toArray() with zero-length array argument
MAJOR	Bad practice - Fields of immutable classes should be final
MAJOR	Correctness - Class defines field that masks a superclass field
MAJOR	Correctness - Method defines a variable that obscures a field
MAJOR	Bad practice - Confusing method names
MAJOR	Correctness - Class defines tostring(); should it be toString()?
MAJOR	Correctness - Very confusing method names
MAJOR	Bad practice - Very confusing method names (but perhaps intentional)
MAJOR	Correctness - Method doesn't override method in superclass due to wrong package for parameter
MAJOR	Bad practice - Method doesn't override method in superclass due to wrong package for parameter
MAJOR	Multi-threading - Naked notify
MAJOR	Correctness - Null pointer dereference
MAJOR	Correctness - Null pointer dereference in method on exception path
MAJOR	Correctness - Method does not check for null argument
MAJOR	Correctness - close() invoked on a value that is always null
MAJOR	Bad practice - equals() method does not check for null argument
MAJOR	Correctness - Value is null and guaranteed to be dereferenced on exception path
MAJOR	Correctness - Non-null field is not initialized
MAJOR	Correctness - Method call passes null to a non-null parameter
MAJOR	Correctness - Method may return null, but is declared @Nonnull
MAJOR	Correctness - Possible null pointer dereference
MAJOR	Correctness - Possible null pointer dereference in method on exception path
MAJOR	Correctness - Method call passes null for non-null parameter
MAJOR	Correctness - Method call passes null for non-null parameter
MAJOR	Correctness - Non-virtual method call passes null for non-null parameter
MAJOR	Correctness - Store of null value into field annotated @Nonnull
MAJOR	Multi-threading - Synchronize and null check on the same field.
MAJOR	Correctness - Read of unwritten field
MAJOR	Bad practice - Method may fail to close database resource

MAJOR	Bad practice - Method may fail to close database resource on exception
MAJOR	Bad practice - Method may fail to close stream
MAJOR	Bad practice - Method may fail to close stream on exception
MAJOR	Security - Absolute path traversal in servlet
MAJOR	Security - Relative path traversal in servlet
MAJOR	Bad practice - Don't reuse entry objects in iterators
MAJOR	Correctness - Nullcheck of value previously dereferenced
MAJOR	Correctness - Invalid syntax for regular expression
MAJOR	Correctness - File.separator used for regular expression
MAJOR	Correctness - \".\" or \"\|\" used for regular expression
MAJOR	Bad practice - Method ignores results of XxxxxXxxxxx.xxxx()
MAJOR	Multi-threading - Class's readObject() method is synchronized
MAJOR	Correctness - Random value from 0 to 1 is coerced to the integer 0
MAJOR	Correctness - Bad attempt to compute absolute value of signed 32-bit hashcode
MAJOR	Correctness - Bad attempt to compute absolute value of signed random integer
MAJOR	Bad practice - Negating the result of compareTo()/compare()
MAJOR	Bad practice - Method ignores exceptional return value
MAJOR	Multi-threading - Return value of putIfAbsent ignored, value passed to putIfAbsent reused
MAJOR	Multi-threading - Constructor invokes Thread.start()
MAJOR	Bad practice - Non-serializable value stored into instance field of a serializable class
MAJOR	Bad practice - Class is Externalizable but doesn't define a void constructor
MAJOR	Bad practice - Transient field that isn't set by deserialization.
MAJOR	Correctness - Dead store due to switch statement fall through
MAJOR	Correctness - Dead store due to switch statement fall through to throw
MAJOR	Bad practice - Static initializer creates instance before all static final fields assigned
MAJOR	Performance - Should be a static inner class
MAJOR	Performance - Could be refactored into a named static inner class
MAJOR	Performance - Could be refactored into a static inner class
MAJOR	Correctness - Deadly embrace of non-static inner class and thread local
MAJOR	Correctness - Unnecessary type check done using instanceof operator
MAJOR	Multi-threading - Method spins on field
MAJOR	Correctness - Method attempts to access a prepared statement parameter with index 0
MAJOR	Correctness - Method attempts to access a result set field with index 0
MAJOR	Bad practice - Method ignores results of InputStream.skip()
MAJOR	Multi-threading - Call to static Calendar
MAJOR	Multi-threading - Call to static DateFormat
MAJOR	Multi-threading - Static Calendar field

MAJOR	Multi-threading - Static DateFormat
MAJOR	Correctness - Unneeded use of currentThread() call, to call interrupted()
MAJOR	Correctness - Static Thread.interrupted() method invoked on thread instance
MAJOR	Bad practice - Certain swing methods needs to be invoked in Swing thread
MAJOR	Multi-threading - Wait with two locks held
MAJOR	Correctness - Value annotated as carrying a type qualifier used where a value that must not carry that qualifier is required
MAJOR	Correctness - Comparing values with incompatible type qualifiers
MAJOR	Correctness - Value that might not carry a type qualifier is always used in a way requires that type qualifier
MAJOR	Correctness - Value that might carry a type qualifier is always used in a way prohibits it from having that type qualifier
MAJOR	Correctness - Value annotated as never carrying a type qualifier used where value carrying that qualifier is required
MAJOR	Multi-threading - Unsynchronized get method, synchronized set method
MAJOR	Bad practice - Usage of GetResource may be unsafe if class is extended
MAJOR	Multi-threading - Method does not release lock on all paths
MAJOR	Multi-threading - Method does not release lock on all exception paths
MAJOR	Performance - Method calls static Math class method on a constant value
MAJOR	Correctness - Uncallable method defined in anonymous class
MAJOR	Correctness - Uninitialized read of field in constructor
MAJOR	Correctness - Uninitialized read of field method called from constructor of superclass
MAJOR	Correctness - Primitive array passed to function expecting a variable number of object arguments
MAJOR	Multi-threading - An increment to a volatile field isn't atomic
MAJOR	Multi-threading - A volatile reference to an array doesn't treat the array elements as volatile
MAJOR	Multi-threading - Synchronization on getClass rather than class literal
MAJOR	Performance - Inefficient use of keySet iterator instead of entrySet iterator
MAJOR	Multi-threading - Class's writeObject() method is synchronized but nothing else is
MAJOR	Security - Servlet reflected cross site scripting vulnerability in error page
MAJOR	Security - Servlet reflected cross site scripting vulnerability
MAJOR	Security - Bad hexadecimal concatenation
MAJOR	Security - Blowfish usage with short key
MAJOR	Security - Cipher with no integrity
MAJOR	Security - Message digest is custom
MAJOR	Security - DES/DESede is insecure
MAJOR	Security - ECB mode is insecure
MAJOR	Security - Hard Coded Password
MAJOR	Security - Hazelcast symmetric encryption
MAJOR	Security - NullCipher is insecure

MAJOR	Security - Cipher is susceptible to Padding Oracle
MAJOR	Security - Potential Path Traversal (file read)
MAJOR	Security - Potential Path Traversal (file write)
MAJOR	Security - Predictable pseudorandom number generator
MAJOR	Security - Regex DOS (ReDOS)
MAJOR	Security - RSA usage with short key
MAJOR	Security - RSA with no padding is insecure
MAJOR	Security - Static IV
MAJOR	Security - Unencrypted Socket
MAJOR	Security - Unvalidated Redirect
MAJOR	Security - TrustManager that accept any certificates
MAJOR	Security - XSSRequestWrapper is a weak XSS protection
MAJOR	Security - Potential XSS in Servlet
MAJOR	Avoid Array Loops
MAJOR	Big Integer Instantiation
MAJOR	Boolean Instantiation
MAJOR	Class Cast Exception With To Array
MAJOR	Integer Instantiation
MAJOR	Missing Static Method In Non Instantiatable Class
MAJOR	Simplify Conditional
MAJOR	String Instantiation
MAJOR	Unused Null Check In Equals
MAJOR	Use Arrays As List
MAJOR	Use Index Of Char
MAJOR	Assignments should not be made from within sub-expressions
MAJOR	Sections of code should not be \"commented out\"
MAJOR	Local variables should not shadow class fields
MAJOR	The Object.finalize() method should not be called
MAJOR	Nested blocks of code should not be left empty
MAJOR	Standard outputs should not be used directly to log anything
MAJOR	Collapsible \"if\" statements should be merged
MAJOR	Unused \"private\" fields should be removed
MAJOR	Magic numbers should not be used
MAJOR	Utility classes should not have public constructors
MAJOR	Try-catch blocks should not be nested
MAJOR	Synchronized classes Vector, Hashtable, Stack and StringBuffer should not be used
MAJOR	Enumeration should not be implemented

MAJOR	Exception handlers should preserve the original exceptions
MAJOR	Empty arrays and collections should be returned instead of null
MAJOR	Unused method parameters should be removed
MAJOR	Xxxxxxxxx and Error should not be caught
MAJOR	Lambdas and anonymous classes should not have too many lines of code
MAJOR	Classes from \"sun.*\" packages should not be used
MAJOR	Exception types should not be tested using \"instanceof\" in catch blocks
MAJOR	\"equals\" method overrides should accept \"Object\" parameters
MAJOR	Xxxxxx.xxx() should not be called directly
MAJOR	Methods should not be named \"tostring\", \"hashcode\" or \"equal\"
MAJOR	Non-constructor methods should not have the same name as the enclosing class
MAJOR	Floating point numbers should not be tested for equality
MAJOR	\"StringBuilder\" and \"StringBuffer\" should not be instantiated with a character
MAJOR	Methods should not have too many lines
MAJOR	Variables should not be self-assigned
MAJOR	\"NullPointerException\" should not be explicitly thrown
MAJOR	\"NullPointerException\" should not be caught
MAJOR	Identical expressions should not be used on both sides of a binary operator
MAJOR	\"Object.wait(...)\" should never be called on objects that implement \"java.util.concurrent.locks.Condition\"
MAJOR	\"Iterator.hasNext()\" should not call \"Xxxxxxxx.xxxx()\"
MAJOR	Synchronization should not be based on Strings or boxed primitives
MAJOR	Two branches in a conditional structure should not have exactly the same implementation
MAJOR	Classes should not be compared by name
MAJOR	Custom serialization method signatures should meet requirements
MAJOR	Reflection should not be used to check non-runtime annotations
MAJOR	Invalid \"Date\" values should not be used
MAJOR	\"BigDecimal(double)\" should not be used
MAJOR	Collections should not be passed as arguments to their own methods
MAJOR	\"hashCode\" and \"toString\" should not be called on array instances
MAJOR	Non-serializable classes should not be written
MAJOR	Values should not be uselessly incremented
MAJOR	\"Double.longBitsToDouble\" should not be used for \"int\"
MAJOR	Primitives should not be boxed just for \"String\" conversion
MAJOR	Objects should not be created only to \"getClass\"
MAJOR	Classes extending java.lang.Thread should override the \"run\" method
MAJOR	Dissimilar primitive wrappers should not be used with the ternary operator without explicit casting
MAJOR	Silly equality checks should not be made

MAJOR	Classes named like \"Exception\" should extend \"Exception\" or a subclass
MAJOR	Inappropriate \"Collection\" calls should not be made
MAJOR	Return values from functions without side effects should not be ignored
MAJOR	\"toString()\" and \"clone()\" methods should not return null
MAJOR	Servlets should not have mutable instance fields
MAJOR	Null pointers should not be dereferenced
MAJOR	\"wait\", \"notify\" and \"notifyAll\" should only be called when a lock is obviously held on an object
MAJOR	Inner class calls to super class methods should be unambiguous
MAJOR	\"Threads\" should not be used where \"Runnables\" are expected
MAJOR	Classes with only \"static\" methods should not be instantiated
MAJOR	Non-serializable objects should not be stored in \"HttpSession\" objects
MAJOR	\"Lock\" objects should not be \"synchronized\"
MAJOR	Blocks should be synchronized on \"private final\" fields
MAJOR	\"notifyAll\" should be used
MAJOR	Conditionally executed blocks should be reachable
MAJOR	Unused \"private\" methods should be removed
MINOR	Singular Field
MINOR	Use String Buffer Length
MINOR	Class variable fields should not have public accessibility
MINOR	Empty statements should be removed
MINOR	Modifiers should be declared in the correct order
MINOR	Method names should comply with a naming convention
MINOR	Class names should comply with a naming convention
MINOR	Interface names should comply with a naming convention
MINOR	Field names should comply with a naming convention
MINOR	Local variable and method parameter names should comply with a naming convention
MINOR	Type parameter names should comply with a naming convention
MINOR	Package names should comply with a naming convention
MINOR	Boolean literals should not be redundant
MINOR	Return of boolean expressions should not be wrapped into an \"if-then-else\" statement
MINOR	Throwable.printStackTrace(...) should not be called
MINOR	String.valueOf() should not be appended to a String
MINOR	Case insensitive string comparisons should be made without intermediate upper or lower casing
MINOR	Public constants and fields initialized at declaration should be \"static final\" rather than merely \"final\"
MINOR	Classes that override \"clone\" should be \"Cloneable\" and call \"super.clone()\"
MINOR	Overriding methods should do more than simply call the same method in the super class
MINOR	\"equals(Object obj)\" and \"hashCode()\" should be overridden in pairs

MINOR	\"equals(Object obj)\" should be overridden along with the \"compareTo(T obj)\" method
MINOR	Method parameters, caught exceptions and foreach variables' initial values should not be ignored
MINOR	A \"while\" loop should be used instead of a \"for\" loop
MINOR	Declarations should use Java collection interfaces such as \"List\" rather than specific implementation classes such as \"LinkedList\"
MINOR	\"public static\" fields should be constant
MINOR	Unused local variables should be removed
MINOR	Local variables should not be declared and then immediately returned or thrown
MINOR	Strings should not be concatenated using '+' in a loop
MINOR	\"==\" and \"!=\" should not be used when \"equals\" is overridden
MINOR	Classes and methods that rely on the default system encoding should not be used
MINOR	The non-serializable super class of a \"Serializable\" class should have a no-argument constructor
MINOR	\"Serializable\" inner classes of \"Serializable\" classes should be static
MINOR	Fields in non-serializable classes should not be \"transient\"
MINOR	\"Serializable\" inner classes of non-serializable classes should be \"static\"
MINOR	Boxing and unboxing should not be immediately reversed
MINOR	\"final\" classes should not have \"protected\" members
MINOR	\"equals\" methods should be symmetric and work for subclasses
MINOR	Math should not be performed on floats
MINOR	\"finalize\" should not set fields to \"null\"
MINOR	\"compareTo\" should not return \"Integer.MIN_VALUE\"
MINOR	Ints and longs should not be shifted by zero or more than their number of bits-1
MINOR	Math operands should be cast before assignment
MINOR	\"compareTo\" results should not be checked for specific values
MINOR	Mutable fields should not be \"public static\"
MINOR	Comments should not be located at the end of lines of code
MINOR	Useless imports should be removed
INFO	Style - Questionable cast to abstract collection
INFO	Style - Questionable cast to concrete collection
INFO	Style - Unchecked/unconfirmed cast
INFO	Style - Unchecked/unconfirmed cast of return value from method
INFO	Style - Method uses the same code for two branches
INFO	Style - Dead store of null to local variable
INFO	Style - Dead store to local variable that shadows field
INFO	I18n - Consider using Locale parameterized version of invoked method
INFO	Style - Code contains a hard coded reference to an absolute pathname
INFO	Style - Call to unsupported method
INFO	Style - Invocation of substring(0), which returns the original value

INFO	Malicious code - Classloaders should only be created inside doPrivileged block
INFO	Malicious code - Method invoked that should be only be invoked inside a doPrivileged block
INFO	Malicious code - May expose internal representation by returning reference to mutable object
INFO	Malicious code - May expose internal representation by incorporating reference to mutable object
INFO	Malicious code - May expose internal static state by storing a mutable object into a static field
INFO	Style - Unusual equals method
INFO	Style - Initialization circularity
INFO	Style - Unsigned right shift cast to short/byte
INFO	Style - Computation of average could overflow
INFO	Style - Integer remainder modulo 1
INFO	Style - Vacuous comparison of integer value
INFO	Experimental - Potential lost logger changes due to weak reference in OpenJDK
INFO	Malicious code - Public static method may expose internal representation by returning array
INFO	Malicious code - Field should be both final and package protected
INFO	Malicious code - Field is a mutable array
INFO	Malicious code - Field is a mutable Hashtable
INFO	Malicious code - Field should be package protected
INFO	Style - Dereference of the result of readLine() without nullcheck
INFO	Style - Immediate dereference of the result of readLine()
INFO	Style - Load of known null value
INFO	Style - Possible null pointer dereference due to return value of called method
INFO	Style - Possible null pointer dereference on branch that might be infeasible
INFO	Style - Parameter must be non-null but is marked as nullable
INFO	Style - Read of unwritten public or protected field
INFO	Experimental - Method may fail to clean up stream or resource on checked exception
INFO	Style - Class exposes synchronization and semaphores in its public interface
INFO	Style - Redundant comparison of non-null value to null
INFO	Style - Redundant comparison of two null values
INFO	Style - Redundant nullcheck of value known to be non-null
INFO	Style - Redundant nullcheck of value known to be null
INFO	Style - Exception is caught when Exception is not thrown
INFO	Style - Class implements same interface as superclass
INFO	Style - Method checks to see if result of String.indexOf is positive
INFO	Style - Method discards result of readLine after checking if it is non-null
INFO	Style - Remainder of 32-bit signed random integer
INFO	Style - Private readResolve method not inherited by subclasses
INFO	Experimental - Class too big for analysis

INFO	Style - Write to static field from instance method
INFO	Style - Value required to have type qualifier, but marked as unknown
INFO	Style - Value required to not have type qualifier, but marked as unknown
INFO	Style - Useless control flow
INFO	Style - Useless control flow to next line
INFO	Style - Unread public/protected field
INFO	Style - Unused public or protected field
INFO	Style - Field not initialized in constructor but dereferenced without null check
INFO	Style - Unwritten public or protected field
INFO	Style - Method directly allocates a specific implementation of xml interfaces
INFO	Security - Potentially sensitive data in a cookie
INFO	Security - Use of ESAPI Encryptor
INFO	Security - Tainted filename read
INFO	Security - Found JAX-RS REST endpoint
INFO	Security - Found JAX-WS SOAP endpoint
INFO	Security - Untrusted Content-Type header
INFO	Security - HTTP headers untrusted
INFO	Security - Untrusted Referer header
INFO	Security - Untrusted User-Agent header
INFO	Security - Untrusted servlet parameter
INFO	Security - Untrusted query string
INFO	Security - Untrusted Hostname header
INFO	Security - Untrusted session cookie value
INFO	Security - Found Spring endpoint
INFO	Security - Found Struts 1 endpoint
INFO	Security - Found Struts 2 endpoint
INFO	Security - Struts Form without input validation
INFO	Security - Found Tapestry page
INFO	Security - FilenameUtils not filtering null bytes
INFO	Security - Found Wicket WebPage
INFO	Unused Modifier

Quadro 2 – Classificação de severidade PHP

Severidade	Item de verificação PHP
BLOCKER	Switch cases should end with an unconditional \"break\" statement
BLOCKER	Track lack of copyright and license headers

BLOCKER	Variable variables should not be used
BLOCKER	\"exit(...)\" and \"die(...)\" statements should not be used
BLOCKER	Functions and variables should not be defined outside of classes
BLOCKER	\"$this\" should not be used in a static context
BLOCKER	Credentials should not be hard-coded
BLOCKER	\"open_basedir\" should limit file access
BLOCKER	\"allow_url_fopen\" and \"allow_url_include\" should be disabled
BLOCKER	\"session.use_trans_sid\" should not be enabled
BLOCKER	\"enable_dl\" should be disabled
BLOCKER	\"file_uploads\" should be disabled
CRITICAL	Expressions should not be too complex
CRITICAL	Constant names should comply with a naming convention
CRITICAL	String literals should not be duplicated
CRITICAL	Control structures should use curly braces
CRITICAL	\"if ... else if\" constructs should end with \"else\" clauses
CRITICAL	Statements should end with a \"case default\" clause
CRITICAL	Classes should not be too complex
CRITICAL	Control flow statements \"if\", \"for\", \"while\", \"switch\" and \"try\" should not be nested too deeply
CRITICAL	Code should not be dynamically injected and executed
CRITICAL	Functions should not be too complex
CRITICAL	References should not be passed to function calls
CRITICAL	Functions should not be nested too deeply
CRITICAL	\"global\" should not be used
CRITICAL	Parentheses should not be used for calls to \"echo\"
CRITICAL	Session-management cookies should not be persistent
CRITICAL	Cognitive Complexity of functions should not be too high
MAJOR	Source files should not have any duplicated blocks
MAJOR	Failed unit tests should be fixed
MAJOR	Branches should have sufficient coverage by tests
MAJOR	Source files should have a sufficient density of comment lines
MAJOR	Lines should have sufficient coverage by tests
MAJOR	Skipped unit tests should be either removed or fixed
MAJOR	Lines should not be too long
MAJOR	Files should not have too many lines of code
MAJOR	Collapsible \"if\" statements should be merged
MAJOR	Unused \"private\" fields should be removed
MAJOR	Functions should not have too many parameters
MAJOR	Nested blocks of code should not be left empty
MAJOR	Local variables should not have the same name as class fields
MAJOR	Generic exceptions ErrorException, RuntimeException and Exception should not be thrown
MAJOR	Track uses of \"FIXME\" tags
MAJOR	Functions should not contain too many return statements
MAJOR	Unused \"private\" methods should be removed

MAJOR	Useless \"if(true) {...}\" and \"if(false){...}\" blocks should be removed
MAJOR	\"switch case\" clauses should not have too many lines of code
MAJOR	Unused function parameters should be removed
MAJOR	Classes should not be coupled to too many other classes (Single Responsibility Principle)
MAJOR	Statements should be on separate lines
MAJOR	Sections of code should not be \"commented out\"
MAJOR	\"for\" loop stop conditions should be invariant
MAJOR	Functions should not have too many lines of code
MAJOR	Classes should not have too many methods
MAJOR	\"switch\" statements should not have too many \"case\" clauses
MAJOR	Function argument names should be unique
MAJOR	Deprecated predefined variables should not be used
MAJOR	PHP 4 constructor declarations should not be used
MAJOR	\" construct\" functions should not make PHP 4-style calls to parent constructors
MAJOR	Variables should not be self-assigned
MAJOR	Short-circuit logic should be used to prevent null pointer dereferences in conditionals
MAJOR	Jump statements should not be followed by dead code
MAJOR	Identical expressions should not be used on both sides of a binary operator
MAJOR	Method arguments with default values should be last
MAJOR	Classes should not have too many fields
MAJOR	Objects should not be created to be dropped immediately without being used
MAJOR	Related \"if/else if\" statements and \"cases\" in a \"switch\" should not have the same condition
MAJOR	Two branches in a conditional structure should not have exactly the same implementation
MAJOR	Files should contain only one top-level class or interface each
MAJOR	Files should not contain inline HTML
MAJOR	Deprecated functions should not be used
MAJOR	Files that define symbols should not cause side-effects
MAJOR	Classes should not have too many lines of code
MAJOR	\"php_sapi_name()\" should not be used
MAJOR	The names of methods with boolean return values should start with \"is\" or \"has\"
MAJOR	PHP parser failure
MAJOR	Multiline blocks should be enclosed in curly braces
MAJOR	Class constructors should not create other objects
MAJOR	Configuration should not be changed dynamically
MAJOR	\"cgi.force_redirect\" should be enabled
MAJOR	Increment (++) and decrement (--) operators should not be used in a method call or mixed with other operators in an expression
MAJOR	Non-empty statements should change control flow or have at least one side-effect
MAJOR	\"goto\" statement should not be used
MINOR	Method and function names should comply with a naming convention
MINOR	Class names should comply with a naming convention
MINOR	Tabulation characters should not be used
MINOR	An open curly brace should be located at the end of a line
MINOR	An open curly brace should be located at the beginning of a line

MINOR	A close curly brace should be located at the beginning of a line
MINOR	Empty statements should be removed
MINOR	Modifiers should be declared in the correct order
MINOR	Boolean literals should not be redundant
MINOR	Return of boolean expressions should not be wrapped into an \"if-then-else\" statement
MINOR	Files should contain an empty newline at the end
MINOR	Lines should not end with trailing whitespaces
MINOR	Interface names should comply with a naming convention
MINOR	Field names should comply with a naming convention
MINOR	Local variable and function parameter names should comply with a naming convention
MINOR	Overriding methods should do more than simply call the same method in the super class
MINOR	A \"while\" loop should be used instead of a \"for\" loop
MINOR	\"switch\" statements should have at least 3 \"case\" clauses
MINOR	Comments should not be located at the end of lines of code
MINOR	Unused local variables should be removed
MINOR	Local variables should not be declared and then immediately returned or thrown
MINOR	File names should comply with a naming convention
MINOR	\"<?php\" and \"<?=\" tags should be used
MINOR	The \"var\" keyword should not be used
MINOR	More than one property should not be declared per statement
MINOR	Only LF character (Unix-like) should be used to end lines
MINOR	Closing tag \"?>\" should be omitted on files containing only PHP
MINOR	PHP keywords and constants \"true\", \"false\", \"null\" should be lower case
MINOR	Method visibility should be explicitly declared
MINOR	\"elseif\" keyword should be used in place of \"else if\" keywords
MINOR	Source code should comply with formatting standards
MINOR	\"final\" should not be used redundantly
MINOR	Files should not contain characters before \"<?php\"
MINOR	Errors should not be silenced
MINOR	\"require_once\" and \"include_once\" should be used instead of \"require\" and \"include\"
MINOR	String literals should not be concatenated
MINOR	\"&&\" and \"\|\|\" should be used
MINOR	Static members should be referenced with \"static
MINOR	Colors should be defined in upper case
MINOR	Superglobals should not be accessed directly
MINOR	Perl-style comments should not be used
MINOR	Alias functions should not be used
MINOR	\"sleep\" should not be called
INFO	Track uses of \"TODO\" tags

ANEXO VII

Glossário

TERMO	SIGNIFICADO
Scrum	O Scrum é o framework no qual pessoas buscam dividir e priorizar o backlog em problemas menos complexos para entregar produtos com um alto valor agregado e em prazos reduzidos. O Scrum contempla alguns ritos essenciais: Sprint Planning, Sprint Review e Sprint Retrospective.
Framework	É um conjunto de conceitos usado para resolver um problema de um domínio específico.
Backlog da Sprint/Iteração	É o conjunto de itens do backlog do produto selecionados para a sprint / iteração, uma previsão de funcionalidade e o trabalho necessário para fornecer essa funcionalidade. O backlog da sprint / iteração torna visível todo o trabalho que o time de desenvolvimento identifica como necessário para atingir o objetivo da sprint / iteração.
Backlog do Produto	É uma lista ordenada de tudo a ser realizado para criar, manter e sustentar um produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto. O product owner é o responsável pelo backlog do produto, incluindo seu conteúdo, disponibilidade e ordenação.
Build	Momento em que o time realiza o trabalho de acordo com o fluxo de execução da sprint.
Design Thinking	É um método prático-criativo de solução de problemas ou questões, com vistas a um resultado futuro. Nesse sentido, é uma forma de pensar baseada ou focada em soluções, com um objetivo inicial, em vez de começar com um determinado problema.
DevSecOps	Colaboração entre desenvolvimento, segurança da informação e operações, permeando todos os ciclos de elaboração de um produto.
Refinamento	Evento de refinamento dos itens de backlog do produto que possuem a possibilidade de serem executados nas próximas sprints / iterações.

TERMO	SIGNIFICADO
Ideação	Etapa que tem como objetivo formatar as demandas, olhando-as com maior clareza e profundidade e imergindo no problema para compreender o contexto e a perspectiva do cliente e, a partir disso, identificar e priorizar as necessidades do usuário que irão nortear a geração de soluções que estejam de acordo com o contexto do assunto trabalhado, gerando o backlog do produto. Para isso, utilizam- se as ferramentas de Design Thinking que estimulam a criatividade.
Iteração	É um período de tempo definido em que se produz uma versão (incremento) do software, junto com a documentação correspondente a essa versão. A iteração possui tarefas que representam o fluxo de trabalho que deve ser executado dentro dela. É um pequeno ciclo de desenvolvimento ou manutenção dentro da fase em que se produz um incremento do software.
Inception	Workshop de uma semana de trabalho colaborativo, no qual a equipe vai entender os objetivos do produto, seus principais usuários e seu escopo funcional de alto nível de uma forma que a duração do projeto possa ser estimada e uma estratégia de lançamento incremental de MVPs possa ser identificada.
MVP	O mínimo produto viável – em inglês, minimum viable product (MVP) – é a versão mais simples de um produto que pode ser disponibilizada para o negócio. Ele determina quais são as funcionalidades mais essenciais para que se tenha o mínimo de produto funcional que possa agregar valor para o negócio (produto mínimo) e que possa ser efetivamente utilizado e validado pelo usuário final (produto viável).
Protótipo de média fidelidade	Também chamado de wireframes, são protótipos muito utilizados já em um trabalho que envolve arquitetura de informação. Utilizam softwares de prototipação, tais como o Balsamiq ou Axure e tem como principais objetivos: Definir a estrutura de conteúdo da interface; Definir o peso, relevância e relação entre os elementos; Criar um layout básico (com conteúdos e imagens de marcação); Criar simulações simples de uso (ex: clicar em um botão); O protótipo de média fidelidade também se torna algo navegável, ou seja, o usuário consegue navegar entre as diferenças seções do projeto.

TERMO	SIGNIFICADO
Conceito INVEST	INVEST é uma abordagem amplamente utilizada para escrever histórias. Ao criar histórias, é muito importante fazer estórias de acordo com a abordagem INVEST. O acrônimo INVEST: I (Independent) – N (Negotiable) – V (Valuable) – E (Estimable) – S (Small) – T (Testable). Esse acrônimo ajuda a lembrar de um conjunto de critérios, ou lista de verificação, para avaliar a qualidade de uma estória de usuário. Se a estória não cumprir um destes critérios, a equipe deve reformular, ou mesmo considerar uma reescrita, que se traduz no ato físico de rasgar o cartão (post-it) da velha estória e escrever um novo.
Product Owner	O product owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do time de desenvolvimento. É a única pessoa responsável por gerenciar o backlog do produto.
Release	É uma versão estável do software que pode ser utilizada pelos usuários finais. É a entrega de um ou mais incrementos do software prontos, gerado pelo time de desenvolvimento em uma ou mais sprints/iteraçóes sucessivas, para que sejam utilizados.
Scrum Master	Responsável por orientar, treinar, ensinar e auxiliar o Time Scrum no entendimento e uso adequado do Scrum. O scrum master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum.
Sprint	É o nome de um ciclo de desenvolvimento do Scrum (é a iteração do framework Scrum). As sprints podem ter a duração de 2 a 4 semanas, sendo esse o time box do ciclo. Todas as sprints de um projeto devem ter a mesma duração. A sprint serve como um container para outros eventos e atividades do Scrum que contêm um planejamento da sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da sprint e uma retrospectiva da sprint. As sprints são feitas consecutivamente, sem intervalos intermediários, isto é, uma nova sprint inicia imediatamente após a conclusão da sprint anterior.
Sprint Planning	Evento onde é feito o planejamento de uma sprint / iteração. O propósito é alinhar o time de desenvolvimento e o product owner sobre o que e como será executado o trabalho dentro da sprint / iteração.
Sprint Retrospective	Evento que ocorre ao final de uma sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e quais ações serão tomadas para melhorar.

TERMO	SIGNIFICADO
Sprint Review	Evento em que o time apresenta o que foi alcançado durante a sprint.
Squad	É um time multifuncional, auto organizado, que possui a expertise para desenvolver todos os aspectos do produto e a autonomia para decidir o que construir, como construir e como trabalhar juntos enquanto constroem. Um Squad de desenvolvimento e manutenção geralmente é composto pelos seguintes perfis: Arquiteto de Software, Analista, Analista UX, Scrum Master, Analista devops, líder técnico e time de desenvolvimento.
Time de Desenvolvimento	Consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “pronto” ao final de cada sprint / iteração. Os times de desenvolvimento são estruturados para organizar e gerenciar seu próprio trabalho. Eles são auto organizados, são multifuncionais, possuindo todas as habilidades necessárias para criar o incremento do produto.
Time Scrum	Consiste de um Product Owner, o time de desenvolvimento e um Scrum Master. Times Scrum são auto organizáveis e multifuncionais, por isso, possuem todas as competências necessárias e escolhem qual a melhor forma para completarem seu trabalho.

Proposta Comercial

MODELO DE PROPOSTA COMERCIAL
Razão Social
CNPJ
Inscrição Estadual
Endereço
Telefone/Fax
Representante Legal
Identidade
CPF
Descrição	Unidade de Medida	Quantidade total estimada (12 meses) ( A )	Valor Unitário da UST ( B )	Preço Total Estimado (12 meses) ( C )
Contratação de serviços especializados em desenvolvimento e sustentação de software em conformidade com a metodologia adotada na Prodemge	UST (Unidade de Serviço Técnico)	92.928	R$ -	R$ - (A) x (B)
Preço total estimado (por extenso):	R$	( )
Prazo de Validade da Proposta: 60 (sessenta) dias
Declaro que nos preços propostos encontram-se incluídos todos os custos diretos e indiretos, os encargos sociais e trabalhistas, fiscais e demais despesas necessárias ao cumprimento integral das obrigações decorrentes da licitação.
Local, data e assinatura

1. As propostas deverão ser obrigatoriamente apresentadas em conjunto com a Planilha de Custos e Formação de Preços.

2. Os licitantes deverão considerar o Anexo IX - Referência Salarial no momento da formulação das propostas. O referido anexo será utilizado para aferição da exequibilidade da proposta.

Referência Salarial

1. JUSTIFICATIVA

Essa referência salarial tem como objetivo prezar pela qualidade do serviço que será prestado, visando que o fornecedor dedique profissionais com a devida qualificação técnica e com baixa rotatividade, visto que seu salário estará compatível com a base salarial do mercado, minimizando assim impactos de retrabalho e atrasos com recorrentes repasses de conhecimento do negócio por parte da Prodemge para o time do Prestador de Serviços.

2. CUSTO MENSAL DE TIME ÁGIL PADRÃO

Conforme disposto no Anexo III - Perfil dos Profissionais, existe uma previsão bem definida de composição de time ágil padrão, que será usado na maioria dos projetos ágeis novos e de melhoria. As regras para compartilhamento de profissionais também estão dispostas no referido item.

Pesquisa realizada em novembro/2020, em sítios de informações sobre salários e vagas de emprego, especializados em pesquisa salarial junto a dados oficiais divulgados do Novo CAGED, eSocial e Empregador Web pela Secretaria da Previdência e Trabalho do Ministério da Economia (antigo MTE), resultou na coleta de salários de acordo com as funções previstas na presente contratação, consideradas as disposições do Anexo III.

Com a finalidade de simplificar o cálculo e compatibilizar os salários fornecidos pelos referidos sítios, utilizou-se o papel de desenvolvedor pleno para todos os desenvolvedores (ressalte-se que a planilha fornecida pela empresa deverá diferenciar o desenvolvedor Sênior e os 2 desenvolvedores Plenos previstos). O mesmo para a função Líder Técnico / Líder de Desenvolvimento que, em alguns casos, considerou-se, como referência, o valor praticado para a função de Supervisor Técnico.

Média salarial em BH/Brasil (base: novembro/2020)

CARGOS \| Fonte:	Xxxxxxxxx.xxx	Xxxxxxxxxxxxxx.xxx.xx	Xxxxx.xxx.xx	Xxxxxxxxx.xxx.xx	xxxxxxx.xxx.xx	xxxxx.xxx	MÉDIA
1. Scrum Master (SM)	N/T	N/T	3.633,98	7.029,00	N/T	8.038,00	6.233,66
2. Analista UX/UI / Designer Interação	3.883,38	4.038,71	3.009,88	3.500,00	2.767,12	4.500,00	3.616,52
3. Analista de Requisitos	5.426,59	5.643,65	4.200,88	4.263,00	5.173,26	5.300,00	5.001,23
4. Arquiteto de software	10.186,16	10.593,61	10.210,01	8.252,00	N/T	9.500,00	9.748,36
5. Analista de dados	N/T	5.825,01	3.123,41	4.105,00	5.982,52	3.100,00	4.427,19
6. Líder Técnico */ Líder de desenvolvimento	5.210,00	5.783,81	3.207,39	N/T	N/T	4.900,00	4.775,30
7. Desenvolvedor	3.710,00	3.802,38	2.461,53	3.417,00	5.173,26	4.800,00	3.894,03

(*) Supervisor técnico

Document Metadata

Table of Contents

TERMO DE REFERÊNCIA

Document Metadata