GOVERNO DO ESTADO DE MINAS GERAIS
GOVERNO DO ESTADO DE MINAS GERAIS
PRODEMGE COMPANHIA DE TECNOLOGIA DA INFORMAÇÃO DO ESTADO DE MINAS GERAIS
Gerência de Compras Processo SEI nº 5140.01.0001223/2024-29
EDITAL DE LICITAÇÃO
Procedimento das Estatais n. º 006/2024
Processo Eletrônico n. º: 5141001 019/2024 Tipo de Licitação: Modo de disputa ABERTO Regime de contratação: PREÇO POR ITEM Critério de Julgamento: MENOR PREÇO
OBJETO: CONTRATAÇÃO DE SERVIÇOS ESPECIALIZADOS EM DESENVOLVIMENTO E SUSTENTAÇÃO DE SOFTWARE, SOB DEMANDA, 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”.
Abertura da sessão pública: 23/05/2024 às 09:30 horas
Regra de participação: ABERTA A TODOS OS LICITANTES
Edital disponível nos sítios: xxx.xxxxxxxx.xxx.xx e xxx.xxxxxxx.xx.xxx.xx
OBS.: ESTE RECIBO DEVERÁ SER REMETIDO À GERÊNCIA DE COMPRAS (GCO) – PRODEMGE, PELO E-MAIL XXXXXXX@XXXXXXXX.XXX.XX P/ EVENTUAIS COMUNICAÇÕES AOS INTERESSADOS, QUANDO NECESSÁRIO.
(Assinatura)
RECIBO
A Empresa retirou o Edital de licitação do processo PROCEDIMENTO DAS ESTATAIS n° 006/2024 e deseja ser informada de qualquer alteração pelo e-mail ou
pelo fax: .
, aos / / .
Nome completo:
Cargo:
EDITAL DE LICITAÇÃO ÍNDICE
1- PREÂMBULO
2- DO OBJETO
3- DOS PEDIDOS DE ESCLARECIMENTOS E DA IMPUGNAÇÃO DO ATO CONVOCATÓRIO
4- DAS CONDIÇÕES DE PARTICIPAÇÃO
5- DO CREDENCIAMENTO
6- DA PRESTAÇÃO DOS SERVIÇOS
7- DAS PROPOSTAS COMERCIAIS
8- DA SESSÃO PÚBLICA
9- DOS RECURSOS
10- DA REABERTURA DA SESSÃO PÚBLICA
11 - DA ADJUDICAÇÃO E DA HOMOLOGAÇÃO
12- DO CONTRATO
13- DA GARANTIA DA EXECUÇÃO
14- DO PAGAMENTO
15 – DAS SANÇÕES ADMINISTRATIVAS
16- DISPOSIÇÕES GERAIS
ANEXO I - TERMO DE REFERÊNCIA ANEXO II - MINUTA DE CONTRATO
EDITAL DE LICITAÇÃO
PROCEDIMENTO DAS ESTATAIS n° 006/2024
CRITÉRIO DE JULGAMENTO: MENOR PREÇO POR ITEM
1 – PREÂMBULO
1.1 – A Companhia de Tecnologia da Informação do Estado de Minas Gerais – PRODEMGE, CNPJ 16.636.540/0001-04, localizada à Xxx xx Xxxxx, 0000, Xxxxxx Xxxxxxx, Xxxx Xxxxxxxxx/XX, tendo em vista o Espelho de Pedidos n.º 048 de 22/03/2024, Deliberação de Diretoria 027, de 13/03/2024 e Portaria da Diretoria PD 026/2023 de 06/12/2023 de designação de Agente de Licitação/Contratação ou Comissão Especial de Licitação e Equipe de Apoio, torna pública, para conhecimento dos interessados a abertura do Procedimento das Estatais n° 006/2024, na forma eletrônica, Modo de Disputa Aberto, pelo critério de julgamento “Menor Preço por item” por intermédio do site xxx.xxxxxxx.xx.xxx.xx, destinada à contratação do objeto citado no item 2 – Do Objeto, deste Edital.
1.2 – O presente Edital foi elaborado conforme minuta padrão aprovada, nos termos do artigo 45 do Regulamento Interno de Licitações e Contratos da PRODEMGE- RILC, versão 6, pela Assessoria Jurídica por meio do Parecer PJD-002/2024.
1.3 – A competência para assinatura deste Edital foi delegada pela Portaria da Diretoria PD 001/2024, de 05/01/2024.
1.4 – A presente licitação será regida por este Edital e seus anexos, pelo disposto no Regulamento Interno de Licitações e Contratos da PRODEMGE – RILC, versão 6, pela Lei Federal nº. 13.303, de 30 de junho de 2016, pelo Decreto Federal nº 8.945, de 27 de dezembro de 2016, pela Lei Complementar n. º 123/2006, de 14 de dezembro de 2006, pelos Decretos Estaduais nº 45.902 de 27 de janeiro de 2012, e atualizações posteriores, n°
47.154 de 20 de fevereiro de 2017 e nº 47.437/2018 de 26 de junho de 2018 e atualizações posteriores.
1.5 - A sessão pública ocorrerá no dia 23/05/2024 às 09:30 horas no Portal de Compras do Estado de Minas Gerais - xxx.xxxxxxx.xx.xxx.xx.
RECEBIMENTO DAS PROPOSTAS COMERCIAIS:
INÍCIO dia 13/05/2024 às 16:00 horas
TÉRMINO dia 23/05/2024 às 09:30 horas.
ABERTURA DAS PROPOSTAS COMERCIAIS: INÍCIO dia 23/05/2024 às 09:30 horas.
1.6 - Para todas as referências de tempo contidas neste Edital será observado o horário de Brasília (DF).
1.7 – A moeda desta licitação é o Real, vedada qualquer oferta vinculada à moeda estrangeira.
2 – DO OBJETO
2.1 - Constitui objeto desta licitação a contratação de serviços especializados em desenvolvimento e sustentação de software, sob demanda, 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”, conforme detalhamentos contidos no Anexo I – Termo de Referência e Anexo II – Minuta de Contrato.
2.2 – A licitação terá lote único, conforme subitem 3.1 do Anexo I - Termo de Referência:
Item | Descrição | Quantidade | Unidade | Regra de participação |
1 | Serviços especializados em desenvolvimento e sustentação de software | 330.000 | UST | Aberto a todos os licitantes |
2.3 - Em caso de divergência entre as especificações do objeto descritas no
xxx.xxxxxxx.xx.xxx.xx e as especificações constantes deste Edital, prevalecerão as últimas.
3 - DOS PEDIDOS DE ESCLARECIMENTOS E DA IMPUGNAÇÃO DO ATO CONVOCATÓRIO
3.1–Os esclarecimentos de dúvidas e pedidos de impugnações quanto ao Edital e seus anexos poderão ser solicitados, exclusivamente, pelo e-mail compras@prodemge. xxx.xx, até 5 (cinco) dias úteis antes da data fixada para a ocorrência do certame.
3.1.1 - Nos pedidos de esclarecimentos e/ou impugnações encaminhados, os interessados deverão se identificar (CNPJ, razão social e nome do representante legal, se pessoa jurídica e nome completo e CPF, se pessoa física).
3.1.2 - Não serão recebidos pedidos de esclarecimentos e/ou impugnações enviados por meios diversos do previsto no subitem 3.1.
3.1.3 – Os esclarecimentos e impugnações serão respondidos em até 03 (três) dias úteis e as respostas serão disponibilizadas no site da PRODEMGE (xxx.xxxxxxxxxx.xxxxxxxx.xxx.xx) e no Portal de Compras do Estado de Minas Gerais (xxx.xxxxxxx.xx.xxx.xx) para conhecimento de todos os interessados.
3.2 – A contagem dos prazos de respostas a que se refere este edital exclui-se o dia do início e inclui- se o do vencimento, considerando dias úteis. Só se iniciam e expiram os prazos em dia de expediente da administração.
3.3 - Qualquer modificação no Edital exige divulgação pelo mesmo instrumento de publicação em que se deu o texto original, reabrindo-se o prazo inicialmente estabelecido, exceto quando, inquestionavelmente, a alteração não afetar a formulação das propostas.
3.4 - As respostas aos pedidos de esclarecimentos e às impugnações aderem a este Edital dele fazendo parte, vinculando a Administração, os licitantes e demais interessados.
4 – DAS CONDIÇÕES DE PARTICIPAÇÃO
4.1 – Poderão participar do processo licitatório os interessados que atenderem a todas as exigências contidas neste Edital e seus anexos, previamente cadastrados perante o Portal de Compras do Estado de Minas Gerais.
4.1.1 – O representante do licitante deverá identificar, em campo próprio do sistema
eletrônico, o tipo do segmento da empresa (microempresa, empresa de pequeno porte,
agricultores familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas) que representa, para fins de cumprimento das disposições da Lei Complementar nº 123/2006 e Decreto Estadual 47.437/2018.
4.1.1.1 - Para fins do disposto neste edital, o enquadramento dos beneficiários indicados no caput do art. 3º do Decreto Estadual nº 47.437, de 26 de junho de 2018 se dará da seguinte forma:
4.1.1.1.1- Microempresa, empresa de pequeno porte, agricultores familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas,
conforme definido nos incisos I e II do caput § 4º do art. 3º da Lei Complementar Federal nº 123, de 14 de dezembro de 2006;
4.1.1.1.2 - Agricultor familiar, conforme definido na Lei Federal nº 11.326, de 24 de julho de 2006;
4.1.1.1.3 - Produtor rural pessoa física, conforme disposto na Lei Federal nº 8.212, de 24 de julho de 1991;
4.1.1.1.4- Microempreendedor individual, conforme definido no § 1º do art. 18-A da Lei Complementar Federal nº 123, de 14 de dezembro de 2006;
4.1.1.1.5 - Sociedade cooperativa, conforme definido no art. 34 da Lei Federal nº 11.488, de 15 de junho de 2007, e no art. 4º da Lei Federal nº 5.764, de 16 de dezembro de 1971.
4.1.1.1.6 - Serão beneficiados pelo tratamento diferenciado, simplificado e favorecido conforme disposto neste edital o produtor rural pessoa física e o agricultor familiar
conceituado na Lei Federal nº 11.326, de 2006, que estejam em situação regular junto à
Previdência Social e ao município, e que tenham auferido receita bruta anual até o limite de que trata o inciso II do caput do art. 3º da Lei Complementar Federal nº 123, de 2006.
4.2 – Estão impedidos de participar interessados que:
4.2.1 - Se enquadrem em um ou mais dispositivos dos artigos 38 e 44 da Lei 13.303/2016;
4.2.2 - Se enquadrem em um ou mais dispositivos do artigo 67 do Regulamento Interno de Licitações e Contratos da Prodemge – RILC, versão 6, disponível em xxx.xxxxxxxx.xxx.xx
4.2.3 - Empresas que tenham como proprietários controladores ou diretores membros dos poderes legislativos da União, Estados ou Municípios ou que nelas exerçam funções
remuneradas, conforme art. 54, II, “a”, x/x xxx. 00, XX, xxxxx xx Xxxxxxxxxxxx xx Xxxxxxxxx.
4.3 – A participação de empresas reunidas em consórcio não será permitida, conforme item 15 do Anexo I – Termo de Referência.
4.4 – A subcontratação não será admitida, conforme item 16 do Anexo I - Termo de Referência.
4.5 - A participação nesta licitação implica a aceitação integral dos termos e condições
previstas neste Edital e seus Anexos, bem como das normas legais e regulamentares que o fundamentam.
5 – DO CREDENCIAMENTO
5.1 – A Prodemge utilizará o Cadastro Geral de Fornecedores do Governo do Estado de Minas Gerais – CAGEF. Para acesso ao sistema eletrônico, os interessados deverão cadastrar-se pelo site xxx.xxxxxxx.xx.xxx.xx (opção “CADASTRO DE NOVOS FORNECEDORES”), conforme instruções nele contidas e no Decreto Estadual 45.902/2012 e atualizações posteriores.
5.2 – O licitante deverá credenciar pelo menos um representante para desempenhar as atividades em seu nome.
5.3 – O cadastramento dar-se-á pela atribuição de chave de identificação e de senha, pessoal e intransferível, cujo uso é de responsabilidade exclusiva do licitante, incluindo qualquer
transação efetuada diretamente ou por seu representante, não cabendo ao provedor do sistema ou à Secretaria de Estado de Planejamento e Gestão - SEPLAG, coordenadora do sistema eletrônico, responsabilidade por eventuais danos decorrentes de uso indevido da senha, ainda que por terceiros.
5.3.1 – O cadastramento do licitante junto ao sistema eletrônico implica na responsabilidade legal pelos atos praticados e a presunção de capacidade técnica para a realização das
transações inerentes ao processo licitatório, sob pena da aplicação das sanções previstas no item 15 do presente Edital.
5.4 – O licitante que desejar obter os benefícios previstos no Capítulo V da Lei Complementar 123/2006, disciplinados no Decreto Estadual 47.437/2018, deverá comprovar a condição de microempresas ou empresas de pequeno porte, agricultores familiares, produtores rurais
pessoas físicas, microempreendedores individuais e sociedades cooperativas no momento do seu credenciamento no CAGEF, conforme subitem 5.1, com a apresentação de:
5.4.1 - Caso inscrito no Registro Público de Empresas Mercantis, a declaração de
enquadramento arquivada ou a certidão simplificada expedida pela Junta Comercial, ou equivalente, da sede da microempresas ou empresas de pequeno porte, agricultores
familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas.
5.4.2 - Caso inscrito no Registro Civil de Pessoas Jurídicas, a declaração de enquadramento
arquivada ou a Certidão de Breve Relato do Cartório de Registro Civil de Pessoas Jurídicas, ou equivalente, da sede da microempresas ou empresas de pequeno porte, agricultores
familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas.
5.4.3 - Na hipótese de o Cartório de Registro Civil de Pessoas Jurídicas não emitir o
documento mencionado no item 5.4.2 deste edital, nos termos da Lei Complementar Federal n° 123/2006, deverá ser apresentada, perante o CAGEF, declaração de porte feita pelo
representante da empresa, sob as penas da lei, mediante a comprovação dessa circunstância.
5.5 – Informações complementares a respeito do cadastramento deverão ser obtidas no site xxx.xxxxxxx.xx.xxx.xx em Cadastro de Fornecedores ou e-mail
xxxxxxxx.xxxxxxxxxxxx@xxxxxxxxxxxx.xx.xxx.xx.
6 – DA PRESTAÇÃO DOS SERVIÇOS
6.1 - As condições de prestação dos serviços estão descritas no Anexo I – Termo de Referência e Anexo II – Minuta de Contrato.
7 – DAS PROPOSTAS COMERCIAIS
7.1 – As Propostas Comerciais deverão ser cadastradas exclusivamente por meio do site: xxx.xxxxxxx.xx.xxx.xx, até às 09:30 horas do dia 23/05/2024, após o preenchimento do formulário eletrônico, com manifestação em campo próprio do sistema sobre atendimento aos requisitos de habilitação, inexistência de fatos impeditivos, restrição na documentação fiscal (para microempresa, empresa de pequeno porte, agricultores familiares, produtores
rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas, se for o caso) e ciência e concordância com as informações contidas no Edital e Anexos.
7.2 – No momento do cadastramento da proposta inicial será obrigatório, no campo “arquivos do fornecedor”, o arquivo solicitado no subitem 27.1 do Anexo I - Termo de
Referência.
7.2.1 - O licitante poderá incluir até 05 (cinco) arquivos de 20Mb cada, referentes à proposta comercial, antes do início da sessão pública.
7.2.2 – Até o horário previsto para o término do envio das propostas, os licitantes poderão alterar a proposta anteriormente enviada.
7.3 – Caso o prazo de validade não esteja expressamente indicado na proposta, considerar- se-á o prazo de 90 (noventa) dias consecutivos para efeito de seu julgamento.
7.4 – Nos preços propostos deverão estar incluídos todos os tributos, encargos e custos, transporte, hospedagem, alimentação, instalações físicas ou quaisquer outros ônus que
porventura possam recair sobre a prestação de serviços, objeto da presente licitação, que em nenhuma hipótese poderão ser repassados à Prodemge.
7.4.1 - A Prodemge está enquadrada no regime de recolhimento Isento ou Imune sobre Operações relativas à Circulação de Mercadorias e sobre Prestações de Serviços de
Transporte Interestadual e Intermunicipal e de Comunicação (ICMS).
7.4.2 - A isenção do ICMS concedida aos fornecedores estabelecidos no estado de Minas Gerais NÃO se aplica à PRODEMGE, devendo os fornecedores mineiros informar nas
propostas enviadas os preços sem a dedução relativa ao mencionado imposto
7.5 – O licitante deverá lançar no campo próprio do Portal de Compras-MG, o valor unitário e total do item e o valor total da proposta para o lote.
7.5.1 – No Sistema, valor total do item é obtido pela multiplicação do valor unitário do item pela quantidade solicitada.
7.5.2 - No Sistema, o valor total da proposta para o lote único é igual ao valor total do item.
7.5.3 - No caso de eventual divergência entre o valor proposto pelo licitante no sistema eletrônico e o constante dos Anexos da Proposta, prevalecerá o primeiro.
7.5.4 – O Portal de Compras-MG não efetua as operações, porém, emite aviso de erro na parte superior da tela quando estão incorretas e solicita a correção.
7.6 – O licitante declarado vencedor deverá realizar a estratificação de sua proposta adequando aos valores finais por ele ofertados.
7.7 – Esclarecimentos de dúvidas sobre envio de propostas e outros procedimentos no uso
do Portal de Compras-MG poderão ser obtidos no site xxx.xxxxxxx.xx.xxx.xx em Cadastro de Fornecedores ou e-mail xxxxxxxx.xxxxxxxxxxxx@xxxxxxxxxxxx.xx.xxx.xx.
8 – DA SESSÃO PÚBLICA
8.1 – DO INÍCIO DA SESSÃO
8.1.1 – No dia e horário marcado no preâmbulo, será aberta a sessão pública desta licitação, pelo Titular da sessão, através do sistema eletrônico do Portal de Compras de Minas Gerais.
8.1.1.1 – O Titular da sessão poderá suspender, adiar ou reabrir a sessão pública, a qualquer momento, informando previamente os licitantes por meio do sistema eletrônico
supramencionado.
8.1.2 - Cabe ao licitante acompanhar as operações no sistema eletrônico durante a sessão
pública da licitação, ficando responsável pelo ônus decorrente da inobservância de qualquer
mensagem emitida pelo sistema, pelo Titular da sessão ou em caso de desconexão.
8.1.2.1 - A PRODEMGE não responderá pela desconexão de qualquer licitante com o sistema eletrônico e sua ocorrência não prejudicará a conclusão válida da sessão da licitação.
8.1.3 – O Titular da sessão e equipe de apoio abrirão as propostas, que serão imediatamente analisadas, observando as regras de aceitação previstas no Edital.
8.1.4 – Os representantes dos licitantes participantes têm a obrigação de permanecer presentes à sessão, desde o início previsto no Edital até a adjudicação, ressalvadas as interrupções informadas no chat pelo Titular da sessão.
8.1.5 – Se na data indicada para abertura da sessão não houver expediente na PRODEMGE, a abertura da sessão fica transferida para o primeiro dia útil seguinte, observados o mesmo
horário e local.
8.2 - DA SESSÃO DE LANCES
8.2.1 – Abertas as propostas de preços, o sistema as ordenará automaticamente, classificando os licitantes.
8.2.2 – Após a análise das propostas, o Titular da sessão iniciará a sessão de lances e
convidará os licitantes classificados a apresentarem lances por meio do sistema eletrônico.
8.2.3 – Durante o transcurso da sessão pública, serão divulgadas, em tempo real, todas as mensagens trocadas no chat do sistema, inclusive valor e horário do menor lance registrado pelos licitantes, vedada a identificação do licitante.
8.2.4 – O licitante poderá oferecer lance inferior ao último por ela ofertado e registrado no sistema.
8.2.4.1 – No caso de lance inferior a 50% do último lance/proposta registrada para aquele licitante, o sistema enviará um alerta desse fato antes da confirmação.
8.2.4.2 – Se o licitante encaminhar lance incorreto poderá solicitar a exclusão do último lance ao Titular da sessão.
8.2.4.2.1 – O Titular da sessão não poderá excluir um lance se o licitante não clicar no local próprio solicitando a exclusão.
8.2.4.2.2 – É de total responsabilidade do licitante a solicitação de exclusão ou a manutenção de seus lances.
8.2.4.2.3 – No caso de empate entre dois ou mais lances, prevalecerá aquele que for recebido e registrado em primeiro lugar pelo sistema.
8.2.5 – Caso o licitante não realize lances, permanecerá o valor da proposta eletrônica apresentada para efeito da classificação final.
8.2.5.1 – Quando os lances estiverem acima do orçamento estimado, o Titular da sessão alertará aos licitantes para que melhores valores sejam propostos.
8.2.6 – No caso de desconexão com o Titular da sessão, no decorrer da etapa competitiva do certame, o sistema eletrônico poderá permanecer acessível aos licitantes para a recepção
dos lances. O Titular da sessão, quando possível, dará continuidade à sua atuação no certame, sem prejuízo dos atos realizados.
8.2.6.1– Quando a desconexão persistir por tempo superior a 10 (dez) minutos, a sessão
pública será suspensa e terá reinício somente após decorridas 24 (vinte e quatro) horas após a comunicação aos participantes, no sítio eletrônico utilizado para divulgação da licitação.
8.2.6.2 – Caso as 24 (vinte e quatro) horas após a desconexão recaia sobre dia não útil ou dia sem expediente na Prodemge, o prazo será referente ao primeiro dia útil subsequente.
8.2.7 – O encerramento da fase de lances será por decisão do Titular da sessão, mediante
encaminhamento de aviso de “TEMPO DE IMINÊNCIA”, com a informação dos minutos para início do tempo randômico.
8.2.7.1 – Transcorrido o tempo de iminência, terá início o tempo randômico, período de tempo de 5 (cinco) até 30 (trinta) minutos aleatoriamente determinado pelo sistema
eletrônico – Portal de Compras-MG, findo o qual será automaticamente encerrada a recepção de lances.
8.2.8 – Encerrada a fase de lances, quando a diferença entre o melhor lance e o subsequente for igual ou inferior a 10%, a disputa poderá ser reiniciada, a critério exclusivo do Titular da
Sessão.
8.2.8.1 – Caso seja reiniciada a disputa, o fornecedor até então melhor classificado não participa da nova disputa e os lances estão limitados ao valor ofertado pelo licitante até então melhor classificado.
8.2.9 – No caso de empate ficto, encerrado o tempo randômico, o sistema identificará a existência de microempresa, empresa de pequeno porte, agricultores familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas
participante.
8.2.9.1 – O Titular da sessão convocará a microempresa, empresa de pequeno porte,
agricultores familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas detentora da melhor proposta dentre aquelas que estejam na situação de empate ficto identificado pelo Portal, ou seja, cujos valores sejam iguais ou superiores até 10% (dez por cento) em relação ao valor apresentado pelo licitante melhor
classificado, para que apresente nova proposta, inferior à melhor proposta, no prazo de 05
(cinco) minutos, sob pena de preclusão do direito de preferência, conforme estabelecido no art. 44 da Lei Complementar n° 123/2006 e do art. 7 do Decreto Estadual n° 47.437/2018.
8.2.9.2 - Se a microempresa, empresa de pequeno porte, agricultores familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas não
apresentar nova proposta, o Titular da sessão convocará as Microempresas ou Empresas de Pequeno Porte remanescentes que estiverem na situação descrita acima, identificadas pelo Portal, na ordem classificatória, para o exercício do mesmo direito.
8.2.10 - Não havendo mais nenhuma microempresa, empresa de pequeno porte, agricultores familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas em situação de empate, o sistema emitirá mensagem, cabendo ao Titular da sessão dar encerramento à disputa do item.
8.2.11 - O critério de desempate somente se aplicará quando a melhor oferta inicial não tiver sido apresentada por microempresa, empresa de pequeno porte, agricultores familiares,
produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas.
8.2.12 - Havendo empate entre 2 (duas) propostas, serão utilizados, na ordem em que se
encontram enumerados, os critérios de desempate, dispostos no art. 55 da Lei 13.303/2016.
8.2.13 – Caso não se realizem lances, será verificada a conformidade entre a proposta de menor preço e o orçamento estimado da contratação estabelecido para o certame.
8.2.14 – Havendo apenas uma proposta, esta poderá ser aceita, desde que atenda a todos os termos do Edital e seus anexos e que seu preço seja compatível com o orçamento estimado para o processo licitatório.
8.3 - DA VERIFICAÇÃO DA EFETIVIDADE DA PROPOSTA
8.3.1 – Declarada encerrada a etapa competitiva de lances, as ofertas serão ordenadas
automaticamente e o sistema informará quem é o licitante detentor da melhor oferta, assim como o valor de referência do certame.
8.3.2 – O Titular da sessão verificará a efetividade da melhor proposta, com o apoio da área técnica, desclassificando-a se:
8.3.2.1 - Contiver vícios insanáveis;
8.3.2.2 - Descumprir especificações técnicas constantes no presente Edital e seus Anexos;
8.3.2.3 - Apresentar preços manifestamente inexequíveis;
8.3.2.4 - Estiver acima do orçamento estimado para a contratação, após a negociação;
8.3.2.5 - Não tiver sua exequibilidade demonstrada, quando exigido pela PRODEMGE;
8.3.2.6 - Apresentar desconformidade com outras exigências do instrumento convocatório, salvo se for possível a acomodação a seus termos antes da adjudicação do objeto e desde
que não prejudique a atribuição de tratamento isonômico entre os licitantes.
8.3.3 – Quando necessário, o Titular da sessão poderá solicitar ao licitante melhor
classificado que demonstre a exequibilidade de seus preços, através do envio, por meio eletrônico, de planilha de custos, readequada ao orçamento proposto, ou prova de
contratação em andamento com preços semelhantes, para análise e decisão sobre a aceitação do menor preço, observando o disposto no artigo 56, § 1º a 4º, da Lei
13.303/2016.
8.3.3.1 – O Titular da sessão poderá solicitar à área técnica análise e emissão de
manifestação por escrito sobre a(s) planilha(s) de preços apresentada(s) pelo licitante, a fim de aferir a exequibilidade da proposta.
8.3.3.2 - São consideradas inexequíveis as propostas que não venham a ser demonstrada pelo ofertante, no prazo estabelecido pelo Titular da sessão, sua viabilidade através de
documentação que comprove que os custos são coerentes com os praticados no mercado e compatíveis com a execução do objeto do futuro contrato.
8.3.4 - Para aceitabilidade da proposta, os valores finais serão examinados relativamente à sua adequação, proporcionalidade e exequibilidade aos preços unitários e global estimados pela PRODEMGE.
8.3.5 - Se a proposta não for aceitável o Titular da sessão examinará as demais propostas subsequentes classificadas, verificando a sua aceitabilidade, quanto ao objeto e valor,
procedendo à verificação das condições de habilitação do licitante, até a apuração de uma proposta que atenda ao Edital e seus anexos.
8.3.6 - Nos casos de divergência entre o valor global apresentado para o lote e a soma/multiplicação dos quantitativos e preços unitários de seus itens, prevalecerá o
resultado da soma/multiplicação dos quantitativos e preços unitários dos itens.
8.3.6.1 - Erros em preenchimento de planilhas não constituem motivo para a desclassificação da proposta. A planilha poderá ser ajustada pelo licitante, no prazo indicado pelo Titular da sessão, desde que não haja majoração do preço global nem dos unitários.
8.4 - DA NEGOCIAÇÃO
8.4.1 - Confirmada a efetividade do lance ou da melhor proposta que obteve a primeira colocação na etapa de julgamento, ou que passe a ocupar essa posição em decorrência da desclassificação de outra que tenha obtido colocação superior, será iniciada a fase de
negociação com o licitante que a apresentou, objetivando condições mais vantajosas à PRODEMGE.
8.4.2 - O Titular da sessão solicitará contraproposta, via sistema, ao licitante que tenha
apresentado o melhor preço, para que seja obtida melhor proposta, vedada a negociação em condições diferentes das previstas em edital.
8.4.3 - Se o valor da proposta vencedora estiver acima do orçamento estimado para o certame, o licitante será informado e será solicitada contraproposta imediatamente.
8.4.3.1 - O Titular da sessão poderá convocar o licitante para enviar proposta negociada, por meio de funcionalidade disponível no sistema.
8.4.3.2 - Será concedido o prazo de até 02 (duas) horas para a efetivação de contraproposta, prorrogável por mais 02 (duas) horas, a pedido do licitante.
8.4.4 - A negociação será feita com os demais licitantes, segundo a ordem inicialmente
estabelecida, quando o preço do primeiro colocado, mesmo após a negociação, permanecer acima do orçamento estimado.
8.4.5 - Se depois de adotada a providência referida no subitem 8.4.3 não for obtido valor igual ou inferior ao orçamento estimado para a contratação, será revogada a licitação.
8.4.6 - Sendo aceitável a oferta de menor valor, será verificado o atendimento das condições habilitatórias pelo licitante que a tiver formulado.
8.4.7 - Constatado o atendimento das exigências fixadas no Edital e seus anexos, o licitante será habilitado e terá a melhor proposta válida.
8.5 – DA DOCUMENTAÇÃO DE HABILITAÇÃO
8.5.1 - O licitante pode utilizar o Cadastro Geral de Fornecedores do Estado de Minas Gerais - CAGEF, possuindo o Certificado de Registro Cadastral (CRC) – Cadastramento, emitido pelo Portal de Compras, com a validade em vigor, para substituir os documentos de habilitação exigidos no subitem 8.5 deste Edital, conforme seu nível de cadastramento.
8.5.1.1 - Na hipótese dos documentos indicados no CRC estarem vencidos, estes deverão ser apresentados com validade em vigor.
8.5.2 - Serão analisados no certificado somente os documentos exigidos para este certame, sendo desconsiderados todos os outros documentos, mesmo que estejam com validade expirada.
8.5.3 – Para fins de habilitação, será feita consulta ao CAFIMP – Cadastro de Fornecedores Impedidos de Licitar com a Administração Pública Estadual, conforme disposto no art. 52 do
Decreto Estadual 45.902/2012 e atualizações posteriores e também ao CEIS – Cadastro Nacional de Empresas Inidôneas e Suspensas.
8.5.4 - Será inabilitado o licitante que:
8.5.4.1 - Deixar de apresentar quaisquer dos documentos exigidos neste item ou apresentá- los com vícios, fora do prazo estabelecido, com a validade expirada ou em desconformidade com o previsto neste Edital e seus Anexos.
8.5.4.2 - Não atenderem a quaisquer dos requisitos exigidos para a habilitação.
8.5.5 - Qualquer interessado poderá requerer que se realizem diligências para aferir a
exequibilidade e a legalidade das propostas, devendo apresentar as provas ou os indícios que fundamentam a suspeita.
8.5.5.1 - Em caso de diligência, poderão ser apresentados apenas documentos
complementares àqueles anteriormente enviados, sendo vedada a inclusão de documentos novos.
8.5.5.1.1 - A vedação à inclusão de novo documento não alcança documento destinado a atestar condição de habilitação preexistente à abertura da sessão pública, apresentado em sede de diligência.
8.5.6 - Rejeitada a documentação de habilitação, o Titular da sessão inabilitará o licitante e retornará à fase de verificação de efetividade do lance ou proposta do próximo colocado, na ordem de classificação, observadas as regras deste Edital e seus Anexos.
8.5.7 – HABILITAÇÃO JURÍDICA
8.5.7.1 – Registro comercial, no caso de empresa individual.
8.5.7.2 – Ato constitutivo, estatuto ou contrato social em vigor, devidamente registrado, em se tratando de sociedades comerciais sendo que, no caso de sociedades por ações, deverá se fazer acompanhar da ata de eleição de seus administradores.
8.5.7.3 – Inscrição do ato constitutivo, no caso de sociedades civis, acompanhada de ato formal de designação de diretoria em exercício.
8.5.7.4 – Decreto de autorização ou equivalente, em se tratando de empresa ou sociedade
estrangeira em funcionamento no país, e ato de registro ou autorização para funcionamento expedido pelo órgão competente quando a atividade assim o exigir.
8.5.7.5 – Comprovação do seu enquadramento como microempresa, empresa de pequeno porte, agricultores familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas mediante apresentação do contrato social ou outro documento legal, se for o caso.
8.5.8 – QUALIFICAÇÃO ECONÔMICO-FINANCEIRA
8.5.8.1 – Certidão negativa de falência, ou recuperação judicial, ou liquidação judicial, ou de execução patrimonial, conforme o caso, expedida pelo distribuidor da sede do licitante ou de seu domicílio, dentro do prazo previsto na própria certidão, ou, na omissão desta, expedida a menos de 180 (cento e oitenta) dias, contados da data da sua apresentação.
8.5.8.1.1 – No caso de comarcas com mais de um cartório distribuidor, deverão ser apresentadas as certidões de cada distribuidor.
8.5.9 – REGULARIDADE FISCAL
8.5.9.1 – Prova de inscrição no Cadastro de Pessoas Físicas – CPF, ou no Cadastro Nacional de Pessoas Jurídicas do Ministério da Fazenda – CNPJ, conforme o caso;
8.5.9.2 – Prova de regularidade perante o Fundo de Garantia do Tempo de Serviço – FGTS.
8.5.9.3 – Prova de regularidade perante o Instituto Nacional do Seguro Social – INSS, mediante a apresentação de Certidão Negativa de Débitos relativos aos Tributos Federais e a Dívida Ativa da União.
8.5.9.4 – Prova de regularidade perante a Fazenda Pública do Estado de Minas Gerais, mediante a apresentação da Certidão de Débito Tributário - CDT.
8.5.9.5 – Para empresa com enquadramento na categoria de microempresa, empresa de pequeno porte, agricultores familiares, produtores rurais pessoas físicas, microempreendedores individuais e sociedades cooperativas, a comprovação de regularidade fiscal será realizada observando os seguintes procedimentos:
8.5.9.5.1 - O licitante deverá encaminhar, conforme subitem 8.5, toda a documentação exigida neste Edital, inclusive os documentos relativos à regularidade fiscal, mesmo que esta apresente alguma restrição, conforme dispõem os artigos 42 e 43 da Lei Complementar nº. 123/2006 e artigo 6º do Decreto Estadual 47.437/2018.
8.5.9.5.2 – Havendo alguma restrição na comprovação da regularidade fiscal será assegurado o prazo de 5 (cinco) dias úteis, prorrogáveis por igual período, a critério da Prodemge, para a regularização da documentação, cujo termo inicial corresponderá ao momento em que o licitante for declarado vencedor do certame, nos termos do § 1º do artigo 43 da Lei Complementar Federal 123/2006.
8.5.9.5.3 – A não regularização da documentação, no prazo previsto no subitem anterior, implicará decadência do direito à contratação, sem prejuízo das sanções previstas na legislação vigente.
8.5.10 – QUALIFICAÇÃO TÉCNICA
Em atendimento ao item 11 do Anexo I - Termo de Referência:
8.5.10.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 e as tecnologias citadas no Anexo I-A. Este atestado, ou conjunto de atestados, deve ter, no mínimo,
110.000 (cento e dez mil) UST´s de serviço prestados no período de 24 meses consecutivos e deverá conter de forma explícita que a licitante possui experiência obrigatoriamente em:
8.5.10.1.1 - 40.000 UST´s (quarenta mil) na tecnologia Java Platform, Enterprise Edition (Java EE) versão 6.0 ou superior, usando Sistemas de Gerenciamento de Banco de Dados – SGBD - relacionais MS SQL Server, Oracle, MySQL ou PostgreSQL; e
8.5.10.1.2 - 4.000 UST´s (quatro mil) na tecnologia JSF, usando Sistemas de Gerenciamento de Banco de Dados – SGBD - relacionais MS SQL Server, Oracle, MySQL ou PostgreSQL; e
8.5.10.1.3 - 30.000 UST´s (vinte mil) na tecnologia PHP utilizando framework Cake ou Laravel usando Sistemas de Gerenciamento de Banco de Dados – SGBD - relacionais MS SQL Server, Oracle, MySQL ou PostgreSQL;
8.5.10.1.4 - planejamento e execução de testes: unitários, funcionais e não funcionais;
8.5.10.1.5 - desenvolvimento e manutenção de apps para dispositivos móveis nos sistemas operacionais Android e iOS utilizando plataforma Ionic;
8.5.10.1.6 - desenvolvimento ou manutenção de sistemas utilizando certificação digital com aderência à ICP-Brasil;
8.5.10.1.7 - desenvolvimento ou manutenção de sistemas utilizando a tecnologia blockchain compatível código aberto;
8.5.10.1.8 - prestação de serviços técnicos de desenvolvimento e manutenção de sistemas de informação, utilizando metodologias ágeis, em regime de fábrica de software, contendo no mínimo 7 (sete) dos seguintes artefatos, práticas ou equivalentes, que devem ter sido produzidos nos projetos:
• Backlog do Produto;
• Gráfico Burndown ou Burnup;
• Planejamento da liberação (release) ou Roadmap;
• Planejamento da iteração (sprint);
• Quadro Informativo (Kanban);
• Diagrama de fluxo cumulativo;
• Documento de requisitos não funcionais;
• Scripts de teste automatizado;
• História de usuário;
• Documento de mensagens;
8.5.10.1.9 -. 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.5.10.2 - Tendo em vista a especificidade da métrica definida neste objeto, para fins da comprovação das USTs exigidas nos atestados:
8.5.10.2.1 - Serão aceitos atestados em pontos de função (PF), considerando, para efeito de conversão, a proporção de 1 (um) PF para 10 (dez) USTs.
8.5.10.2.2 - Da mesma forma, serão aceitos atestados em horas, fica estabelecida a equivalência entre 01 (uma) UST e 01 (uma) hora de serviço em outros órgãos e empresas.
8.5.10.3 - 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.5.10.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.5.10.4.1 - A recusa do emitente do atestado em prestar esclarecimentos e/ou fornecer documentos comprobatórios, ou sofrer diligências, desconstituirá o Atestado de Capacidade Técnica e poderá, inclusive, configurar prática de falsidade ideológica ensejando investigação criminal e abertura de Processo Administrativo Disciplinar, conforme o caso, para fins de apuração de responsabilidades, além da desclassificação no certame.
8.5.10.5 - Para fins de comprovação, somente serão aceitos os atestados referentes a serviços realizados pela licitante em sua personalidade jurídica própria. Dessa forma, não serão aceitos
atestados em nomes de empresas que pertençam ao seu grupo empresarial para demonstração de sua capacidade técnica.
8.5.10.6 - Com o objetivo de reduzir o tempo de análise do conjunto de atestados a licitante deverá enviar uma planilha contendo um resumo com apontamentos relacionando cada atestado apresentado ao(s) respectivo(s) item(s) atendido(s), bem como o intervalo de datas dos serviços executados.
8.5.10.7 - Para efeito de comprovação do volume de serviços, é permitido o somatório de contratos executados. Para isso, a licitante deverá fixar, a seu critério, intervalo de tempo de tempo de 24 meses consecutivos, independentemente do ano no qual o volume de serviços foi executado.
8.5.11 – DECLARAÇÃO
8.5.11.1 – Deverão ser apresentadas também a(s) seguinte(s) declaração(ões) e/ou documento(s):
a) Declaração formal, sob penas da lei de que, caso vencedora do certame, irá disponibilizar os profissionais necessários à execução dos serviços, bem como comprovar a sua qualificação técnica, em atendimento ao subitem 27.3 do Anexo I - Termo de Referência.
8.5.11.2 – As declarações apresentadas para este certame não precisam ter firma reconhecida. As assinaturas serão conferidas pelo Titular da sessão e equipe de apoio com base na documentação do representante legal.
8.5.11.3 – Em caso de dúvida sobre a autenticidade da assinatura, pode-se exigir o reconhecimento de firma, conforme previsto no artigo 17 da Lei Estadual n. º 14.184/02.
8.5.11.4 – Serão aceitos no processo, para todos os efeitos legais, documentos elaborados e assinados por meio de recursos de certificação digital, realizada por autoridade certificadora credenciada no âmbito da Infraestrutura de Chaves Pública Brasileira - ICP Brasil.
8.6 – DO ENVIO DOS DOCUMENTOS DE HABILITAÇÃO
8.6.1 - A partir da convocação do Titular da sessão, o licitante melhor classificado enviará pelo link disponibilizado no chat do sistema eletrônico do Portal de Compras de Minas Gerais, no prazo máximo de 1 (uma) hora, os documentos exigidos no subitem 8.5 para fins de comprovação das condições de habilitação constantes neste Edital e seus Anexos.
8.6.2 - Em caráter excepcional e caso seja detectado problemas no envio dos documentos de habilitação na forma acima prevista, em decorrência de erros gerados pelo sistema eletrônico, confirmado pela SEPLAG, o Titular da sessão poderá autorizar o envio da documentação através do e-mail xxxxxxx@xxxxxxxx.xxx.xx, no prazo máximo de 01 (uma) hora, conforme disposto no subitem 8.6.1.
8.6.3 - A apresentação de documentos físicos originais somente será exigida se houver dúvida quanto à integridade do arquivo digitalizado.
8.6.4 - Para fins de habilitação, é facultada ao Titular da sessão a verificação de informações e o fornecimento de documentos que constem de sítios eletrônicos de órgãos e entidades das esferas municipal, estadual e federal, emissores de certidões, devendo tais documentos ser juntados ao processo. A Administração não se responsabilizará pela eventual indisponibilidade dos meios eletrônicos, no momento da verificação. Ocorrendo essa indisponibilidade e não sendo apresentados os documentos necessários para verificação, o licitante será inabilitado.
8.6.5 - Todos os documentos apresentados para a habilitação deverão conter, de forma clara e visível, o nome empresarial, o endereço e o CNPJ do fornecedor.
8.6.6 - Se o fornecedor figurar como estabelecimento matriz, todos os documentos deverão estar em nome da matriz.
8.6.7 - Se o fornecedor figurar como filial, todos os documentos deverão estar no nome da filial, com exceção daqueles que, pela própria natureza, comprovadamente são emitidos em nome da matriz.
8.6.8 - Em qualquer dos casos, atestados de capacidade técnica ou de responsabilidade técnica podem ser apresentados em nome e com o número do CNPJ(MF) da matriz ou da filial da empresa licitante.
8.6.9 - O não atendimento de qualquer das condições aqui previstas provocará a inabilitação do licitante vencedor, sujeitando-o, eventualmente, às punições legais cabíveis.
8.7 - DA PROVA DE CONCEITO
8.7.1 - Não haverá prova de conceito para esse certame, conforme subitem 5.9 do Anexo I - Termo de Referência.
9 – DOS RECURSOS
9.1 – Concluída a fase de habilitação, qualquer licitante poderá manifestar a intenção de recorrer, imediata e motivadamente, no prazo de 10 (dez) minutos, através do sistema eletrônico.
9.1.1 - A falta de manifestação imediata e motivada da intenção de recorrer dos licitantes importará decadência do direito de recurso
9.2 – Finalizado o prazo, o Titular da sessão realizará o juízo de admissibilidade das intenções de recurso, decidindo imediatamente sobre o aceite ou não.
9.3 – O não aceite das intenções de recurso deverá ser motivado.
9.4 – Acatada a intenção de recurso, será concedido o prazo de 5 (cinco) dias úteis para apresentação das razões de recurso, ficando as demais licitantes desde logo intimadas para apresentar contrarrazões em igual número de dias, contados do término do prazo do recorrente, sendo-lhes assegurada vista imediata dos autos.
9.5 – O encaminhamento das razões do recurso e de eventuais contrarrazões pelos demais licitantes, deverá ser feito por meio do sistema eletrônico, em formulários próprios do Portal de Compras, exclusivamente.
9.5.1 – Em caso de indisponibilidade do sistema, previamente comprovada pelo Titular da sessão, deverá o recurso, dentro do prazo legal, ser encaminhado para o e-mail xxxxxxx@xxxxxxxx.xxx.xx.
9.6 – Não serão reconhecidos os recursos interpostos após os respectivos prazos legais e em desconformidade com o estabelecido no Edital.
9.7 – Os recursos deverão ser julgados em até 05 (cinco) dias úteis e terão igual prazo para sua publicação nos sites xxx.xxxxxxxxxx.xxxxxxxx.xxx.xx e xxx.xxxxxxx.xx.xxx.xx.
9.8 - O acolhimento de recurso importará a invalidação apenas dos atos insuscetíveis de aproveitamento.
10 – DA REABERTURA DA SESSÃO PÚBLICA
10.1 – Em situações em que um recurso for acolhido, resultando na invalidação de atos e procedimentos anteriores à sessão pública ou na própria anulação da sessão, os atos que foram anulados e aqueles que deles dependem serão realizados novamente”.
10.2 - Todos os licitantes remanescentes deverão ser convocados para acompanhar a sessão reaberta.
10.2.1 - A convocação se dará por meio de avisos no portal de compras, site da Prodemge e publicação no Diário Oficial Eletrônico Minas Gerais.
10.2.2 - A convocação feita por e-mail dar-se-á de acordo com os dados contidos no CAGEF, sendo responsabilidade do licitante manter seus dados cadastrais atualizados.
11 – DA ADJUDICAÇÃO E DA HOMOLOGAÇÃO
11.1 – Inexistindo manifestação recursal, o Titular da sessão pública adjudicará o objeto da licitação ao licitante vencedora, com a posterior homologação do resultado pela Autoridade Administrativa Competente delegada da Prodemge.
11.2 – Havendo interposição de recurso, após o julgamento, a Autoridade Competente da Prodemge adjudicará e homologará o procedimento licitatório ao licitante vencedor.
11.3 – A publicidade da homologação será realizada nos sites xxx.xxxxxxxx.xxx.xx e xxx.xxxxxxx.xx.xxx.xx.
12 – DO CONTRATO
12.1 – O licitante vencedor cujo preço tenha sido adjudicado na ATA DE REALIZAÇÃO DO PROCESSO LICITATÓRIO, terá o prazo de 5 (cinco) dias para assinatura do contrato, podendo ser prorrogado, uma vez, por igual período, devidamente justificado, contados da data de convocação.
12.2 – A adjudicatária deverá comprovar a manutenção das condições demonstradas na habilitação para assinar o contrato.
12.3 – Como requisito para a assinatura do contrato, o licitante vencedora deverá encaminhar os documentos atualizados exigidos no Edital, que estiverem com validade vencida, o Ato constitutivo, estatuto ou contrato social e seus aditivos em vigor, devidamente registrados, em se tratando de sociedades comerciais, e no caso de sociedade de ações, acompanhadas de documentos de eleição de seus administradores assim como cópia do documento de identidade dos responsáveis pela assinatura do contrato.
12.4 – Caso a adjudicatária não apresente situação regular no ato da assinatura do contrato, ou se recuse a assiná-lo, serão convocadas as licitantes na sequência para celebrar o contrato dentro das melhores condições para a administração.
13 - DA GARANTIA EXECUÇÃO
13.1 - Será exigida prestação de garantia contratual pela Contratada, em valor equivalente a 5% (cinco por cento) do valor do Contrato, em até 10 (dez) dias úteis após a assinatura do Contrato, conforme previsto no item 18 do Anexo I - Termo de Referência.
13.2 - O prazo previsto para a apresentação da garantia poderá ser prorrogado, por igual período, quando solicitado pela Contratada durante o respectivo transcurso, e desde que ocorra motivo justificado e aceito pela PRODEMGE.
13.3 - O não recolhimento da garantia no prazo estabelecido no neste item caracteriza inadimplemento contatual, sujeitando a Contratada às sanções previstas neste Edital e seus Anexos.
13.4 - No caso de alteração do valor do contrato, ou prorrogação de sua vigência, a garantia deverá ser readequada ou renovada nas mesmas condições.
13.5 - As demais regras sobre a garantia exigida constam do Anexo II - Minuta do Contrato deste Edital.
14 – DO PAGAMENTO
14.1 - As condições de pagamento estão descritas no Anexo II - Minuta de Contrato.
14.2 – Nenhum pagamento será efetivado sem que a Unidade Administrativa da PRODEMGE, a que incumbir o acompanhamento da execução do(s) serviço(s), ateste que foram correta e integralmente prestados.
14.3 – O atraso na entrega do documento de cobrança implicará prorrogação do vencimento em tantos dias úteis quantos forem os dias de atraso.
15 - DAS SANÇÕES ADMINISTRATIVAS
15.1 – Garantido o contraditório e a ampla defesa, poderão ser aplicadas as sanções previstas nos artigos 82 a 84 da Lei 13.303/2016 e disposições contidas no Regulamento Interno de Licitações e Contratos da Prodemge, versão 6, ao licitante que:
a) deixar de apresentar documentação exigida para o certame;
b) apresentar documentação falsa;
c) ensejar o retardamento da execução do objeto da licitação;
d) não mantiver a proposta;
e) falhar ou fraudar a execução do futuro contrato;
f) tenham sofrido condenação definitiva por praticarem, por meios dolosos, fraude fiscal no recolhimento de quaisquer tributos;
g) tenham praticado atos ilícitos visando a frustrar os objetivos da licitação;
h) demonstrem não possuir idoneidade para contratar com a Prodemge em virtude de atos ilícitos praticados.
i) comportar-se de modo inidôneo, inclusive com a prática de atos lesivos à Administração Pública previstos na Lei Federal nº 12.846/2013.
15.2 – As sanções serão obrigatoriamente registradas no CAFIMP, sem prejuízo das multas e das demais cominações legais previstas no respectivo instrumento contratual.
15.3 - O licitante/A Contratada, notificada da penalidade que poderá lhe ser aplicada, terá o prazo de 10 (dez) dias úteis, a contar da data da notificação, para apresentar defesa prévia.
15.4 - Durante o processo de aplicação de penalidade, se houver indícios de prática de infração administrativa tipificada pela Lei Federal nº 12.846, de 1º de agosto de 2013, e pelo Decreto Estadual nº 46.782, de 23 de junho de 2015, e atualizações posteriores, como ato lesivo à administração pública nacional ou estrangeira, cópias do processo administrativo
necessárias à apuração da responsabilidade da empresa deverão ser remetidas à Controladoria-Geral do Estado, com despacho fundamentado, para ciência e decisão sobre a eventual instauração de investigação preliminar ou Processo Administrativo de Responsabilização – PAR.
16 – DISPOSIÇÕES GERAIS
16.1 – Este Edital deverá ser lido e interpretado na íntegra. Após o encaminhamento da proposta, não serão aceitas alegações de falhas ou irregularidades de quaisquer de suas cláusulas e condições e esta comunicação não terá efeito de recurso.
16.2 – Da sessão de licitação, o sistema gerará ata circunstanciada, na qual estarão registrados todos os atos do procedimento e as ocorrências relevantes, que estará disponível para consulta, após o fechamento do processo, no site xxx.xxxxxxx.xx.xxx.xx.
16.3 – É facultado ao Titular da sessão ou à Autoridade Superior em qualquer fase do julgamento
promover diligência destinada a esclarecer ou complementar a instrução do processo e a aferição do preço ofertado, bem como solicitar a órgãos competentes a elaboração de pareceres técnicos
destinados a fundamentar suas decisões de homologação.
16.3.1 – Em caso de diligência, os documentos devem ser encaminhados para o e-mail: xxxxxxx@xxxxxxxx.xxx.xx, no prazo de até 2 duas horas.
16.3.1.1 - É facultado ao Titular da Sessão prorrogar o prazo estabelecido, a partir de solicitação fundamentada feita no chat pelo licitante, antes de findo o prazo.
16.4 – Os documentos que não possuírem prazo de validade estabelecido pelo órgão expedidor ou pelo Edital, deverão estar datados dos últimos 180 (cento e oitenta) dias até a data de solicitação pelo Titular da sessão.
16.5 - Todos os documentos emitidos em língua estrangeira deverão ser entregues acompanhados da tradução para língua portuguesa, em tradução livre e/ou juramentada.
16.6 – O Titular da sessão, no interesse da Administração, em qualquer fase da licitação, poderá promover correções de vícios sanáveis, erros ou falhas que não alterem a substância das propostas, dos documentos e de sua validade jurídica, relevar omissões puramente formais observadas na documentação e proposta, desde que não contrariem a legislação vigente e não comprometam a lisura da licitação, privilegiando o princípio da eficiência.
16.7 – Caberá à empresa cadastrada acompanhar as operações no sistema eletrônico durante a sessão pública do processo licitatório, ficando responsável pelo ônus decorrente da perda de negócios diante da inobservância de quaisquer mensagens emitidas pelo sistema ou de sua desconexão.
16.8 – A presente licitação poderá ser revogada por razões de interesse público, decorrente de fato superveniente devidamente comprovado, ou anulada, no todo ou em parte, por ilegalidade, de ofício ou por provocação de terceiros, mediante parecer escrito e devidamente comprovado.
16.8.1 – Em caso de revogação do certame, será aberto o prazo de 05 (cinco) dias úteis para manifestação dos interessados, respeitando-se o princípio do contraditório e da ampla defesa.
16.8.1.1 – Não se aplica o disposto no subitem 16.8.1, nos casos em que o desfazimento do processo de contratação ocorrer antes da fase de apresentação de lances ou propostas, nos termos do §3º do artigo 62 da Lei 13.303/2016.
16.9 – O Edital deste processo licitatório poderá ser retirado nos sites ou xxx.xxxxxxxxxx.xxxxxxxx.xxx.xx e xxx.xxxxxxx.xx.xxx.xx.
16.10 – As informações e os atos praticados e pertinentes a presente licitação serão disponibilizados no site da PRODEMGE xxx.xxxxxxxxxx.xxxxxxxx.xxx.xx, garantindo ampla publicidade.
16.11 – Fazem parte integrante deste Edital:
ANEXO I - TERMO DE REFERÊNCIA ANEXO II - MINUTA DE CONTRATO
Belo Horizonte, 10 de maio de 2024
Venância Xxxx Xxxxx xx Xxxxx Assessor Organizacional
Documento assinado eletronicamente por Xxxxxxxx Xxxx Xxxxx Xx Xxxxx, Servidor(a) Público(a), em 10/05/2024, às 11:32, conforme horário oficial de Brasília, com fundamento no art. 6º, § 1º, do Decreto nº 47.222, de 26 de julho de 2017.
A autenticidade deste documento pode ser conferida no site xxxx://xxx.xx.xxx.xx/xxx/xxxxxxxxxxx_xxxxxxx.xxx? acao=documento_conferir&id_orgao_acesso_externo=0, informando o código verificador 87934599 e o código CRC 43FDE9CE.
Referência: Processo nº 5140.01.0001223/2024-29 SEI nº 87934599
TERMO DE REFERÊNCIA
1. Identificação do Processo Processo: nº 006/2024
Procedimento das Estatais: nº 5141001 019/2024
2. Objeto:
Contratação de serviços especializados em desenvolvimento e sustentação de software, sob demanda, 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”.
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 quantidade total de UST (Unidade de Serviço Técnico) é de 330.000 (trezentos e trinta mil).
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 1 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.14 deste Termo de Referência.
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.
3.1. Detalhamento do Lote
O objeto está inserido em item único conforme abaixo:
Item | Qtde | Unidade | Descrição |
01 | 330.000 | UST | Serviços especializados em desenvolvimento e sustentação de software |
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.
4.2.2 Em seguida, é realizada a 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, e o Prestador de Serviços 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.14.
4.2.4 As Sprints (iterações) terão duração entre 1 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 que deverão ser entregues ao final daquela Sprint. A sustentação planejada seguirá o mesmo processo executado para demandas de desenvolvimento seguindo a metodologia ágil.
4.2.5 Entende-se por sustentação planejada, no contexto desse documento, a atividade de modificar e aprimorar um sistema de software após sua entrega. Trata-se, portanto, de implementações de melhorias e mudanças, o que inclui correção de bugs, melhorias de desempenho, atualização de recursos e adaptação a novos requisitos, etc.
4.2.6 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 do 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.7 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.8 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 em Ambiente Tecnológico - Anexo I – D.
4.2.9 O serviço contratado será mensurado em Unidade de Serviço Técnico – UST, conforme descrito no item 4.3 Métrica UST e Atividades.
4.2.10 O Prestador de Serviços poderá atuar em todas as etapas do fluxo apresentado na Figura 1 - Fluxo Geral de Trabalho. 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.11 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 o Prestador 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 à empresa. A execução de uma demanda fora dos padrões de SLA acordados gera, automaticamente, abatimentos em fatura, as quais incidem diretamente sobre o faturamento da empresa quanto à referida demanda.
4.2.12 O fluxo do processo de desenvolvimento de software descrito neste item 4.2 poderá ser alterado durante a execução do contrato, a critério da Prodemge, e o Prestador de Serviços deverá se
adequar a ele em um prazo máximo de até 30 (trinta) dias corridos, a contar da data de recebimento da notificação.
4.2.13 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 o uso para qualquer fim ou comercialização por parte do Prestador de Serviços.
4.2.14 Detalhamento dos Eventos do Fluxo de Processo de Desenvolvimento de Software
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 Prestador de Serviços: ▪ Scrum Master ▪ Líder Técnico ▪ Arquiteto de Software ▪ Analista | ▪ Miro ou Mural Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) | |
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 ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) | |
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 | ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) ▪ Jenkins ▪ Git ▪ Artifactory ▪ Maven ▪ Junit ▪ Sonar ▪ IDEs de desenvolvimento ▪ SGBD | |
Evento Responsável Descrição Entregável Perfis envolvidos Ferramentas envolvidas
Pré- Refinamento (Sprint x +1) | PRODEMGE e Prestador de Serviços | Etapa de refinamento e preparação dos itens de Backlog dos produtos 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 ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) ▪ 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 ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) ▪ InVision / Adobe XD |
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 | ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) |
Evento Responsável Descrição Entregável Perfis envolvidos Ferramentas envolvidas
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 | ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) ▪ 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 | ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) | |
Sprint Pré Review | PRODEMGE e Prestador de Serviços | Evento em que o time verifica internamente o que foi alcançado durante a Sprint, validando todo o trabalho e verificando se está em conformidade com o que foi planejado. | ▪ Apresentação dos resultados ▪ Backlog de ajustes | PRODEMGE: ▪ 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 | ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) | |
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 | ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) |
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. Este evento pode acontecer em duas etapas: Retrospectiva interna (somente o time) e Retrospectiva com o PO. | ▪ 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 | ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) ▪ 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 ▪ Ferramenta de gestão de tarefas (Git, Trello, Redmine, SDM, Jira) |
4.2.15 Homologação de Sistemas
As Sprints serão homologadas pelo Product Owner (PO), após a entrega pelo Prestador de Serviços, nos seguintes termos:
a) O Squad 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 12 - Critérios de Aceitabilidade do Objeto, deste Termo de Referência.
4.2.16 Artefatos / Entregáveis
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 planejada 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.16.1 A relação de artefatos a serem entregues pelo Prestador de Serviços não se limita àqueles citados no item 4.2.16, alíneas (a) a (o). Todo e qualquer artefato produzido deverá ser entregue à Prodemge.
4.2.16.2 As estimativas de esforço, em UST´s, para a elaboração desses artefatos estão definidas no Repertório de USTs - Anexo I – C.
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 - 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.3.1 As atividades pertinentes ao processo de trabalho como: participação nos ritos e reuniões de alinhamentos, por exemplo, não são passíveis de entregáveis, mas também serão dimensionadas em UST, de acordo com o que foi previsto no Repertório de UST’s - Anexo I – C, e serão formalizados via documento padrão da Prodemge, entregue ao final de cada Sprint.
4.3.1.4 As atividades e entregáveis estão detalhados e dimensionados no Repertório de UST’s - Anexo I - C.
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.6 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.
4.4 Fluxo de Sustentação Planejada
4.4.1 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.8.4.5, figura 2 - Fluxo de processo e desenvolvimento/sustentação de sistemas, deste Termo de Referência.
4.4.2 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.5 Estudo do Sistema Legado
4.5.1 Ciente da dificuldade de se obter proficiência e eficiência em sistemas escritos por terceiros, a Prodemge irá demandar o Estudo do Sistema-Legado 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 ou uma equipe de colaboradores-estudados, de acordo com o contexto do Projeto.
4.5.1.1 A depender do tamanho e da complexidade do sistema, será demandado por prazo variável de 1 (um) até 20 (vinte) dias úteis de estudo do sistema, tendo
como limite de critério de faturamento 160 (cento e sessenta) USTs por funcionário capacitado.
4.5.2 O Estudo do Sistema deve gerar os seguintes entregáveis:
4.5.2.1 Para sistemas onde houver apenas ajustes/evoluções da documentação pelo Prestador de Serviço:
a) Detalhamento completo por escrito contemplando o entendimento das funcionalidades, regras de negócio, assim como a apresentação presencial ou por videoconferência sobre o estudo realizado do sistema.
4.5.2.2 Para sistemas onde houver ajustes/evoluções da arquitetura, documentação e código-fonte:
a) Detalhamento completo por escrito contemplando o entendimento das funcionalidades, sua arquitetura tecnológica, incluindo dados técnicos e de
regras de negócio, assim como a apresentação presencial ou por videoconferência sobre o estudo realizado do sistema.
4.5.3 O documento entregue e a apresentação realizada pelo Prestador de Serviços serão avaliados por uma equipe técnica da Prodemge e obterão uma nota indicando “satisfatório” ou “insatisfatório”.
4.5.3.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.
4.5.4 A Prodemge pagará o valor contratado pelo estudo do sistema apenas se a documentação/apresentação obtiverem a nota de “satisfatório”.
4.5.4.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.5.4.2 O custo de retificação, citado no item 4.5.4.1, correrá por conta do Prestador de Serviços.
4.5.4.3 Chama-se de “colaborador-estudado” o colaborador do Prestador de Serviços que passou pelo mencionado Estudo do Sistema e obteve grau “satisfatório” nos entregáveis solicitados: documentação e apresentação.
4.5.5 O Estudo será contratado para a equipe do Prestador de Serviços alocada na Prodemge, conforme previsto no repertório, de acordo com o contexto de cada projeto e das responsabilidades sobre sistemas atribuídas a cada funcionário.
4.5.6 Haja vista o investimento feito pela Prodemge com o Estudo do Sistema, o Prestador de Serviços terá maior condições de prover, com qualidade, as alterações necessárias nos sistemas. No entanto, tal investimento também traz responsabilidades.
4.5.6.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.5.6.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.5.6.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.5.6.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.5.6.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.5.7 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.5.7.1 Para efeito de cálculo da Ordem de Serviço, será usada como base a proporção de 8 (oito) UST’s por dia de estudo do código-fonte.
4.5.8 Após o estudo e a aprovação do colaborador-estudado, este estará apto para atuar nos sistemas designados pela Prodemge.
4.6 Transferência de Conhecimento
4.6.1 Definição: consiste no fornecimento de subsídios para que as equipes técnicas da Prodemge ou empresa por ela designada obtenham todos os conhecimentos necessários para dar continuidade ao atendimento das solicitações de serviços, quando da rescisão ou finalização do contrato firmado com o Prestador de Serviços;
4.6.2 O Prestador de Serviços deverá promover o repasse de todo o conhecimento adquirido ou produzido na execução dos serviços para os técnicos da Prodemge ou de empresa por ela designada;
4.6.3 Toda e qualquer informação produzida no âmbito da execução do objeto do contrato será de propriedade da Prodemge e fica o Prestador de Serviços obrigado a documentar e registrar os
produtos, serviços e eventos observando as metodologias e ferramentas utilizadas pela Companhia;
4.6.4 O Prestador de Serviços deverá entregar toda e qualquer documentação/produto gerado em meio magnético e/ou físico em função da prestação de serviços técnicos, observando as metodologias e ferramentas utilizadas pela Prodemge;
4.6.5 O Prestador de Serviços deverá descrever a metodologia que será utilizada para transferir conhecimento aos técnicos da Prodemge, os quais poderão ser multiplicadores do conhecimento transferido a outros técnicos ou a usuários finais;
4.6.6 Caberá ao Prestador de Serviços promover o repasse de conhecimento aos seus novos profissionais em caso de substituição dos responsáveis pela execução de serviços em andamento, minimizando problemas relacionados à continuidade e qualidade dos serviços prestados;
4.7 Transição Contratual
4.7.1 Em ocorrendo nova licitação com mudança de fornecedor, a fim de evitar a descontinuidade do serviço e prejuízos à Administração, o Prestador de Serviços signatário do contrato em fase de expiração, deverá repassar para o vencedor do novo certame, os documentos necessários à continuidade da prestação dos serviços.
4.7.2 Para fins de cumprimento do item anterior, um Plano de Transição, endereçando todas as atividades necessárias para a completa transição, deverá ser entregue à Prodemge pelo Prestador de Serviços, 3 (três) meses antes da expiração ou da finalização do contrato.
4.7.3 No Plano de Transição deverão estar identificados todos os compromissos, papéis e responsabilidades, artefatos e tarefas, a data de início da transição, o tempo necessário e a identificação de todos os envolvidos nesse processo.
4.7.4 Será de inteira responsabilidade do Prestador de Serviços a execução do Plano de Transição, bem como a garantia do repasse bem-sucedido de todas as informações necessárias para a continuidade dos serviços pela Prodemge ou empresa por ela designada.
4.7.5 É de responsabilidade da Prodemge a disponibilidade dos recursos qualificados identificados no Plano de Transição como receptores do serviço.
4.7.6 O fato de o Prestador de Serviços ou seus representantes não cooperarem ou reterem qualquer informação ou dado solicitado pela Prodemge, que venha a prejudicar, de alguma forma, o andamento da transição das tarefas e serviços para um novo prestador, constituirá quebra de
contrato, sujeitando-a as obrigações em relação a todos os danos causados à Prodemge, conforme estipulado nas Sanções Administrativas aplicáveis.
4.7.7 Durante o tempo requerido para desenvolver e executar o Plano de Transição, o Prestador de Serviços deve responsabilizar-se pelo esforço adicional que necessite dedicar à tarefa de completar a transição, sem ônus para a Prodemge.
4.7.8 A transição do contrato atual para o vencedor deste certame será cuidadosamente planejada junto à Xxxxxxxx, de modo a minimizar o risco da descontinuidade de serviços e evitar prejuízo para Administração, podendo haver sobreposição entre o encerramento do contrato vigente e o início do novo.
4.7.8.1 Antes de encerrar o atual contrato, é necessário que algumas atividades sejam realizadas com vistas a garantir:
- A continuidade de serviços;
- O tratamento dos aspectos legais;
- A transferência de conhecimento; e
- A avaliação dos resultados alcançados
4.8 Processo de Gestão
4.8.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.8.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.8.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.8.3.1 É no âmbito desse processo que é homologado o faturamento das demandas e aplicados os abatimentos em faturas ao Prestador de Serviços.
4.8.3.2 A execução de uma demanda fora do prazo e da qualidade prevista na OS gerará, automaticamente, abatimentos na fatura, as quais incidem diretamente sobre o faturamento da empresa referente à Ordem de Serviço que ampara tal demanda.
4.8.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.8.3.4 As atividades de gestão sobre as equipes alocadas pelo Prestador de Serviços não serão remuneradas diretamente.
4.8.3.4.1 Somente são remuneráveis os entregáveis e atividades, conforme especificado na metodologia da Prodemge e no Repertório de UST’s - Anexo I
- C.
4.8.3.5 Demais detalhes sobre fluxo de gestão de contrato estão explicitados no Modelo de Gestão e Volumetria - Anexo I – B.
4.8.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.
4.8.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.8.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.8.4.3 Os perfis solicitados para a composição do Time poderão ser alocados, mediante anuência da Prodemge, em mais de um Squad.
4.8.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.8.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
TERMO DE REFERÊNCIA
4.8.4.6 A critério da Prodemge, o fluxo de processo de desenvolvimento e sustentação de sistema poderá ser ajustado ao longo do tempo, decorrente das possíveis evoluções metodológicas.
5. Detalhes dos itens do Objeto
5.1. Marca e Modelo
Não se aplica
5.2. Justificativa de Marca e Modelo
Não se aplica
5.3. Forma de Entrega
5.3.1.Os serviços serão prestados remotamente.
5.3.2.O Prestador de Serviços deverá se submeter à Política de Segurança da Informação da Prodemge.
5.3.2.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.
5.3.2.2. Toda e qualquer infraestrutura de conectividade ao servidor de VPN da Prodemge será de responsabilidade do Prestador de Serviços.
5.3.3.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
0.0.0.Xx estações de trabalho para prestação dos serviços objeto deste Termo de Referência deverão apresentar minimamente as configurações abaixo descritas:
a) Processador Intel I5 10ª geração ou superior;
b) 8 GB de memória RAM;
c) HD de 1 TB;
d) Monitor de 22 polegadas, teclado e mouse.
5.3.5.Caso a arquitetura do projeto exija um hardware superior ao citado no item 5.3.4, será de responsabilidade do Prestador de Serviços realizar o upgrade do seu maquinário, sem que isso gere custos adicionais à Prodemge e/ou prejuízo ao andamento do projeto.
5.4. Local de Entrega
5.4.1.A critério da Prodemge, a prestação dos serviços poderá ser nas dependências físicas da Prodemge em Belo Horizonte/MG, no endereço: Xxx xx Xxxxx 0000, Xxxxxx Xxxxxxx.
0.0.0.Xx hipótese de ocorrer o disposto no item 5.4.1, deverá ser observado:
5.4.2.1. 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, sem que haja nenhum tipo de vínculo da Prodemge com os funcionários da empresa prestadora dos serviços ficando a cargo da mesma a responsabilidade sobre todos os encargos sociais, trabalhistas, fiscais e demais despesas necessárias decorrentes ao cumprimento integral das obrigações decorrentes desta licitação.
5.4.2.2. Deverá ser agendada com antecedência mínima de 30 (trinta) dias, por email, uma visita técnica para conhecimento do ambiente de trabalho.
5.5. Prazo de Entrega/execução
Conforme definido nas Ordens de Serviço, levando em consideração o prazo de duração da Sprint
que poderá variar entre 1 a 4 semanas.
5.6. Validade dos produtos
Não se aplica
5.7. Condições de Pagamento
5.7.1.Processo de faturamento
5.7.1.1. O ciclo de faturamento praticado para a prestação dos serviços será mensal.
5.7.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.
5.7.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.
5.7.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
5.7.2.O processo de remuneração do Prestador de Serviços praticado pela Prodemge considera o pagamento nas seguintes situações:
5.7.2.1. O Prestador de Serviços será remunerado pela execução das atividades relacionadas em uma Ordem de Serviço (OS) quando, ao final da respectiva sprint, as atividades realizadas e os entregáveis correspondentes - quando aplicáveis - estiverem de acordo com o objetivo planejado para a Sprint, observando os critérios de aceite e demais condições definidas antes do início da execução da OS.
5.7.2.1.1. Em caso de inexecução total das entregas técnicas previstas na O.S., mas havendo participação nos ritos e encontros previstos, a liberação do faturamento dos respectivos ritos será realizada, e o backlog será replanejado em conjunto com a equipe, para as OS's subsequentes, observando a aplicação do SLA caso necessário.
5.7.2.2. Artefatos que forem demandados pela Prodemge em atendimento a necessidades específicas do projeto, desde que as respectivas atividades estejam previstas no Repertório de USTs - Anexo I - C e tenham sido previamente acordados antes do início da Sprint, observando-se o item 4.2.16.
5.7.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. Atividades entregues de forma parcial não serão consideradas como entregues para efeito de faturamento.
5.7.2.4. De forma geral, é desejável que a entrega de todos os artefatos definidos no backlog de uma Sprint seja feita por completo.
5.7.2.5. Todas as entregas, parciais ou totais, e seus respectivos pagamentos deverão observar os critérios de aceite definidos no item 12 – Critérios de Aceitabilidade do objeto e os redutores especificados no item 14.1 – Indicadores de SLA.
5.7.3.Processo de Pagamento
5.7.3.1. Os serviços serão remunerados pela execução das atividades relacionadas em uma Ordem de Serviço (OS).
5.7.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.
5.7.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.
5.7.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.
5.7.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 processo.
5.7.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.
5.7.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.
5.7.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.
5.7.3.9. O pagamento será efetuado mensalmente em até 30 (trinta) dias corridos do recebimento das faturas pela Prodemge.
5.8. Prazo de Garantia / Assistência Técnica
5.8.1.O Prestador de Serviços compromete-se a efetuar as necessárias correções relativas aos softwares produzidos, sem ônus adicional para a Prodemge, por 180 (cento e oitenta) dias corridos após a emissão do Termo de Encerramento da respectiva Ordem de Serviço e abrange todas as funcionalidades produzidas ou alteradas pelo mesmo, incluindo a integração com outros sistemas conforme o projeto. Esta garantia deve ser prestada mesmo após o término da vigência do contrato.
0.0.0.Xx 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.
5.8.3.O Prestador de Serviços deverá ainda corrigir erros de qualquer natureza que impeçam ou dificultem o uso e a adaptação/modificação futura, 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
5.9. Amostras / Protótipo / Prova Gráfica / Prova de conceito
Não se aplica
6. Justificativa da contratação
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.
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, 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
A utilização da métrica UST (Unidade de Serviço Técnico) em contratos com fábricas de software traz algumas vantagens e justificativas importantes, quais sejam:
- Clareza na remuneração: A métrica UST permite uma clareza na forma como os serviços são remunerados, pois se baseia na quantidade de trabalho técnico realizado. Isso pode ser vantajoso ao estabelecer preços e evitar mal-entendidos entre as partes.
- Flexibilidade na alocação de recursos: Com base na métrica UST, a fábrica de software pode ter flexibilidade para alocar recursos de acordo com as necessidades do projeto, sem estar restrita a uma determinada quantidade fixa de horas ou equipe.
- Foco na entrega de valor: Ao pagar pelas USTs, o cliente está priorizando a entrega efetiva de valor em termos de funcionalidade e qualidade, em vez de simplesmente pagar por horas de trabalho independentemente do resultado.
- Ajuste de escopo facilitado: A métrica UST pode facilitar discussões sobre ajuste de escopo, uma vez que o foco é na entrega de valor e os custos estão alinhados com o trabalho técnico realizado.
Importante ressaltar que a utilização da métrica UST está cuidadosamente detalhada através de um Repertório de UST's de forma a garantir transparência, definição clara do que compõe uma UST além da relação do conjunto de atividades executáveis no âmbito do contrato. De se ressaltar, por oportuno, que o acompanhamento do trabalho realizado está atrelado a mecanismos de controle de qualidade e entregas efetivas.
7. Justificativa da modalidade
Será realizado o processo licitatório conforme Procedimento das Estatais, seguindo a Lei 13.303/2016, destinando-se a assegurar a seleção da proposta mais vantajosa, inclusive no que se refere ao ciclo de vida do objeto, observando os princípios da impessoalidade, da moralidade, da igualdade, da publicidade, da eficiência, da probidade administrativa, da economicidade, do desenvolvimento nacional sustentável, da vinculação ao instrumento convocatório, da obtenção de competitividade e do julgamento objetivo.
8. Justificativa do agrupamento de itens em lotes
8.1. Justificativa para Lote Único
O único item a ser licitado trata-se de da Unidade de Serviço Técnico – UST, que nada mais é que uma métrica utilizada para mensurar 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. Esse item precisa ser executado pela mesma
CONTRATADA e sua divisão traria prejuízos e/ou inviabilizaria o desenvolvimento e a sustentação de software, visto que, para assegurar que o resultado gerado seja um sistema desenvolvido ou a sustentação de um sistema pré-existente, é preciso que todo o trabalho seja feito por apenas um Prestador de Serviço.
A não observância desta peculiaridade sujeitaria a Prodemge a riscos desnecessários de descontinuidade, uma vez que se veria obrigada a coordenar ações de diferentes fornecedores, com possibilidade de ocorrência de sobreposição de responsabilidades técnicas entre os mesmos dado o alto grau de integração e dependência entre as atividades desempenhadas pelos profissionais.
A opção pelo não parcelamento da solução visa assegurar a harmonia durante a prestação do serviço sem implicar em maior custo de fiscalização.
Assim, com base no Acórdão nº 1.214/2013 –TCU - Plenário, quanto a eventual parcelamento do objeto, entende-se que a contratação em tela segue a diretriz estabelecida no referido Acórdão ao contratar serviço de desenvolvimento de software de forma destacada de outros serviços com menor grau de especialização.
8.2. Lotes exclusivos para Microempresa / Empresa Pequeno Porte
Há que se ressaltar ainda que, apesar da fundamentada opção pela não separação de reserva de cota a ME/EPP, todas as vantagens e prerrogativas das empresas da categoria seguem mantidas, no que diz respeito à sua documentação de habilitação e empate ficto na disputa de preço, ficando assim assegurada a preferência quando puderem competir e fornecer conforme estabelecido pelo modelo de compra. Sendo assim, entendemos ser a melhor configuração para a Administração e para a compra pretendida a não reserva de cotas entre os lotes licitados.
Posto isso, para esta licitação em específico não serão reservados lotes para ME/EPP de acordo com o previsto no art. 49, III da Lei Complementar Federal nº 123/2006 c/c o art. 11 do Decreto Estadual nº 47.437/2018, visto que. Ademais, o valor de referência estimado da licitação é superior a R$ 80.000,00 (oitenta mil reais).
9. Justificativa do quantitativo
Justifica-se a contratação do quantitativo de 330.000 (trezentos e trinta mil) Unidades de Serviços Técnicos (UST), em função da necessidade de atendimento às demandas de desenvolvimento de sistemas de informação pela Prodemge, previstas para os anos de 2024/2026, baseado em contratos firmados pela Prodemge, com um volume da ordem de 46 projetos em andamento e/ou em fase de contratação, com os clientes da Companhia.
O volume acima apresentado foi estimado com base na série histórica de execução de Ordens de Serviço nos últimos 12 meses, conforme demonstrado na tabela abaixo.
Mês | Qtde UST faturada/mês |
fevereiro-23 | 8.636,50 |
março-23 | 10.133,50 |
abril-23 | 11.245,50 |
maio-23 | 10.260,26 |
junho-23 | 10.996,50 |
julho-23 | 14.210,00 |
agosto-23 | 10.191,00 |
setembro-23 | 4.929,92 |
outubro-23 | 12.401,50 |
novembro-23 | 11.667,85 |
dezembro-23 | 10.701,50 |
janeiro-24 | 9.563,50 |
fevereiro-24 | 10.070,50 |
TOTAL 135.008,03
MÉDIA MENSAL 11.250,67
média mensal x 24 meses | 270.016,06 |
demanda reprimida (20%) | 54.003,21 |
Expectativa próximos 24 meses | 324.019,27 |
10.Visita ou vistoria técnica
Não se aplica
11.Qualificação Técnica
A documentação relativa à qualificação técnica consistirá em:
11.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 e as tecnologias citadas no Anexo I-A. Este atestado, ou conjunto de atestados, deve ter, no mínimo, 110.000 (cento e dez mil) UST´s de serviço prestados no período de 24 meses consecutivos e deverá conter de forma explícita que a licitante possui experiência obrigatoriamente em:
11.1.1. 40.000 UST´s (quarenta mil) na tecnologia Java Platform, Enterprise Edition (Java EE) versão
6.0 ou superior, usando Sistemas de Gerenciamento de Banco de Dados – SGBD - relacionais MS SQL Server, Oracle, MySQL ou PostgreSQL; e
11.1.2. 4.000 UST´s (quatro mil) na tecnologia JSF, usando Sistemas de Gerenciamento de Banco de Dados – SGBD - relacionais MS SQL Server, Oracle, MySQL ou PostgreSQL; e
11.1.3. 30.000 UST´s (vinte mil) na tecnologia PHP utilizando framework Cake ou Laravel usando Sistemas de Gerenciamento de Banco de Dados – SGBD - relacionais MS SQL Server, Oracle, MySQL ou PostgreSQL;
11.1.4. planejamento e execução de testes: unitários, funcionais e não funcionais;
11.1.5. desenvolvimento e manutenção de apps para dispositivos móveis nos sistemas operacionais Android e iOS utilizando plataforma Ionic;
11.1.6. desenvolvimento ou manutenção de sistemas utilizando certificação digital com aderência à ICP- Brasil;
11.1.7. desenvolvimento ou manutenção de sistemas utilizando a tecnologia blockchain compatível código aberto;
11.1.8. prestação de serviços técnicos de desenvolvimento e manutenção de sistemas de informação, utilizando metodologias ágeis, em regime de fábrica de software, contendo no mínimo 7 (sete) dos seguintes artefatos, práticas ou equivalentes, que devem ter sido produzidos nos projetos:
• Backlog do Produto;
• Gráfico Burndown ou Burnup;
• Planejamento da liberação (release) ou Roadmap;
• Planejamento da iteração (sprint);
• Quadro Informativo (Kanban);
• Diagrama de fluxo cumulativo;
• Documento de requisitos não funcionais;
• Scripts de teste automatizado;
• História de usuário;
• Documento de mensagens;
11.1.9. 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.
11.2. Tendo em vista a especificidade da métrica definida neste objeto, para fins da comprovação das USTs exigidas nos atestados:
11.2.1. Serão aceitos atestados em pontos de função (PF), considerando, para efeito de conversão, a proporção de 1 (um) PF para 10 (dez) USTs.
11.2.2. Da mesma forma, serão aceitos atestados em horas, fica estabelecida a equivalência entre 01 (uma) UST e 01 (uma) hora de serviço em outros órgãos e empresas.
11.3. 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.
11.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.
11.4.1. A recusa do emitente do atestado em prestar esclarecimentos e/ou fornecer documentos comprobatórios, ou sofrer diligências, desconstituirá o Atestado de Capacidade Técnica e poderá, inclusive, configurar prática de falsidade ideológica ensejando investigação criminal e abertura de Processo Administrativo Disciplinar, conforme o caso, para fins de apuração de responsabilidades, além da desclassificação no certame.
11.5. Para fins de comprovação, somente serão aceitos os atestados referentes a serviços realizados pela licitante em sua personalidade jurídica própria. Dessa forma, não serão aceitos atestados em nomes de empresas que pertençam ao seu grupo empresarial para demonstração de sua capacidade técnica.
11.6. Com o objetivo de reduzir o tempo de análise do conjunto de atestados a licitante deverá enviar uma planilha contendo um resumo com apontamentos relacionando cada atestado apresentado ao(s) respectivo(s) item(s) atendido(s), bem como o intervalo de datas dos serviços executados.
11.7. Para efeito de comprovação do volume de serviços, é permitido o somatório de contratos executados. Para isso, a licitante deverá fixar, a seu critério, intervalo de tempo de 24 meses consecutivos, independentemente do ano no qual o volume de serviços foi executado.
11.8. Tal exigência visa a evitar que o somatório de atestados acumulados durante longo período de tempo atinja o quantitativo mínimo exigido, não resultando, porém, na comprovação da efetiva capacidade logística e operacional da empresa licitante para executar o objeto previsto, em aderência aos Acórdãos 2.048/2006 e 1.287/2008, todos do Plenário do TCU.
12.Critérios de aceitabilidade do objeto
12.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.
12.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.
12.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. 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
12.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.
12.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 Repertório de USTs - Anexo I - C.
13.Cronograma Fisico-financeiro
Não se aplica
14.Níveis de serviço
14.1. Indicadores de SLA
14.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 | 6% | 8% | 10% |
O cálculo do pagamento se dará conforme fórmula abaixo:
PG = (UST – REDUTOR), onde:
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 – (6% (900)) = 846 USTs (redução de 6% conforme tabela)
14.1.2. Em caso de inexecução total o valor inicial presente na Ordem de Serviço será utilizado como referência para cálculo do SLA exposto no item 14.1.1.
14.1.3. Participações em reuniões, Encontros e Ritos
14.1.3.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 Repertório de UST´s - Anexo I - C.
14.1.3.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.
14.2. Disposições Gerais relativas ao SLA
14.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.
14.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.
14.2.3. O descumprimento dos níveis de serviços estabelecidos neste documento motivará a aplicação de abatimentos compensatórios.
14.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:
14.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);
14.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.
14.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 23.1;
14.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.
14.2.6. Os redutores serão aplicados independente do critério de aceite da entrega, definido no item 12 deste Termo de Referência.
14.2.7. Procedimento para aplicação de abatimentos nas faturas
14.2.7.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.
14.2.7.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.
14.2.7.3. Uma vez apresentada a justificativa, o gestor do projeto apresentará manifestação e decidirá sobre a aplicação do abatimento.
14.2.7.4. O termo de encerramento da Sprint contemplará o detalhamento da entrega pelo Prestador de Serviços, explicitando o abatimento a ser aplicado.
14.2.8. Incidência de defeitos
14.2.8.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.
14.2.8.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.
14.2.8.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.
14.2.9. Os procedimentos e a operacionalização do processo de gerenciamento de cobranças e de aplicação de penalidades encontram-se descritos de forma detalhada no Modelo de Acordo Operacional - Anexo I – G.
15.Da participação de consórcios
Não será permitida a participação de empresas reunidas em consórcio, devido à baixa complexidade do objeto a ser adquirido, considerando que as empresas que atuam no mercado têm condições de fornecer os serviços de forma independente.
16.Subcontratação
Não será aceita a subcontratação.
17.Vigência da Contratação
2 (dois) anos.
18.Garantia Financeira
18.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 5% (cinco por cento) do valor do contrato.
18.2. A CONTRATADA deverá optar por uma das modalidades de garantia, itens abaixo
18.2.1. Caução em dinheiro;
18.2.2. Seguro-garantia;
18.2.3. Fiança bancária
18.3. A CONTRATADA terá o prazo máximo de 30 (trinta) dias após a assinatura deste contrato para apresentar à Gerência de Contratos-GCT da PRODEMGE o documento comprobatório da garantia prestada, sob pena de aplicação de sanção, inclusive multa e/ou rescisão contratual.
18.3.1. No caso de garantia contratual, por fiança bancária ou seguro-garantia, somente serão aceitas se contemplar todos os eventos indicados no item 18.
18.3.2. A garantia contratual, por fiança bancária ou seguro-garantia deve ter validade durante a execução do contrato e 3 (três) meses após o término da vigência contratual.
18.4. A garantia prestada pela CONTRATADA será liberada ou restituída após a execução integral do contrato, devendo ser atualizada monetariamente na hipótese de caução em dinheiro.
18.5. O valor da garantia poderá ser utilizado em caso de inadimplemento das obrigações contratuais, trabalhistas, indenizações à PRODEMGE e a terceiros, e para pagamento de multas impostas à CONTRATADA, sem que isso inviabilize a aplicação de multas em valor superior ao da garantia prestada.
18.6. Na hipótese de haver prorrogação deste contrato, a CONTRATADA fica obrigada a complementar ou substituir a garantia prestada no prazo de até 30 (trinta) dias após assinatura do Termo Aditivo.
18.7. Se o valor da garantia de execução for utilizado para o pagamento de qualquer obrigação, a CONTRATADA obriga-se a restabelecer o seu valor real, no xxxxx xxxxxx xx xxxxx xx 00 (xxxxxx) dias, a contar da data em que for comunicada pela PRODEMGE.
18.8. No encerramento da vigência contratual, competirá à Gerência de Contratos da PRODEMGE providenciar a liberação/restituição da Garantia Contratual à CONTRATADA.
18.9. A devolução da garantia não exime a CONTRATADA das responsabilidades administrativa, civil e penal, oriundas da execução do objeto do presente contrato.
19.Sustentabilidade Ambiental
Não se aplica
20.Unidade Fiscalizadora
Informação interna.
21.Orçamento estimado
A Prodemge, baseada no artigo 34 da Lei 13.303/2016 e no RILC (Regulamento Interno de Licitações e Contratos), se reserva no direito de não informar o orçamento estimado neste momento, visando a isonomia entre os licitantes e a busca da proposta mais vantajosa para a empresa.
22.Obrigações da contratada
22.1. O Prestador de Serviços se obriga e se compromete perante a Prodemge a:
22.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;
22.1.2. Utilizar, na prestação dos serviços, mão de obra qualificada e com certificados de acordo com
Perfil dos Profissionais - Anexo I - A.
22.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;
22.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;
22.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;
22.1.6. 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;
22.1.7. Responsabilizar-se pela gestão dos profissionais alocados para a prestação dos serviços especificados neste Termo de Referência.
22.1.8. 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 Perfil dos Profissionais - Anexo I – A.
22.1.9. 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.
22.1.9.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.
22.1.9.2. É vedada a alocação de estagiários como parte dos profissionais a serem alocados.
22.1.10. 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.
22.1.11. 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.
22.1.12. Entregar, ao final do 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.
22.1.13. 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.
22.1.14. Participar de reuniões de alinhamento, caso necessário, com a Prodemge durante a prestação dos serviços.
22.1.15. Participar de todas as reuniões técnicas previstas no Repertório de USTs - Anexo I – C.
22.1.15.1. As reuniões serão previamente agendadas pela Prodemge sempre que julgar necessário, sem limite de quantidade, sem frequência predefinida.
22.1.16. 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.
22.1.17. 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.
22.1.18. 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 22.1.15.1 quando houver necessidade de que sejam presenciais, nas dependências da Prodemge
22.1.19. Elaborar em conjunto com a Prodemge o planejamento de cada iteração e o objetivo de cada release do produto.
22.1.20. Implantar, nos devidos ambientes da Prodemge, os componentes do software desenvolvidos.
22.1.21. Disponibilizar toda a documentação do desenvolvimento do software, bem como os códigos implementados durante a prestação do serviço.
22.1.22. Prestar todos os serviços em conformidade com ambiente tecnológico da Prodemge descrito no Ambiente Tecnológico e Processo de Integração Contínua Baixa Plataforma da Prodemge - Anexo I - D.
22.1.23. Prestar todos os serviços de sustentação planejada de software em conformidade com o item 4.4 deste Termo de Referência.
22.2. Comprovar, após a assinatura do contrato, que possui em seu corpo técnico, profissionais que atendam todos os requisitos definidos no Perfil dos Profissionais - Anexo I - A, na quantidade definida no quadro 1 abaixo:
Quadro 1 – Quantidade de profissionais x perfil
PERFIS | QTDE. ESTIMADA |
Scrum Master (SM) | 5 |
Analista UX | 1 |
Analista de Requisitos e Testes | 14 |
Arquiteto de Software | 1 |
Analista de dados | 1 |
Líder Técnico | 1 |
Desenvolvedor | 37 |
TOTAL DE PROFISSIONAIS | 60 |
22.3. A fim de subsidiar a precificação e eventual contratação, disponibilizamos, apenas como referência, o quantitativo de perfis. Reiteramos que as informações disponibilizadas não têm caráter vinculativo. Não obstante, tais quantitativos de perfis devem servir apenas como referência para a elaboração da proposta.
22.4. Os quantitativos de perfis apresentados foram estimados com base na série histórica dos últimos 18 meses de execução das atuais demandas. Dessa forma, não existe a garantia de quantitativo mínimo de perfis ou compromisso por parte da Prodemge em manter um fluxo uniforme de demandas ao longo da execução.
22.5. Após assinatura do contrato, durante o período de até 30 (trinta) dias corridos a Prodemge fará em conjunto com o Prestador de Serviços, o planejamento para atendimento às demandas de desenvolvimento de sistemas de informação da Companhia.
22.6. A empresa deverá comprovar a qualificação técnica de todos os profissionais que prestarão serviços durante a execução do contrato.
22.6.1. Para assegurar que os profissionais alocados para a execução do serviço sejam qualificados tecnicamente, deverão ser entregues os currículos e sua respectiva documentação de qualificação.
22.6.1.1. Os currículos dos profissionais deverão atender aos requisitos constantes no Anexo I – A e serão avaliados e aprovados pela Prodemge antes do seu ingresso nas Squads;
22.6.1.2. Cabe exclusivamente à Prodemge a aceitação da capacitação profissional, bem como em situações excepcionais a flexibilização quanto ao tempo de experiência, formação acadêmica e/ou certificação exigida que se fizer pertinente e necessária à plena execução dos serviços, desde que justificada para compor o processo no atendimento ao interesse da Prodemge.
22.6.1.3. Os perfis profissionais são balizadores para execução dos serviços, contudo se houver mudança de tecnologia ou modificação das necessidades da Prodemge, estes perfis profissionais deverão ser treinados/qualificados pelo Prestador de Serviços e/ou substituídos, sempre em negociação prévia entre as partes.
22.6.2. 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.
22.6.3. 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 ensino reconhecidas pelo MEC.
22.6.4. A comprovação das certificações deverá ser feita através da apresentação de cópia dos certificados emitidos pelos órgãos competentes.
22.6.5. Para comprovação do vínculo empregatício do profissional com o Prestador de Serviços, serão considerados:
a) Carteira de Trabalho e Previdência Social (CTPS) ou;
b) Ficha de Registro de Empregado (RE), devidamente registrada ou;
c) Contrato vigente de prestação de serviços entre a empresa e a pessoa física do profissional ou;
d) Estatuto ou contrato social do Prestador de Serviços (no caso de sócio da empresa).
22.6.6. Toda a documentação do profissional exigida neste item 22.6 deverá ser entregue à Prodemge em até 15 (quinze) dias após a aprovação do respectivo currículo.
22.6.7. Ao longo da execução do contrato, o Prestador de Serviços deverá enviar toda a documentação comprobatória que comprove a capacitação técnica e o vinculo empregatício do profissional com o Prestador de Serviço, de acordo com a necessidade da Prodemge para a formação das equipes
/ Squads.
22.6.8. O processo de comprovação técnica será devidamente seguido para os possíveis casos de substituição de profissionais durante a execução do contrato.
23.Obrigações da Prodemge
23.1. São obrigações da Prodemge:
23.1.1. Exercer a gestão física e financeira do contrato.
23.1.2. Acompanhar e controlar o faturamento global do contrato;
23.1.3. Organizar e disponibilizar as informações gerenciais;
23.1.4. Fornecer informações técnicas sobre os sistemas e ambiente tecnológico relacionado.
23.1.5. Acompanhar e atuar como fiscal do contrato.
23.1.6. Acompanhar e atuar como fiscalizadora da gestão exercida pelo Prestador de Serviço sobre os profissionais alocados.
23.1.7. Efetuar e/ou aferir métricas.
23.1.8. Analisar indicadores apresentados por meio de relatórios fornecidos pelo Prestador de Serviços ou mesmo coletá-los diretamente.
23.1.9. Homologar as entregas conforme critério estabelecidos no item 12 - Critérios de aceitabilidade deste Termo de Referência.
23.1.10. Proceder à abertura de Ordens de Serviços (OS) para cada Sprint.
23.1.11. Aferir os níveis de serviços especificados no contrato para cada entrega.
23.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.
23.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;
23.1.14. Treinar profissionais do Prestador de Serviços em caso de frameworks proprietários;
23.1.15. Na hipótese de recusa do Prestador de Serviços em prorrogar o contrato, as Ordens de Serviço devem limitar-se àquelas passíveis de início e conclusão dentro do prazo de vigência estabelecido no contrato, visando evitar a emissão de Ordens de Serviço que tenham início durante a vigência contratual, porém, entregues após o término deste.
23.1.16. Ao témino do prazo de vigência contratual, se não houver manifestação de intenção de prorrogação do contrato pelo Prestador de Serviços, as Ordens de Serviço devem ser limitadas à abertura, desde que possam ser concluídas dentro do prazo de vigência do contrato.
24.Sanções Cabíveis
24.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 normas do artigo 185 a 204 do Regulamento Interno de Licitações e Contratos da Prodemge.
24.1.1. O cancelamento do projeto por parte do Prestador do Serviço de forma unilateral acarretará em descumprimento contratual sujeito às sanções previstas nesta cláusula
24.2. 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.
24.2.1. 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 de participação em licitação e impedimento de contratar com a Prodemge, por prazo não superior a 2 (dois) anos.
24.3. As sanções previstas nesta cláusula, quando aplicadas, deverão levar em consideração a
natureza e a gravidade dos fatos, a extensão e a relevância da obrigação descumprida, a culpabilidade da contratada, os fins a que a sanção se destina, os princípios da razoabilidade e da proporcionalidade.
24.4. Os procedimentos para a aplicação de sanções estão previstos nos art. 185 e seguintes do Regulamento Interno de Licitações e Contratos da Prodemge, o qual observa o devido processo legal, garantindo o contraditório e a ampla defesa.
25.Matriz de Riscos Não se aplica 26.Glossário
Ver Anexo I - E
27.Demais condições essenciais para contratação:
27.1. Apresentar proposta conforme o modelo constante do Anexo I – F Proposta Comercial.
27.2. As 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.
27.3. A licitante deverá apresentar junto à documentação técnica exigida na habilitação, declaração formal, sob penas da lei de que, caso vencedora do certame, irá disponibilizar os profissionais necessários à execução dos serviços, bem como comprovar a sua qualificação técnica, conforme estabelecido no item 22.2 deste Termo de Referência.
ANEXO I - A
Perfil dos Profissionais
1. Formação dos Squads
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, momento no qual será definido pela Prodemge em quais papéis haverá participação do Prestador de Serviços naquela demanda. Nesse sentido, poderá ocorrer a formação de Squad Mistos, com papéis sendo executados pela Prodemge outros pelo Prestador de Serviços, ou Squad com todos os papéis sendo executados pelo Prestador de Serviços.
1.2.1.Os perfis elencados para a composição do Time poderão ser alocados, mediante anuência da Prodemge, em mais de um Squad.
1.2.2.Os Desenvolvedores do Prestador de Serviços deverão ter conhecimento, no mínimo das tecnologias conforme a necessidade do projeto que irão atuar.
1.2.2.1. Backend: JAVA e/ou PHP e/ou Node.js
1.2.2.2. Frontend: Angular JS e/ou VUE JS e/ou React Native e/ou Flutter e/ou IONIC e/ou Swift e/ou Android
1.2.3. As tecnologias previstas no item 1.2.2 apresentam um conjunto não exaustivo e poderão ser revisadas a qualquer tempo, durante a execução do contrato, sendo passíveis de inclusão de novos itens conforme as necessidades da Prodemge
1.2.4.Os arquitetos de software devem possuir conhecimento nas mesmas linguagens de programação e também nos bancos de dados Oracle, Microsoft SQLServer, PostgreSQL e MySQL.
1.3. O Prestador de Serviços deverá ter uma equipe de apoio à gestão composta basicamente de
1.3.1. Coordenador
1.3.2. Lider de projetos (1 para cada 10 projetos)
1.3.3.Apoio a Gestão (analistas e/ou líderes técnicos que atuam nos times)
1.3.3.1. Estes profissionais poderão dividir o seu tempo atuando em um determinado time e dando suporte a outros times (limitado a 2, a depender da demanda do(s) time(s) em que estiver atuando efetivamente)
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 referente ao projeto em que o profissional irá atuar, 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 a experiência da equipe alocada serão graduadas em “sênior” e “pleno” com impactos na experiência dos profissionais.
2.5. Os perfis profissionais são balizadores para execução dos serviços, contudo se houver mudança de tecnologia ou modificação das necessidades da Prodemge, estes perfis profissionais deverão ser treinados/qualificados pelo Prestador de Serviços e/ou substituídos, sempre em negociação prévia entre as partes.
2.6. 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.6.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. |
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, com conhecimento das tecnologias conforme a necessidade do projeto em que irá atuar. Backend: Java e/ou PHP e/ou Node Js Frontend: Angular JS e/ou VUE JS e/ou React Native e/ou Flutter e/ou IONIC e/ou, Swift e/ou Android Outros conhecimentos: analytics, APIs e automação de teste . |
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” | 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. |
Perfil | Breve descrição | Formação | Qualificação exigida |
etc. Conhecimentos em ferramentas de visualização de dados, mineração de dados, ETL. | |||
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, com conhecimento das tecnologias conforme a necessidade do projeto em que irá atuar. Backend: Java e/ou PHP e/ou Node Js Frontend: Angular JS e/ou VUE JS e/ou React Native e/ou Flutter e/ou IONIC e/ou, Swift e/ou Android Outros conhecimentos: analytics, APIs e automação de teste Bancos de dados Oracle, Microsoft SQLServer, PostgreSQL e MySQL |
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 com conhecimento das tecnologias conforme a necessidade do projeto em que irá atuar: Backend: Java e/ou PHP e/ou Node Js Frontend: Angular JS e/ou VUE JS e/ou React Native e/ou Flutter e/ou IONIC e/ou, Swift e/ou Android Outros conhecimentos: analytics, APIs e automação de testes. |
CIENTISTA DE DADOS | Profissional do Prestador de Serviços responsável por projetos relacionados à Ciência de Dados e Inteligência Artificial | Formação superior completa (graduação) em Ciência da Computação, Estatística, Matemática, Engenharia de Computação, Engenharia de Dados ou áreas relacionadas. Pós-graduação (lato sensu e/ou stricto sensu) ou cursos específicos em Ciência de Dados, | Experiência de no mínimo 3 anos em projetos relacionados à Ciência de Dados e Inteligência Artificial Mínimo de 3 anos de experiência em linguagens de programação estatística como R, Python, e linguagens de consulta |
Perfil | Breve descrição | Formação | Qualificação exigida |
Machine Learning, Inteligência Artificial ou áreas afins | de banco de dados como SQL, Hive,impala | ||
Princípios e práticas de desenvolvimento de software ágil, incluindo o Manifesto Ágil, Scrum, Extreme Programming (XP) e Kanban; | |||
Conhecimento básico de técnicas de levantamento e documentação de requisitos; | |||
Conhecimento básico de técnicas de levantamento e documentação de processos de negócio; | |||
Conhecimento em frameworks e biblioteca e linguagens de machine learning, como TensorFlow, PyTorch, NumPy, Pandas, SciPy, NLP entre outros | |||
Métodos de aprendizado de máquina como k-Nearest Neighbors, Naive Bayes, SVM, Decision Forests. | |||
Manipulação, limpeza e processamento de grandes volumes de dados. | |||
Ferramentas de Visualização de Dados como matplotlib, ggplot, d3.js, Tableau que ajudam a codificar visualmente os dados. | |||
Conhecimento em Estatística, Aprendizado de Máquina e Ferramentas de Ciência de dados | |||
ENGENHEIRO DE | Profissional, prestador de | Formação superior completa (graduação) em Ciência da Computação, Estatística, Matemática, Engenharia de Computação, Engenharia de Dados ou áreas relacionadas. Pós-graduação (lato sensu e/ou stricto sensu) ou cursos específicos em Engenharia de dados. | Experiência de no mínimo 3 anos em |
DADOS | serviços responsável por | projetos relacionados à Engenharia de | |
projetar e construir pipelines | dados | ||
de dados eficientes para | |||
coletar, processar e armazenar grandes volumes de dados de diversas fontes | Conhecimento em: - Programação (Python, Java, Scala) - Bancos de Dados (relacionais e NoSQL) - Ferramentas ETL | ||
Experiência em Big Data: - Apache Hadoop - Apache Nifi - Apache Airflow - Apache Sqoop - Apache Oozie - Apache Spark - Apache Hive - Apache Hue - Apache Impala - Apache Atlas |
Perfil | Breve descrição | Formação | Qualificação exigida |
- Apache Ranger - Apache Kudu - DBT - Ferramentas de governança e integração de dados - Computação em Nuvem (AWS, Azure, Google Cloud) - Sistemas Distribuídos - Arquitetura de Dados - Codificação - Sistemas Operacionais (UNIX, Linux, Solaris, Windows) | |||
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 Owner
d) PMI: Agile Certified Practitioner (PMI-ACP).
ANEXO I - B
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 Repertório de UST´s – Anexo I - C, 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 Termo de Encerramento informando:
1.2.1.6.1. Os itens definidos na Ordem de Serviços que foram devidamente entregues e a quantidade de UST’s a serem pagas referente a entrega feita;
1.2.1.6.2. Se o cumprimento dos entregáveis foi total ou parcial;
1.2.1.6.3. 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. Realização semanal de reunião status report para acompanhamento dos projetos com a Fabrica.
1.2.2.3. Gerir o processo de faturamento.
1.2.2.4. 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.5. Realizar abatimentos em faturas.
1.2.2.6. Fazer interface entre os Squads e o Prestador de Serviços.
1.2.2.7. 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. 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.5. 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 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.
2.5.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.6. 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 da Sprint;
8. Objetivo da 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.7. 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.7.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.8. 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 da Sprint;
6. Data de entrega do backlog da Sprint;
7. Descrição dos serviços entregues / não entregues na Sprint Review:
• Itens do backlog da Sprint entregues:
I. Atividades executadas do catálogo de UST,
II. Grau de complexidade,
III. Quantidade de UST’s.
• Itens de backlog da Sprint não entregues / não aceitos;
8. Parecer do aceite do P.O;
9. Assinaturas dos responsáveis.
2.9. 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. Volumetria Estimada
3.1. A quantidade de USTs prevista foi calculada com base em estudo exploratório onde verificou-se a necessidade de complementação do equivalente a 330.000 (trezentos e trinta mil) para o período de 24 (vinte e quatro) meses, para atendimento aos serviços demandados pelos diversos clientes da Prodemge.
ANEXO I - C
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 UST’s |
E1 | Encontros | Alinhamento Comunicado sobre as etapas de execução que serão contratadas e apresentação da visão do Product Backlog ou qualquer reunião técnica sobre o produto não prevista nas atividades contempladas neste repertório. Entregável: Documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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) Entregável: Canva do time feito na ferramenta de colaboração da Prodemge e documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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. Entregável: Documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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 | Discovery Etapa de descoberta do produto, definição do MVP (Mínimo Produto Viável) e mapeamento do Backlog, podendo ser realizadas no formato de Ideação, Inception ou de acordo com cada contexto. Entregável: Documento com a definição do MVP e mapeamento do backlog registrados no repositório do projeto e documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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 - Contempla: Pré Refinamento (levantamento de requisitos) e o Rito de refinamento (momento de explanação do requisito para o time) Entregável: Documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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). A etapa de Pré Refinamento para o perfil do Analista de Requisitos não deve ser considerada no cálculo de UST’s. Está contemplada na atividade “Histórias”(H1/H2). |
R3 | Ritos | Sprint Planning Entregável: Backlog da Sprint, registrado no repositório do projeto e documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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 Pré Review Contempla: Pré Review (momento de review interna, sem o PO). Entregável: Documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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 Review Review (com o PO). Entregável: Documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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). |
R6 | Ritos | Sprint Retrospective (interna) | 1 UST por hora de reunião por participante (a quantidade total de horas |
Contempla: Retrospectiva Interna (momento de retrospectiva interna, sem o PO) Entregável: Quadro da retrospectiva preenchido na ferramenta de colaboração do projeto e documento formalizando a participação de cada participante nos encontros/ritos da sprint. | e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge). | ||
R7 | Ritos | Sprint Retrospective Retrospectiva (com o PO). Entregável: Quadro da retrospectiva preenchido na ferramenta de colaboração do projeto e documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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). |
R8 | Ritos | Daily Entregável: Documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 1 UST por Daily (independente do número de participantes). |
L1 | Liderança Ágil | Acompanhamento do Scrum Master: acompanhamento do time, resolução de impedimentos, atualização de gestão à vista e métricas de acompanhamento, elaboração de documentos necessários de registros, etc. Entregável: Quadro de gestão à vista atualizado. | 30 UST’s por Sprint. |
H1 | Histórias | Entendimento, refinamento, escrita e validação da história. Entregável: Especificação da história registrada no diretório do projeto, conforme padrões definidos pela Prodemge. | 16 UST’s por história |
H2 | Histórias | Alteração/Ajustes da história. Entregável: Alterações na especificação da história registrada no diretório do projeto, contemplando o versionamento e alterações/ajustes realizados no documento. | 4 UST’s por história alterada. |
A1 | Arquitetura | Definições arquiteturais da solução (Elaborar arquitetura candidata e arquitetura executável a ser adotada no produto) – Será validado pelo time técnico da Prodemge. Entregável: Documento de Arquitetura padrão da Prodemge. | 50 UST’s |
A2 | Arquitetura | Repasse e/ou acompanhamento da arquitetura da solução. Entregável: Documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 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. Entregável: Documento de entrevista e imagem da logomarca registrados no repositório do projeto. | 15 UST’s |
AD2 | Análise e desenho | Elaboração do guia de usabilidade Entregável: Guia de Usabilidade conforme padrões definidos no projeto. | 5 UST’s |
AD3 | Análise e desenho | Prototipação: Entrevista, observações e validações com o usuário para mapeamento da experiência desejada e construção de protótipo de média fidelidade da tela, sendo que uma tela pode envolver mais de uma história. Entregável: protótipo de média fidelidade da tela, sendo que uma tela pode envolver mais de uma história. | 8 UST’s por tela prototipada |
AD4 | Análise e desenho | Alteração/ajuste de Protótipo Entregável: alterações no protótipo de média fidelidade da tela, sendo que uma tela pode envolver mais de uma história, | 2 UST’s por protótipo de tela alterado. |
contemplando o versionamento e alterações/ajustes realizados no protótipo. | |||
B1 | Implementação back-end | Implementação back-end de 1 história ou item arquitetural (Codificação Completa, incluindo operações, autorizações, relatórios, validação do campo, sanitização das “strings”, integrações, serviços etc.). Entregável: Código-Fonte registrado no diretório do projeto. | 21 UST’s por história ou item arquitetural |
B2 | Implementação back-end | Alteração/ajuste/refatoração de história, item arquitetural ou item de trabalho. Entregável: Código-Fonte registrado no diretório do projeto, contemplando o versionamento e alterações/ajustes realizados no código. | 8 UST’s por história ou item arquitetural alterado. |
F1 | Implementação front-end | Implementação front-end de 1 história ou item arquitetural (validações, construções de tela, etc) Entregável: Código-Fonte registrado no diretório do projeto. | 21 UST’s por história ou item arquitetural |
F2 | Implementação front-end | Alteração/ajuste/refatoração de história, item arquitetural ou item de trabalho. Entregável: Código-Fonte registrado no diretório do projeto, contemplando o versionamento e alterações/ajustes realizados no código. | 8 UST’s por história ou item arquitetural alterado. |
LT1 | Liderança Técnica | Realizar atividades de liderança técnica como: Fazer code review, elaborar estratégia de implementação, dar suporte aos desenvolvedores, etc. Entregável: Documento formalizando a participação de cada participante nos encontros/ritos da sprint. | 1 UST por hora alocada a cada sprint (o tempo de dedicação para essa atividade deve ser definida no planejamento da iteração e validada pela Prodemge). |
T1 | Teste | Preparação (escrever cenários de teste) e implementação de testes funcionais (a serem definidos de | 10 UST’s por história |
acordo com cada contexto) por história. Entregável: Cenários/casos de teste e evidências por vídeo dos testes funcionais realizados registrados no diretório do projeto. | |||
T2 | Teste | Testes automatizados: Preparação e implementação de testes automatizados (testes unitários, de integração, regressão, etc) por história. Entregável: Script’s de testes automatizados registrados no diretório do projeto, podendo ser reutilizáveis quando necessários pela Prodemge. | 10 UST’s por história |
T3 | Teste | Preparação (escrever cenários de teste) e implementação de testes funcionais (a serem definidos de acordo com cada contexto) por erro (bug) na história. Nota: usar este item apenas quando a necessidade não for testar uma história inteira. Entregável: Cenário / caso de testes e evidenias dos testes funcionais realizados, registrados no diret´rio do projeto | 2 UST por erro na história |
H3 | Homologação | Realizar homologação assistida com o PO. Entregável: Documento formalizando a participação de c ada participante nos encontros/ritos da sprint. | 1 UST por hora de reunião de homologação por participante (a quantidade total de horas e de participantes, bem como seu perfil, deve ser, sempre, definidos pela Prodemge). |
AB1 | Ambiente | Configuração de ambiente de desenvolvimento. Entregável: Documento formalizando que a configuração foi realizada. | 4 UST’s por desenvolvedor |
AB2 | Ambiente | Configuração de ambiente de banco de dados. Entregável: Documento formalizando que a configuração foi realizada. | 4 UST’s por desenvolvedor |
EC1 | Estudo | Estudo do negócio/arquitetura definida para o produto. Entregável: apresentação do Estudo e documento formalizando que a apresentação foi realizada. | 1 UST por hora de estudo. Não ultrapassando 5 dias úteis de estudo e 40 UST por sprint. Será definido pela Prodemge de acordo com a complexidade do sistema. |
EC2 | 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 160 UST. Será definido pela Prodemge de acordo com a complexidade do sistema. |
D1 | Dados | Modelagem de dados - Criação do modelo de dados base/inicial Fica a critério da Prodemge definir se algum nível (conceitual, lógico, físico) não terá necessidade de ser construído. Entregável: Documentação contemplando o modelo de dados, conforme padrões definidos pela equipe, registrada no diretório do projeto. | 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. |
D2 | Dados | Modelagem de dados - Evolução do modelo referente à 1 história. Entregável: Alterações realizadas, contemplando o versionamento e alterações/ajustes realizados no modelo de dados. | 4 UST’s por história |
D3 | 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 entregáveis: (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 |
1.1. Os entregáveis supracitados, assim como os demais presentes no edital, não possuem template específico e serão solicitados conforme o contexto e necessidade de cada projeto. Caberá ao fornecedor gerar os entregáveis conforme padrões definidos pela Prodemge.
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. Ritos / Encontros não são passíveis de aplicação de fator de complexidade. Sua duração é estimada na abertura da OS e poderá ser revisada no Termo de Encerramento, contemplando de fato a quantidade exata de UST's utilizadas, presentes nas atas de reuniões geradas para cada item, durante a execução da Sprint
2.5. A decisão da aplicação do fator de ajuste será feita no fechamento da Ordem de Serviço.
ANEXO I - D
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 Xxxxxxx 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 de Sistemas
3.2.1 O processo no ambiente de homologação de sistemas 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 de sistemas.
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: Uma violação 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: Uma violação 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: Uma violação que pode impactar fortemente a produtividade do desenvolvedor: pedaço descoberto de código, blocos duplicados, parâmetros não utilizados.
d. MINOR: Uma violação 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: Nenhuma violação, 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 |