TERMO DE REFERÊNCIA
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 ▪ 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 | |
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. |
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