TERMO DE REFERÊNCIA – TR
TERMO DE REFERÊNCIA – TR
Serviço de Desenvolvimento e Sustentação de Sistemas
1. OBJETO DA CONTRATAÇÃO
1.1. Contratação de empresa especializada em tecnologia da informação para a prestação de serviços técnicos continuados de desenvolvimento e sustentação de sistemas, sob demanda, conforme as especificações descritas neste Termo de Referência e seus anexos, durante o período de 12 (doze) meses, para atender às necessidades do Ministério Público de Pernambuco (MPPE).
1.2. Este termo de referência foi elaborado de acordo com a Resolução n.º 102-CNMP, datada de 23.09.2013, publicada no DOU de 11.10.2013, que disciplina, no âmbito do Ministério Público Brasileiro, os procedimentos relativos à contratação de soluções de Tecnologia da Informação. Da mesma forma, a contratação decorrente deste termo de referência seguirá os procedimentos da citada norma.
1.2.1. A Resolução n.º 102-CNMP poderá ser consultada, na íntegra, através do site: xxxx://xxx.xxxx.xx.xx/xxxxxx/xxxxxxxxxx/0000-xxxxxxxxx-000-xx-0000
1.2.2. Em consonância aos procedimentos previstos na Resolução Nº102-CNMP, fazem parte deste Termo de Referência os seguintes anexos:
1.2.2.1. ANEXO I – CATÁLOGO DE SERVIÇOS.
1.2.2.2. XXXXX XX – PERFIS PROFISSIONAIS.
1.2.2.3. ANEXO III – ARQUITETURA E AMBIENTE.
1.2.2.4. ANEXO IV – METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE (MDS).
1.2.2.5. ANEXO V – NÍVEIS MÍNIMOS DE SERVIÇO.
1.2.2.6. ANEXO VI – MINUTA DO TERMO DE CIÊNCIA.
1.2.2.7. ANEXO VII – MINUTA DO TERMO DE COMPROMISSO DE MANUTENÇÃO DE SIGILO.
1.2.2.8. ANEXO VIII – MINUTA DO TERMO DE RECEBIMENTO PROVISÓRIO.
1.2.2.9. ANEXO IX – MINUTA DO TERMO DE RECEBIMENTO DEFINITIVO.
1.2.2.10. ANEXO X – MINUTA DE DECLARAÇÃO DOS COMPROMISSOS ASSUMIDOS.
1.2.2.11. XXXXX XX – MODELO DE PROPOSTA DE PREÇOS.
1.2.2.12. ANEXO XII – MINUTA DO CONTRATO DE PRESTAÇÃO DE SERVIÇOS.
2. FUNDAMENTAÇÃO DA CONTRATAÇÃO
2.1. Quantitativo
ID | ITEM | CÓDIFO EFISCO | DESCRIÇÃO | MÉTRICA | QUANTIDADE ESTIMADA ANUAL |
1 | 1.1 | 512751-3 | Unidade de Serviço Técnico – Serviço Desenvolvimento de Novos Sistemas e Sustentação de Sistemas Legados | UST | 47.309 |
TOTAL ESTIMADO | 47.309 UST |
2.2. Motivação
2.2.1. A contratação de serviços de fábrica de software (construção e manutenção de sistemas) tem como objetivo dar vazão às demandas por novos sistemas dentro da agenda de implantação do Processo Eletrônico na Instituição e às demandas de mudanças e de sustentação dos sistemas existentes.
2.2.2. A contratação dos serviços de Fábrica de Software contribui diretamente para o Planejamento Estratégico de Tecnologia e Inovação (PETI) do MPPE quanto ao alcance dos objetivos estabelecidos “Agilizar a transformação dos requisitos de negócio em soluções operacionais”, “Garantir o alcance dos benefícios a partir do portfolio de investimentos e serviços de tecnologia e inovação” e “Assegurar a entrega de projetos de T&I dentro do prazo, orçamento, atendimento a requisitos (escopo) e padrões de qualidade”.
2.2.3. Está em curso o Programa Processo Eletrônico, cujo objetivo é tornar a atuação finalística do MPPE totalmente eletrônica. Processo Eletrônico é o paradigma em que todas os procedimentos e peças processuais são virtuais, ou seja, foram geradas ou digitalizadas em arquivos para visualização e atuação por meio eletrônico. Assim, não há utilização de papel. Neste caso, diz-se que os autos do processo estão digitalizados. O Processo eletrônico é um conjunto de sistemas e serviços de TI que precisam ser desenvolvidos e/ou implantados pelo MPPE através da Coordenadoria Ministerial de Tecnologia da Informação (CMTI) e do Núcleo de Tecnologia e Inovação (NTI).
2.2.4. Visando dimensionar a quantidade de serviços necessários para implementar o portfólio de TI e suportar os serviços de TI, considerando o quadro de servidores atualmente disponível no MPPE, e considerando também o benchmark de utilização de métricas UST, estima-se que serão necessárias 47.309 UST para viabilizar a mão de obra necessária para o DEMSTI.
2.2.4.1. Utilizou-se benchmark de 40% das UST com nível de complexidade alta e 60% das UST com nível de complexidade padrão, considerando análise interna sobre os produtos de software disponíveis no portfólio de aplicações, a existência de serviços legados com tecnologias de menor produtividade de trabalho e o portfólio de demandas e projetos de TI.
2.2.4.2. Foi estabelecida como base de trabalho a execução de 176 UST mensais de prestação de serviço, correspondente o quantitativo previsto para prover 8 UST diárias de prestação de serviço, sendo esta a métrica para dimensionamento do esforço da CONTRATANTE.
2.2.4.3. Contudo, ressalte-se que esta contratação é baseada em produtividade. Sendo assim, um profissional pode produzir mais que 176 UST mensais em função das características das atividades e demandas relacionadas.
2.2.4.4. Foi estabelecido o período de 12 meses de trabalho como vigência contratual, contemplando todo o ciclo de operação da fábrica, incluindo inserção, operação inicial, fase de produção e eventual descomissionamento.
2.2.5. Contratação dos Serviços de Fábrica de Software
2.2.5.1. Para melhor apoiar o MPPE no cumprimento da sua missão institucional, a CMTI deve buscar maior eficiência na construção e na sustentação de soluções tecnológicas, no provimento de informações para atender às constantes tomadas de decisão e na automação contínua dos processos de trabalhos com foco na economicidade e agilidade institucional. Dentro deste contexto, é preciso atender à elevada demanda de desenvolvimento de sistemas novos, manutenção e melhorias nos sistemas legados e de terceiros necessários ao desempenho das atividades dos usuários. Faz-se necessário, também, atender às demandas de integração, migração e modernização desses sistemas, o que contrasta com a insuficiência de recursos humanos no setor responsável pela construção de soluções. A capacidade produtiva de qualquer time de desenvolvimento é limitada aos recursos existentes. Nesse sentido, é fundamental a expansão da capacidade produtiva na construção de sistemas através da contratação de serviços de desenvolvimento e manutenção de sistemas.
2.2.5.2. A expansão da capacidade desejada é por meio da contratação do que se chama “Fábrica de Software”, conjunto de profissionais, recursos materiais, processos e metodologias para o desenvolvimento e manutenção de softwares, sistemas e aplicações, englobando desde a análise de requisitos até a fase de entrega e manutenção.
2.2.5.3. A contratação da fábrica não se limita à execução dos projetos acima listados. O serviço de Fábrica de Software é um mecanismo de agilidade da TI na resposta às demandas por soluções e mudanças.
2.2.5.4. A Fábrica de Software atua em todo o ciclo de vida da construção de soluções (etapas de produção), com etapas e tarefas perfeitamente definidas para cada tipo de profissional, indo da produtividade da linha de produção às rotinas de controle de qualidade. Percebe-se, facilmente, que o foco deixa de ser a pessoa e passa a ser os processos de construção e entrega (delivery). Os principais pontos, neste novo modelo de trabalho, são o PROCESSO e o PRODUTO. O insumo básico necessário para a construção de um produto imaterial que é o componente de software especificado.
2.2.5.5. A Fábrica de Software especializa-se no processo de produção e o cliente nas características inerentes ao seu negócio e no atendimento aos seus usuários. Tal prática está perfeitamente adequada ao Plano Estratégico desta casa, focando, cada vez mais, a equipe técnica da TI no desenvolvimento de sistemas estratégicos da instituição e na administração da operação da TI.
2.2.5.6. Órgãos como Conselho Nacional do Ministério Público (CNMP), MPRS, MPBA, MPGO, MPSE, MPSP, MPRJ, MPRO, MPMT entre outros, além do Governo do Estado, TCE-PE e TJPE utilizam ou utilizaram serviços de Fábrica de Software. Ao longo de 2019, a Coordenação de Soluções realizou amplo estudo para melhor formatar o Termo de Referência desta contratação, incluindo a visita de fornecedores e o contato com outros órgãos para se entender como os processos de contratação foram realizados.
2.2.6. Justificativa da métrica Unidade de Serviços Técnicos (UST)
2.2.6.1. Baseando-se em boas práticas como o Guia de Boas Práticas em Contratação de Soluções de Tecnologia da Informação do TCU, na Instrução Normativa MP/SLTI Nº 1/2019, no Acórdão 2037/2019 do TCU, no Acórdão 1508/2020 do TCU, opta-se pela modalidade de pregão eletrônico, de contratação de serviços especializados na modalidade presencial e não presencial, utilizando Unidades de Serviços de Técnicos (UST) para o dimensionamento das demandas, com aferição e medição de produtividade e qualidade por meio de indicadores de níveis mínimos de serviços, com o intuito de impedir o paradoxo ineficiência-lucro.
2.2.6.2. A unidade de medida escolhida – UST – equivale a uma hora de esforço especializado não individualizado. Embora a medição do esforço seja feita em UST, a remuneração será sempre vinculada a resultados, na forma de entregáveis específicos, e de níveis de serviço estabelecidos e cumpridos. A remuneração é feita, exclusivamente, pela dimensão do projeto em UST, conforme aprovado pelo MPPE anteriormente ao início da execução do desenvolvimento.
2.2.6.3. A métrica UST é utilizada para mensurar serviços de Tecnologia da Informação com complexidades variadas, permitindo o controle e a precificação de serviços preestabelecidos, bem como a mensuração do esforço em situações ou problemas previamente conhecidos.
2.2.6.4. Esta métrica, além de permitir o controle e a precificação de todos os serviços previstos neste Termo de Referência, apresenta a vantagem de permitir que o tempo, para fins de obtenção dos resultados pretendidos, seja um dos focos de controle. Desta forma viabiliza-se a priorização das ações, incluindo-se as alterações ou mudanças requeridas periodicamente ou eventualmente. Outra vantagem neste tipo de contratação é que não há caracterização de locação exclusiva de mão-de- obra, vez que a forma básica para a solicitação do serviço por demanda é “o próprio serviço”, estabelecendo, inicialmente, quais serviços e em quanto tempo devem ser realizados. Somente após esta definição que, independe da quantidade de pessoas, se faz a devida identificação dos recursos humanos capazes de executar a tarefa, ou seja, define-se a qualificação técnico-profissional.
2.2.6.5. Em termos de economicidade, a presente metodologia busca o melhor aproveitamento dos recursos humanos, materiais e financeiros disponíveis, evitando que sejam desperdiçados recursos com alocações indevidas, desnecessárias e onerosas. Os serviços serão demandados, caso a caso, estipulando-se um prazo para sua realização , devendo o produto da demanda atender ao formato e qualidade previamente pactuada. O atendimento ao prazo fixado para entrega do produto, bem como o formato e a qualidade pactuada serão utilizados como instrumento de controle das etapas de solicitação, acompanhamento, avaliação, atestação e pagamento.
2.2.6.6. Embora seja serviço comumente ofertado no mercado, sabe-se que diversos riscos existem na contratação de uma Fábrica de Software, tais como o não alcance dos requisitos do cliente, problemas de qualidade, a criação de cronogramas e orçamentos inexequíveis, imprevistos com os recursos alocados, processo de software imaturo e suporte tecnológico discrepante da matriz tecnológica da contratante. Portanto, o estabelecimento de uma operação baseada em modelos quantitativos e qualitativos atrelados a métricas mensuráveis e critérios específicos para a gestão contratual, torna- se um processo mais eficiente de gestão contratual e de fornecedor.
2.2.6.7. Esta contratação permitirá uma mensuração objetiva do resultado do trabalho e dos quantitativos consumidos a partir do estabelecimento de Instrumentos de Medição de Resultado (IMR). Conforme Instrução Normativa nº 05/2017, do Ministério do Planejamento, Desenvolvimento e Gestão, ora invocada a título de boas práticas, o IMR é definido como mecanismo que define, em bases compreensíveis, tangíveis, objetivamente observáveis e comprováveis, os níveis esperados de qualidade da prestação do serviço e respectivas adequações de pagamento.
2.2.6.8. Esta contratação também está em consonância com o Acordão 1508/2020 do TCU, que dentre outros pontos, recomenda que, “em contratações baseadas em UST, sejam implantados controles internos que assegurem a existência dos catálogos de serviços, juntamente com todos os detalhamentos cabíveis de cada serviço, como perfis profissionais, tempo estimado de execução e produtos e resultados esperados, a fim de mitigar o risco de antieconomicidade e de inobservância dos normativos já existentes, que versam sobre a clareza da solução de tecnologia da informação demandada”.
2.2.6.9. As estimativas estabelecidas no catálogo têm por base uma relação de equivalência entre o esforço técnico de uma determinada atividade, executada por determinados perfis de trabalho, e a complexidade de sua execução. Para cada demanda a ser executada, é estabelecido o esforço em UST para sua conclusão, criando-se um modelo objetivo e assertivo para o dimensionamento dos serviços e controle da execução contratual.
2.2.6.10. O catálogo de serviços para esta contratação foi estabelecido com base nas principais atividades relacionadas à metodologia de desenvolvimento de soluções da Instituição, realizando-se, inclusive, benchmark com outras Instituições, visando à melhor definição deste catálogo.
2.2.6.11. Está prevista a implantação de Processo de Construção de Soluções para operação da Fábrica de Software, assegurando a formalização do acompanhamento das atividades da empresa contratada, incluindo atividades, artefatos, papéis e atribuições, métricas e indicadores de processo e qualidade.
2.2.6.12. Ressalte-se que os Acórdãos 2.037/2019-TCU e 1508/2020-TCU estabeleceram recomendações com o objetivo de auxiliar aos órgãos e entidades quanto à realização de contratações baseadas em UST:
RECOMENDAÇÕES E REQUISITOS DE CONTRATAÇÃO | ANÁLISE E COBERTURA PELO TERMO DE REFERÊNCIA |
“Evitar o uso da métrica UST para a contratação de serviços de suporte contínuo de infraestrutura de TI, visto que esse serviço não gera resultados ou produtos aferíveis pelo contratante.” | O objeto desta contratação não contempla o escopo de suporte contínuo de infraestrutura de TI, mas os serviços de construção e manutenção de sistemas e serviços de TI, com base em metodologia de trabalho e previsão de entregáveis. |
“Avaliar, durante o planejamento da contratação, alternativas à métrica UST, bem como documentar as justificativas da escolha. ” | Na fase de identificação das soluções e estudos técnicos preliminares, foram avaliadas alternativas de contratação e atendimento à demanda, entendendo-se que a modalidade de Unidade de Serviços Técnicos (UST) melhor se adequada ao contexto da Organização. |
“Na pesquisa de preços para contratação de serviços medidos por UST, para além da simples comparação de valores, avaliar as características das contratações para fins de se averiguar a similaridade dos serviços e a composição dos custos unitários. ” | Faz parte da etapa de Pesquisa de Preços o levantamento de contratações similares de outros entes públicos e a devida caracterização das fontes consultadas, inclusive por meio de sítios eletrônicos especializados em processos licitatórios. Também faz parte da definição do preço de referência, a pesquisa direta com fornecedores, mediante solicitação formal de cotação, assegurando-se uma melhor definição do orçamento da contratação. |
RECOMENDAÇÕES E REQUISITOS DE CONTRATAÇÃO | ANÁLISE E COBERTURA PELO TERMO DE REFERÊNCIA |
“Especificar no Catálogo apenas serviços diretamente vinculados aos resultados esperados da contratação, não se permitindo o pagamento individualizado por serviços intermediários. Constar no Catálogo de Serviços apenas itens relacionados ao objeto da contratação. ” | Os serviços estabelecidos no catálogo são diretamente vinculados aos resultados esperados na contratação e contemplando o conjunto de atividades para entrega do serviço ao longo do ciclo de vida de construção ou manutenção de uma solução, não sendo passível de contratação tarefas intermediárias específicas ou pontuais. O catálogo de serviços, portanto, é o instrumento de solicitação de serviços junto ao fornecedor. |
“Estabelecer no TR as regras e procedimentos para eventuais alterações no Catálogo de Serviços. ” | Existe previsão de revisão e atualização do catálogo de serviços visando à melhor prestação de serviços e obtenção de resultados para a CONTRATANTE. |
“Apresentar no Catálogo de Serviço o respectivo valor monetário estimado de cada serviço, independentemente da métrica ou unidade utilizada. ” | Os serviços do catálogo possuem estimativas quantitativas individuais de esforço em UST. A UST possui valor financeiro de referência com base na pesquisa de preços da contratação. Desse modo, cada serviço possui valor monetário estimado. |
“Constar no Termo de Referência e no Catálogo de Serviços, para a suficiente caracterização do serviço a ser licitado, no mínimo, os seguintes elementos: Nome do serviço, descrição do serviço e dos respectivos entregáveis e atividades; Qualificação dos profissionais necessários (perfis); Esforço necessário à execução dos serviços; Prazo e quantitativo estimado; Estabelecer memórias de cálculo que justifiquem os esforços previstos. ” | O catálogo de serviços possui caracterização suficiente para seu devido entendimento e utilização. O catálogo de serviços estabelecido possui itens como definição do serviço, produtos esperados, fator de complexidade associados e perfis de trabalho associados à execução das tarefas do serviço. Também foram elencados perfis profissionais que devem estar disponíveis para execução dos serviços do catálogo. Ressalte-se que foram estabelecidos níveis mínimos de serviço, critérios de qualidade da prestação de serviços e acordos de nível de serviço referente aos prazos de atendimento e execução das atividades, governados a partir de um processo de emissão e controle de Ordens de Serviço. |
“Exigir o fornecimento à Administração da planilha de custo e formação de preço pelo vencedor da licitação, juntamente com a proposta de preços, de maneira a minimizar o risco de sobrepreço. ” | Está prevista no pregão eletrônico a etapa de apresentação de proposta de preços, sendo solicitado, adicionalmente, a apresentação de planilhas de custos e formação de preços, com base na Instrução Normativa Nº5/2017 do Ministério do Planejamento, Desenvolvimento e Gestão. |
“Elaborar planilha de custo e formação de preço, na fase de planejamento da contratação, com o objetivo de calcular o valor estimado da contratação, que, se for o caso, constará no Termo de Referência.” | A partir do catálogo de serviços e da lista de perfis profissionais exigidos, e considerando as demandas institucionais, foi estabelecida previsão do volume de UST para esta contratação. E, com base na Pesquisa de Preços, foi estabelecido o valor estimado da contratação, constando tal informação também no Termo de Referência. |
2.2.6.13. Ante o exposto, corrobora-se a adoção do modelo de UST de contratação no caso vertente, com a fixação de remuneração balizada por instrumentos de medição de resultado.
2.3. Objetivos e Resultados da Contratação
2.3.1. Aumento das entregas de software necessárias à Instituição, evitando danos aos processos de trabalho das diversas áreas.
2.3.2. Prover maior velocidade na entrega dos projetos, dentro dos níveis de qualidade esperados.
2.3.3. Ampliar o portfólio de serviços oferecidos pela Coordenadoria Ministerial de Tecnologia da Informação (CMTI).
2.3.4. Promover a continuidade da padronização quanto a tecnologias e métricas.
2.3.5. Aprimorar a gestão dos recursos utilizados em manutenção e desenvolvimento de sistemas.
2.3.6. Aprimorar a previsibilidade do atendimento aos serviços de desenvolvimento, manutenção e documentação dos sistemas informatizados do MPPE por meio do aumento das entregas realizadas dentro dos prazos acordados.
2.4. Levantamento das alternativas
Solução 1 – Absorção das atividades pelo quadro atual de servidores efetivos | |
Entidade | MINISTÉRIO PÚBLICO DE PERNAMBUCO |
Descrição | Execução dos serviços técnicos de sustentação e desenvolvimento de sistemas, utilizando o quadro atual de servidores do MINISTÉRIO PÚBLICO DE PERNAMBUCO (MPPE). |
Fornecedor | MPPE |
Solução 2 – Ampliação do quadro de servidores efetivos com absorção das atividades | |
Entidade | MINISTÉRIO PÚBLICO DE PERNAMBUCO |
Descrição | Ampliação do quadro funcional com novos servidores para a área de tecnologia da informação que prestarão os serviços técnicos de sustentação e desenvolvimento de sistemas. |
Fornecedor | MPPE |
Solução 3 – Serviço de Sustentação e Desenvolvimento de sistemas | |||
Entidade | MPPE, empresas de mercado | ||
Descrição | Contratação de empresa especializada em sustentação e desenvolvimento de sistemas, limitada aos quantitativos anuais, conforme as especificações descritas neste documento, durante o período de 12 (doze) meses, prorrogáveis de acordo com as possibilidades definidas na Lei nº 8.666/1993, para atender às necessidades do MINISTÉRIO PÚBLICO DE PERNAMBUCO (MPPE). | ||
Fornecedor | Empresa de mercado | Valor | R$ 7.482.630,14 |
2.4.1. Análise Financeira da Solução 03 - Serviço de Sustentação e Desenvolvimento de sistemas
DETALHAMENTO DA SOLUÇÃO 3 – SERVIÇO DE SUSTENTAÇÃO E DESENVOLVIMENTO DE SISTEMAS | ||||
ID | ITEM | DESCRIÇÃO | MÉTRICA | QUANTIDADE ESTIMADA ANUAL |
1 | 1.1 | Unidade de Serviço Técnico – Serviço Desenvolvimento de Novos Sistemas e Sustentação de Sistemas Legados | UST | 47.309 |
TOTAL ESTIMADO | 47.309 UST |
2.5. Referência aos estudos preliminares
2.5.1. O resultado da realização dos Estudos Preliminares encontra-se apresentado através dos seguintes documentos acostados aos autos: Estudos Técnicos Preliminares.
2.6. Justificativa da Solução Escolhida
2.6.1. A contratação de serviços de fábrica de software (construção e manutenção de sistemas) tem como objetivo dar vazão às demandas por novos sistemas dentro da agenda de implantação do Processo Eletrônico na Instituição e às demandas de mudanças e de sustentação dos sistemas existentes.
2.6.2. Atualmente o Departamento de Soluções de TI (DEMSTI) é responsável por realizar a sustentação dos sistemas e serviços de TI, incluindo manutenções corretivas e evolutivas de soluções existentes, e por entregar novos sistemas para atender às demandas do MPPE, incluindo as necessidades por painéis de informação (BI)
2.6.2.1. O DEMSTI conta somente com equipe de apenas 15 pessoas (referência a Janeiro/22) para suportar todos os serviços de TI associados a sistemas de informação e painéis de BI.
2.6.2.2. O DEMSTI é responsável por atender e dar suporte avançado a chamados relativos aos sistemas do MPPE e por apoiar a resolução de chamados para sistemas externos.
2.6.2.3. Existem hoje cerca 50 sistemas e serviços/componentes e 15 paineis de Informação (BI), mantidos diretamente ou indiretamente pela equipe do DEMSTI. Alguns destes produtos são setoriais e outros produtos são institucionais.
2.6.2.4. Projetos de alta complexidade, como “Processo Eletrônico”, também são executados pelas equipes do DEMSTI.
2.6.2.5. O DEMSTI é responsável por avaliar, planejar e tratar todas as demandas referentes a sistemas de informação provenientes de todas as áreas do MPPE bem como realizar relacionamento com as áreas do MPPE quando a agenda “Soluções de TI” é objeto de discussão.
2.6.2.6. O DEMSTI contribui ativamente com as discussões sobre portfólio de projetos e gestão de mudanças junto ao Comitê Gestor de Sistemas da Área Fim (CGSAF).
2.6.3. O cenário considerando a absorção da demanda sem contratação de mão de obra ou serviço de fornecedores foi avaliado, mas constatado como inviável pela falta de disponibilidade de mão de obra interna, sendo esta uma carência dentro da área de TI do MPPE. Não há hoje no quadro de pessoal a disponibilidade de profissionais em quantidade suficiente para atender a carga de demandas. Alguns fatores impactam de forma negativa este cenário:
2.6.3.1. Incapacidade de remanejamento de servidores para esta solução pois todo o quadro atual de TI já se encontra alocado em diversas atividades.
2.6.3.2. Falta de perspectiva de novas vagas para servidores da área de tecnologia da informação proporcionais à demanda de suporte aos sistemas do MPPE.
2.6.3.3. A ampliação do quadro efetivo da CMTI para execução das atividades se torna inviável em função da impossibilidade de aumento do custeio de pessoal e a não previsão de concurso público.
2.6.4. Assim, a solução encontrada durante a realização dos estudos preliminares foi a execução de serviços de sustentação/desenvolvimento de sistemas, mensurados através de métricas que possibilitem a remuneração dos fornecedores, com base no alcance de resultados e dos índices mínimos de qualidade, atendendo assim a orientação do Tribunal de Contas da União na Súmula n° 269.
3. DESCRIÇÃO DA SOLUÇÃO E ESPECIFICAÇÃO TÉCNICA
3.1. Descrição da Solução
3.1.1. A Solução de TI abrange a prestação dos serviços de manutenção e desenvolvimento de sistemas, sob demanda conforme especificações e requisitos mínimos obrigatórios exigidos neste documento.
3.1.2. Atualmente, o MPPE tem utilizado duas arquiteturas principais baseadas em Java. A primeira arquitetura com Spring Boot e Angular, e a segunda arquitetura com EJB, BMP e JSF, além de outras tecnologias complementares. Além disso, existem sistemas legados e de terceiros implantados, com algum nível de customização, utilizando linguagens como PHP, Python e Java, por exemplo.
3.1.3. Os serviços de desenvolvimento consistem no desenvolvimento de novos sistemas de informação, ao passo que os serviços de sustentação (manutenção) compreendem as manutenções (adaptativa, evolutiva e corretiva) dos sistemas em produção no MPPE.
3.1.4. Os serviços de sustentação e desenvolvimento de sistemas abrangem a execução de todas as tarefas inerentes às disciplinas típicas de um processo de software, incluindo: Requisitos e Análise, Documentação técnica e manuais, Arquitetura de Software e de Dados, Implementação (codificação), Teste, Gestão de Configuração, Implantação, Migração/manutenção de dados em sistemas legados cedidos ou adquiridos, Apoio técnico (incluindo orientação e esclarecimento de dúvidas, capacitação, elaboração de pareceres técnicos, configuração, parametrização e transferência de tecnologia) e eventual gestão de projeto, devendo-se considerar os grupos de tarefa abaixo estabelecidos:
3.1.4.1. TAREFAS DE DESENVOLVIMENTO DE NOVOS SISTEMAS DE INFORMAÇÃO:
3.1.4.1.1. Corresponde ao desenvolvimento de novos aplicativos ou sistemas de informação, a partir de especificações estabelecidas ou validadas pelo MPPE, aplicando os procedimentos necessários à garantia da qualidade do produto. Este serviço abrange todas as fases do processo de desenvolvimento de sistemas, desde a análise de viabilidade até sua disponibilização para o usuário final, através da configuração e preparação dos ambientes de desenvolvimento, homologação e produção, incluindo a migração e os treinamentos necessários para a utilização dos sistemas.
3.1.4.1.2. Planejar e organizar atividade de Consultoria para projetos de Inovação, mapeamento e desenho de processos de negócio, Mapeamento de modelos de negócios e requisitos à solução de sistema de informação em unidade da CONTRATANTE coberta pela presente Contratação. O atendimento dessas solicitações deve obedecer a prazos e cronogramas elaborados e apresentados pela LICITANTE após o registro da solicitação, os quais devem ser aprovados pela CONTRATANTE.
3.1.4.2. TAREFAS DE MANUTENÇÃO DE SISTEMAS DE INFORMAÇÃO: correspondem às modificações em sistemas já existentes ou internalizados após o final da garantia do serviço de desenvolvimento. Têm o objetivo de prevenção, correção de falhas, implementação de melhorias ou adaptações, classificadas conforme abaixo:
3.1.4.2.1. Manutenção adaptativa – Adequação de aplicações às mudanças de ambiente operacional, compreendendo hardware e software básico, mudanças de versão, linguagem e SGBD, que não impliquem em inserção, alteração ou exclusão de funcionalidades. Esse tipo de serviço se aplica também aos cenários de internalização de aplicações, que consiste na adequação de sistemas fornecidos ao MPPE.
3.1.4.2.2. Manutenção corretiva - Consiste na correção de defeitos de sistemas em produção. Abrange comportamentos inadequados que causem problemas de uso ou funcionamento do sistema e quaisquer desvios em relação aos requisitos aprovados. Os custos de manutenção corretiva de erros gerados pela CONTRATADA são de sua responsabilidade, durante o período de garantia dos sistemas.
3.1.4.2.3. Manutenção evolutiva - Corresponde a mudança em requisitos funcionais de sistemas em produção decorrentes de alterações de regras de negócio e/ou demandas legais.
3.1.4.2.4. Manutenção perfectiva – Contempla a modificação de um sistema em produção para detectar e corrigir falhas latentes antes que se materializem. Agrega aplicativos ou ferramentas complementares. Provê melhorias de desempenho, documentação ou outros atributos do software.
3.1.4.2.5. Migração - Atividades de Manutenção de Soluções de TI/Serviços podem implicar a necessidade de contratação de serviço de Migração de Tecnologia, que dependendo da complexidade poderão se classificar como Projeto.
3.1.4.3. TAREFAS DE INTEGRAÇÃO:
3.1.4.3.1. Teste pós integração - Execução/acompanhamento/monitoração, a critério do MPPE, de testes sobre versões integradas a partir de produtos de 1 ou mais Sprints, podendo estes serem de diferentes equipes de desenvolvimento, compreendendo testes de validação, exploratórios, caixa branca, regressivos, de segurança, estresse, carga, dentre outros.
3.1.4.3.2. Manutenção da biblioteca de Testes - Manter em execução toda a estrutura que compõe os testes dos sistemas envolvidos, tais como massas, scripts, artefatos, simuladores, rotinas e processos negociais dos sistemas.
3.1.4.3.3. Testes Eventuais - Realização de testes pontuais motivados por demandas externas e não planejadas.
3.1.4.3.4. Verificação de Compatibilidade -Realização de testes específicos para verificar a correta execução da aplicação nos diferentes modelos de hardware, navegadores e sistemas operacionais.
3.1.4.3.5. Geração de indicadores - Prover indicadores de varredura, cobertura dos testes, falhas, dentre outros.
3.1.4.3.6. Apoio à Homologação - Apoiar aos gestores e equipe responsável pela homologação ativa (HMP).
3.1.4.4. TAREFAS DE APOIO AO PLANEJAMENTO:
3.1.4.4.1. Apoiar o planejamento dos roadmaps dos produtos atendidos por vários Sprints, gerando visões de médio/longo prazos em forma de cronogramas gerenciais e relatórios de evolução. Acompanhar a evolução das entregas, sinalizando riscos e potenciais desvios, sempre com o objetivo de entrega de valor ao cliente demandante.
3.1.4.4.2. A elaboração e atualização da documentação dos sistemas decorrentes do objeto desta contratação deverão ser realizadas pela CONTRATADA, é obrigatória, sem custo adicional e devem estar em conformidade com o modelo estabelecido pela Instituição.
3.1.4.4.3. Os produtos a serem desenvolvidos pela CONTRATADA deverão ser entregues respeitando o processo de desenvolvimento de software, os requisitos expressos na OS e demais exigências contidas nesta contratação.
3.1.4.4.4. Os detalhes do processo de desenvolvimento de software serão apresentados como parte do plano de inserção da CONTRATADA.
3.1.4.5. TAREFAS DE CONFIGURAÇÃO DE MUDANÇA:
3.1.4.5.1. Serviços de configuração e mudanças no processo de desenvolvimento, incluindo a criação de linhas de base, verificação de padrões de nomes e de organização dos itens de configuração na ferramenta de Gerência de Configuração, bem com o controle de configuração e mudança dos produtos entregues ao MPPE.
3.1.4.5.2. Prestar suporte à atividade de desenvolvimento de produtos para que os desenvolvedores e integradores tenham espaços de trabalho adequados para criar e testar seus projetos e, dessa forma, permitir que todos os produtos em desenvolvimento fiquem disponíveis para inclusão no ambiente de implantação de forma controlada quando solicitado ou conforme necessário.
3.1.4.6. TAREFAS DE APOIO À QUALIDADE DE SOFTWARE:
3.1.4.6.1. Serviços de avaliação da qualidade do software e seus artefatos, tais como realizar testes, avaliar a arquitetura, modelo de dados, documentação, entre outros.
3.1.4.6.2. Serviço de apoio a metodologias ágeis, tais como: Coaching para indivíduos (Modelo GROW, Modelos para feedback, Metacognização e Hipóteses comportamentais) e Coaching para times ágeis (Personal, Executive e Team Coaching, Coaching para atuar em disfunções de um time, Desenvolvimento de Competências, Facilitação de retrospectivas comportamentais em times, Facilitação e coaching apoiados por Canvas, entre outros).
3.1.4.7. TAREFAS DE APOIO À ARQUITETURA DE SOFTWARE:
3.1.4.7.1. Serviço de apoio à definição de arquitetura de solução para sistemas e orientação aos desenvolvedores quanto aos padrões de projetos adotados.
3.1.4.7.2. Apoio na definição das tecnologias a serem utilizadas para determinado desenvolvimento.
3.1.4.7.3. Realizar a integração (empacotamento) e merges (mesclas) de builds paralelamente desenvolvidos.
3.1.4.7.4. Realizar estudos de prospecção no mercado na busca das melhores práticas, tendências e soluções em uso na indústria, apresentando proposta para sua implementação no MPPE.
3.1.4.7.5. Serviços de análise de impacto na migração de versão das ferramentas e tecnologias em uso na disponibilização de serviços fazem parte deste agrupamento.
3.1.4.8. TAREFAS DE APOIO AO COMISSIONAMENTO DE AMBIENTE:
3.1.4.8.1. Instalação e configuração de servidor de aplicação em ambiente de não-produção (tais como ambientes de desenvolvimento e homologação) e publicação (deploy) dos sistemas desenvolvidos nestes ambientes.
3.1.4.9. TAREFAS TÉCNICAS ADICIONAIS ASSOCIADAS A SISTEMAS DE INFORMAÇÃO:
3.1.4.9.1. Suporte especializado - consiste na execução de procedimentos de alta especialização não mensuráveis eventualmente requeridos em projeto, evolução e/ou sustentação de sistemas, tais como prospecção tecnológica e construção de provas de conceito, construção e definição de soluções arquiteturais, diagnóstico de problemas em cenários de alta complexidade e apoio em soluções de gestão de dados, intervenções e correções de problemas em ambientes e infraestruturas relacionadas aos produtos, dentre outros.
3.1.4.9.2. Assessoria em usabilidade e experiência do usuário (UX) - consiste na análise, prospecção e projeto de melhoria de experiência de usuário, com o objetivo de incrementar aspectos cognitivos e ambientais, otimização dos processos de interface gráfica e padronização da identidade visual.
3.1.4.9.3. Testes não-funcionais - consiste no planejamento, especificação, execução e registro dos resultados de testes de software não-funcionais tais como testes de carga, performance e stress, dentre outros.
3.1.4.9.4. Modelagem de processo de negócio - consiste no apoio ao mapeamento e aperfeiçoamento de processo de negócio, através de discussões, estudos e diagramação de processos junto às áreas de negócio.
3.1.4.9.5. Treinamento de usuários - consiste no apoio à confecção de material de treinamento para usuários de sistemas, bem como instrução presencial ou remota em treinamentos respectivos.
3.1.4.9.6. Implantação assistida - assistência presencial aos procedimentos de homologação de soluções, apoiando no saneamento de eventuais problemas e dúvidas, além de configurações e testes adicionais eventualmente necessários;
3.1.4.9.7. Atualização de arquitetura de deployment de legado - construção, configuração e adaptação de scripts e pacotes de sistemas legados para o padrão de deployment de acordo com a arquitetura de containers com entrega contínua.
3.1.4.9.8. Documentação de legado - consiste na criação e/ou manutenção de documentação de sistemas legados conforme padrões estabelecidos na MDS vigente, desde que não haja manutenção associada, cuja documentação já é obrigatória.
3.1.4.9.9. Manutenção adaptativa de médio porte - alteração não-funcional de sistema com impacto localizado, necessária para adaptá-lo a determinados tipos de mudanças que não impliquem em reescrita de várias camadas, restringindo-se a porções arquiteturais específicas, tais como uso de novos componentes corporativos, mecanismos de autenticação com single sign on ou de acesso a funcionalidades de autorização, motores de busca, mudança de hardware dedicado, mecanismos de auditoria automática, dentre outros.
3.1.5. Os serviços deverão ser prestados tendo como base na quantidade de tarefas, quantidades de UST por tarefa e grupo de atividades previstas no momento da emissão das Ordens de Serviço, conforme catálogo de serviços.
3.1.6. Os serviços de desenvolvimento e sustentação dos sistemas deverão adotar as boas práticas de engenharia de software para garantir a qualidade e a adequação do incremento que será entregue, a exemplo de práticas como: Refactoring (melhorar o código-fonte sem alterar comportamento); Teste unitário; Inspeção de código; Integração contínua; Padrões arquiteturais de projeto; Modularização dos componentes arquiteturais; Baixo acoplamento e alta coesão das funcionalidades; Reusabilidade de componentes; Planejamento e execução de testes automatizados.
3.1.7. Os serviços deverão ser executados em conformidade com a Metodologia de Desenvolvimento de Software (MDS) do MPPE, os padrões de desenvolvimento definidos pelo MPPE e seus relacionamentos, metodologias de projeto, tecnologias, ferramentas e ambiente de desenvolvimento e infraestrutura utilizados pelo MPPE. Este modelo deve ser utilizado a título de referência de paradigma de construção de soluções, podendo sofrer ajustes visando à melhoria da entrega de soluções pela CONTRATADA junto à CONTRATANTE.
3.1.8. O MPPE terá ampla liberdade de atualizar as versões dos sistemas operacionais, componentes arquiteturais e de software, ferramentas de apoio ao desenvolvimento de sistemas, todos de sua propriedade ou de seu direito de uso, segundo sua necessidade e conveniência, cabendo, nestes casos, à CONTRATADA adaptar-se à respectiva mudança, sem quaisquer custos adicionais para o MPPE.
3.1.9. Sempre que demandados pelo MPPE, os serviços prestados deverão atender:
3.1.9.1. As normas e os padrões da Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil).
3.1.9.2. A acessibilidade a pessoas com limitação ou deficiência (visual, motora, cognitiva), naquilo que afetar a interface com usuário e a interação humano-sistema; o Art. 47 do Decreto Federal nº 5.296 de 2004, do Acesso à Informação e à Comunicação; e as diretrizes e padrões de acessibilidade definidos pelo Modelo de Acessibilidade em Governo Eletrônico (eMAG), do Programa de Governo Digital do Governo Federal, e pelas Diretrizes de Acessibilidade para Conteúdo Web (WCAG) e Accessible Rich Internet Applications (WAI-ARIA), do Word Wide Web Consortium (W3C).
3.1.9.3. Diretrizes definidas pelos Padrões Web em Governo Eletrônico (ePWG), do Programa de Governo Digital do Governo Federal.
3.1.9.4. Os padrões definidos no Modelo de Requisitos para Sistemas Informatizados de Gestão de Processos e Documentos do Poder Judiciário (Moreq-Jus).
3.1.10. Da forma de medição dos serviços
3.1.10.1. A Unidade de Serviço Técnico (UST) equivale a uma hora de esforço útil especializado. A medição do esforço útil, feita em UST, vincula a remuneração sempre a resultados, na forma de entregáveis específicos, e a níveis de serviço pré-estabelecidos.
3.1.10.2. Para cada tarefa será atribuída uma complexidade estabelecida através da qualificação técnica e dos grupos de atividades exigidos para sua execução, conforme Anexo I – Catálogo de Serviços.
3.1.10.3. Os colaboradores da CONTRATADA não poderão acumular a execução de mais de uma tarefa de forma simultânea.
3.1.10.4. As medições serão realizadas mensalmente, em função da métrica de Referência denominadas UST (Unidade de Serviço Técnico) considerando o nível de complexidade e os produtos previstos a serem gerados.
3.1.10.5. Poderá ser aplicado um fator multiplicador sobre o valor da UST em função da complexidade da tarefa demandada na Ordem de Serviço:
FATORES DE COMPLEXIDADE | ||
Nível de Complexidade | Definição das Atividades | Multiplicador |
C1 | Atividades pontuais e eventuais, com baixo grau de risco, que não envolvam programação, tais como: classificação e registro de informações, pesquisas na web, manutenção de textos estáticos, registros/eventos, versionamento de documentos, bem como utilização, operação e manutenção da base de conhecimento e ferramentas de apoio. Este nível de complexidade está previsto apenas para casos simples, excepcionais, que não possam ser enquadrados como casos de complexidade padrão. | 0,50 |
C2 | COMPLEXIDADE PADRÃO. Atividades que envolvam lógica de programação sem algoritmos complexos, desenho e redesenho de processos, consultoria de processos, execução de processos de inovação, elaboração de scripts, elaboração de documentos, manuais de usuário, design visual ou criativo, animações vetoriais e infográficos e serviços de apoio técnico e implantação de sistemas. | 1,00 |
C3 | 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 e afins. | 1,5 |
C4 | Serviços que envolvam programação em Sistemas com elevado grau de risco e sem envolvimento de algoritmos complexos, a ponto de demandar alta criatividade e/ou especialidade no desenho da solução Manutenção em Sistemas com maior dependência de outros Sistemas e mais restrições por regras e tecnologia de sistemas legados. | 2,00 |
3.1.10.5.1. Para classificar a complexidade dos serviços serão considerados os seguintes critérios: Relevância do objeto; Dificuldade operacional; Quantidade de documentação decorrente; Características técnicas e tecnológicas dos produtos e serviços; Catálogo de Serviços.
3.1.10.5.2. A qualificação do fator de complexidade é de exclusiva competência da CONTRATANTE e será indicado tomando por base a execução da demanda por profissionais experientes e competentes providos pela CONTRATADA.
3.1.10.5.3. O fator de complexidade não será utilizado para compensar a falta de capacidade e/ou eficiência de profissionais alocados pela CONTRATADA.
3.1.10.6. O pagamento correspondente às entregas de cada Ordem de Serviço (OS) emitida será efetuado, mensalmente, no valor correspondente aos itens finalizados de cada OS, após o recebimento provisório e aprovação dos serviços e posterior recebimento definitivo pelo Gestor do Contrato. O valor de cada ordem de serviço(OS) será calculado por meio da seguinte fórmula:
Valor_OS = Valor_UST * Esforço_Total_UST, onde:
Valor_OS = Valor total em reais da ordem de serviço.
Valor_UST = Corresponderá ao valor em reais da unidade de serviço técnico.
Esforço_Total_UST = Total de unidades de serviço técnico * fator de complexidade (POR GRUPO DE UST).
3.1.10.7. A CONTRATADA deverá alocar os recursos humanos necessários para atender cada tarefa considerando a complexidade, grupo de atividades, e a quantidade de UST previstas para execução dos serviços. No momento da prestação dos serviços os colaboradores devem ser associados na ferramenta à tarefa que executarão para registro de suas atividades, a fim de cumprir a Ordem de Serviço.
3.1.10.8. O quantitativo de Unidades de Serviço Técnico total previsto para execução durante a vigência do contrato representa meramente uma estimativa de utilização dos serviços, portanto não haverá nenhuma obrigação do MPPE na utilização do quantitativo total indicado. Somente serão devidas e pagas as Unidades de Serviço efetivamente prestadas.
3.1.10.9. O controle da quantidade de UST executadas será feito através de abertura e fechamento diário de requisição de serviço, na Solução de Gerenciamento de Demandas do MPPE, para cada tarefa demandada na Ordem de Serviço em execução e durante o período estabelecido na mesma, devendo ser discriminadas de forma resumida, na referida requisição de serviço, as ações e procedimentos executados em cada tarefa.
3.1.10.10.Mensalmente, a CONTRATADA fará o ajuste no Relatório Gerencial de Serviços, excluindo as Unidades de Serviço Técnico que extrapolarem a quantidade diária definida na Ordem de Serviço para cada tarefa.
0.0.00.00.Xx caso de falha ou indisponibilidade da Solução de Gerenciamento de Demandas da CONTRATANTE, a CONTRATADA deverá apresentar justificativa no Relatório Gerencial de Serviços acompanhada de declaração do gestor da unidade do MPPE onde o serviço for prestado para fins de evidência da execução do serviço.
3.1.10.11.1. Caso ocorra falha no registro da requisição de serviço por parte da CONTRATADA, será facultado ao Departamento de Soluções da CMTI, emitir declaração para fins de evidência da execução do serviço, cabendo à CONTRATADA apresentar justificativa no Relatório Gerencial de Serviços.
0.0.00.00.Xx final de cada mês, a medição será realizada de acordo com o somatório das UST consumidas na execução das tarefas resultantes das requisições de serviço abertas no mês, confrontadas com os Indicadores de Níveis Mínimos de Serviço (Anexo V do Termo de Referência).
3.1.10.13.A frequência de aferição e avaliação dos níveis de serviços e demais indicadores de desempenho será mensal, devendo a CONTRATADA elaborar relatório gerencial de serviços, até o 5º (quinto) dia útil do mês subsequente ao da prestação do serviço. Devem constar desse relatório, entre outras informações, os indicadores/metas de níveis de serviços acordados e alcançados, recomendações técnicas, administrativas e gerenciais para o próximo período e demais informações relevantes para a gestão contratual. O conteúdo detalhado e a forma do relatório gerencial serão definidos pelas partes.
3.1.10.14.O valor mensal total referente aos serviços prestados será a base sobre a qual serão aplicados os índices de atendimento aos Indicadores Qualidade do Serviço, bem como a base para o cálculo das glosas, quando for o caso.
3.1.10.15.Os indicadores de qualidade do serviço, incluindo Níveis Mínimos de Serviço, Indicadores de Níveis Serviço, Critérios Gerais de Nível de Serviço e Termos de Recebimento dos Produtos e Serviços serão detalhados no Termo de Referência desta contratação.
3.1.11. Dos valores de referência para os Serviços
3.1.11.1. Para definição dos valores cobrados de referência das Unidades de Serviço Técnico (UST), a CONTRATADA deverá levar em consideração os valores de HOMEM-HORA praticados no mercado como base de cálculo dos salários de seus colaboradores.
3.1.11.2. A proponente deverá informar em sua proposta de preços a Convenção Coletiva de Trabalho utilizada como referência para cálculo da composição de custos e formação de preços, bem como apresentar planilha de custos e formação de preços padrão com base na Instrução Normativa Nº5 do Ministério do Planejamento, Desenvolvimento e Gestão.
3.1.11.2.1. O salário-base apresentado na proposta de preços deverá ser considerado como o praticado durante toda a vigência do contrato, observando as alterações decorrentes das Convenções Coletivas de Trabalho.
3.1.11.3. Xxxx a proponente informe em sua proposta salário-base inferior ao previsto no item anterior, deverá apresentar em sua proposta as seguintes documentações adicionais:
3.1.11.3.1. Documentação demonstrando que já tenha contratado, ou tenha condições reais de contratar, pelos valores propostos, profissionais com qualificação igual ou superior à exigida nesta contratação.
3.1.11.3.2. Para fins da demonstração comprobatória exigida, poderá ser solicitada a apresentação de cópias de carteira de trabalho (CTPS), do contrato de trabalho ou instrumento similar, de profissionais que já prestem serviços equivalentes para a proponente mediante salário-base igual ou inferior ao informado no item de sua proposta, bem como estudo de mercado de órgão de pesquisa independente, demonstrando que o salário-base proposto está dentro da faixa salarial do mercado para profissionais com a mesma qualificação.
3.1.11.3.3. A documentação comprobatória apresentada, deverá estar acompanhada dos comprovantes de que os profissionais atendem aos requisitos de qualificação profissional constantes nesta contratação.
3.1.11.3.4. Visando à contratação de profissionais qualificados e adequados às necessidades da CONTRATANTE, a tabela de referência salarial abaixo descrita deve ser utilizada como referência mínima na remuneração praticada pela CONTRATADA. Desta forma, o salário dos profissionais da CONTRATADA não poderão ficar abaixo dos valores descritos a seguir:
TABELA DE REFERÊNCIA SALARIAL | |
PERFIL PROFISSIONAL | MEDIANA DOS VALORES SALARIAIS |
Gerente de Projetos | R$ 14.052,50 |
Scrum Master | R$ 14.052,50 |
Arquiteto de Soluções | R$ 14.052,50 |
Agile Coach | R$ 11.500,00 |
Analista de Sistemas | R$ 8.800,00 |
Analista de Requisitos | R$ 8.800,00 |
Analista Programador Sênior | R$ 11.500,00 |
Analista Programador Pleno | R$ 8.800,00 |
Analista Programador Júnior | R$ 5.192,51 |
Analista de Testes | R$ 5.192,51 |
Analista de UX | R$ 6.169,00 |
Projetista/Desenvolvedor BPM | R$ 8.800,00 |
Administrador de Dados | R$ 5.192,51 |
Analista de BI | R$ 7.739,50 |
3.1.11.3.4.1. Esta tabela de referência salarial foi estabelecida a partir de contratações públicas de postos de serviço, sites de vagas de emprego e tabelas de referência de salários praticados no mercado.
3.1.11.3.4.2. Dada a distribuição não uniforme dos valores obtidos, utilizou-se o critério “Mediana dos salários” ao invés da “média salarial”, para se obter valor adequado da amostra.
3.1.12. Das Ordens de Serviços
3.1.12.1. A execução das tarefas/atividades será sempre precedida da emissão de Ordem de Serviço (OS), contendo no mínimo: identificação do serviço, descrição do serviço, horário de prestação dos serviços, período para a execução do serviço, quantitativo de tarefas, complexidade e grupo de atividades para cada tarefa, quantitativo diário autorizado (mínimo e máximo) e total estimado de UST por tarefa, prazo para a execução do serviço, local da execução do serviço, especificações técnicas do serviço esperados, outras informações julgadas necessárias.
3.1.12.2. A Ordem de Serviço (OS) será emitida, assinada e autorizada pelos Fiscais do Contrato e pelo Gestor do Contrato.
3.1.12.3. Toda Ordem de Serviço deverá ser assinada pelo Preposto, representante da CONTRATADA perante o MPPE, declarando a ciência por parte da CONTRATADA dos serviços solicitados e das atividades descritas na “Ordem de Serviço – OS”, de acordo com as especificações estabelecidas pelo MPPE;
3.1.12.4. Os serviços deverão estar sempre de acordo com as especificações constantes nas Ordens de Serviços;
3.1.12.5. O controle da execução dos serviços se dará em 03 (três) momentos, a saber: no início da execução – quando a Ordem de Serviço é emitida pelo MPPE; durante a execução – com o acompanhamento e supervisão dos Fiscais do Contrato; e ao término da execução ou do mês de referência – com o fornecimento de “Relatório Gerencial de Serviços” pela CONTRATADA e atesto do mesmo pelos Fiscais do Contrato.
3.1.12.6. Todos os serviços prestados pela CONTRATADA deverão ser necessariamente documentados, registrados em ferramentas indicadas pelo MPPE, conforme procedimentos a serem definidos pelo MPPE.
3.1.12.7. Quando da alteração de uma Ordem de Serviço Padrão em execução, requisitando uma nova tarefa, a CONTRATADA terá até 30 (trinta) dias, a partir da data de alteração da ordem de serviço, para iniciar a execução da tarefa.
3.1.12.8. Caso o MPPE deseje reduzir a quantidade de tarefas solicitada através de Ordem de Serviço Padrão, esta deverá comunicar à CONTRATADA em um prazo de, no mínimo, 30 (trinta) dias de antecedência, devendo alterar a ordem de serviço em execução.
3.1.12.9. O modelo de prestação dos serviços é representado, em seu nível mais alto, pelo fluxo genérico do de gestão e execução de Ordens de Serviço de acordo com o seguinte padrão:
3.1.12.9.1. Fluxo de Construção de Novos Produtos
ETAPA: IDEAÇÃO | |||
PASSO | RESPONSÁVEL | AÇÃO | ENTREGÁVEL |
I01 | CONTRATANTE e CONTRATADA | Realizar trabalho de ideação | - Documento de Visão - Etapas da entrega Pode haver OS intermediária de entrega parcial do material |
I02 | CONTRATADA | Conhecer o documento de visão | - Backlog inicial do projeto |
ETAPA: ENTENDIMENTO INICIAL | |||
PASSO | RESPONSÁVEL | AÇÃO | ENTREGÁVEL |
E01 | CONTRATADA | Entendimento inicial | - Acordos realizados - Desenho da arquitetura - Modelo de dados inicial - Guia de identidade visual |
ETAPA: DESENVOLVIMENTO | |||
PASSO | RESPONSÁVEL | AÇÃO | LISTA DE ENTREGÁVEIS |
D01 | CONTRATADA | Escrever épico e histórias de usuário | - Mapa de Histórias de usuários (épico) - Histórias de usuário - Tarefas de trabalho - Regras de negócio - Regras de validação - Critérios de aceite - Protótipos - Modelo de dados - revisão - Desenho da arquitetura - revisão - Guia de identidade visual - revisão - Backlog do Produto |
D02 | CONTRATANTE | Aprovar o épico e histórias de usuário | - Aprovação das entregas de D01 |
D03 | CONTRATADA | Juntar orçamentos iniciais | - OS com orçamento |
D04 | CONTRATANTE | Aprovar orçamentos iniciais | - Aprovação dos orçamentos de D03 |
ETAPA: DESENVOLVIMENTO | |||
PASSO | RESPONSÁVEL | AÇÃO | LISTA DE ENTREGÁVEIS |
Se for OS de especificação – encaminhar para encerramento | |||
D05 | CONTRATADA | Realizar desenvolvimento | - Código-fonte - Scripts de criação e população de banco de dados - Script dos testes unitários - Roteiro de teste - Evidências de testes - Testes automatizados - Nota de liberação |
D06 | CONTRATANTE | Avaliar entrega | - Aprovação da entrega de D05 |
D07 | CONTRATANTE | Registrar erros da entrega D05 | - Se houver erros na entrega, registrar os mesmos, ligando-os às OS de origem |
D08 | CONTRATADA | Juntar orçamentos finais revisados | - OS com orçamento |
D09 | CONTRATANTE | Aprovar orçamentos finais | - Aprovação dos orçamentos de D08 |
D10 | CONTRATANTE | Encerrar OS e liberar pagamento | - Aprovação final |
ETAPA: VERSÃO | |||
PASSO | RESPONSÁVEL | AÇÃO | ENTREGÁVEL |
V01 | CONTRATANTE | Definir histórias da versão | - Nota de liberação |
V02 | CONTRATADA | Preparar versão e disponibilizar | - Versão funcional no ambiente designado |
3.1.12.9.2. Fluxo de Sustentação
ETAPA: ENTENDIMENTO INICIAL | |||
PASSO | RESPONSÁVEL | AÇÃO | ENTREGÁVEL |
E01 | CONTRATADA | Entendimento inicial | - Acordos realizados - Desenho da arquitetura - Modelo de dados inicial - Guia de identidade visual |
ETAPA: SUSTENTAÇÃO | |||
PASSO | RESPONSÁVEL | AÇÃO | ENTREGÁVEL |
S01 | CONTRATADA | Detalhar item de sustentação | - Histórias de usuário - Tarefas de trabalho - Regras de negócio - Regras de validação - Critérios de aceite - Protótipos - Modelo de dados - revisão - Desenho da arquitetura - revisão - Guia de identidade visual - revisão - Backlog do Produto |
S02 | CONTRATANTE | Aprovar item de sustentação | - Aprovação das entregas de S01 |
S03 | CONTRATADA | Realizar sustentação | - Código-fonte - Scripts de criação e população de banco de dados - Script dos testes unitários - Roteiro de teste - Evidências de testes - Testes automatizados - Nota de liberação |
S04 | CONTRATANTE | Avaliar entrega | - Aprovação da entrega de S03 |
S05 | CONTRATANTE | Registrar erros da entrega S03 | - Se houver erros na entrega, registrar os mesmos, ligando-os às OS de origem |
S06 | CONTRATADA | Juntar orçamentos finais | - OS com orçamento |
S07 | CONTRATANTE | Aprovar orçamentos finais | - Aprovação dos orçamentos de S06 |
S08 | CONTRATANTE | Encerrar OS e liberar pagamento | - Aprovação final |
ETAPA: VERSÃO | |||
PASSO | RESPONSÁVEL | AÇÃO | ENTREGÁVEL |
V01 | CONTRATANTE | Definir histórias da versão | - Nota de liberação |
V02 | CONTRATADA | Preparar versão e disponibilizar | - Versão funcional no ambiente designado |
3.1.13. Do local e horário da prestação dos Serviços
3.1.13.1. Os serviços poderão ser prestados nas dependências da CONTRATANTE em função das necessidades específicas de cada ordem de serviço.
3.1.13.2. O MPPE poderá estabelecer, em comum acordo entre as partes, a execução da prestação dos serviços remotamente na modalidade de teletrabalho, de forma parcial ou integral. Nesse caso, o MPPE comunicará a CONTRATADA o período de início e/ou fim do regime de teletrabalho com antecedência mínima 05 (cinco) dias úteis, com a emissão de emissão de Ordem de Serviço extraordinária.
3.1.13.3. O acesso remoto ao ambiente tecnológico da CONTRATANTE deverá ser feito por meio do uso da infraestrutura de VPN – Virtual Private Network, da CONTRATANTE.
3.1.13.4. Para cada um dos projetos em andamento a CONTRATANTE deverá ser informada sobre os profissionais envolvidos e a forma de trabalho acordada – presencial na CONTRATANTE, presencial na CONTRATADA ou remota.
3.1.13.5. Em caso de trabalho realizado nas dependências da CONTRATANTE, o MPPE disponibilizará espaço físico, mobiliário e computadores a serem utilizados pela equipe da CONTRATADA que prestar os serviços nas dependências da Instituição. Será de responsabilidade da CONTRATADA os equipamentos e softwares utilizados pela equipe técnica que executar os serviços de forma remota.
3.1.13.6. Os serviços deverão ser prestados nas dependências do MPPE, durante o horário estabelecido em dias de expediente ministerial, das 08:00 às 18:00.
3.1.13.7. A seu critério, o MPPE poderá especificar intervalo (“janela”) de horário para prestação do serviço mais restrito que o seu horário normal de funcionamento para determinados projetos ou sistemas, desde que mantenha, ao menos, 8:00 (oito horas) contínuos no novo horário.
3.1.13.8. Não haverá expediente forense nos feriados nacionais, estaduais e municipais, durante o recesso natalino compreendido entre os dias 20 de dezembro e 02 de janeiro, bem como nas datas determinadas pela Procuradoria Geral de Justiça, formalizadas através de portaria publicada no Diário Oficial Eletrônico, devendo os trabalhos da CONTRATADA serem realizados fora das dependências da CONTRATANTE.
3.1.13.9. O MPPE poderá demandar a execução de serviços extraordinários em horários diferentes do horário padrão através da emissão de Ordem de Serviço extraordinária, contendo o detalhamento necessário, incluindo o horário para prestação dos serviços.
3.1.13.9.1. Os serviços extraordinários compreendem atividades necessárias ao atendimento das demandas geradas através dos Processos de Gerenciamento de Mudanças e Liberação e Gerenciamento de Incidentes que não podem ser realizados durante o horário normal de expediente.
3.1.13.9.2. As Ordens de Serviço extraordinárias serão explicitamente autorizadas pelo MPPE e emitidas com no mínimo um dia útil de antecedência.
3.1.13.9.3. As Ordens de Serviço extraordinárias serão explicitamente autorizadas pelo MPPE e emitidas com no mínimo 5 (cinto) dias úteis de antecedência.
3.1.13.10.Caso ocorra a interrupção dos serviços por períodos inferiores a duas horas no decorrer da execução diária de uma tarefa demandada através de Ordem de Serviço Padrão, será facultado ao gestor do contrato autorizar a CONTRATADA complementar a execução das Unidades de Serviço, prevista para execução no dia, em horário diverso do horário padrão. Nesse caso, as Unidades de Serviço devem ser executadas no mesmo dia em que ocorreu a interrupção, portanto não haverá emissão de nova Ordem de Serviço.
3.1.13.11.A CONTRATADA poderá solicitar a emissão de Ordem de Serviço Complementar, em horário diferente do horário padrão, visando complementar o quantitativo mensal previsto para execução dos serviços de sustentação/desenvolvimento, considerando fatores supervenientes que impediram a execução completa da tarefa durante o expediente forense. A Ordem de Serviço Complementar deverá ser previamente autorizada pelo MPPE.
3.1.14. Do Recebimento do Serviço
3.1.14.1. A frequência de aferição e avaliação dos níveis de serviços será mensal, devendo, a CONTRATADA, elaborar Relatório Gerencial de Serviços, apresentando-o ao MPPE, até o 5º. (quinto) dia útil do mês subsequente ao da prestação dos serviços, momento no qual o MPPE fará o recebimento provisório.
3.1.14.2. Devem constar desse relatório, dentre outras informações, os indicadores/metas de níveis de serviços definidos e alcançados, recomendações técnicas, administrativas e gerenciais para o próximo período e demais informações relevantes para a gestão contratual.
3.1.14.3. Contagem detalhada dos serviços prestados.
3.1.14.3.1. Ao final de execução da OS, a Contratada deverá entregar a contagem detalhada de UST consumidas acompanhada de memória de cálculo que discrimine cada um dos elementos que compuseram a contagem.
3.1.14.3.2. A memória de cálculo deve conter minimamente as seguintes informações: 3.1.14.3.2.1. Tarefas, conforme definido no catálogo.
3.1.14.3.2.2. Condições e índices de ajuste aplicáveis ao caso em questão, à demanda solicitada ou ao produto gerado.
3.1.14.3.2.3. Total de UST consumida por item de catálogo obtida a partir da relação “quantitativo unitário de UST definido no catálogo para a variação X (multiplicado por) índices de ajuste aplicáveis X (multiplicado por) quantidade de unidades de medida necessária”.
3.1.14.3.2.4. Total de UST da OS.
3.1.14.3.3. Para as tarefas canceladas pela CONTRATANTE cuja execução já tenha sido iniciada na data de cancelamento, deverá ser contabilizada apenas a quantidade de unidades de medida efetivamente realizadas. de unidades de medida contabilizada na contagem detalhada deverá ser igual a 1 (um).
3.1.14.3.4. A critério da CONTRATANTE, as informações apresentadas na memória de cálculo poderão ser destacadas por produtos entregues ou por demandas atendidas.
3.1.14.3.5. A CONTRATANTE avaliará a contagem detalhada de UST, aprovando-a ou solicitando à CONTRATADA as correções em caso de divergências.
3.1.14.3.6. Aprovada a contagem detalhada, a OS deverá ser atualizada para refletir o quantitativo total de UST. A memória de cálculo deverá ser anexada à OS.
3.1.14.3.7. A aprovação da contagem detalhada é condição indispensável para o recebimento definitivo da OS.
3.1.14.4. O Relatório Gerencial de Serviços para a apuração do cumprimento dos Níveis Mínimos de Serviço na prestação de serviços será gerado a partir dos dados fornecidos por ferramenta indicada pelo MPPE.
3.1.14.5. Os indicadores de desempenho estabelecidos para cada serviço, deverão ser monitorados e servirão de base para a avaliação mensal da Contratada, nos “Relatórios de Gerenciais dos Serviços” do Contrato, onde será possível verificar a efetividade do atendimento e permitir a depuração do processo.
3.1.14.6. Os Níveis Mínimos de Serviços devem ser considerados e entendidos pela CONTRATADA como um compromisso de qualidade, que assumirá, junto ao MPPE.
3.1.14.7. A análise dos resultados destas avaliações, pelo MPPE, resultará em advertências, penalizações e redução na fatura, caso a CONTRATADA não cumpra com os seus compromissos, de qualidade e desempenho.
3.1.14.8. Para aceite do recebimento e posterior encaminhamento ao pagamento, deverão ser apresentadas as Ordem de Serviços emitidas e assinadas e demais documentos técnicos pertinentes e comprobatórios de execução do serviço.
3.1.14.9. Após a apuração dos níveis de serviços exigidos e de cálculo do pagamento devido, o MPPE realizará o recebimento definitivo dos serviços.
3.1.15. Requisitos de Segurança da Informação
3.1.15.1. A CONTRATADA deverá submeter-se à Política de Segurança de Informação definida pelo MPPE em seus regulamentos, bem como executar os serviços com base nas boas práticas de segurança da informação e aos normativos da Lei Geral de Proteção a Dados (LGPD) da CONTRATANTE.
3.1.15.2. O MPPE comunicará à CONTRATADA as alterações introduzidas na Política de Segurança da Informação, bem como a edição dos regulamentos complementares, e definirá, de comum acordo com a CONTRATADA, o prazo necessário para a implementação dessas alterações.
3.1.15.3. As atividades previstas neste Termo de Referência, executadas através de comunicação remota, deverão utilizar conexão segura entre a rede da Contratada e a do MPPE.
3.1.15.4. A CONTRATADA será responsável pelos custos de comunicação remota entre sua sede e seus colaboradores em regime de teletrabalho e as instalações (datacenter) do MPPE.
3.1.15.5. O acesso remoto aos ambientes do MPPE pela CONTRATADA se dará apenas por meio de funcionários autorizados com respectivo usuário e senha individual.
3.1.15.6. A CONTRATADA deverá enviar, sempre que solicitado pelo MPPE, uma relação contendo todos os usuários nominados que possuam acesso aos ambientes do MPPE.
3.1.15.7. A CONTRATADA poderá ter acesso autorizado aos ambientes de teste, homologação e treinamento para todos os seus funcionários cadastrados.
3.1.15.8. O acesso ao ambiente de produção do MPPE deverá seguir os seguintes procedimentos:
3.1.15.8.1. Para cada necessidade de acesso ao ambiente de produção do MPPE, visando atualização de programas, transferência de arquivos e outras atividades relacionadas aos serviços, a CONTRATADA deverá encaminhar pedido formal ao MPPE, contendo a justificativa do pedido, o período (com a data e hora de início e a data e hora de término) em que se dará tal acesso e o detalhamento de todos os recursos que serão acessados incluindo bancos de dados, tabelas, equipamentos.
3.1.15.8.2. O MPPE analisará o pedido, deferindo ou não a solicitação. Caso deferido, o MPPE emitirá autorização para acesso durante o período solicitado.
3.1.15.8.3. A autorização formal do MPPE permitirá o uso de comunicação remota por meio seguro para acesso ao seu ambiente de produção.
3.1.15.8.4. A CONTRATADA terá acesso remoto ao ambiente de infraestrutura do MPPE, somente por meio de usuário específico e com nível de acesso condizente com a justificativa apresentada pela CONTRATADA.
3.1.15.8.5. A CONTRATADA responderá por quaisquer acessos de seus funcionários ao ambiente de produção que não tenham sido expressamente autorizados pelo MPPE, assim como, desde que devidamente comprovados, por quaisquer prejuízos que seu acesso ao ambiente de produção do MPPE vier a causar no funcionamento da Solução, inclusive a perda, total ou parcial, bem como corrupção dos registros do banco de dados do MPPE.
3.1.15.8.5.1. Constatado o prejuízo à Solução disponibilizado ao MPPE, a CONTRATADA será notificada para corrigir os problemas causados em decorrência do seu acesso ao ambiente de produção do MPPE, que serão tratados, quando aplicável, através de abertura de chamados.
3.1.16. Implantação da Operação dos Serviços, Prazos e Condições
3.1.16.1. Deverá ser realizada até o 5º (quinto) dia útil após a assinatura do Contrato, na Sede do MPPE, uma reunião de alinhamento, conforme agendamento efetuado pelo Gestor do Contrato, com o objetivo de:
3.1.16.1.1. Indicar formalmente um preposto apto a representá-la junto ao MPPE, que deverá responder pela fiel execução do Contrato.
3.1.16.1.2. Nivelar os entendimentos acerca das condições estabelecidas no Contrato, no Edital e em seus Anexos, esclarecendo, caso necessário, possíveis dúvidas acerca do objeto.
3.1.16.1.3. Definir em conjunto com o MPPE o modelo do Relatório Gerencial de Serviços, o qual deverá ser aprovado pelo Gestor do Contrato.
3.1.16.1.4. Indicar a equipe técnica que receberá o repasse de conhecimentos realizado pelo MPPE que deverá ocorrer em até 10 (dez) dias úteis após a assinatura do contrato.
3.1.16.1.5. Entregar todos os documentos assinados e exigidos no Termo de Referência. 3.1.16.1.6. Emissão da primeira Ordem de Serviço Padrão pelo MPPE.
3.1.16.1.7. Planejamento detalhado do plano de implantação da operação dos serviços da CONTRATADA junto à CONTRATANTE.
3.1.16.2. O início da prestação dos serviços deverá ocorrer em até 10 (dez) dias corridos após a emissão da primeira Ordem de Serviço Padrão.
3.1.16.3. Ao final do repasse a CONTRATADA emitirá uma Declaração de Repasse de Conhecimentos, anexando a comprovação de execução das 40 horas de atividades no ambiente do MPPE através de relatório específico emitido.
3.1.16.4. A operação da Fábrica de Software deverá ocorrer em 3 fases:
FASE | DESCRIÇÃO | PERÍODO PREVISTO |
Implantação e Transição | Fase de implantação da operação dos serviços da CONTRATANTE. Prevê-se o consumo de cerca de 10% do escopo de serviços previsto nesta fase. | Mês 01 a Mês 03 |
Operação Estabelecida | Fase de plena operação dos serviços contratados. Prevê-se o consumo de 80% do escopo de serviços previsto nesta fase. | Mês 03 a Mês 12 |
Descomissionamento (eventual) | Fase eventual de desmobilização dos serviços contratados, em caso de encerramento ou não renovação de contrato de prestação de serviços. Prevê-se o consumo de 10% do escopo de serviços previsto nesta fase. Esta fase terá como objetivo o repasse de conhecimento, artefatos e informações pertinentes quanto à prestação de serviços pela CONTRATADA. | Mês 11 a Mês 12 |
3.1.16.5. Durante a execução do contrato de prestação de serviços, a CONTRATANTE deverá designar gerente comercial ou gerente de projetos com dedicação exclusiva para atuar no relacionamento junto à CONTRATADA na gestão das demandas e atividades por parte da CONTRATANTE.
3.1.16.6. A Fase de Implantação e Transição prevê a preparação da CONTRATANTE para recepção dos serviços prestados.
3.1.16.6.1. O MPPE promoverá um repasse de conhecimentos para a CONTRATADA abordando a Metodologia de Desenvolvimento de Software (MDS), os padrões de desenvolvimento e seus relacionamentos, ambiente, metodologias, fluxos de trabalho, segurança da informação, ferramentas para registro e acompanhamento das demandas e sistemas corporativos do MPPE.
3.1.16.6.2. A CONTRATADA deverá replicar o repasse de conhecimentos para todos os seus colaboradores que executarão os serviços de sustentação e desenvolvimento de sistemas. O repasse de conhecimentos não será necessário para os colaboradores da CONTRATADA que executarão os serviços eventuais sob demanda.
3.1.16.6.3. O repasse terá duração de até 40 horas (cinco dias úteis) e será executado na modalidade "hands- on", ou seja, utilizando os recursos, ferramentas e processos em atividades práticas de execução dos serviços no ambiente do MPPE para garantir a adequação do colaborador ao ambiente da CONTRATANTE. O MPPE encaminhará à CONTRATADA as demandas que serão executadas pelos colaboradores durante o repasse de conhecimentos, sem custos ao MPPE.
3.1.16.6.4. Os primeiros 90 dias após o início da execução dos serviços serão considerados como período de estabilização e de ajustes específicos, durante o qual os níveis de serviços exigidos poderão ser flexibilizados entre as partes.
3.1.16.6.5. A Fase de Implantação e Transição deverá contemplar todos os esforços necessários à realização das atividades, incluindo:
3.1.16.6.5.1. Definição do modelo de gestão do serviço, incluindo previsões de utilização de capacidade, processo de solicitação de serviços e prestação de contas.
3.1.16.6.5.2. Preparação de Infraestrutura (ambientes e plataformas tecnológicas, ferramentas e infraestruturas).
3.1.16.6.5.3. Recursos humanos (definição dos gestores do serviço e mobilização de equipes técnicas). 3.1.16.6.5.4. Transferência de conhecimento (inventário de aplicações, portfólio de projetos e serviços
procedimentos e demais informações pertinentes).
3.1.16.6.5.5. Adaptação de Metodologia (estabelecimento da metodologia de trabalho junto à CONTRATANTE, incluindo processo de software, procedimentos e fluxos de trabalho).
3.1.16.6.5.6. Definição do processo de operação da fábrica de software.
3.1.16.6.5.7. Indicadores e Métricas de Serviço (revisão dos indicadores de serviços e estrutura do modelo de medição e monitoramento).
3.1.16.6.5.8. Estabelecimento das ferramentas de Gestão de demandas e gestão de projetos.
3.1.16.6.5.9. Definição do Plano de Manutenção (demandas de manutenção), dos Squads (times) a serem mobilizados, do Plano Anual de Serviço (situação de partida, projetos previstos e evolução programada da carteira de projetos) e da volumetria de consumo de UST previsto. Este item busca trazer previsibilidade e linearidade na execução contratual.
3.1.16.6.5.10. Definição dos Comitês de Governança e Fiscalização do Serviço.
3.1.16.6.6. A CONTRATANTE em hipótese alguma garantirá à CONTRATADA um quantitativo mínimo mensal de requisições de serviços, observando estritamente o volume da demanda apresentada. Prevê- se a seguinte estimativa de consumo:
ESTIMATIVA DE CONSUMO | ||||
(A) PERFIS PARA EXECUÇÃO DE TAREFAS | (B) Qtd de Profissionais | (C) Qtd UST Mensal Padrão | (D) Qtd UST Mensal Por Perfil (B*C) | (E) Previsão (12 Meses) (D*12) |
Scrum Master | 1 | 88 | 88 | 1.056 |
Desenvolvedor | 6 | 176 | 1.056 | 12.672 |
Analista de Requisitos/Product Owner | 2 | 176 | 352 | 4.224 |
Analista de Testes | 2 | 176 | 352 | 4.224 |
Projetista/Desenvolvedor BPM | 2 | 176 | 352 | 4.224 |
Analista de UX | 1 | 88 | 88 | 1.056 |
Arquiteto de Soluções | 1 | 176 | 176 | 2.112 |
Especialista em Paineis de Informação (BI) | 2 | 176 | 352 | 4.224 |
TOTAL DE UST | 33.792 | |||
60% DE UST COM COMPLEXIDADE PADRÃO (60% de 33.792) | 20.275 | |||
40% DE UST COM COMPLEXIDADE ALTA (40% de 33.792) | 27.034 | |||
TOTAL ESTIMADO DE UST | 47.309 |
3.2. Ritos do Processo de Construção e Sustentação de Soluções
3.2.1. Processo de Construção de Soluções
3.2.1.1. Para atender ao objeto do serviço, o prestador de serviços contratado deverá conhecer e seguir a metodologia proposta, observando as premissas da etapa correspondente ao serviço solicitado. A figura abaixo apresenta o modelo de trabalho a ser adotado:
3.2.1.2. Para cada projeto iniciado, seja nova solução ou sustentação, a CONTRATANTE designará um gerente de produtos, que atuará como Product Owner ou Gerente de Produtos (PO) na metodologia ágil. O gerente de produtos fará a iteração entre a área de negócios e a CONTRATADA, podendo, a seu critério, envolver os profissionais da contratada em quaisquer fases do trabalho.
3.2.1.3. A metodologia utilizada na prestação do serviço está fundamentada nos métodos ágeis, de acordo com as melhores práticas de mercado, e adequada às necessidades e especificidades da CONTRATANTE. Esta metodologia deve ser seguida pela CONTRATADA, em conformidade com as diretrizes determinadas pela CONTRATANTE. A metodologia de desenvolvimento almejada, fundamentada nos métodos ágeis, propõe minimamente as seguintes fases: Ideação (Design Sprint e Lean Inception); Desenvolvimento da Solução com base em Sprints (iterações) com duração entre 2 (duas) a 4 (quatro) semanas, contemplando: Planejamento da Sprint; Construção da solução e testes; Revisão; Retrospectiva e lições aprendidas.
3.2.2. Paradigma de Construção de Soluções
3.2.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 e suas diversas ferramentas ou similares, são levantadas as necessidades do cliente, gerando a primeira versão da Visão do produto.
3.2.2.2. A partir da criação da visão, faz-se uma imersão nas necessidades, mapeia-se a jornada do usuário, as macro-histórias e define-se o MVP (Mínimo Produto Viável), bem como as fases de entrega do produto, concluindo-se a fase de alinhamento (Lean Inception) do produto.
3.2.2.3. Estas etapas deverão ser realizadas pela CONTRATANTE, que pode solicitar auxílio da CONTRATADA para sua execução, respeitando as tarefas existentes no Catálogo de Serviços.
3.2.2.4. A partir do resultado da visão, inicia-se o fluxo do Scrum, com todos os seus eventos e artefatos. As Sprints (iterações) terão duração entre 2 (duas) a 4 (quatro) semanas, prazo a ser definido na fase de Planejamento. A duração definida para a Sprint permanecerá a mesma até o fim do projeto, salvo casos excepcionais pactuados entre a CONTRATANTE e a CONTRATADA e devidamente apresentados no termo de aceite da Sprint.
3.2.2.5. O Gerente de Produtos (PO) definirá, a cada ciclo, 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 tarefas de trabalho (se a demanda for para sustentação de sistemas e puderem ser planejadas) que deverão ser entregues ao final daquela Sprint.
3.2.2.6. As tarefas de trabalho de atendimento rápido (demandas de manutenção que não podem esperar para entrar no fluxo de uma Sprint) deverão ser acordadas entre a CONTRATANTE e a CONTRATADA, de forma a garantir os planejamentos executados em cada Sprint.
3.2.2.7. Caso a CONTRATADA finalize as histórias ou itens planejados antes do prazo definido para a Sprint corrente, poderá negociar com o Gerente de Produtos (PO) e iniciar a execução de outras histórias/itens que já estejam preparadas e priorizadas no backlog.
3.2.3. Paradigma de Sustentação de Soluções
3.2.3.1. As atividades de sustentação, sejam elas de natureza evolutiva ou corretiva deverão ser planejadas e seguir o mesmo processo de trabalho adotado no desenvolvimento ágil. Assim, essas atividades devem ser cadastradas como itens de sustentação no backlog do produto e planejadas em iterações (Sprints).
3.2.3.2. Ficará a critério da CONTRATANTE definir quais ritos e atividades serão executadas, levando-se em consideração a natureza do contexto da demanda. Por exemplo: uma Sprint planejada apenas com demandas de correção poderá exigir ou não o rito de refinamento.
3.2.3.3. Ciente da dificuldade de se obter proficiência e eficiência em códigos-fonte escritos por terceiros, a CONTRATANTE poderá demandar o estudo e a avaliação do código-fonte pela CONTRATADA, com o intuito de promover a qualidade e a agilidade das manutenções nos sistemas da mesma e formar um colaborador-estudado, com a devida remuneração pela execução desta atividade.
3.2.3.4. Este estudo do código-fonte poderá gerar como entregável, um detalhamento completo por escrito contemplando as funcionalidades e sua arquitetura tecnológica, incluindo dados técnicos e de regras de negócio.
3.2.3.5. Os conteúdos do documento escrito e da apresentação serão definidos pela CONTRATANTE no momento do início da prestação do serviço, em função de cada sistema a ser sustentado.
3.2.3.6. O estudo poderá ser contratado para toda a equipe da CONTRATADA alocada para sustentação na CONTRATANTE, de acordo com as responsabilidades sobre sistemas atribuídas a cada colaborador.
3.2.3.7. Haja vista o investimento feito pela CONTRATANTE com o estudo de código-fonte, a CONTRATADA terá maior condições de prover, com qualidade, a manutenção dos sistemas. No entanto, tal investimento também traz responsabilidades. A CONTRATADA deverá fazer uma gestão do conhecimento efetiva, de maneira que afastamentos e desligamentos de colaboradores-estudados não signifiquem perda do conhecimento.
3.2.3.8. Caso um dos colaboradores-estudados da CONTRATADA deixe de fazer parte da equipe de colaboradores que atendem à CONTRATANTE, a CONTRATADA fica obrigada a realizar o repasse do estudo do código-fonte para o colaborador que for substituí-lo, sem ônus para a CONTRATANTE.
3.2.4. Visão geral da Homologação das Entregas
3.2.4.1. A CONTRATADA deverá entregar as funcionalidades desenvolvidas na Sprint no ambiente de quality assurance (homologação da CONTRATANTE.
3.2.4.2. As Sprints serão homologadas pelo gerente do produto (PO) da CONTRATANTE, podendo contar com o apoio dos analistas do projeto, após a entrega pela CONTRATADA.
3.2.4.3. O aceite das entregas será definido pelos critérios estabelecidos nas histórias de usuários ou tarefas de trabalho e conforme qualidade de código.
3.2.4.4. A CONTRATANTE terá prazo de até 5 (cinco) dias úteis para confirmar ou alterar o aceite da Sprint.
3.2.4.5. Caso sejam encontrados defeitos, a CONTRATANTE deverá reportá-los dentro do prazo de avaliação da Sprint para sua imediata correção. A cada nova entrega reabre-se o prazo de até 5 (cinco) dias úteis de avaliação.
3.2.4.6. A entrega somente será homologada e aprovada quando todos os seus defeitos reportados pela CONTRATANTE forem sanados pela CONTRATADA.
3.2.4.7. Enquanto estiver vigente o contrato, ainda que já tenha sido feito o aceite inicial da entrega e a confirmação do aceite após os testes realizados no ambiente de homologação, a CONTRATADA se responsabilizará por todas e quaisquer correções, provenientes de defeitos de construção encontrados, assegurando assim o perfeito funcionamento do(s) software(s) desenvolvido(s).
3.2.4.8. As correções de defeitos devem ser feitas sem custos adicionais para a CONTRATANTE.
3.2.5. O paradigma de desenvolvimento de software, seja novo produto ou sustentação, deverá ser composto pelos eventos listados na tabela abaixo:
EVENTO | RESPONSÁVEL | DESCRIÇÃO | ENTREGÁVEL | POSSÍVEIS PAPEIS ENVOLVIDOS |
Reunião de Kick-off do projeto | CONTRATANTE e CONTRATADA | Reunião de alinhamento de expectativas e abertura do projeto. | Formalização da abertura do projeto | CONTRATANTE: - Gerente do projeto |
A reunião de kick-off do projeto poderá ocorrer antes ou após a etapa de ideação | CONTRATADA: - Analista de requisitos | |||
Ideação | CONTRATANTE e CONTRATADA (caso necessário) | 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 documento de visão do produto com as etapas de entrega | Documento de visão do produto com as etapas de entrega | CONTRATANTE: - Gerente do projeto - Responsáveis da área de negócios CONTRATADA (se necessário): - Analista de requisitos - Arquiteto de soluções - Analista de UX/UI |
Alinhamento Inicial | CONTRATANTE e CONTRATADA | Comunicado sobre as etapas de execução que serão contratadas e apresentação do documento de visão oriundo da ideação | Acordos realizados | CONTRATANTE: - Gerente do projeto - Analistas do projeto CONTRATADA: - Analista de requisitos - Arquiteto de soluções - Analista de dados - Analista de UX/UI |
Workshop Formação do Time | CONTRATANTE e CONTRATADA | Etapa que tem como objetivo executar dinâmicas que visam a integração, alinhamento e definição de macro acordos para andamento das rotinas e atividades. Deve ser refeito toda vez que houver substituição dos membros da equipe, seja por parte da CONTRATANTE ou da CONTRATADA | Acordos realizados | CONTRATANTE: - Gerente do projeto - Analistas do projeto CONTRATADA: - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Analista de UX/UI - Desenvolvedores |
Criação do ambiente | CONTRATANTE e CONTRATADA | Etapa pós alinhamento inicial em que o time prepara o mínimo necessário para iniciar a construção do produto. | - Desenho da arquitetura - Modelo de dados inicial - Guia de identidade visual | CONTRATANTE: - Gerente do projeto - Analistas do projeto |
Nesse momento, o time configura os ambientes, refina o modelo inicial 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 | CONTRATADA: - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Analista de UX/UI - Desenvolvedores | |||
Refinamento das Sprints seguintes (Sprint x +1) | CONTRATANTE e CONTRATADA | Etapa de refinamento e preparação dos itens de Backlog do produto selecionados pelo PO e que podem ser executados nas próximas Sprints. Enquanto uma Sprint está em execução, esta etapa ocorre em paralelo para preparar os itens de Backlog para a próxima Sprint (x +1). | - Mapa de Histórias de usuários (épico) - Histórias de usuário - Tarefas de trabalho - Regras de negócio - Regras de validação - Critérios de aceite - Protótipos - Modelo de dados - Desenho da arquitetura - Guia de identidade visual - Backlog do Produto | CONTRATANTE: - Gerente do projeto - Analistas do projeto - Responsáveis da área de negócios CONTRATADA: - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Analista de UX/UI |
Refinamento da Sprint atual | CONTRATANTE (participação eventual) e CONTRATADA | Evento em que o analista de requisitos apresenta para todo o time as histórias de usuário ou tarefas de trabalho que deseja para a Sprint e os critérios de aceite. O UX/UI 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 | - Mapa de Histórias de usuários (épico) - Histórias de usuário - Tarefas de trabalho - Regras de negócio - Regras de validação - Critérios de aceite - Protótipos | CONTRATANTE (se necessário): - Gerente do projeto CONTRATADA: - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Analista de UX/UI - Desenvolvedores |
Planejamento da Sprint | CONTRATANTE (participação eventual) e CONTRATADA | Evento onde é feito o planejamento de uma Sprint para alinhamento do time de desenvolvimento sobre o que e como será executado o trabalho dentro da Sprint | - Backlog da Sprint - Definição da Sprint | CONTRATANTE (se necessário): - Gerente do projeto CONTRATADA: - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Analista de UX/UI - Desenvolvedores |
Construção da Sprint | CONTRATADA | 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 - Scripts de criação e população de banco de dados - Script dos testes unitários - Roteiro de teste - Evidências de testes - Testes automatizados - Nota de liberação | CONTRATADA: - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Desenvolvedores |
Reunião Diária | CONTRATANTE (participação eventual) e | Evento diário de curta duração para verificar o andamento do trabalho de construção, onde o | - Burndown (atualizado) - Gestão à vista atualizado | CONTRATANTE (se necessário): - Gerente do projeto |
CONTRATADA | 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 | CONTRATADA: - Analista de UX/UI - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Desenvolvedores | ||
Revisão da Sprint | CONTRATANTE e CONTRATADA | Evento em que o time apresenta o que foi alcançado durante a Sprint, validando todo o trabalho com o Gerente do projeto e gerando o aceite | - Apresentação dos resultados - Termo de aceite da Sprint - Termo de encerramento da OS com a quantidade de UST realizadas | CONTRATANTE: - Gerente do projeto - Analistas do projeto CONTRATADA: - Analista de UX/UI - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Desenvolvedores |
Retrospectiva da Sprint | CONTRATANTE e CONTRATADA | Evento que ocorre ao final de uma Sprint com o objetivo de identificar o que funcionou bem, o que pode ser melhorado e quais ações serão tomadas para melhorar as próximas Sprints | - Plano de ações | CONTRATANTE: - Gerente do projeto - Analistas do projeto CONTRATADA: - Analista de UX/UI - Analista de requisitos - Analista de dados - Analista de testes - Arquiteto de soluções - Desenvolvedores |
Liberação de versão | CONTRATANTE e CONTRATADA | Liberação do incremento do produto no ambiente definido | - Nota de liberação | CONTRATANTE: - Gerente do projeto - Analistas do projeto CONTRATADA: -- Analista de requisitos - Analista de dados - Arquiteto de soluções |
3.2.6. Times de Construção e Sustentação de Soluções
3.2.6.1. A CONTRATADA deverá formar times para a realização das atividades de desenvolvimento e sustentação de sistemas, seguindo orientações da metodologia ágil proposta e sempre com a aprovação final da CONTRATANTE.
3.2.6.2. A critério da CONTRATANTE, este modelo de gestão poderá ser ajustado ao longo do tempo.
3.2.6.3. Cada time deve ser organizado conforme o modelo de time multidisciplinar autogerenciável, que deve ser contemplado por um ou mais perfis elencados abaixo:
PARTE INTERESSADA | PERFIL PROFISSIONAL ESTABELECIDO |
CONTRATANTE | Gerente de produto (PO) |
Analistas do projeto (se necessário) | |
CONTRATADA | Líder técnico ou responsável da organização |
Analista UX/UI | |
Analista de requisitos | |
Analista de testes | |
Arquiteto de soluções | |
Analista de dados | |
Desenvolvedor (diversos perfis) | |
Scrum master (SM) |
3.2.6.4. O time será formado no início da execução de cada projeto, com a atribuição de todos os papéis. No caso de substituição de profissional do time essa informação deverá ser repassada pela CONTRATADA à CONTRATANTE.
3.2.6.5. A determinação dos papeis envolvidos em cada projeto poderá variar em função da demanda, de acordo com a aprovação da CONTRATANTE.
3.2.6.6. Nas demandas de sustentação e manutenção de software, o time poderá conter apenas os perfis que a CONTRATANTE julgar necessários para o atendimento da demanda em questão.
3.2.6.7. Os papéis de Scrum master, Arquiteto de soluções, Analista UX/UI e Analista de dados poderão ser alocados, para desempenharem o mesmo papel, mediante anuência da CONTRATANTE, em mais de um time.
3.2.6.8. Caso a equipe alocada em determinado time fique ociosa, a CONTRATADA, com a anuência da CONTRATANTE, poderá realocá-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.
3.2.6.9. O estabelecimento da composição dos times não obriga a CONTRATADA a execução de nenhum quantitativo estabelecido na contratação.
3.2.6.10. A gestão sobre o desempenho e atividades das equipes da CONTRATADA é de responsabilidade da CONTRATADA.
3.2.6.11. A qualquer tempo, a CONTRATANTE poderá exigir da CONTRATADA a demonstração da relação de pessoal vinculado à operação da CONTRATANTE, solicitando-se também a demonstração dos pagamentos realizados relacionados a salários, encargos e benefícios.
4. MODELO DE PRESTAÇÃO DE SERVIÇO / FORNECIMENTO DE BENS
4.1. Justificativa para Parcelamento do Objeto
4.1.1. Os serviços de Sustentação e Desenvolvimento de Sistemas compreendem as tarefas necessárias às manutenções (adaptativa, evolutiva e corretiva) dos sistemas em produção no MPPE, bem como o desenvolvimento de novos sistemas demandados pelas diversas áreas judiciais e administrativas do MPPE e que guardam forte interdependência entre si. Este serviço deve ser prestado por equipes dotadas de competências técnicas especializadas, e que devem buscar, de forma conjunta e compartilhada, o alcance dos seguintes objetivos:
4.1.1.1. Solucionar, de forma precisa e conforme prazos estabelecidos, as demandas pertencentes ao escopo de atividades delegadas por esta contratação.
4.1.1.2. Permitir que grupos especializados concentrem sua atuação em atividades que proporcionem maior fluxo de valor à instituição, tais como:
4.1.1.2.1. Entrega de novos sistemas e funcionalidades em sistemas existentes proporcionando incremento de produtividade e controle das atividades
4.1.1.2.2. Manutenção da disponibilidade dos serviços de TI.
4.1.1.2.3. Aperfeiçoamento dos serviços de TI existentes.
4.1.1.2.4. Solução de demandas de maior complexidade.
4.1.2. A execução do serviço por equipes distintas dispersaria a responsabilidade pelo alcance dos objetivos. Essa dispersão acarretaria diluição do comprometimento com os processos de trabalho e traria riscos de sobreposição de atividades. Além disso, a comunicação direta e contínua entre as equipes é essencial para a qualidade da prestação do serviço, haja vista que os objetivos são comuns e a fronteira de atuação é muito tênue, dada a forte interconexão das atividades no que concerne aos aspectos técnicos (caráter generalista) e metodológicos (registro, investigação e diagnóstico).
4.1.3. Ante o exposto, a adjudicação do serviço a uma única empresa mitigará os riscos em comento e proporcionará melhor gestão e maior qualidade na execução do serviço de sustentação.
4.2. Metodologia de Trabalho
4.2.1. Para a execução do contrato, será implementado método de trabalho baseado no conceito de delegação de responsabilidade. Esse conceito define o MPPE como responsável pela gestão do contrato e pela atestação da aderência aos padrões de qualidade exigidos dos serviços entregues, e a CONTRATADA como responsável pela execução dos serviços, distribuição, controle e supervisão dos recursos humanos necessários.
4.2.2. Entretanto, a natureza dos serviços requer o atendimento tempestivo a demandas dos usuários. Por esse motivo, será exigida a disponibilidade permanente de equipes qualificadas e dimensionadas de forma compatível com a demanda esperada. Com isso, configura-se um modelo de contratação no qual a remuneração máxima é estabelecida com base no dimensionamento descrito em Ordens de Serviço, porém os valores efetivamente pagos são calculados em função dos serviços efetivamente prestados confrontados com o cumprimento de metas de desempenho e de qualidade exigidos.
4.2.3. O serviço executado no escopo da contratação envolverá a execução de atividades de rotina, que devem ser executadas de maneira contínua para apoiar os processos de trabalho do ambiente de TIC do MPPE, bem como de atendimentos realizado sob demanda.
4.2.4. A execução dos serviços será gerenciada pela CONTRATADA, que fará o acompanhamento diário da qualidade e dos níveis de serviço alcançados com vistas a efetuar eventuais ajustes. Os dados relativos ao registro e atendimento de demandas deverão ser mantidos atualizados nas ferramentas indicadas pelo MPPE, os quais serão utilizados para obter informações para a emissão dos relatórios gerenciais mensais e para a fiscalização do cumprimento das obrigações contratuais. Quaisquer problemas que venham a comprometer o bom andamento dos serviços ou o alcance dos níveis de serviço estabelecidos devem ser imediatamente comunicados aos gestores do contrato.
4.2.5. A CONTRATADA e os profissionais alocados na execução dos serviços deverão transferir ao MPPE, de forma incondicional, todos os direitos referentes à propriedade intelectual sobre procedimentos, roteiros de manutenção e configuração de equipamentos e demais documentos produzidos no âmbito do contrato.
4.2.6. Quaisquer problemas que venham a comprometer o bom andamento do serviço ou o alcance dos níveis de serviço e indicadores exigidos deverão ser imediatamente comunicados ao Gestor do Contrato, que colaborará com a CONTRATADA na busca da melhor solução para o problema.
4.2.7. Os recursos humanos disponibilizados para prestação dos serviços poderão ser compartilhados pela CONTRATADA para execução simultânea de outros contratos.
4.2.7.1. Para os serviços de Desenvolvimento de Novos Sistemas e Sustentação de Sistemas Legados mensurados em Unidades de Serviço Técnico o compartilhamento de recursos humanos não poderá ser realizado durante a execução da tarefa de rotina, independente do local de prestação de serviço. A CONTRATADA deverá garantir que os recursos humanos necessários para prestação dos serviços sejam alocados durante todo o período e com as atividades definidas nas Ordens de Serviço.
5. ELEMENTOS PARA GESTÃO DO CONTRATO
5.1. Papeis e Responsabilidade
ID | Papel | Entidade | Responsabilidade |
1 | Fiscais Técnicos | Servidores indicados pela CMTI | 1) Avaliação da qualidade dos serviços realizados e justificativas, de acordo com os Critérios de Aceitação definidos em contrato; 2) Identificação de não conformidade com os termos contratuais; 3) Verificação da manutenção das condições classificatórias referentes à habilitação técnica. 4) Verificação de manutenção das condições elencadas no Plano de Sustentação (Documento elaborado no planejamento da contratação, que visa garantir a continuidade do negócio durante e após a entrega da Solução de Tecnologia da Informação, bem como após o encerramento do contrato); 5) Comunicar por escrito ao gestor do contrato qualquer falta cometida pela empresa CONTRATADA, seja por inadimplemento de cláusula ou condição do contrato, ou por serviço executado de forma inadequada, fora do prazo, ou mesmo não realizado, formando o dossiê das providências adotadas para fins de materialização dos fatos que poderão levar a aplicação de sanção ou à rescisão contratual; 6) Sugerir ao gestor do contrato a aplicação de penalidades nos casos de inadimplemento parcial ou total do contrato; 7) Realizar pessoalmente a medição dos serviços contratados; 8) Recusar serviço ou fornecimento irregular ou em desacordo com condições previstas em edital, na proposta da CONTRATADA e no contrato; 9) Receber e dirimir reclamações relacionadas à qualidade de serviços prestados; 10) Averiguar se é a contratada quem executa o contrato e certificar-se de que não existe cessão ou subcontratação fora das hipóteses legais; 11) Verificar o cumprimento das normas trabalhistas por parte da contratada, a exemplo da jornada de trabalho, limitações de horas extras, descanso semanal, bem como da obediência às normas de segurança do trabalho, a fim de evitar acidentes com agentes administrativos, terceiros e empregados do contrato; |
ID | Papel | Entidade | Responsabilidade |
12) Atestar a efetiva realização do objeto contratado para fins de pagamento das faturas correspondentes; 13) Acompanhar e analisar os testes, ensaios, exames e provas necessários ao controle da qualidade dos materiais, serviços e equipamentos a serem aplicados nos serviços. | |||
2 | Fiscais Requisitante do Contrato | Servidores indicados pela CMTI | 1) Avaliação da qualidade dos serviços realizados e justificativas, de acordo com os Critérios de Aceitação definidos em contrato, em conjunto com o Fiscal Técnico quando solicitado pelo Gestor do Contrato; 2) Identificação de não conformidade com os termos contratuais, em conjunto com o Fiscal Técnico quando solicitado pelo Gestor do Contrato; 3) Verificação da manutenção da necessidade, economicidade e oportunidade da contratação; 4) Verificação de manutenção das condições elencadas no Plano de Sustentação (Documento elaborado no planejamento da contratação, que visa garantir a continuidade do negócio durante e após a entrega da Solução de Tecnologia da Informação, bem como após o encerramento do contrato), em conjunto com o Fiscal Técnico quando solicitado pelo Gestor do Contrato; 5) Acompanhar e analisar os testes, ensaios, exames e provas necessários ao controle da qualidade dos materiais, serviços e equipamentos a serem aplicados nos serviços, em conjunto com o Fiscal Técnico; 6) Verificar o cumprimento das normas trabalhistas por parte da contratada, a exemplo da jornada de trabalho, limitações de horas extras, descanso semanal, bem como da obediência às normas de segurança do trabalho, a fim de evitar acidentes com agentes administrativos, terceiros e empregados do contrato, em conjunto com o Fiscal Técnico quando solicitado pelo Gestor do Contrato; 7) Receber e dirimir reclamações relacionadas à qualidade de serviços prestados, em conjunto com o Fiscal Técnico quando solicitado pelo Gestor do Contrato; 8) Comunicar por escrito ao gestor do contrato qualquer falta cometida pela empresa contratada, seja por inadimplemento de cláusula ou condição do contrato, ou por serviço executado de forma inadequada, fora do prazo, ou mesmo não realizado, formando o dossiê das providências adotadas para fins de materialização dos fatos que poderão levar a aplicação de sanção ou à rescisão contratual, em conjunto com o Fiscal Técnico quando solicitado pelo Gestor do Contrato; 10) Sugerir ao gestor do contrato a aplicação de penalidades nos casos de inadimplemento parcial ou total do contrato, em conjunto com o Fiscal Técnico quando solicitado pelo Gestor do Contrato. |
3 | Fiscal Administrativo | Coordenadoria de Tecnologia da Informação | 1) Certificar-se do correto cálculo e recolhimento das obrigações trabalhistas, previdenciárias e tributárias decorrentes do contrato; 2) Efetuar o controle da vigência, realizando comunicado ao fiscal técnico em tempo hábil, uma vez que este deverá controlar os prazos de execução, necessidades de prorrogações ou nova contratação, ficando o fiscal administrativo responsável pelo controle da época de reajustamento dos preços contratados, tomando as providências cabíveis em tempo hábil junto à Divisão Central de Contratos e Convênios do MPPE, quando necessário; 3) Verificar se a empresa contratada cumpriu com a garantia contratual prevista no contrato. |
4 | Gestor do Contrato | Coordenadoria de Tecnologia da Informação | 1) Manter registro próprio, atualizado, das ocorrências relacionadas à execução do contrato; 2) Acompanhar o cumprimento do cronograma de execução e dos prazos previstos em conjunto com o Fiscal Técnico e Fiscal Requisitante; 3) Determinar à CONTRATADA a regularização das falhas ou defeitos observados, assinalando prazo para correção; 4) Relatar, por escrito, à autoridade competente do órgão responsável, a inobservância de cláusulas contratuais ou quaisquer ocorrências que possam trazer dificuldades, atrasos, defeitos e prejuízos à execução da avença, em especial os que ensejarem a aplicação de penalidades; |
ID | Papel | Entidade | Responsabilidade |
5) Comunicar à autoridade competente do órgão responsável, apresentando as devidas justificativas, a eventual necessidade de acréscimos ou supressões de serviços, materiais ou equipamentos, identificadas no curso das atividades de fiscalização; 6) Solicitar à CONTRATADA a substituição de empregado ou preposto da CONTRATADA e aprovar, previamente, mediante termo juntado ao processo, a substituição de iniciativa da CONTRATADA, quando assim exigir o contrato; 7) Receber, definitivamente, por meio de ateste na nota fiscal/fatura ou documento equivalente, devidamente discriminado, obras, serviços e materiais; 8) Acompanhar o prazo de vigência do contrato e manifestar-se, quando provocado pela Administração, sobre os aspectos de oportunidade, conveniência, razoabilidade e economicidade administrativa de realizar-se alteração, prorrogação ou rescisão do contrato, anexando, quando for o caso, documentação comprobatória. |
5.2. Deveres e Responsabilidades da Contratante
5.2.1. Nomear Gestor e Fiscais do contrato para acompanhar e fiscalizar a execução do contrato, sob o aspecto quantitativo e qualitativo, anotando em registro próprio as falhas detectadas.
5.2.2. Receber o objeto fornecido pela CONTRATADA que esteja em conformidade com a proposta aceita.
5.2.3. Aplicar à Contratada as sanções administrativas regulamentares e contratuais cabíveis.
5.2.4. Efetuar o pagamento à CONTRATADA, dentro dos prazos preestabelecidos em Contrato, desde que cumpridas todas as formalidades e exigências contratuais
5.2.5. Prestar, por meio de seu Gestor do Contrato, as informações e os esclarecimentos pertinentes ao(s) fornecimento(s) e serviço(s) contratado(s) que venham a ser solicitados pela CONTRATADA.
5.2.6. Registrar os incidentes e problemas ocorridos durante a execução do Contrato.
5.2.7. Comunicar oficialmente à CONTRATADA sobre quaisquer falhas verificadas na fiscalização do cumprimento dos fornecimentos e serviços prestados.
5.2.8. Informar à CONTRATADA sobre atos que possam interferir direta ou indiretamente nos fornecimentos e serviços prestados.
5.2.9. Proporcionar os recursos técnicos e logísticos necessários para que a CONTRATADA possa realizar os fornecimentos e executar os serviços conforme as especificações estabelecidas em Contrato, incluindo os recursos de hardware (microcomputadores, impressoras e servidores de rede) e software básico (sistema operacional e aplicativos de escritório) essenciais à prestação dos serviços, quando executados nas dependências do MPPE.
5.2.10. Revogar e eliminar autorizações de acesso concedidas à CONTRATADA e a seus representantes ao final do contrato e quando houver substituições na equipe que atende ao MPPE.
5.2.11. Disponibilizar cópia da Política de Segurança da Informação (PSI/MPPE) e das demais normas pertinentes à execução dos serviços, bem como às suas atualizações.
5.3. Deveres e Responsabilidades da Contratada
5.3.1. Prestar os serviços contratados conforme especificações, quantidades, prazos e demais condições estabelecidas neste documento e respectivo Contrato.
5.3.2. São de responsabilidade da CONTRATADA todas as despesas diretas e indiretas, incidentes sobre o serviço contratado, inclusive a resolução de problemas de inconformidade, para os quais tenha concorrido direta ou indiretamente.
5.3.3. Responsabilizar-se pela execução operacional dos serviços e gestão dos recursos a seu cargo.
5.3.4. Planejar, desenvolver, implantar, executar e manter os serviços objeto do contrato de acordo com os níveis de serviço estabelecidos no Anexo XIII – Indicadores de Nível Mínimo de Serviços.
5.3.5. Utilizar, na prestação dos serviços, pessoal devidamente capacitados e habilitados para os serviços contratados que atenda às exigências profissionais estabelecidas pelo MPPE observadas as especificações listadas no Anexo VI - Atividades e Qualificações Profissionais.
5.3.6. Manter seu corpo técnico atualizado em relação às tecnologias, normas e metodologias adotadas pelo MPPE, capacitando às suas expensas os profissionais envolvidos na execução dos serviços, garantindo a qualificação necessária desses profissionais, de modo a cumprir os prazos estabelecidos e garantir a qualidade dos serviços.
5.3.7. Manter as atualizações na documentação comprobatória da qualificação técnica dos profissionais alocados na execução dos serviços e disponibilizar essa documentação ao MPPE, sempre que solicitada.
5.3.8. Manter as condições de habilitação e qualificação exigidas na licitação durante toda a vigência do Contrato.
5.3.9. Obedecer ao especificado em todas as normas, padrões, processos e procedimentos do MPPE, respeitando os princípios éticos e compromissos de conduta estabelecidos pelo MPPE.
5.3.10. O MPPE pode, a qualquer tempo, atualizar sua plataforma tecnológica, bem como, suas normas, padrões, processos e procedimentos comprometendo-se a Contratada a se adaptar nos prazos definidos no contrato contados a partir da data de notificação por parte do MPPE. Para as atualizações cujos prazos não estejam definidos explicitamente no contrato, o prazo para adaptação da Solução será no máximo de 30 (trinta) dias corridos.
5.3.11. Responsabilizar-se pela execução do objeto do presente documento, respondendo civil e criminalmente por todos os danos, perdas e prejuízos que, por dolo ou culpa sua, de seus empregados, prepostos, ou terceiros no exercício de suas atividades, vier a, direta ou indiretamente, causar ou provocar ao MPPE.
5.3.12. Obter todas as autorizações, aprovações e franquias necessárias à execução dos serviços, pagando os emolumentos prescritos por lei e observando as leis, regulamentos e posturas aplicáveis. É obrigatório o cumprimento de quaisquer formalidades e o pagamento, às suas expensas, das multas porventura impostas pelas autoridades, mesmo daquelas que, por força dos dispositivos legais, sejam atribuídas à Administração Pública.
5.3.13. Abster-se, qualquer que seja a hipótese, de veicular publicidade ou qualquer outra informação acerca das atividades objeto deste documento sem prévia autorização do MPPE.
5.3.14. Manter sigilo, sob pena de responsabilidade civil, penal e administrativa, sobre todo e qualquer assunto de que tomar conhecimento em razão da execução do objeto do Contrato, respeitando todos os critérios de sigilo, segurança e inviolabilidade aplicáveis aos dados, informações, regras de negócios, documentos, entre outros.
5.3.15. Prestar qualquer tipo de informação solicitada pelo MPPE sobre os serviços contratados bem como fornecer qualquer documentação julgada necessária ao perfeito entendimento do objeto desta Contratação.
5.3.16. Participar, no período compreendido entre a assinatura do contrato e o termo final do prazo para o início da prestação dos serviços, de reunião inicial para alinhamento de expectativas contratuais com equipe de técnicos do MPPE. O MPPE fará a convocação dos representantes da empresa e fornecerá previamente a pauta da reunião.
5.3.17. Xxxxxx preposto responsável pela supervisão permanente dos serviços prestados, durante todo o período de vigência do contrato, com poderes de representante legal para tratar de todos os assuntos relacionados ao contrato, em atenção aos art. 68 da Lei no 8.666/93, sem ônus adicional para a CONTRATANTE. O preposto deverá ter disponibilidade para, pelo menos, uma reunião semanal para acompanhamento das demandas e uma reunião mensal de para apresentação dos relatórios mensais de prestação dos serviços, nas instalações da Contratante, na cidade de Recife, Pernambuco. A critério do MPPE, esta reunião poderá ocorrer por videoconferência.
5.3.17.1. O preposto indicado pela CONTRATADA não poderá acumular de forma simultânea a função de preposto e a função de membro das equipes de Desenvolvimento e/ou Sustentação de Sistemas.
5.3.18. Encaminhar ao MPPE, antes da data de início da realização dos serviços e mensalmente, junto ao relatório gerencial de níveis de serviço, relação nominal dos profissionais que atuarão junto ao MPPE, indicando o CPF, área de atuação e apresentando documentação comprobatória da qualificação dos profissionais alocados na execução dos serviços, bem como da comprovação de seu vínculo empregatício com a Contratada.
5.3.19. Elaborar e apresentar ao MPPE, mensalmente, Relatório Gerencial dos Serviços executados, contendo detalhamento dos níveis de serviços executados comparados com os contratados e demais informações necessárias ao acompanhamento e avaliação da execução dos serviços.
5.3.20. Manter os seus profissionais devidamente identificados por meio de crachá, quando em trabalho nas dependências do MPPE.
5.3.21. Gerenciar seus profissionais, exercendo supervisão técnica e administrativa durante toda a execução dos serviços prestados ao MPPE.
5.3.22. Atender, quando necessário, a necessidades eventuais demandadas através dos procedimentos de atendimento dos chamados técnicos em horários extraordinários, finais de semana ou feriados.
5.3.23. Promover o afastamento, no prazo máximo de 24 (vinte e quatro) horas após o recebimento da notificação, de qualquer dos seus profissionais que não estejam produzindo os resultados esperados na prestação dos serviços, que não correspondam aos critérios de confiança ou relacionamento interpessoal ou que perturbe a ação da equipe de fiscalização da CONTRATANTE. A substituição deverá ocorrer no prazo máximo de 05 (cinco) dias úteis, a partir do recebimento da notificação da CONTRATANTE, sendo vedado, inclusive, o eventual retorno do profissional substituído às dependências da CONTRATANTE para cobertura de licenças, dispensas, suspensões ou quaisquer ausências de outros profissionais em atuação para cumprimento dos serviços contratados.
5.3.24. Solicitar, obrigatoriamente, ao MPPE a revisão, modificação ou revogação de privilégios de acesso a sistemas, informações e recursos do MPPE, quando da transferência, remanejamento, promoção ou demissão de profissional sob sua responsabilidade que tenham executado tarefas relacionadas ao contrato com o MPPE.
5.3.25. Administrar todo e qualquer assunto relativo aos profissionais alocados na execução dos serviços.
5.3.26. Garantir a remuneração de todos os colaboradores que estiverem à disposição da CONTRATADA para execução dos serviços, responsabilizando-se única e exclusivamente por todos os encargos decorrentes da execução do contrato, observando de devida legislação para os serviços executados em horários extraordinários, bem como garantir a devida remuneração durante o período de repasse dos conhecimentos executado no ambiente do MPPE, portanto deve ser considerando como de efetivo trabalho o período em que o empregado estiver a disposição da CONTRATADA, devendo ser remunerado na forma da lei.
5.3.27. Responsabilizar-se única e exclusivamente pelo pagamento de todos os encargos e demais despesas, diretas ou indiretas, decorrentes da execução do objeto do presente Termo de Referência, tais como impostos, taxas, contribuições fiscais, previdenciárias, trabalhistas, fundiárias, enfim, por todas as obrigações e responsabilidades, sem qualquer ônus adicional ao MPPE, obrigando-se a saldá-los na época própria, vez que os seus profissionais não manterão nenhum vínculo empregatício com o MPPE.
5.3.28. Responsabilizar-se pelo ônus decorrente de todas as reclamações e/ou ações judiciais ou extrajudiciais, por culpa ou dolo, que possam eventualmente ser alegadas por terceiros, contra o MPPE, procedentes da prestação dos serviços do objeto desta contratação, originariamente ou vinculada por prevenção, conexão ou continência.
5.3.29. Responsabilizar-se pelo cumprimento das prescrições referentes às leis trabalhistas, de previdência social e normas regulamentadoras da medicina e segurança do trabalho.
5.3.30. Assumir a responsabilidade por todas as providências e obrigações estabelecidas na legislação específica de acidentes de trabalho quando, em ocorrência da espécie, forem vítimas seus trabalhadores no desempenho dos serviços ou em conexão com eles, ainda que ocorridos nas dependências do MPPE ou a serviço dele.
5.3.31. Responder por quaisquer danos causados diretamente a bens, tangíveis e intangíveis, de propriedade do MPPE ou de terceiros, quando tenham sido causados por seus profissionais durante a execução dos serviços.
5.3.32. Encaminhar à unidade fiscalizadora a solicitação de pagamento dos serviços prestados, emitidas em conformidade com os dados de medição de serviços previamente validados na reunião mensal de acompanhamento.
5.3.33. Reportar ao MPPE imediatamente qualquer anormalidade, erro ou irregularidades que possa comprometer a execução dos serviços e o bom andamento das atividades do MPPE.
5.3.34. Providenciar cópia, para todos os profissionais alocados na execução dos serviços, da PSTI/MPPE e das demais normas disponibilizadas pelo MPPE, bem como zelar pela observância de tais normas.
5.3.35. Solicitar, dos profissionais alocados na execução dos serviços, a assinatura de termo de sigilo e responsabilidade, bem como termo de ciência, de acordo com modelo a ser fornecido pelo MPPE.
5.3.36. Apresentar mensalmente ao MPPE cópia da documentação que comprove a quitação das obrigações trabalhistas e previdenciárias.
5.3.37. Devolver os crachás fornecidos pelo MPPE quando do desligamento de seus profissionais ou do término do contrato, e ainda ser o MPPE ressarcido por eventuais extravios ou danos.
5.3.38. Abster-se de contratar, para atuar no âmbito da presente contratação, servidor ativo ou aposentado do quadro do MPPE ou ocupante de cargo em comissão, assim como de cônjuge, companheiro, parente em linha reta, colateral ou por afinidade, até o 3º grau.
5.3.39. É vedada a subcontratação para a execução dos serviços objetos desta contratação.
5.3.40. Assumir a responsabilidade e o ônus financeiro pelo deslocamento dos profissionais de suas instalações para as instalações do MPPE, inclusive quanto às despesas de passagem e hospedagem.
5.3.41. Seguir as instruções e observações efetuadas pelo Gestor do Contrato, e fiscais técnicos, bem como reparar, corrigir, remover, reconstruir ou substituir às suas expensas, no todo ou em parte, os produtos e/ou artefatos que tenham sido construídos ou mantidos pela CONTRATADA, caso eles apresentem vícios, defeitos ou incorreções.
5.3.42. Fornecer informações e esclarecimentos sobre seus profissionais, em no máximo 48 (quarenta e oito) horas a contar do envio da solicitação feita pelo MPPE.
5.3.43. A CONTRATADA deverá fornecer os equipamentos utilizados por sua equipe técnica bem como providenciar a comunicação remota entre sua sede e seus colaboradores em regime de teletrabalho e/ou com as instalações (datacenter) da CONTRATANTE.
5.3.44. Tratar como “confidenciais” quaisquer informações, a que tenha acesso para execução do objeto, não podendo revelá-los ou facilitar sua revelação a terceiros. A obrigação permanecerá válida durante o período de vigência contratual e nos doze meses subsequentes ao seu término, e o seu descumprimento implicará em sanções administrativas e judiciais contra a Contratada. A CONTRATADA deverá assinar o Termo de Compromisso - Anexo IX e o Termo de Ciência - Anexo X.
5.3.45. Repassar, quando do período de transição inicial e/ou final do contrato, ou quando solicitado pelo MPPE, aos profissionais indicados pelo MPPE, os documentos, procedimentos e demais conhecimentos necessários para continuidade dos serviços prestados na vigência do contrato.
5.4. Forma de Acompanhamento do Contrato
ID | Evento | Forma de Acompanhamento |
1 | Reunião de alinhamento inicial do Contrato | Cronograma de implantação da Solução, Termo de Compromisso, Termo de Ciência e Plano de Inserção |
2 | Prestação dos serviços continuados de sustentação e desenvolvimento de sistemas | Demandas registradas através de chamados técnicos e acompanhadas através de relatórios mensais de prestação de serviços. |
5.5. Metodologia de Avaliação da Qualidade
Etapa/Fase/Item | Método de Avaliação |
Início da Prestação dos Serviços | Verificar se o início dos serviços ocorreu dentro do prazo definido em Contrato. |
Comprovação do atendimento aos requisitos de experiência dos empregados da CONTRATADA | No início da prestação dos serviços, e sempre que houver alteração na equipe de colaboradores da CONTRATADA, esta deverá apresentar currículo e demais documentos que comprovem que seus colaboradores atendem às especificações de perfis profissionais. |
Verificar a qualidade dos serviços prestados. | A verificação do atendimento da qualidade dos serviços prestados será realizada da forma descrita neste Termo de Referência e seus anexos. |
5.6. Prazos e Condições
5.6.1. Os prazos e condições de execução dos serviços estão estabelecidos detalhadamente de acordo com o conteúdo do item 3 – Descrição da Solução e Especificações Técnicas.
5.7. Aceite, Alteração, Cancelamento e Reajuste
5.7.1. Condições de Aceite
5.7.1.1. O aceite se dará pelo estabelecido no item 3 – Descrição da Solução e Especificações Técnicas deste documento e Anexo V – Indicadores de Nível Mínimo de Serviço.
5.7.2. Condições de Alteração
5.7.2.1. A Contratada deverá aceitar, nas mesmas condições propostas, os acréscimos ou supressões que se fizerem necessários, até o limite de 25% (vinte e cinco por cento) do valor inicial do contrato.
5.7.2.2. Alteração contratual unilateral, pela Administração Pública, quando houver modificação do projeto ou das especificações, para melhor adequação técnica aos seus objetivos conforme o artigo 65, inciso I, alínea a, da Lei nº 8.666, de 21 de junho de 1993, a Lei de Licitações e Contratos Administrativos.
5.7.3. Condições de Rescisão
5.7.3.1. Constituem motivo para rescisão contratual:
5.7.3.1.1. O não cumprimento de cláusulas contratuais, especificações ou prazos.
5.7.3.1.2. O cumprimento irregular de cláusulas contratuais, especificações e prazos.
5.7.3.1.3. A lentidão do seu cumprimento, levando o MPPE a comprovar a impossibilidade da execução do serviço, nos prazos estipulados.
5.7.3.1.4. O atraso injustificado no início dos serviços.
5.7.3.1.5. A paralisação dos serviços, sem justa causa e prévia comunicação ao MPPE.
5.7.3.1.6. A subcontratação total ou parcial das obrigações contraídas.
5.7.3.1.7. A associação da Contratada com outrem, a cessão ou transferência total ou parcial das obrigações contraídas, bem como a fusão, cisão ou incorporação da Contratada, que afetem a boa execução do Contrato, sem prévio conhecimento e expressa autorização do MPPE.
5.7.3.1.8. O desatendimento das determinações regulares da autoridade designada para acompanhar e fiscalizar a execução do Contrato, assim como as de seus superiores.
5.7.3.1.9. O cometimento reiterado de faltas na execução do Contrato, anotadas pelo MPPE. 5.7.3.1.10. A decretação de falência ou a instauração de insolvência civil da Contratada. 5.7.3.1.11. A dissolução da Contratada.
5.7.3.1.12. A alteração social ou a modificação da finalidade ou da estrutura da Contratada que prejudique a execução do Contrato.
5.7.3.1.13. Razões de interesse público, justificadas e determinadas, de alta relevância e amplo conhecimento, pela máxima autoridade do MPPE, e exaradas no Processo Administrativo a que se refere este Contrato.
5.7.3.1.14. A ocorrência de caso fortuito ou de força maior, regularmente comprovada, impeditiva da execução do Contrato.
5.7.3.1.15. O descumprimento do disposto no Inciso V, do Artigo 27, da Lei 8.666/93, sem prejuízo das sanções cabíveis.
5.7.3.1.16. O Contrato poderá ser rescindido por acordo entre as partes, mediante aviso-prévio e escrito, desde que haja conveniência para o MPPE, conforme previsto no Artigo 79, Inciso II da Lei 8666/93.
5.7.3.1.17. Poderá o MPPE rescindir imediatamente o Contrato, sem qualquer ônus, no caso de persistência no inadimplemento de obrigações pela Contratada, e pelas quais já tenha a mesma, sido notificada para providenciar as devidas regularizações.
5.7.3.1.18. O Contrato poderá ser rescindido pelo MPPE a qualquer tempo, sem ônus de qualquer espécie, a exclusivo critério do MPPE, desde que devidamente notificado, devendo este notificar a Contratada de sua intenção rescisória, com antecedência mínima de 45 (quarenta e cinco) dias corridos.
5.7.4. Condições de Reajuste.
5.7.4.1. O reajustamento tem como finalidade a manutenção da justa remuneração decorrente da suscetibilidade inflacionária dos contratos.
5.7.4.2. O emprego do reajustamento contratual visa exclusivamente a recomposição de preços apresentados pelos orçamentos referenciais ou propostas licitatórias que com o transcorrer do tempo ficam em descompasso com os praticados no mercado em função da desvalorização da moeda, cabendo sempre a demonstração analítica em sua atestação.
5.7.4.3. Os valores do contrato, serão reajustados pelo Índice de Preços ao Consumidor - IPCA, utilizando-se o percentual acumulado dos últimos 12 meses.
5.7.4.4. Caso o índice de reajustamento estabelecido neste Contrato seja extinto ou de qualquer outra forma não possa mais ser utilizado, o reajustamento utilizará como expressão para cálculo o índice geral de preços mais vantajoso para a CONTRATANTE, apresentado por instituição oficial.
5.7.4.5. O intervalo de 12 (doze) meses completos necessários para o cálculo do reajuste terá como marco inicial a data de apresentação da proposta.
5.8. Condições para Pagamento
5.8.1. A Reunião Mensal de Acompanhamento deverá ocorrer até o 5º (quinto) dia útil do mês subsequente ao da prestação dos serviços.
5.8.2. Na Reunião Mensal de Acompanhamento deverá ser entregue ao MPPE o Relatório Gerencial dos Serviços que será utilizado para efeitos de faturamento.
5.8.2.1. A estrutura e a definição do conteúdo do Relatório Gerencial dos Serviços serão definidas na Reunião Inicial do Contrato.
5.8.3. Os faturamentos dos serviços executados pela CONTRATADA, serão efetuados conforme abaixo:
5.8.3.1. Somente serão pagos serviços efetivamente realizados, homologados e/ou validados pelos fiscais/equipe de fiscalização/comissão de fiscalização designados pelo MPPE, que estiverem dentro dos padrões tecnológicos do MPPE, definidos de acordo com cada serviço executado.
5.8.3.2. O pagamento referente aos serviços será realizado através de depósito bancário preferencialmente nas agências do BANCO BRADESCO S/A, devendo as solicitações de pagamento, referentes à execução dos serviços previamente autorizadas, serem entregues até o dia 10 (dez) do mês subsequente à prestação dos mesmos, devendo o mesmo ser realizado, sem quaisquer acréscimos e atualização monetária, até o último dia útil do referido mês, devidamente atestado pelo(s) setor(es) competente(s) deste MPPE.
5.8.3.3. Nos casos de eventuais atrasos de pagamento, desde que a CONTRATADA não tenha concorrido de alguma forma para tanto, fica convencionado que a taxa de compensação financeira devida pelo MPPE, entre a data do vencimento e o efetivo adimplemento da parcela, será calculada mediante a aplicação da seguinte fórmula:
EM = I x N x VP, sendo:
EM = Encargos Moratórios.
N = Número de dias entre a data prevista para o pagamento e a do efetivo pagamento. VP = Valor da parcela a ser paga.
I = Índice de compensação financeira = 0,00016438 (no qual i = taxa percentual anual no valor de 6% (seis por cento)), assim apurado:
5.8.3.4. Caso a solicitação de pagamento não seja apresentada pela CONTRATADA ou, ainda, esteja incompleta ou com falhas, os prazos para realização do pagamento serão suspensos até que sejam sanadas as pendências apontadas pelo MPPE.
5.8.3.5. O prazo para pagamento será suspenso durante o período de indisponibilidade do sistema de pagamento do Estado de Pernambuco ao final de cada exercício financeiro, aproximadamente entre 20 de dezembro e 31 de janeiro do ano subsequente, cujos pagamentos serão realizados até o final da primeira quinzena do mês de fevereiro.
5.8.3.6. O pagamento somente será efetuado após a apresentação de certidões que comprovem a regularidade da empresa com o fisco Federal, Estadual e Municipal, FGTS, INSS e débitos trabalhistas.
5.8.3.6.1. As certidões apresentadas somente serão aceitas com prazo de validade determinado no documento ou com data de emissão não superior a 180 (cento e oitenta) dias corridos.
5.8.3.6.2. Sobre o valor de cada parcela incidirão as retenções previstas em lei; para tanto, a CONTRATADA deverá fazer apenas destaque na nota fiscal.
5.8.3.6.3. Constatada a situação de irregularidade da CONTRATADA, deve-se providenciar a sua advertência, por escrito, no sentido de que, no prazo de 05 (cinco) dias úteis, a CONTRATADA regularize sua situação ou, no mesmo prazo, apresente sua defesa.
5.8.3.6.4. O prazo do item anterior poderá ser prorrogado uma vez, por igual período, a critério da Administração.
5.8.3.6.5. Não havendo regularização ou sendo a defesa considerada improcedente, a Administração deverá comunicar aos órgãos responsáveis pela fiscalização da regularidade fiscal quanto à inadimplência da CONTRATADA, bem como quanto à existência de pagamento a ser efetuado pela Administração, para que sejam acionados os meios pertinentes e necessários para garantir o recebimento de seus créditos.
5.8.3.6.6. Persistindo a irregularidade, a Administração deverá adotar as medidas necessárias à rescisão do contrato em execução, nos autos dos processos administrativos correspondentes, assegurada à CONTRATADA a ampla defesa.
5.8.3.6.7. Havendo a efetiva prestação de serviços, os pagamentos serão realizados normalmente, até que se decida pela rescisão contratual, caso a CONTRATADA não regularize sua situação.
5.8.3.6.8. Somente por motivo de economicidade, segurança nacional ou outro interesse público de alta relevância, devidamente justificado, em qualquer caso, pela máxima autoridade do órgão ou entidade CONTRATANTE, não será recolhido o contrato em execução com empresa ou profissional inadimplente em sua regularidade fiscal e trabalhista. Não será efetuado qualquer pagamento à CONTRATADA, em caso de descumprimento das condições de habilitações e qualificações exigidas na licitação.
5.8.3.7. Os serviços serão faturados mensalmente após a solicitação de pagamento por parte da CONTRATADA e aceite do Relatório Gerencial de Serviço, por parte da CONTRATANTE.
5.8.3.8. O valor do pagamento mensal estará diretamente vinculado ao índice alcançado para os indicadores estabelecidos, sendo pago conforme resultado obtido e decrementado (cumulativamente) quando não forem atingidas as metas exigidas. Caso a CONTRATADA não cumpra com os seus compromissos, de qualidade e desempenho, terá a sua fatura reduzida conforme estabelecido no Anexo XIII - Indicadores de Nível Mínimo de Serviços.
5.8.3.9. Quando houver divergência entre a solicitação de pagamento apresentada e a prestação dos serviços verificada pela CONTRATANTE, a parte incontroversa poderá ser faturada ficando a parte controversa para ser discutida e compensada na fatura posterior.
5.8.3.10. O MPPE reserva-se o direito de recusar o pagamento, no ato da ATESTAÇÃO, caso o objeto não esteja em conformidade com as condições deste instrumento.
5.8.3.11. Os valores da(s) NF(s) / Xxxxxx(s) deverão ser os mesmos consignados na Nota de Xxxxxxx, sem o que não será liberado o respectivo pagamento. Em caso de divergência, será estabelecido prazo para a CONTRATADA fazer a substituição desta(s) NF(s) / Fatura(s).
5.9. Garantia
5.9.1. A CONTRATADA garantirá os serviços realizados durante toda a vigência do contrato.
5.9.2. A Contratada se obriga a corrigir quaisquer defeitos nos serviços entregues no período de vigência do contrato, sem ônus para o MPPE. Os defeitos compreendem, mas não se limitam, as imperfeições percebidas no serviço, ausência de artefato de documentação obrigatório e qualquer outra ocorrência que impeça o seu funcionamento normal. Tais defeitos poderão ser apurados pelo MPPE ainda que tenham sido faturados e pagos sem nenhuma restrição, ou seja, a fatura aceita não é documento de garantia de qualidade.
5.9.3. Esta garantia abrange toda correção decorrente dos erros ou falhas cometidas na execução dos serviços contratados.
5.10. Propriedade, Sigilo, Restrições
5.10.1. A CONTRATADA cederá ao MPPE, nos termos do art. 111, da Lei Federal N.º 8.666/93, combinado com o art. 4.º, da Lei Federal N.º 9.609/98, o direito patrimonial e a propriedade intelectual em caráter definitivo, os resultados produzidos em consequência dos serviços contratados, entendendo-se por resultados quaisquer estudos, relatórios, artefatos, descrições técnicas, fluxos de trabalho, protótipos, dados, esquemas, plantas, desenhos, diagramas, roteiros, tutoriais, código fonte de IDE (Ambiente de Desenvolvimento Integrado), ferramentas que auxiliam na engenharia de software (ferramenta CASE), software e respectivos componentes, frameworks de desenvolvimento, fontes dos códigos de programas computacionais em qualquer mídia, páginas de Intranet e Internet e qualquer outra documentação produzida no escopo da presenta contratação, em papel ou em mídia eletrônica, entregues conforme versões e fabricantes indicados pelo MPPE, sendo vedado à CONTRATADA sua cessão, locação ou venda a terceiros.
5.10.2. Toda a documentação produzida pela CONTRATADA referente à implantação dos serviços e documentos exigidos neste Termo de Referência passam a ser propriedade de forma perpétua do MPPE, não precisando este MPPE de autorização da CONTRATADA para reproduzir, distribuir e publicar em documentos públicos ou fornecer a terceiros quando a administração considerar necessário.
5.10.3. Todas as informações obtidas ou extraídas pela CONTRATADA quando da execução dos serviços deverão ser tratadas como confidenciais, sendo vedada qualquer divulgação a terceiros, devendo a CONTRATADA, zelar por si, por seus sócios, empregados e subcontratados pela manutenção do sigilo absoluto sobre os dados, informações, documentos, especificações técnicas e comerciais de que eventualmente tenham conhecimento ou acesso em razão dos serviços executados.
5.10.4. A obrigação assumida de Confidencialidade permanecerá válida durante o período de vigência do contrato principal e o seu descumprimento implicará em sanções administrativas e judiciais contra a CONTRATADA, previstas no CONTRATO e na legislação pertinente.
5.10.5. Para efeito do cumprimento das condições de propriedade e confidencialidade estabelecidas, a CONTRATADA exigirá de todos os seus empregados que, a qualquer título, venham a integrar a equipe executante do Objeto deste Termo de Referência, a assinatura do Anexo IX - Termo de Compromisso, bem como a assinatura do Anexo X - Termo de Ciência onde o signatário e os funcionários que compõem seu quadro funcional declaram-se, sob as penas da lei, ciente das obrigações assumidas e solidário no fiel cumprimento das mesmas.
5.11. Mecanismos Formais de Comunicação
5.11.1. São instrumentos formais de comunicação entre a CONTRATANTE e a CONTRATADA:
ID | Função de Comunicação | Emissor | Destinatário | Forma de Comunicação | Periodicidade |
01 | Registro de Chamados Técnicos | Contratante | Contratada | Portal de Serviços da Contratada e atendimento telefônico | Quando demandado pelo MPPE |
02 | Emissão de Nota de Empenho | Contratante | Contratada | Nota de Xxxxxxx | Quando demandado pelo MPPE |
03 | Registro das Reuniões realizadas entre a contratante e a contratada | Contratada/ Contratante | Contratada/ Contratante | Ata de Reunião | Sempre que houver reunião entre as partes |
04 | Relato de alguma ocorrência contratual através de Ofício por correspondência. | Contratante | Contratada | Documentos Oficiais | Sempre que houver falha no atendimento a algum item do contrato ou quando necessário. |
05 | Troca de informações técnicas necessárias a execução do contrato | Contratada/ Contratante | Contratada/ Contratante | Através de telefone, e-mail, presencial, relatórios, documentos texto, planilhas, slides, sítios da internet, PDF (Portable Document Format): documento em formato portável. | Quando necessário. |
6. ESTIMATIVA DE PREÇOS
ITEM | COD EFISCO | Objeto | UN | Quantidade | Valor Unit Médio | Valor Total Médio |
1 | 512751-3 | Unidade de Serviços Técnicos - Serviço Desenvolvimento de Novos Sistemas e Sustentação de Sistemas Legados | UST | 47.309 | R$ 158,17 | R$ 7.482.630,14 |
7. ADEQUAÇÃO ORÇAMENTÁRIA
7.1. Fonte de Recursos
7.1.1. A fonte de recursos para esta contratação será informada oportunamente pela Assessoria de Planejamento, Estratégia e Orçamento (AMPEO) do MPPE.
8. SANÇÕES APLICÁVEIS
8.1. Com fundamento no art. 7 da Lei N. 10.520/2002 e, subsidiariamente, nos artigos 86 e 87 da Lei N. 8.666/1993, a CONTRATADA ficará sujeita, assegurada prévia e ampla defesa, as seguintes penalidades:
8.1.1. Advertência.
8.1.2. Xxxxxx, estipuladas na forma a seguir:
8.1.2.1. multa de 0,5% (cinco décimos por cento) sobre o valor faturado pela empresa no período de 06 (seis) meses, para cada indicador de nível de serviço que apresente discrepância superior a 10% em relação à meta prevista em 03 (três) medições em meses consecutivos, ou alternados, realizadas a cada período de 06 (seis) meses da execução dos serviços, até o limite de 5% (cinco por cento) sobre o valor faturado neste mesmo período.
8.1.2.2. multa de 1% (um por cento) sobre o valor total faturado para o contrato, no mês da infração, para cada ocorrência de descumprimento de obrigações contratuais que não sejam relacionadas ao atingimento das metas estabelecidas para os indicadores de nível de serviço, até o limite 10% (dez por cento) sobre o valor total faturado para o contrato no mês da infração.
8.1.2.3. multa de 1% (um por cento) sobre o valor total faturado para o contrato, no mês da infração, para cada indicador/meta de níveis de serviço que tenha sido objeto de fraude, manipulação ou descaracterização pela CONTRATADA, até o limite 10% (dez por cento) sobre o valor total faturado para o contrato no mês da infração.
8.1.2.4. multa de 10% (dez por cento) sobre o valor total do contrato, em caso de inexecução total da obrigação assumida, caracterizando-se quando houver reiterado descumprimento de obrigações contratuais.
8.1.2.5. multa de 0,5% (cinco décimos por cento) sobre o valor mensal a ser pago pela Ordem de Serviço Padrão, pelo atraso no início do serviço, por dia de atraso, até o limite de 10% (dez por cento) do valor mensal a ser pago pela Ordem de Serviço Padrão.
8.1.2.6. 1% (um por cento) por dia sobre o valor da garantia contratual, pela não apresentação/atualização, até o percentual de 10% (dez por cento), no prazo estabelecido neste instrumento, da garantia de execução contratual.
8.1.2.7. 0,5% (meio por cento) por evento sobre o valor global atualizado do contrato, pela não manutenção das condições de habilitação e qualificação exigidas no instrumento convocatório, até o limite de 10% (dez por cento) sobre o valor global atualizado do contrato.
8.1.3. Impedimento de licitar e contratar com o Estado de Pernambuco e descredenciamento do SICAF, pelo prazo de até 5 (cinco) anos, sem prejuízo das multas previstas no contrato e das demais penalidades.
8.1.4. DECLARAÇÃO DE INIDONEIDADE para licitar e contratar com a Administração Pública enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação perante a própria autoridade que aplicou a penalidade.
8.2. RESCISÃO, nos casos previstos no art.78 da Lei nº 8.666/93.
8.3. Ao MPPE será assegurado, após regular processo administrativo, utilizar a garantia para permitir a compensação da multa aplicada. Se a multa for de valor superior ao valor da garantia prestada, além da perda desta, responderá a CONTRATADA pela sua diferença, a qual será descontada dos pagamentos eventualmente devidos pela Administração ou ainda, quando for o caso, cobrada judicialmente.
8.4. As sanções acima descritas poderão ser aplicadas de forma distinta ou cumulativa, sem prejuízo de responsabilização nas esferas cível e penal.
8.5. Sempre que houver irregularidade na prestação dos serviços executados, a CONTRATANTE efetuará a apuração das ocorrências e comunicará à CONTRATADA, conforme especificado. As multas serão aplicadas sobre a garantia contratual e quando a mesma não for suficiente para a quitação integral da multa o restante será descontada nas notas fiscais da CONTRATADA.
8.6. A CONTRATADA terá prazo máximo de 05 (cinco) dias úteis contados do recebimento da comunicação para apresentar as justificativas.
8.7. Caso não haja manifestação da CONTRATADA dentro desse prazo ou caso a CONTRATANTE entenda serem improcedentes as justificativas, serão aplicadas as penalidades previstas.
8.8. Caso ocorram divergências entre as justificativas apresentadas pela CONTRATADA e o atesto emitido pelo MPPE, o faturamento da parte incontroversa poderá ter o seu pagamento autorizado e os ajustes poderão ser realizados no período subsequente após a conclusão dos processos de apuração das irregularidades.
8.9. As notificações de multas e sanções são de responsabilidades da Divisão Central de Contratos e Convênios do MPPE que receberá dos setores responsáveis os relatórios com as ocorrências insatisfatórias que comprometam a execução do contrato.
9. CRITÉRIOS DE SELEÇÃO DO FORNECEDOR
9.1. Proposta de Preço
1.1.1. Organização da Proposta
9.1.1.1. A proposta deverá conter obrigatoriamente os seguintes elementos:
9.1.1.1.1. Preço unitário por item, em moeda corrente nacional, cotados com apenas duas casas decimais, expressos em algarismos e por extenso, sendo que, em caso de divergência entre os preços expressos em algarismos e por extenso, serão levados em consideração os últimos.
9.1.1.1.2. Não deve conter cotações alternativas, emendas, rasuras ou entrelinhas.
9.1.1.1.3. Deve fazer menção ao número do pregão e do processo licitatório.
9.1.1.1.4. Deve ser datada e assinada na última folha e rubricadas nas demais, pelo representante legal da empresa.
9.1.1.1.5. Deve conter na última folha o número do CNPJ da empresa.
9.1.1.1.6. Deve informar o prazo de validade da proposta, que não poderá ser inferior a 60 (sessenta) dias corridos, contados da data de entrega da mesma.
9.1.1.1.7. Indicação do nome do banco, número da agência, número da conta corrente, para fins de recebimento dos pagamentos.
9.1.1.1.8. A CONTRATADA deverá assegurar que a proposta apresentada atende aos requisitos previstos neste Termo de Referência.
9.1.1.1.8.1. O valor final da proposta de preços do licitante vencedor deve ser discriminado em planilhas de custos e formação de preços, com base na Instrução Normativa Nº5 do Ministério do Planejamento, Desenvolvimento e Gestão.
9.1.1.1.8.2. A critério da CONTRATANTE, poderá ser solicitado à CONTRATADA o detalhamento do valor apresentado para os serviços, devendo-se contemplar neste detalhamento os valores de remuneração, encargos sociais, benefícios e demais itens de composição do preço – com rigorosa observância da legislação trabalhista, inclusive, de convenções e/ou acordos coletivos de trabalho, bem como dimensionar a mão de obra necessária para o atendimento ao objeto do Termo de Referência.
9.1.1.1.8.3. A critério da CONTRATANTE, poderão ser solicitadas informações complementares sobre a proposta comercial da CONTRATADA visando à demonstração pela CONTRATADA da exequibilidade do serviço.
9.2. Qualificação Técnica
9.2.1. Atestado(s) de capacidade técnica, expedido(s) por pessoa(s) jurídica(s) de direito público ou privado, que comprove(m) a aptidão para desempenho de atividade compatível com o objeto deste Edital.
9.2.2. Será aceito o somatório de atestados para comprovação das capacitações exigidas.
9.2.3. O atestado de capacidade técnica apresentado deverá conter no mínimo o CNPJ e endereço da entidade emitente, data de emissão, descrição do serviço realizado, quantitativo de UST/Horas, número e vigência do contrato, local onde os serviços foram prestados, o nome, função e telefone do responsável e a qualidade da Solução fornecida.
9.2.4. Os atestados deverão referir-se a serviços prestados no âmbito da atividade econômica principal ou secundária especificadas no contrato social vigente da proponente.
9.2.5. A comprovação de capacidade técnica estará sujeita à confirmação da veracidade de suas informações através de possíveis diligências, conforme prescreve o art. 43, § 3º, da Lei 8.666/93.
9.2.6. Para comprovação de atividade compatível com o objeto deste Edital os atestados, ou o conjunto de atestados, devem conter a execução de serviços com a seguinte natureza:
9.2.6.1. Experiência em Levantamento de requisitos funcionais e/ou não funcionais através de histórias de usuários para desenvolvimento de sistemas.
9.2.6.2. Experiência em Desenvolvimento e manutenção de sistemas utilizando nas plataformas JAVA, PHYTON, JAVASCRIPT, CSS, HTML5 e PHP, com base ainda na arquitetura Tecnológica da CONTRATANTE, conforme Anexo III – Arquitetura Tecnológica.
9.2.6.3. Comprovação que a empresa executou Projetos de desenvolvimento, em modelo ágil, nas etapas de Análise, Projeto e Implementação, utilizando plataformas tecnológicas como: Angular, Node.js, Spring Boot, Docker, Xxxxxxx e Sonar.
9.2.6.4. Experiência em levantamento, especificação de requisitos, modelagem, análise, projeto lógico e físico, implantação e manutenção de sistemas para ambiente web, utilizando Java com acesso a banco de dados relacional Oracle, MySQL, PostGreSQL e utilização de webservices (API REST ou SOAP).
9.2.6.5. Experiência em desenvolvimento e implantação de solução utilizando ferramentas de Data Warehouse, extração, transformação e carga de dados com ETL/ELT, desenvolvimento e utilização de webservices (API REST ou SOAP), integrações por meio de JSON e/ou serviços API.
9.2.6.6. Experiência em implantação e/ou utilização de ferramentas como Selenium, Cucumber, Jmeter ou SonarQube dentro do processo de construção de soluções.
9.2.6.7. Experiência em desenvolvimento e manutenção de sistemas nas plataformas mobile IOS e/ou Android.
9.2.6.8. Experiência em Gerenciamento de projetos de desenvolvimento e manutenção de sistemas aderente ao PMI (Project Management Institute)/PMBOK.
9.2.6.9. Experiência em metodologias ágeis como SCRUM e/ou SAFe (scaled agile framework).
9.2.6.10. Desenvolvimento e manutenção de sistemas utilizando processos e metodologias formais.
9.2.6.11. Execução de testes utilizando processo de testes formal (teste unitário, teste integrado de sistema e teste de carga e desempenho) suportado por ferramenta de gerenciamento de teste. Os atestados devem conter a indicação das ferramentas utilizadas.
9.2.6.12. Utilização de processo gerência de configuração com ferramenta de controle de versão e fluxos de trabalho baseados em branches de código-fonte. Os atestados devem conter a indicação das ferramentas utilizadas.
9.2.7. Visando assegurar que a empresa contratada possui experiência na prestação dos serviços indicados, a empresa deverá apresentar atestados de capacidade para os serviços de desenvolvimento de sistemas. As comprovações de experiência dos serviços prestados pela licitante devem ter sido executadas de forma satisfatória por um período ininterrupto e mínimo de 12 (doze) meses.
9.2.8. O volume total do somatório das comprovações de experiências não pode poderá ser inferior ao mínimo de 23.650 unidades de serviço técnico (UST).
9.2.9. Poderão ser apresentados um ou mais atestados, indicando-se o somatório de estimativas para alcance da métrica estabelecida.
9.2.10. Para fins da comprovação das UST exigidas nos atestados, 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) UST. Da mesma forma, serão aceitos atestados unidades equivalentes, tais como Horas e Horas de Serviço Técnico (HST). Neste último caso, a proporção será de 1:1 (um para um). Em caso de atestados relacionados a contratações de postos de serviço, deve-se explicitar a carga horária dos profissionais alocados e diretamente envolvidos na prestação de serviços.
9.2.11. A empresa deverá apresentar atestado de capacidade para os Serviços de desenvolvimento de sistemas utilizando a tecnologia Java, incluindo uma ou mais especificações da plataforma Java conforme Anexo III – Arquitetura Tecnológica. Estes serviços devem ter sido executados de forma satisfatória em um período ininterrupto de 12 (doze) meses, com volumes não inferiores ao mínimo de 30% de unidades de serviço técnico (UST).
9.2.12. A empresa deverá apresentar atestado de capacidade para os Serviços de desenvolvimento de sistemas utilizando banco de dados Oracle 11g ou superior. Estes serviços devem ter sido executados de forma satisfatória em um período ininterrupto de 12 (doze) meses, com volumes não inferiores ao mínimo de 5% de unidades de serviço técnico (UST).
9.2.13. Somente serão aceitos atestados expedidos após a conclusão do contrato ou decorrido no mínimo um ano do início de sua execução, exceto se houver sido firmado para ser executado em prazo inferior.
9.2.14. Não serão aceitos atestados emitidos pela proponente, em seu próprio nome, nem qualquer outro em desacordo com as exigências do edital.
9.2.15. Cada atestado deverá vir acompanhado de informações sobre projetos relevantes desenvolvidos para uma melhor compreensão a respeito da capacidade técnica da CONTRATADA.
9.2.15.1. O detalhamento dos projetos deverá contemplar minimamente as seguintes informações: nome do projeto; tamanho do projeto em UST (ou outra métrica utilizada); tipo de projeto (se desenvolvimento ou manutenção); linguagens de programação e tecnologias utilizadas; banco de dados; metodologia de desenvolvimento e/ou sustentação utilizada no serviço executado; metodologia de gerenciamento de projetos.
9.2.16. A empresa deverá comprovar capacidade de execução dos serviços de desenvolvimento e manutenção de sistemas por meio do estabelecimento de processo de qualidade e maturidade no desenvolvimento de software. Para comprovação desse item, adicionalmente deverá ser apresentada a seguinte documentação:
9.2.16.1. Certificados CMMi Nível DEV 3 ou superior, ou MPS-BR-SW Nível C ou superior, expedidos por instituição qualificada e autorizada para esta finalidade.
9.2.16.2. A exigência de tal comprovação tem como objetivo trazer maior segurança ao processo de contratação de fornecedores, objetivando-se a prestação de serviços de qualidade minimamente aceitáveis. Tais certificações visam à melhoria da maturidade de processos de software, fornecendo às organizações elementos essenciais de processos eficazes e de capacidade de desenvolvimento de software, resguardando a CONTRATADA quanto às práticas de desenvolvimento de software das licitantes, dentro ou fora de suas dependências.
9.2.16.3. Caso a proponente não possua os certificados listados no item anterior, e visando à ampla competitividade do certame, será aceita, para fins de comprovação da adoção de padrões de qualidade, a apresentação da seguinte documentação comprobatória:
9.2.16.3.1. Descrição da metodologia de projetos de software utilizada. 9.2.16.3.2. Exemplos de planos de projetos executados e templates utilizados. 9.2.16.3.3. Plano de gerência de configuração dos projetos.
9.2.16.3.4. Guia de medição/indicadores de projetos. 9.2.16.3.5. Especificação/documentação de requisitos.
9.2.16.3.6. Registros de reunião de acompanhamento dos projetos com a alta direção. 9.2.16.3.7. Registros de monitoramento do projeto.
9.2.16.3.8. Lista de riscos identificados do projeto. 9.2.16.3.9. Registros da gestão de mudanças do projeto.
9.2.16.3.10. Ações tomadas para problemas identificados nos projetos. 9.2.16.3.11. Exemplos de auditorias da qualidade realizada e checklists utilizados. 9.2.16.3.12. Exemplos de auditorias de configuração do projeto.
9.2.16.3.13. Exemplos de baselines de configuração criadas no projeto.
9.2.17. Comprovação de que a empresa possui programa de integridade estruturado com o objetivo de prevenir, detectar e sanar desvios, fraudes, irregularidades e atos ilícitos praticados contra a administração pública, nacional ou estrangeira (Decreto Federal n 8.420/2015), ou que possui normativos internos e realiza a diligência prévia para a avaliação da reputação, idoneidade e das práticas de combate à corrupção de terceiros, tais como, fornecedores, distribuidores, agentes, consultores, representantes comerciais e/ou parceiros operacionais, bem como de empregados.
9.2.18. Comprovação de que a empresa possui um Código de ética, Guia de Conduta ou documentos correlatos que descrevem as condutas éticas que devem ser observadas pelos integrantes da Alta Administração, empregados próprios e/ou terceirizados.
9.3. Justificativa de Adoção da Modalidade da Licitação e Natureza do Serviço
9.3.1. Modalidade de Licitação
9.3.1.1. A modalidade de licitação sugerida é o pregão na forma eletrônica com modo de disputa aberto e fechado, considerando se tratar de serviço comum, nos termos da lei Federal n° 10.520/2002, vez que seus padrões de desempenho e qualidade podem ser objetivamente definidos pelo Termo de Referência e Edital, por meio de especificações usuais no mercado.
9.3.2. Natureza do Serviço
9.3.2.1. Os serviços previstos compreendem a realização de atividades específicas e delimitadas, executadas dentro do ciclo de vigência do contrato.
9.3.2.2. A natureza do serviço é continuada visto que existe demanda contínua da utilização dos serviços estabelecidos mesmo após a implementação das demandas atuais estabelecidas para o período de 12 meses. Esta necessidade não se satisfaz com a execução do objeto dentro do prazo único de 12 meses, renovando-se com o tempo e exigindo, desta forma, execução continuada dos serviços prestados. A continuidade da necessidade do serviço retrata, portanto, a permanência da necessidade institucional a ser satisfeita, cujo atendimento não exaure prestação semelhante no futuro.
9.3.2.3. Este serviço também possui caráter contínuo em vista da sua essencialidade para assegurar os serviços de construção e sustentação de sistemas para habilitação dos processos organizacionais por meio da TI, de forma rotineira e permanente, apoiando o funcionamento das atividades finalísticas e administrativas do órgão, de modo que sua interrupção poderia comprometer a prestação de um serviço público ou o cumprimento da missão institucional.
9.3.2.4. Ademais, a prestação dos serviços não gera vínculo empregatício entre os empregados da CONTRATADA e a Administração, vedando-se qualquer relação entre estes que caracterize pessoalidade e subordinação direta. O modelo de contratação proposto tem pagamento realizado pelo serviço realizado, não exigindo alocação de mão-de-obra.
9.4. Justificativa para Aplicação do lote exclusivo/cota reservada
9.4.1. Para esta contratação, não se aplica o disposto nos incisos I e III do art. 48 da Lei Complementar n° 123, de 14 de dezembro de 2006, pelos seguintes motivos: Para o inciso I, para esta contratação o valor estimado é superior a R$ 80.000,00 (oitenta mil reais), conforme descrito no Item 6 – Estimativa de Preços; Para o inciso III, o objeto deste Termo de Referência visa a contratação de serviço e não a aquisição de bens de natureza divisível, conforme previsto no referido inciso.
9.4.2. Dessa forma, em conformidade com o disposto no inciso III, Art. 49 da Lei Complementar nº 123, de 14 de dezembro de 2006, o disposto no inciso III do Art. 48, da mesma lei, não será aplicada margem de preferência a esta contratação.
9.5. Critérios de Seleção
9.5.1. Tipo de Licitação
9.5.1.1. A licitação será do tipo menor preço. Os valores máximos aceitáveis, tanto unitários quanto global, estão descritos no Item 6 – Estimativa de Preços.
9.5.1.2. O objeto desta contratação será realizado por execução indireta, sob o regime de empreitada por Preço Unitário, nos termos dos art. 6°, VIII, "b" da Lei n. 8.666/93.
9.6. Do Atestado de Vistoria Técnica
9.6.1. Atestado de Vistoria a ser fornecido pelo MPPE ou declaração de dispensa, conforme as seguintes condições:
9.6.1.1. Fica facultado à proponente, caso seja necessário levantar, “in loco”, subsídios para formulação de suas propostas, realizar vistoria técnica nas instalações do MPPE, durante o horário de funcionamento regular do mesmo. Caso a proponente não realize a vistoria técnica deverá emitir declaração de dispensa, informando que tem pleno conhecimento da natureza e do escopo dos serviços, conforme o Anexo XI – Declaração de Dispensa de Vistoria.
9.6.1.2. O agendamento da vistoria deverá ser previamente efetuado nos telefones de contatos do MPPE, mencionando as informações de contato da Empresa (razão social, endereço e telefone) e de seu representante (nome completo e telefone) o qual efetuará a vistoria.
9.6.1.3. MPPE: Xxx xx Xxx, 000 – 0x xxxxx - xxx XXXXX – Xxxxxx-XX, na Coordenadoria Ministerial de Tecnologia da Informação (CMTI).
9.6.1.4. A vistoria deverá ser agendada e realizada em no máximo 02 (dois) dias úteis antes da abertura das propostas.
9.6.1.5. Durante a vistoria, será dado acesso às dependências do MPPE.
9.6.1.6. Quando da vistoria, a proponente deverá se inteirar de todos os aspectos referentes à execução do serviço, não se admitindo, posteriormente, qualquer alegação de desconhecimento desses aspectos.
9.6.1.7. Para todos os efeitos, considerar-se-á que a Empresa tem pleno conhecimento da natureza e do escopo dos serviços, não se admitindo, posteriormente, qualquer alegação de desconhecimento desses elementos de contratação.
9.6.1.8. Efetuada a vistoria será lavrado, por representante da equipe técnica do MPPE designado para tanto, o respectivo Atestado de Vistoria.
9.7. Qualificação Econômico-Financeira
9.7.1. Balanço patrimonial e demonstrações contábeis referentes ao último exercício social, comprovando índices de Liquidez Geral – LG, Liquidez Corrente – LC, e Solvência Geral – SG superiores a 1 (um).
9.7.2. Capital Circulante Líquido ou Capital de Giro (Ativo Circulante - Passivo Circulante) de, no mínimo, 16,66% (dezesseis inteiros e sessenta e seis centésimos por cento) do valor estimado da contratação, tendo por base o balanço patrimonial e as demonstrações contábeis do último exercício social.
9.7.3. Comprovação de patrimônio líquido de 10% (dez por cento) do valor estimado da contratação, por meio da apresentação do balanço patrimonial e demonstrações contábeis do último exercício social, apresentados na forma da lei, vedada a substituição por balancetes ou balanços provisórios, podendo ser atualizados por índices oficiais, quando encerrados há mais de 3 (três) meses da data da apresentação da proposta.
9.7.4. Balanço patrimonial e demonstrações contábeis do último exercício social, que comprovem a boa situação financeira da empresa, vedada a substituição por balancetes ou balanços provisórios, podendo ser atualizados por índices oficiais quando encerrado há mais de 3 (três) meses da data de apresentação da proposta.
9.7.5. Declaração da proponente, acompanhada da relação de compromissos assumidos, conforme modelo constante do Anexo VII - Declaração de Compromissos Assumidos, de que 1/12 (um doze) avos dos contratos firmados com a Administração Pública e/ou com a iniciativa privada, vigentes na data apresentação da proposta não é superior ao patrimônio líquido da proponente, observados os seguintes requisitos:
9.7.5.1. A declaração deve ser acompanhada da Demonstração do Resultado do Exercício – DRE, relativa ao último exercício social.
9.7.5.2. Caso a diferença entre a declaração e a receita bruta discriminada na Demonstração do Resultado do Exercício – DRE apresentada seja superior a 10% (dez por cento), para mais ou para menos, a proponente deverá apresentar justificativas.
9.7.6. Certidão negativa de feitos sobre falência, recuperação judicial ou recuperação extrajudicial, expedida pelo distribuidor da sede da proponente.
10. GARANTIA CONTRATUAL
10.1. A CONTRATADA deverá entregar na Central de Contratos do MPPE, no prazo de 10 (dez) dias consecutivos, contados a partir da data de assinatura de contrato, a título de garantia, a quantia equivalente a 5% (cinco por cento) do valor global do contrato, cabendo-lhe optar dentre as modalidades previstas no art. 56, § 1º, da Lei Nº 8.666/93. A garantia será devolvida à CONTRATADA somente depois do cumprimento integral das obrigações assumidas, inclusive recolhimento de multas e satisfação de prejuízos causados ao MPPE.
10.1.1. A garantia deverá ter validade durante a execução do contrato e 90 (noventa) dias após término da vigência contratual, devendo ser renovada a cada prorrogação.
10.2. A garantia, qualquer que seja a modalidade escolhida, assegurará o pagamento de:
10.2.1. Prejuízos advindos do não cumprimento do objeto do contrato.
10.2.2. Prejuízos diretos causados à Administração, decorrentes de culpa ou dolo durante a execução do contrato.
10.2.3. Multas moratórias e punitivas aplicadas pela Administração à contratada.
10.2.4. Obrigações trabalhistas e previdenciárias de qualquer natureza, não adimplidas pela contratada, quando couber.
10.3. A modalidade seguro-garantia somente será aceita se contemplar todos os eventos indicados no item 10.2, observada a legislação que rege a matéria.
10.4. A não renovação, tempestivamente, da Garantia do Contrato ensejará a aplicação de sanções contratuais definidas neste documento.
10.5. Caso o valor da garantia seja utilizado no todo ou em parte para o pagamento de multas, ela deve ser complementada no prazo de até 48 (quarenta e oito) horas, contado da solicitação do MPPE, a partir do qual se observará o disposto abaixo:
10.5.1. A inobservância do prazo fixado para apresentação da garantia acarretará a aplicação de multa de 0,07% (sete centésimos por cento) do valor do contrato por dia de atraso, observado o máximo de 2% (dois por cento).
10.5.2. O atraso superior a 25 (vinte e cinco) dias autoriza a Administração a promover a rescisão do contrato por descumprimento ou cumprimento irregular de suas cláusulas, conforme dispõem os incisos I e II do art. 78 da Lei nº 8.666, de 1993.
10.6. O garantidor não é parte para figurar em processo administrativo instaurado pelo MPPE com o objetivo de apurar prejuízos e/ou aplicar sanções à CONTRATADA.
10.7. A garantia será considerada extinta:
10.7.1. Com a devolução da apólice, carta-fiança ou autorização para o levantamento de importâncias depositadas em dinheiro a título de garantia, acompanhada de declaração da Administração, mediante termo circunstanciado, de que a CONTRATADA cumpriu todas as cláusulas do contrato.
10.7.2. Com o término da vigência do contrato, observado o prazo previsto no subitem 10.1 acima, que poderá, independentemente da sua natureza, ser estendido em caso de ocorrência de sinistro.
11. VIGÊNCIA CONTRATUAL
11.1. O prazo de vigência do presente contrato é de 12 (doze) meses, a contar da data da sua assinatura, podendo este prazo ser prorrogado por iguais e sucessivos períodos, até o limite de 60 (sessenta) meses, conforme previsto no inciso II, art. 57, da Lei n 8.666/93.
11.2. Caso a licitante vencedora se recusar a assinar o contrato ou não cumprir as condições necessárias para sua assinatura, aplicar-se-á o previsto no artigo 7.º da lei n.º 10.520/2002 e será convocada a segunda classificada, intimando-se as demais participantes da fase de lances para que, em sessão pública, seja examinada a última oferta válida e verificada a aceitabilidade da proposta, sem prejuízo das sanções cabíveis, e assim, sucessivamente, até a apuração de uma proposta que atenda ao edital. O Pregoeiro poderá negociar para que seja obtido preço melhor, e, após, procederá à habilitação da licitante detentora da melhor oferta.
12. ENCERRAMENTO DO CONTRATO
12.1. Em caso de encerramento do contrato, deverão ser observados os seguintes procedimentos:
12.1.1. A CONTRATADA providenciará a devolução de quaisquer equipamentos disponibilizados a seus funcionários para exercício das atividades contratualmente estabelecidas.
12.1.2. A CONTRATADA deverá elaborar e executar um Plano de Transição, com transferência de tecnologia e técnicas empregadas, sem perda de informações, aos técnicos do MPPE ou do fornecedor de uma nova Solução de Tecnologia da Informação adquirida ao final da vigência da presente contratação.
12.1.2.1. O Plano de Transição deverá ser apresentado pela CONTRATADA 30 (trinta) dias antes do encerramento do contrato para aprovação da CONTRATANTE.
12.1.3. A CONTRATANTE promoverá a revogação de perfis de acesso de funcionários da CONTRATADA.
Equipe de Planejamento da Contratação
XXXXX XXXXX X. SANTOS Mat. 188.651-7
Integrante Técnico
RONILSON A. DE B. FIGUEIRÊDO Mat. 187.827-1
Integrante Administrativo
XXXXXXX XXXX X. XXXXXXX Xxx. 187.745-3
Coordenadoria Ministerial de Tecnologia da Informação (CMTI) Integrante Requisitante
XXXXXX XXXXX XXXXX XX XXXXX Xxx. 188.937-0
Integrante Técnico
ANEXO I CATÁLOGO DE SERVIÇOS
O Catálogo de Serviços foi concebido para contemplar todas as demandas associadas à execução dos Serviços de Sustentação e Desenvolvimento de Sistemas a partir dos processos de engenharia de software padrões.
Os Grupos de Serviços abaixo listados, previstos nesta contratação, visam proporcionar maior clareza e detalhamento sobre a natureza das atividades e seus requisitos a serem desempenhadas pela CONTRATADA e está associado aos serviços a serem executados pela CONTRATANTE.
1. Grupo de Serviços de Manutenção Corretiva
1.1. O serviço de manutenção corretiva compreende as atividades realizadas pela CONTRATADA com objetivo de manter os sistemas em seu estado normal de operação, prestando atendimento à equipe técnica do MPPE, investigando e tratando eventos relativos a erros, compreendendo no mínimo:
1.1.1. Correção de erros ou falhas provocadas pela implementação incorreta de funcionalidades, construção de rotinas para correção de imperfeições no sistema, quer seja da implementação das regras de negócio ou de correção de dados no banco de dados da solução, ou seja, recolocar o sistema em pleno estado de funcionamento, removendo definitivamente os defeitos apresentados, seja em rotinas “batch” ou “on-line”.
1.1.2. Correção de erros de integrações oriundos de falhas de comunicação com outros sistemas.
1.1.3. Execução de ações, proativas e/ou reativas, utilizando-se de coleta de dados estatísticos e indicadores de operação dos sistemas e de seus componentes.
1.2. A CONTRATADA deverá avaliar os erros abertos, acionando a equipe do MPPE para tomar as ações cabíveis, ou, quando aplicável, reestabelecer a operação dos sistemas, podendo solicitar para tal, operações de parada, de reinício, bem como verificar a disponibilidade dos sistemas.
1.3. Os serviços deverão contemplar a resolução de incidentes e problemas quanto a questões funcionais e técnicas relacionadas a instalação, configuração, suporte, customização e utilização dos sistemas.
1.4. A execução dos serviços de Manutenção Corretiva será demandada através dos chamados técnicos abertos na ferramenta indicada pelo MPPE e encaminhados para a fila de atendimento da CONTRATADA, considerando a complexidade, grupo de atividades e severidade do chamado.
1.5. Os chamados para os serviços de manutenção corretiva terão origem em decorrência de qualquer incidente detectado no tocante ao pleno estado de funcionamento dos sistemas,inclusive incidentes relacionados com instalação, configuração, otimização e atualização.
1.6. Os chamados serão classificados, conforme os seguintes níveis de severidade:
Nível | Descrição |
0 | Incidente que acarrete a paralisação total do sistema. |
1 | Incidente que acarrete paralisação de funcionalidades críticas do sistema ou comprometimento grave dedados, processos ou ambiente. |
2 | Incidente que acarrete paralisação parcial do sistema ou comprometimento mediano de dados, processos ouambiente. |
3 | Incidente sem paralisação do sistema e pequeno ou nenhum comprometimento de dados, processos ouambiente. |
1.7. A severidade do chamado será atribuída exclusivamente pelo MPPE no momento da aberturado chamado.
1.8. A resolução dos incidentes será composta por duas fases: análise/resolução do incidente sem codificação e correção de código:
1.8.1. A fase de análise/resolução do incidente sem codificação compreende a execução das seguintes atividades:
1.8.1.1. Identificar o incidente e validar a classificação determinada pelo MPPE.
1.8.1.2. Verificar e inserir, em sistema disponibilizado pelo MPPE, informações adicionais que não tenham sido previamente fornecidas pelo MPPE referentes ao correto grupo de atendimento, categoria, prioridade, impacto, urgência dentre outras informações.
1.8.1.3. Proceder com o atendimento após validação e complementação das informações.
1.8.1.4. Verificar e acompanhar os incidentes em relação às atividades de registro, atendimento, investigação, diagnóstico, escalonamento, qualidade das informações, dentre outros.
1.8.1.5. Notificar ao MPPE quaisquer anormalidades que possam causar impacto nas atividades.
1.8.1.6. Comunicar-se, quando necessário, com o solicitante, parceiro externo ou com o MPPE, de forma a obter informações decisórias necessárias e inerentes à busca da solução e/ou atendimento do incidente.
1.8.1.7. Realizar o diagnóstico dos incidentes previamente classificados e encaminhados para a equipe técnica pelo MPPE.
1.8.1.7.1. O diagnóstico deve contemplar a pesquisa em documentação disponibilizada pelo MPPE ou pelos fabricantes dos sistemas, dicionário de dados, bases de dados, avaliação de código, entre outros).
1.8.1.8. Executar aplicativos em ambiente de homologação para simulação do incidente.
1.8.1.9. Implementar soluções temporárias ou definitivas (parametrizações, configurações, intervenção em bases de dados, execução de scripts, orientação ao solicitante quanto às de regras e funcionalidades dos sistemas).
1.8.1.10. Verificar se as informações de documentação das atividades realizadas para o atendimento da demanda, desde a abertura desta, estão corretamente preenchidas.
1.8.1.11. Comunicar-se, quando necessário, com o usuário final da demanda de forma a tratar questões relativas à solução do incidente ou atendimento da requisição.
1.8.1.12. Realizar os devidos testes para confirmar que o incidente foi solucionado, atualizando o status do chamado para resolvido.
1.8.1.13. Encaminhar o chamado para a equipe técnica designada pelo MPPE como responsável pelo fechamento do chamado.
1.8.1.14. A resolução do incidente nessa fase se restringe à aplicação de solução que não exijam codificação de sistema.
1.8.1.15. Caso seja identificada necessidade de correção de código o chamado deverá ser pausado e a CONTRATADA deverá abrir um novo chamado em ferramenta disponibilizada pelo MPPE e encaminhar para resolução definitiva do incidente através de alteração do códigodo sistema.
1.8.1.15.1.O novo chamado deverá ser registrado com a mesma severidade e instruído com todasas evidências do incidente, como prints de telas, logs dos sistemas, gravação da operação do sistema no momento do incidente e demais informações coletadas.
1.8.1.16.O chamado referente ao incidente original deverá fazer referência ao chamado aberto para correção do código. Após implantação da versão com correção, a CONTRATADA deverá atualizar o status do chamado para resolvido e encaminhá-lo para a equipe técnica designada pelo MPPE como responsável pelo fechamento do chamado.
1.8.2. A fase de correção de código compreende a execução das seguintes atividades:
1.8.2.1. Realizar a correção dos erros previamente classificados e encaminhados para a equipe técnica obedecendo ao Modelo de Desenvolvimento de Software (MDS) indicado pelo MPPE, padrões de desenvolvimento definidos pelo MPPE e seus relacionamentos, metodologias de projeto, tecnologias, ferramentas e ambiente de desenvolvimento e infraestrutura utilizados pelo MPPE.
1.8.2.2. Executar aplicativos em ambiente de homologação para simulação do incidente.
1.8.2.3. Implementar soluções definitivas através de versões de sistemas para corrigir defeitos ou executar requisições de serviços.
1.8.2.4. Realizar os devidos testes para confirmar que o chamado encaminhado foi solucionado.
1.8.2.5. Documentar a solução adotada para a correção e atualizar os artefatos para distribuição de versão do sistema, quando necessário, de acordo com padrões estabelecidos pelo CONTRATANTE.
1.8.2.6. Implantar as versões com a correção em ambiente de produção.
1.8.2.7. Realizar o devido fechamento do chamado, observando se as informações básicas de identificação estão corretamente preenchidas, tais como: categoria, prioridade, impacto, urgência, dentre outras, bem como o preenchimento da documentação referente às atividades realizadas para o atendimento da demanda.
1.8.2.8. Comunicar a implantação da solução à equipe técnica responsável pela fase de análise/resolução do incidente para tratamento do chamado referente ao incidente original.
1.9. Caso a CONTRATADA identifique necessidade de execução de atividades em horário diverso do horário padrão decorrentes da execução dos Processos de Gerenciamento de Mudanças e Liberação e Gerenciamento de Incidentes, deverá comunicar formalmente ao MPPE, justificando a solicitação e propondo a abertura de uma Ordem de Serviço Extra.
1.9.1. Os serviços somente serão executados em horário diverso do padrão após aprovação de OS extraordinária pelo MPPE.
1.9.2. A critério do MPPE poderá ocorrer abertura prévia da OS extraordinária autorizando a execução de atividades previamente definidas que serão executadas sempre que ocorrerem determinados eventos descritos na respectiva Ordem de Serviço.
1.9.3. A CONTRATADA deverá registrar uma nova requisição de serviço, na Solução de Gerenciamento de Service Desk do MPPE, para cada tarefa demandada na Ordem de ServiçoExtra em execução e durante o período estabelecido na mesma, devendo ser discriminadas de forma resumida, na referida requisição de serviço, as ações e procedimentos executados. Deverá ser registrada uma requisição em cada dia para cada tarefa.
2. Grupo de Serviços de Apoio
2.1. Os serviços de Apoio compreendem as atividades realizadas pela Contratada com o objetivo de executar atividades de apoio a gestão, desenvolvimento e sustentação de sistemas. A CONTRATADA deverá executar no mínimo as atividades para esclarecimento de dúvidas, capacitação, configuração de parâmetros dos sistemas, configuração/implementação de fluxos utilizando metodologia BPM, elaboração de parecer técnico, análise de impacto, produção assistida, atualização/configuração de ferramentas de trabalho, desenvolvimento de geradores de código e implementação de integração contínua.
2.2. Estes serviços têm como objetivo principal fornecer o apoio necessário ao bom e desenvolvimento e funcionamento das soluções de TI.
2.3. As atividades definidas neste Anexo são meramente exemplificativas, considerando que a evolução dos serviços de TI necessários para o atendimento à sustentação e desenvolvimento de sistemas e consequente alteração no Modelo de Desenvolvimento de Software do MPPE são realizados de forma periódica e contínua.
2.4. Na vigência do Contrato, a CONTRATADA deverá a adaptar-se, no prazo de 30 (trinta) dias corridos, a partir da comunicação formal do MPPE, às eventuais alterações, inclusões e/ou exclusões de tipos de atividades, artefatos e complexidade mencionados neste Anexo.
2.5. O MPPE definirá em conjunto com a CONTRATADA outros artefatos que se façam necessários em função da especificidade da atividade a ser realizada em cada demanda solicitada.
2.6. As demandas referentes aos Serviços de Apoio Técnico serão abertas e gerenciadas nas através de chamados técnicos registrados nas ferramentas de gestão de demandas do MPPE.
2.7. Os artefatos deverão ser entregues e as atividades executadas registradas na ferramenta de gestão de demandas do MPPE.
2.8. Os chamados serão atribuídos à CONTRATADA considerando a atividade que será executada e sua complexidade.
2.9. Os prazos para início do atendimento e entrega das demandas serão acordados entre o MPPE e a CONTRATADA e registrados nos chamados técnicos para acompanhamento, sendo computados em dias úteis.
2.10. Esclarecimento de Dúvidas
2.10.1. Gerar informações sobre dúvidas quanto ao uso as regras de funcionamento de um sistema ou quaisquer outros esclarecimentos solicitados. No decorrer da execução da atividade pode ser necessária a realização de reuniões que esclareçam com detalhes o trabalho a ser realizado.
2.10.2. Possíveis Artefatos de Entrada: Chamado técnico com solicitação do demandante, bem como qualquer outro artefato disponível a ser analisado para gerar a informação solicitada.
2.10.3. Artefatos Gerados: Informação Técnica que contemple o esclarecimento das dúvidas relatadas no chamado técnico.
2.11. Capacitação
2.11.1. Capacitar colaboradores do MPPE, bem como usuários externos nos sistemas da Instituição.
2.11.2. Possíveis Artefatos de Entrada: Solicitação de capacitação com as informações referentes à ementa, carga horária, local, quantidade de participantes, material didático.
2.11.3. Artefatos Gerados: Relação de presença dos participantes, avaliação dos participantes, material didático produzido.
2.12. Configuração de Parâmetros dos Sistemas
2.12.1. Avaliar e implementar configurações e parametrizações em sistemas, considerando as regras de negócio e funcionalidades impactadas, bem como as atividades necessárias.
2.12.2. Possíveis Artefatos de Entrada: Chamado técnico com resultados esperados nas funcionalidades do sistema.
2.12.3. Artefatos Gerados: Documentação contendo a parametrização realizada e os resultados alcançados.
2.13. Configuração/Implementação de Fluxos Utilizando Metodologia BPM
2.13.1. Avaliar, propor, construir, homologar e implementar fluxos em sistemas utilizando metodologia BPM.
2.13.2. Possíveis Artefatos de Entrada: Descrição do objetivo do fluxo e dos resultados esperados.
2.13.3. Artefatos Gerados: Fluxo implantado, documentação técnica conforme padrão definido pelo MPPE e os resultados alcançados.
2.14. Elaboração de Parecer Técnico
2.14.1. Gerar informações técnicas sobre as regras de funcionamento de um sistema, forma de implementação das funcionalidades, fluxo de interação com o usuário, sua interação com outros sistemas, ou quaisquer outros esclarecimentos solicitados.
2.14.2. Possíveis Artefatos de Entrada: Descrição detalhada do objetivo do Parecer Técnico, resultados esperados que devem constar no parecer; como, por exemplo, a apresentação de cenários de solução para tomada de decisão, bem como qualquer outro artefato disponível a ser analisado para conclusão do parecer.
2.14.3. Artefatos Gerados: Parecer Técnico conforme template do MPPE e outras informações julgadas necessárias pelo MPPE e relatadas no início da demanda.
2.15. Executar Análise de Impacto
2.15.1. Avaliar uma solicitação de mudança em sistema ou componentes de software, com a finalidade de identificar os artefatos afetados pela mudança, avaliar o impacto da mudança nos artefatos, os riscos envolvidos e gerar a estimativa para o desenvolvimento e implementação da mudança.
2.15.2. Possíveis Artefatos de Entrada: Documento de análise de impacto, conforme template do MPPE, descrição detalhada do objetivo da Análise de Impacto, resultados esperados e que devem constar na análise de impacto.
2.15.3. Artefatos Gerados: Documento de análise de impacto estimativa de esforço em Unidades de Serviço Técnico, outras informações julgadas necessárias pelo MPPE relatadas no início da demanda.
2.16. Acompanhamento e Produção Assistida
2.16.1. Acompanhar e/ou realizar a execução de um componente de software a fim de garantir sua correta execução. Conferir o resultado do processamento e atestar a conclusão do processamento por meio de consultas a banco de dados, logs de auditoria ou outras informações que comprovem o sucesso da execução. O componente de software pode ser uma funcionalidade de sistema, um script de banco de dados, uma rotina batch ou um programa que tenha início e fim bem definidos.
2.16.2. Possíveis Artefatos de Entrada: Descrição da necessidade, código a ser executado, banco de dados a ser consultado para conferência e outras informações consideradas importantes.
2.16.3. Artefatos Gerados: Relatório com as informações de funcionalidades e rotinas testadas, logs comprovando a correta execução do software e outras informações julgadas necessárias pelo MPPE relatadas no início da demanda.
2.17. Atualização/Configuração de Ferramentas de Trabalho
2.17.1. Atualizar versão, instalar componentes e plugins em ferramentas de trabalho (Redmine, Jira, MediaWiki, Sonar, TestLink ou outra ferramenta utilizada pelo MPPE baseadas em software livre).
2.17.2. Possíveis Artefatos de Entrada: Sistema e versão atual, objetivo da atualização / configuração a ser realizada, descrição da versão do software/plugin a ser atualizado/instalado, informação do ambiente a ser realizada a atualização/configuração (caso seja um ambiente de homologação este deve ser um clone de produção) e outras informações consideradas importantes.
2.17.3. Artefatos Gerados: Plano de Implantação para atualização / configuração do sistema no ambiente informado, scripts de migração de banco de dados, caso necessários e outras informações julgadas necessárias pelo MPPE e relatadas no início da demanda.
2.18. Elaboração de Documento de Visão
2.19. Elaborar de Documento de Visão com contendo levantamento de funcionalidades. Com participações em reuniões, entrevistas com os usuários e levantamento das principais funcionalidades do sistema de acordo com as necessidades do usuário.
2.20. Artefatos Gerados: Relatório de Prestação de Serviço, Documento de Visão, atas de reuniões eestimativa de prazo, Fluxo de Processo de Negócio em notação BPMN, com a possibilidade de produção de artefatos extras conforme a necessidade da Elaboração de Documento de Visão.
3. Grupo de Serviços de Desenvolvimento
3.1. O serviço compreende atividades realizadas pela Contratada com o objetivo de desenvolvimento e manutenção de sistemas, incluindo as atividades de análise de negócio, levantamento de requisitos, análise de sistemas, projeto, implementação, testes, implantaçãode sistemas e migração/manutenção de dados a partir de especificações estabelecidas pelo MPPE para novos sistemas ou em sistemas legados, cedidos ou adquiridos, compreendendo no mínimo:
3.1.1. Serviços de Manutenção Evolutiva que corresponde a inclusão, alteração e exclusão de características e/ou funcionalidades em aplicações em produção, decorrentes de alterações de regras de negócio e/ou demandas legais.
3.1.2. Serviços de Manutenção Adaptativa que corresponde a adequação de aplicações às mudanças de ambiente operacional, compreendendo infraestrutura e serviços básicos, mudanças de versão, linguagem e sistema gerenciador de banco de dados (SGBD), mudanças de versão de navegadores web, melhoria de performance, entre outros.
3.2. A entrega deverá estar em conformidade com a versão do Modelo de Desenvolvimento de Software (MDS) indicado pelo MPPE e padrões de desenvolvimento definidos pelo MPPE. Faz parte ainda do projeto de desenvolvimento a migração ou carga inicial de dados em sistemas.
3.2.1. O MPPE poderá, a seu critério, alterar a exigência de conformidade com o MDS vigente do MPPE, devendo a CONTRATADA adequar-se no prazo máximo de 15 (quinze) dias.
3.3. A execução dos serviços de Manutenção e Desenvolvimento serão demandados através dos chamados técnicos abertos na ferramenta indicada pelo MPPE e encaminhados para a fila de atendimento da Contratada, considerando a complexidade e grupo de atividades.
3.4. Os chamados poderão conter a solicitação do ciclo completo para desenvolvimento de uma demanda ou somente uma fase específica.
3.5. O prazo estimado para atendimento da demanda será acordado entre o MPPE e a CONTRATADA e registrado no chamado técnico, considerando os seguintes fatores:
3.5.1. Backlog de demandas em execução pela CONTRATADA
3.5.2. Nos casos em que a demanda estiver aguardando uma ação do MPPE, como, por exemplo, verificação de artefatos, o prazo de execução do chamado ficará suspenso pela quantidade de dias despendido na realização da demanda.
3.6. No final do atendimento do chamado, a CONTRATADA deverá providenciar a entrega formal, em repositório definido pelo MPPE, de todos os artefatos produzidos ou atualizados de acordo com o especificado no chamado
3.7. Para permitir melhor controle das atividades executadas durante a execução da demanda, poderão ser abertos chamados específicos para atividades relacionadas à demanda principal (subtarefas). Os chamados “filhos” deverão ser associados ao chamado principal.
3.7.1. O MPPE definirá os tipos de chamados, documentação de entrada e produtos gerados para cada atividade do ciclo de desenvolvimento da demanda.
3.8. A abertura dos chamados técnicos e a priorização da execução dos serviços deverá ser determinada pelo MPPE.
4. Garantia dos Serviços
4.1.1. A CONTRATADA garantirá os serviços realizados durante toda a vigência do contrato.
4.1.2. A CONTRATADA se obriga a corrigir quaisquer defeitos nos serviços entregues no período de vigência do contrato, sem ônus para o MPPE. Os defeitos compreendem, mas não se limitam,as imperfeições percebidas no serviço, ausência de artefato de documentação obrigatório e qualquer outra ocorrência que impeça o seu funcionamento normal.
4.1.3. Tais defeitos poderão ser apurados pelo MPPE ainda que tenham sido faturados e pagos sem nenhuma restrição. Sendo assim, ressalte-se que a fatura aceita não é documento de garantia de qualidade.
4.1.4. Esta garantia abrange toda correção decorrente dos erros ou falhas cometidas na execução dos serviços contratados e/ou decorrentes de integração e adequação sistêmica, desde que, comprovadamente, não tenham se dado em razão das especificações feitas pelo MPPE.
4.1.5. Deverão ser observadas pela CONTRATADA todas as garantias previstas neste documento e respectivo contrato. O não cumprimento das condições estabelecidas sujeitará a CONTRATADA a penalidades.
4.1.6. Os erros identificados em ambiente de produção, mesmo que ocasionados pelo ambiente computacional, estarão cobertos pela garantia.
4.1.7. Os erros identificados apenas em ambiente de produção, mesmo quando não apresentados em ambiente de testes e homologação estarão cobertos pela garantia.
4.1.8. Toda manutenção coberta por garantia deverá ser solicitada através de uma Ordem de Serviço obrigando-se a CONTRATADA a sanar os erros ou inconsistência apontados.
5. Glossário
Ambiente é o conjunto de componentes de software (software básico, software servidor, ferramentas, runtimes e afins) instalados, configurados e integrados, em certa configuração de hardware, no qual determinado sistema ou aplicação opera, para uma finalidade durante seu ciclo de vida como desenvolvimento, teste, homologação, treinamento, produção, suporte e afins.
Arquivo lógico referenciado é um grupo de dados ou informações de controle logicamente relacionados, reconhecido pelo usuário, lido e/ou mantido por uma função transacional, podendo ser um arquivo lógico interno (ALI) ou arquivo de interface externa (AIE), conforme Manual de Práticas de Contagem de Pontos de Função (CPM) versão 4.3.1 do IFPUG.
Plano de Teste (charter) de teste é um breve documento de preparação para um teste exploratório; declara objeto, missão e escopo de uma sessão de teste, limites de tempo (time box) e área(s) de concentração, podendo incluir também referência a eventuais requisitos e documentos existentes relacionados ao objeto e possíveis ideias e observações sobre a realização do teste; tudo de forma sucinta em tópicos simples (tipicamente 1 ou 2 linhas de texto, cada).
Caso de teste é um conjunto de pré-condições de execução, entradas (valores e ações) e resultados esperados, elaborados para guiar a execução a alcançar o(s) objetivo(s) do teste, tais como para exercitar o caminho de um determinado programa ou verificar o atendimento a um requisito específico. Referências: norma ABNT NBR ISO/IEC/IEEE 29119-1:2014 (Teste de software, Parte 1: Conceitos e definições) e Glossário Padrão de Termos de Teste de Software do ISTQB/BSTQB v3.1br Foundation.
Código-fonte é um conjunto de itens de configuração de software versionado contendo instruções computacionais e definições de dados em formato próprio (linguagem de programação, sintaxe ou estrutura específica) para entrada em um compilador, interpretador, analisador (parser), montador ou mecanismo similar, incluindo: telas, formulários, relatórios e modelos; classes, interfaces, pacotes/módulos/unidades, bibliotecas etc.; scripts SQL, procedimentos armazenados (Oracle PL/SQL, PL/pgSQL), JavaScript, CSS, Shell etc.; arquivos de recurso, de mapeamento e de configuração; e afins. O código fonte deve ter sintaxe correta, ser adequadamente comentado para plena compreensão, obedecer a padrões e convenções de codificação estabelecidas, ser incorporado a projeto compilável e executável, e ser devidamente versionado em repositório.
Componente arquitetural é o resultado de uma ou mais decisões de como implementar parte(s) de um sistema. Tanto o mecanismo quanto a lógica de funcionamento, seja do ponto de vista conceitual
quanto qualquer escolha de como implementá-lo, constituem um componente arquitetural. A arquitetura de um sistema é composta pela sinergia de todos os seus componentes arquiteturais subjacentes. As decisões de implementação avaliam o custo benefício baseando-se em critérios técnicos, financeiros, pessoais, políticos, sociais, organizacionais, culturais e outros. Os critérios técnicos geralmente são associados a características de qualidade do produto de software conforme norma ISO/IEC 25010.
Processo elementar é a menor unidade de atividade significativa para o usuário, completa e que deixa o negócio da aplicação em um estado consistente, conforme Manual de Práticas de Contagem de Pontos de Função (CPM) versão 4.3.1 do IFPUG.
Requisito é a representação documentada que traduz ou expressa uma condição ou capacidade que deve estar presente (atingida ou possuída) no sistema, para resolver um problema ou alcançar um objetivo. O conjunto de requisitos define o que o produto de software faz para seus usuários, e quais restrições ou imposições formais ele deve satisfazer nesse contexto. Referências: norma ISO/IEC/IEEE 24765:2017 (Vocabulário de engenharia de sistemas e software) e livro Mastering Requirements Processes, 3rd edition, Xxxxxxxxx e Xxxxxxxxx.
Revisar compreende analisar Os itens (tarefas) do Catálogo de Serviços estão organizados em seções que buscam agrupar tipos de serviços correlatos, orientados a disciplinas típicas de um processo de software. Cada item é identificado por um número único no formato seção.sequencial e por uma oração descritiva da tarefa.
Unidade de medida define o referencial de grandeza adotado para multiplicar o quantitativo unitário de UST de uma tarefa ou variação desta, necessária para atender determinada demanda.
Teste de aceitação deve permitir comparação entre os requisitos especificados para o sistema e as necessidades dos usuários finais. A especificação de um teste de aceitação deve conceber casos de teste com o intuito de demonstrar que o sistema não atende aos requisitos especificados, e se esses casos de teste forem malsucedidos o sistema pode ser aceito. Geralmente são executados pelos usuários finais do sistema. Referências: norma ISO/IEC/IEEE 24765:2017 (Vocabulário de engenharia de sistemas e software) e livro The Art of Software Testing, 2rd edition, Xxxxxxxx X.Myers.
6. CATÁLOGO DE SERVIÇOS
6.1. O Catálogo de serviços descreve o conjunto de tarefas elencadas e produtos previstos considerando as atividades comumente realizadas dentro das disciplinas de engenharia de software e boas práticas de construção de soluções.
6.2. Cada tarefa atribui um perfil profissional requerido para executá-la. Algumas tarefas possibilitam mais de um perfil profissional.
6.3. As métricas de esforço previstas e associadas às atividades foram considerados com base em boas práticas de construção de soluções e em análises internas ao MPPE, considerando, entre outros fatores, a arquitetura tecnológica elencada, os benchmarks de produtividade associadas às pilhas tecnológicas dos produtos e as especificidades do catálogo de aplicações legadas.
6.4. Devido à constante mudança tecnológica e a diversidade de serviços de TI existentes, o rol das atividades descritas no catálogo não é exaustivo, podendo este catálogo ser alterado em função das necessidades do MPPE. Portando, ao longo da execução do contrato, este catálogo de serviços poderá ser ajustado visando prever atividades complementares ao processo de construção e gestão de soluções inicialmente não contempladas.
6.5. O benchmark de dimensionamento das atividades abaixo descritas será utilizado para fins de mensuração do esforço previsto para execução dos serviços pela CONTRATADA e entrega de produtos planejados dentro do ciclo de construção e sustentação de soluções. Eventualmente, a CONTRATANTE poderá utilizar outros critérios para mensuração e dimensionamento do esforço dos trabalhos previstos visando sempre à otimização dos trabalhos realizados pela CONTRATADA.
6.6. De modo geral, todas as tarefas possuem como padrão o nível de complexidade “C2 (Multiplicador: 1,00) – Complexidade Padrão”.
6.7. Os fatores de complexidade poderão ser aplicados em função de cada demanda específica, sendo o nível de complexidade (C1, C2, C3 e C4) das tarefas estabelecido nas Ordens de Serviço em função de cada demanda específica.
6.8. A critério da CONTRATANTE, para cenários em que não é adequado o detalhamento das demandas, poderão ser estabelecidos pacotes de trabalho, medidos em UST, contemplando um conjunto extensivo de atividades e serviços a serem executados pela CONTRATADA, sempre visando a uma implementação efetiva das demandas e à otimização do orçamento da contratação.
ÁREA | CÓDIGO | TAREFA |
Encontro | ENC01 | Reuniões da metodologia ágil |
Encontro | ENC02 | Reuniões com a CONTRATANTE |
Encontro | ENC03 | Ministrar workshop ou treinamento |
Encontro | ENC04 | Acompanhamento do Scrum Master/Líder do Projeto |
Encontro | ENC05 | Implantar Processo de Software |
Estudo | EST01 | Estudos para realização do trabalho de ideação de sistema |
Estudo | EST02 | Elaborar parecer técnico, análises e diagnósticos |
Estudo | EST03 | Mapear processo via diagrama BPMN |
Estudo | EST04 | Elaborar documento de visão de sistema |
Estudo | EST05 | Elaborar documento arquitetural do sistema |
Estudo | EST06 | Elaboração de plano de trabalho para atividades demandas por solicitação de serviço |
Estudo | EST07 | Elaboração do Planejamento do Produto |
Estudo | EST08 | Elaborar Relatórios Gerais |
História | HIST01 | Realizar o entendimento, refinamento, escrita e validação de história de usuário |
História | HIST02 | Especificar Regras de negócio e Regras de Validação |
História | HIST03 | Atualizar backlog do produto |
História | HIST04 | Elaborar backlog da Sprint |
História | HIST05 | Realizar elicitação e Análise de Requisitos |
ÁREA | CÓDIGO | TAREFA |
Protótipo | PROT01 | Desenvolver protótipo de baixa ou média fidelidade |
Protótipo | PROT02 | Desenvolver protótipo navegável de alta fidelidade |
Protótipo | PROT03 | Elaboração de tela (html/css) |
Protótipo | PROT04 | Alteração pontual em tela (html/css) existente |
Dado | DADO01 | Avaliar e elaborar modelo de dados lógico e requisitos para modelo de dados físico |
Dado | DADO02 | Escrever script para criação ou alteração de Arquivo lógico referenciado (tabela ou view) |
Dado | DADO03 | Escrever script para população de tabela fato que não seja realizada pela aplicação |
Dado | DADO04 | Escrever scripts para automação de carga ou extração de dados |
Código | COD01 | Implementar código fonte – front-end e/ou back-end |
Código | COD02 | Implementar testes unitários – front-end e back-end |
Código | COD03 | Implementar processo elementar implícito |
Código | COD04 | Incluir ou alterar elemento de interface com usuário |
Código | COD05 | Inspecionar código-fonte de sistema em sustentação |
Código | COD06 | Refactoring de Aplicações |
Arquitetura | ARQ01 | Elaborar desenho e arquitetura de solução e componentes arquiteturais |
Arquitetura | ARQ02 | Apoiar as equipes na estruturação de ambientes |
Teste | TESTE01 | Planejar testes e testar história de usuário |
Teste | TESTE02 | Realizar teste exploratório |
Teste | TESTE03 | Implementar Testes Automatizados |
Versão | VER01 | Gerar ambiente para entrega de versão |
Versão | VER02 | Implantar componente arquitetural |
Versão | VER03 | Gerar build da aplicação |
Versão | VER04 | Gerar script de banco de dados para publicação de versão |
Versão | VER05 | Elaborar documentação de procedimentos para publicação de versão |
Versão | VER06 | Configurar sistema e ambientes |
Versão | VER07 | Realizar deploy de sistema |
Apoio | AP01 | Apoiar a resolução de incidentes (chamados) |
Apoio | AP02 | Apoiar a resolução de incidentes de infraestrutura (chamados) |
Manual | MAN01 | Elaborar manual de usuário em formato de texto e imagens |
Manual | MAN02 | Elaborar manual de usuário em formato de vídeo e narração |
Paineis de Informação | PBI01 | Elaborar Protótipos de Paineis de Informação |
Paineis de Informação | PBI02 | Implementar Painéis de Informação |
DETALHAMENTO DO CATÁLOGO DE SERVIÇOS
CÓDIGO | ENC01 |
ÁREA | Encontro |
TAREFA | Reuniões da metodologia ágil |
PRODUTO | Ata de reunião ou relatório |
PERFIL PROFISSIONAL | Todos os perfis profissionais |
UNIDADE DE MEDIDA | Hora de reunião por participante da CONTRATADA |
UST | 1 |
ORIENTAÇÕES ADICIONAIS | Esta tarefa contempla todas as reuniões definidas na forma de trabalho acordada entre CONTRATANTE e CONTRATADA e na Metodologia de Desenvolvimento de Software |
CÓDIGO | ENC02 |
ÁREA | Encontro |
TAREFA | Reuniões com a CONTRATANTE |
PRODUTO | Ata de reunião ou relatório |
PERFIL PROFISSIONAL | Todos os perfis profissionais |
UNIDADE DE MEDIDA | Hora de reunião por participante da CONTRATADA |
UST | 1 |
ORIENTAÇÕES ADICIONAIS | Reuniões entre a CONTRATADA e a CONTRATANTE para realizar levantamentos de regras de negócios ou requisitos de sistema |
CÓDIGO | ENC03 |
ÁREA | Encontro |
TAREFA | Ministrar workshop ou treinamento |
PRODUTO | Ata de reunião ou relatório |
PERFIL PROFISSIONAL | Todos os perfis profissionais |
UNIDADE DE MEDIDA | Hora de treinamento por instrutor da CONTRATADA |
UST | 1 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | ENC04 |
ÁREA | Encontro |
TAREFA | Acompanhamento do Scrum Master/Líder do Projeto |
PRODUTO | Ata de reunião ou relatório |
PERFIL PROFISSIONAL | Scrum Master e/ou Líder do Projeto |
UNIDADE DE MEDIDA | Uma cobrança a cada Sprint |
UST | 24 |
ORIENTAÇÕES ADICIONAIS | Acompanhamento do Scrum Master envolvendo preparação e condução de ritos, resolução de impedimentos, atualização de métricas de acompanhamento e demais atividades correlatas |
CÓDIGO | ENC05 |
ÁREA | Encontro |
TAREFA | Implantar Processo de Software |
PRODUTO | MDS atualizado e implantado na CMTI/ Equipes Treinadas |
PERFIL PROFISSIONAL | Agile Coach |
UNIDADE DE MEDIDA | Único |
UST | 24 |
ORIENTAÇÕES ADICIONAIS | Implantar Processo de Software (Modelo de Desenvolvimento de Software - MDS) atualizado com as melhores práticas de gerenciamento e desenvolvimento ágil na Coordenadoria Ministerial de Tecnologia da Informação (CMTI) a partir de consultoria para organização das equipes internas e contratadas, bem como realização de sessões de Coach e desenvolvimento de equipes. Esta atividade inclui também a implantação e parametrização de ferramentas e artefatos do processo. |
CÓDIGO | EST01 |
ÁREA | Estudo |
TAREFA | Estudos para realização do trabalho de ideação de sistema |
PRODUTO | Documentação referente ao estudo realizado, incluindo planilhas, mapas mentais e regras que apoiem a criação da documentação e manutenção de sistema. |
PERFIL PROFISSIONAL | Todos os perfis |
UNIDADE DE MEDIDA | Hora de Estudo |
UST | 1 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | EST02 |
ÁREA | Estudo |
XXXXXX | Xxxxxxxx parecer técnico, análises e diagnósticos |
PRODUTO | Documentação relacionada ao parecer técnico, incluindo relatórios e produções de conhecimento associadas. |
PERFIL PROFISSIONAL | A definir na abertura da ordem de serviço |
UNIDADE DE MEDIDA | Carga-horária |
UST | 1 por hora de trabalho. |
ORIENTAÇÕES ADICIONAIS | Realização de atividades de diagnósticos sobre ambientes, serviços e aplicações visando à identificação de situações específicas demandadas pelo MPPE, tais como identificação de erros, avaliação de melhorias, avaliações técnicas, análise de desempenho, entre outros |
CÓDIGO | EST03 |
ÁREA | Estudo |
TAREFA | Mapear processo via diagrama BPMN |
PRODUTO | Documento de mapeamento de processo |
PERFIL PROFISSIONAL | Projetista/Desenvolvedor BPM e/ou Analista de Requisitos |
UNIDADE DE MEDIDA | Processo mapeado |
UST | 16 |
ORIENTAÇÕES ADICIONAIS | Os artefatos de mapeamento do processo devem contemplar todos os elementos necessários para um entendimento efetivo sobre o processo. |
CÓDIGO | EST04 |
ÁREA | Estudo |
TAREFA | Elaborar documento de visão de sistema |
PRODUTO | Documento de Visão do Sistema |
PERFIL PROFISSIONAL | Analista de Requisitos/Product Owner |
UNIDADE DE MEDIDA | Macroprocesso mapeado |
UST | 5 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | EST05 |
ÁREA | Estudo |
TAREFA | Elaborar documento arquitetural do sistema |
PRODUTO | Documento de Visão do Sistema |
PERFIL PROFISSIONAL | Arquiteto de Soluções |
UNIDADE DE MEDIDA | Componente arquitetural/módulo de sistema |
UST | 5 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | EST06 | ||
ÁREA | Estudo | ||
TAREFA | Elaboração de plano de trabalho para atividades demandas por solicitação de serviço | ||
PRODUTO | Plano de Trabalho | ||
PERFIL PROFISSIONAL | Analista de Sistemas | ||
UNIDADE DE MEDIDA | Quantidade de USTs estimadas no plano de trabalho homologado pelo fiscal técnico. | ||
UST | Variável em função da Complexidade | ||
ORIENTAÇÕES ADICIONAIS | COMPLEXIDADE DESCRIÇÃO DA UST COMPLEXIDADE | ||
Baixa Até 80 USTs 2 Normal Mais de 80 até 160 USTs 4 Mediana Mais de 160 até 320 USTs 8 |
CÓDIGO | EST07 |
ÁREA | Estudo |
TAREFA | Elaborar do Planejamento do Produto |
PRODUTO | Documento no formato de Documento de Abertura do Projeto |
PERFIL PROFISSIONAL | Gerente do Projeto/ Analista de Requisitos/ Analista de Sistemas |
UNIDADE DE MEDIDA | Quantidade de USTs estimadas no plano de trabalho homologado pelo fiscal técnico. |
UST | 12 |
ORIENTAÇÕES ADICIONAIS | Descrever a visão do produto, o mapeamento geral do(s) processo(s) de negócio, os marcos, as grandes entregas ou etapas do produto, os envolvidos no projeto, a equipe de desenvolvimento, os riscos, o custo e um cronograma inicial |
CÓDIGO | EST08 |
ÁREA | Estudo |
TAREFA | Elaborar Relatórios Gerais |
PRODUTO | Documento no formato de Documento de Abertura do Projeto |
PERFIL PROFISSIONAL | A ser definido pelo MPPE. |
UNIDADE DE MEDIDA | Hora de Trabalho |
UST | 1 UST por hora de trabalho |
ORIENTAÇÕES ADICIONAIS | Descrever o trabalho realizado, o que foi entregue, termos de encerramento de projeto, lições aprendidas, considerações para melhoria do processo e possíveis considerações sobre o produto entregue, bem como produção de informações gerais demandas pelo MPPE |
CÓDIGO | HIST01 |
ÁREA | História |
TAREFA | Realizar o entendimento, refinamento, escrita e validação de história de usuário |
PRODUTO | História de usuário/Epics de backlog do produto registradas e priorizadas na ferramenta institucional de gestão de projetos |
PERFIL PROFISSIONAL | Analista de Requisitos/Product Owner/ Analista de sistemas |
UNIDADE DE MEDIDA | História de usuário |
UST | 2 |
ORIENTAÇÕES ADICIONAIS | Com base nas informações iniciais de requisitos e funcionalidades levantadas pela atividade de análise, e registradas por meio das histórias de usuário, elencar as histórias necessárias para implementação das funcionalidades no sistema |
CÓDIGO | HIST02 |
ÁREA | História |
TAREFA | Especificar Regras de negócio e Regras de Validação |
PRODUTO | História de usuário |
PERFIL PROFISSIONAL | Analista de Requisitos/Product Owner/ Analista de sistemas |
UNIDADE DE MEDIDA | Regra de negócio ou Regra de validação |
UST | 2 |
ORIENTAÇÕES ADICIONAIS | Especificação de funcionalidade por meio de História do Usuário (user story) ou Epics, contemplando também a descrição textual de funcionalidade, regras e comportamentos. |
CÓDIGO | HIST03 |
ÁREA | História |
TAREFA | Atualizar backlog do produto |
PRODUTO | História/Epics de backlog do produto atualizadas e priorizadas na ferramenta institucional de gestão de projetos |
PERFIL PROFISSIONAL | Analista de Requisitos/Product Owner/ Analista de sistemas |
UNIDADE DE MEDIDA | História de usuário |
UST | 1 |
ORIENTAÇÕES ADICIONAIS | Revisão dos requisitos e funcionalidades levantadas inicialmente devido a mudanças nas condições do negócio ou melhor entendimento sobre o produto. Dessa forma serão revistas as histórias de usuário contidas no backlog do produto e repriorizadas |
CÓDIGO | HIST04 |
ÁREA | História |
TAREFA | Elaborar backlog da Sprint |
PRODUTO | Tarefas da Sprint registradas e priorizadas na ferramenta de gestão de projetos do MPPE |
PERFIL PROFISSIONAL | Scrum Master/Product Owner |
UNIDADE DE MEDIDA | História de Usuário |
UST | 2 |
ORIENTAÇÕES ADICIONAIS | Com base no backlog do produto cadastrado, durante o planejamento da Sprint (Sprint Planning), priorizar e aprovar as tarefas que serão desenvolvidas durante a Sprint. Essa atividade é recorrente a cada ciclo iterativo conhecido como Sprint. |
CÓDIGO | HIST05 |
ÁREA | História |
TAREFA | Realizar elicitação e Análise de Requisitos |
PRODUTO | Documento de Requisitos e suas alterações |
PERFIL PROFISSIONAL | Analista de Requisitos/ Analista de Sistemas |
UNIDADE DE MEDIDA | Por função, atividade ou processo de trabalho. Discricionário ao MPPE |
UST | 1 a 3 |
ORIENTAÇÕES ADICIONAIS | Levantamento, mapeamento e análise de requisitos funcionais e não funcionais de sistemas, tanto para o desenvolvimento de novos produtos quanto para manutenção de sistemas legados. |
CÓDIGO | PROT01 |
ÁREA | Protótipo |
TAREFA | Desenvolver protótipo de baixa ou média fidelidade |
PRODUTO | Tela de protótipo |
PERFIL PROFISSIONAL | Analista de UX |
UNIDADE DE MEDIDA | Tela de protótipo |
UST | 4 |
ORIENTAÇÕES ADICIONAIS | Esse serviço deve ser preferencialmente produzido por meio da ferramenta de design digital Sketch. O formato original do arquivo padrão na ferramenta Sketch, se for o caso, ou o mesmo arquivo exportado em outros formatos podem ser requeridos. |
CÓDIGO | PROT02 |
ÁREA | Protótipo |
TAREFA | Desenvolver protótipo navegável de alta fidelidade |
PRODUTO | Tela de protótipo |
PERFIL PROFISSIONAL | Analista de UX |
UNIDADE DE MEDIDA | Tela de protótipo |
UST | 6 |
ORIENTAÇÕES ADICIONAIS | Esse serviço deve ser preferencialmente produzido por meio da ferramenta de design digital Sketch. O formato original do arquivo padrão na ferramenta Sketch, se for o caso, ou o mesmo arquivo exportado em outros formatos podem ser requeridos. |
CÓDIGO | PROT03 |
ÁREA | Protótipo |
TAREFA | Elaboração de tela (html/css) |
PRODUTO | Código da implementação incorporado ao sistema e adicionado ao repositório, ou sistema de controle de versão |
PERFIL PROFISSIONAL | ANALISTA UX |
UNIDADE DE MEDIDA | Tela de protótipo |
UST | 4 |
ORIENTAÇÕES ADICIONAIS | Criação de estrutura inicial completa (tela), aplicação de estilos e organização dos componentes visuais estáticos de tela com base em protótipo. |
CÓDIGO | PROT04 |
ÁREA | Protótipo |
TAREFA | Alteração pontual em tela (html/css) existente |
PRODUTO | Código da implementação incorporado ao sistema e adicionado ao repositório, ou sistema de controle de versão |
PERFIL PROFISSIONAL | ANALISTA UX |
UNIDADE DE MEDIDA | Tela |
UST | 1 |
ORIENTAÇÕES ADICIONAIS | Criação de estrutura inicial completa (tela), aplicação de estilos e organização dos componentes visuais estáticos de tela com base em protótipo. |
CÓDIGO | DADO01 |
ÁREA | Dado |
TAREFA | Avaliar e elaborar modelo de dados lógico e requisitos para modelo de dados físico |
PRODUTO | Modelo de dados. Arquivo em formatos editáveis em ferramentas case específicas. Contendo diagrama de Classes em padrão UML ou diagrama equivalente como Diagrama de Entidade Relacionamento DER que descreva as entidades do sistema e seus relacionamentos |
PERFIL PROFISSIONAL | Analista de sistemas/ Administrador de Dados/ Desenvolvedor |
UNIDADE DE MEDIDA | Arquivo lógico referenciado (tabela ou view) |
UST | 1 por classe ou processo de trabalho |
ORIENTAÇÕES ADICIONAIS | Deverão incluir informações relativas a atributos, relacionamentos, chaves, índices e qualquer outra necessidade de validação para geração da entidade no modelo de dados da aplicação – relacional ou não relacional |
CÓDIGO | DADO02 |
ÁREA | Dado |
TAREFA | Escrever script para criação ou alteração de Arquivo lógico referenciado (tabela ou view) |
PRODUTO | Scripts |
PERFIL PROFISSIONAL | Analista de sistemas/ Administrador de Dados/ Desenvolvedor |
UNIDADE DE MEDIDA | Arquivo lógico referenciado (tabela ou view) |
UST | 2 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | DADO03 |
ÁREA | Dado |
XXXXXX | Xxxxxxxx script para população de tabela fato que não seja realizada pela aplicação |
PRODUTO | Scripts |
PERFIL PROFISSIONAL | Analista de sistemas/ Administrador de Dados/ Desenvolvedor |
UNIDADE DE MEDIDA | Tabela populada (preenchida) |
UST | 2 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | DADO04 |
ÁREA | Dado |
TAREFA | Escrever scripts para automação de carga ou extração de dados |
PRODUTO | Scripts |
PERFIL PROFISSIONAL | Analista de sistemas/ Administrador de Dados/ Desenvolvedor |
UNIDADE DE MEDIDA | Tabela populada (preenchida) |
UST | 2 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | COD01 |
ÁREA | Código |
TAREFA | Implementar código fonte – front-end e/ou back-end |
PRODUTO | Código da implementação incorporado ao sistema e adicionado ao repositório, ou sistema de controle de versão |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Processo elementar principal |
UST | 12 |
ORIENTAÇÕES ADICIONAIS | Para o caso de alteração de funcionalidade no lado servidor, incluindo manutenções corretivas ou evolutivas, será previsto o total de até 6 UST por processo elementar principal. Para o caso de alteração de funcionalidade no lado cliente, exemplo: caixa de diálogo em JavaScript, , incluindo manutenções corretivas ou evolutivas, será previsto o total de até 6 UST por processo elementar principal. |
CÓDIGO | COD02 |
ÁREA | Código |
TAREFA | Implementar testes unitários – front-end e back-end |
PRODUTO | Código da implementação incorporado ao sistema e adicionado ao repositório, ou sistema de controle de versão |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Processo elementar principal |
UST | 10 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | COD03 |
ÁREA | Código |
TAREFA | Implementar processo elementar implícito |
PRODUTO | Código-fonte e demais artefatos previstos na implementação. |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Processo elementar implícito |
UST | 6 |
ORIENTAÇÕES ADICIONAIS | Deve haver cobrança associada a processos elementares implícitos, como regras de negócios complexas, dropdowns, cálculos matemáticos e outras estruturas não mapeadas em processos elementares principais. Processos elementares implícitos já codificados no projeto não devem ser cobrados novamente. |
12
CÓDIGO | COD04 |
ÁREA | Código |
TAREFA | Incluir ou alterar elemento de interface com usuário |
PRODUTO | Código-fonte e demais artefatos previstos na implementação |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Processo elementar principal |
UST | 1 |
ORIENTAÇÕES ADICIONAIS | Utilizado para mudanças simples como trocas de rótulos, padrões visuais básicos, acertos de termos ou mensagens |
CÓDIGO | COD05 |
ÁREA | Código |
TAREFA | Inspecionar código-fonte de sistema em sustentação |
PRODUTO | Desenvolvedor |
PERFIL PROFISSIONAL | Processo elementar principal |
UNIDADE DE MEDIDA | Tarefa de sustentação que necessite de inspeção do código para sua realização |
UST | 3 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | COD06 |
ÁREA | Código |
TAREFA | Refactoring de Aplicações |
PRODUTO | Descrição e registro da atividade realizada na tarefa, no caso de se tratar de desenvolvimento interno, se não for o caso, o registro deve ser negociado. Código-fonte dos produtos refatorados. |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Módulo de Aplicação |
UST | 18 |
ORIENTAÇÕES ADICIONAIS | Inclui trabalho completo de refactoring, alteração e evolução de aplicações, componentização e transformação de aplicações em serviços, dockerização de aplicações, criação de scripts para migração de serviços para o paradigma de nuvem, infraestrutura as a service (IAAS), entre outros. |
CÓDIGO | ARQ01 |
ÁREA | Arquitetura |
XXXXXX | Xxxxxxxx desenho e arquitetura de solução e componentes arquiteturais |
PRODUTO | Diagrama contendo a arquitetura da solução apresentada em formato PDF e PNG. Outros formatos podem ser requeridos. |
PERFIL PROFISSIONAL | Arquiteto de Soluções |
UNIDADE DE MEDIDA | Componente arquitetural adicionado/Módulo |
UST | 16 |
ORIENTAÇÕES ADICIONAIS | Elaboração do desenho e arquitetura de solução para novos sistemas. Analisar e construir a arquitetura da solução. Como os componentes principais da solução estarão organizados, pode incluir componentes de software, servidores, serviços, interfaces, protocolos bem como o fluxo de atividades e interação entre os componentes. Analisar e construir a arquitetura da solução e como ela estará acoplada ou será evoluída a partir de um sistema existente. Como os componentes principais da solução estarão organizados, pode incluir componentes de software, servidores, serviços, interfaces, protocolos bem como o fluxo de atividades e interação entre os componentes |
CÓDIGO | ARQ02 |
ÁREA | Arquitetura |
TAREFA | Apoiar as equipes na estruturação de ambientes |
PRODUTO | Documentação como descrição da realização da estruturação dos ambientes. |
PERFIL PROFISSIONAL | Arquiteto de Soluções |
UNIDADE DE MEDIDA | Hora utilizada para apoio |
UST | 2 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | TESTE01 |
ÁREA | Teste |
TAREFA | Planejar testes e testar história de usuário |
PRODUTO | Plano de Teste e/ou Relatórios de Testes |
PERFIL PROFISSIONAL | Analista de Testes |
UNIDADE DE MEDIDA | História de usuário |
UST | 12 |
ORIENTAÇÕES ADICIONAIS | Planejar roteiro de testes, escrever cenários de testes e realizar os testes de uma história de usuário |
CÓDIGO | TESTE02 |
ÁREA | Teste |
TAREFA | Realizar teste exploratório |
PRODUTO | Relatórios de Testes |
PERFIL PROFISSIONAL | Analista de Testes |
UNIDADE DE MEDIDA | Sprint |
UST | 3 |
ORIENTAÇÕES ADICIONAIS | Realizar testes gerais do sistema, além das histórias de usuário, visando a realização de quaisquer validações sobre o funcionamento geral |
CÓDIGO | TESTE03 |
ÁREA | Teste |
TAREFA | Implementar Testes Automatizados |
PRODUTO | Scripts de implementação de testes. |
PERFIL PROFISSIONAL | Analista de Testes |
UNIDADE DE MEDIDA | História de Usuário/Processo Elementar |
UST | 10 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | VER01 |
ÁREA | Versão |
TAREFA | Gerar ambiente para entrega de versão |
PRODUTO | Documento com descrição dos ambientes criados, estruturados e versionados, mais evidências da realização do trabalho. |
PERFIL PROFISSIONAL | Desenvolvedor/ Analista de Sistemas |
UNIDADE DE MEDIDA | Ambiente funcional |
UST | 24 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | VER02 |
ÁREA | Versão |
TAREFA | Implantar componente arquitetural para possibilitar entrega de versão |
PRODUTO | Código-fonte e demais artefatos previstos no comissionamento do componente em um ambiente |
PERFIL PROFISSIONAL | Arquiteto de Soluções |
UNIDADE DE MEDIDA | Componente instalado em um ambiente |
UST | 8 |
ORIENTAÇÕES ADICIONAIS | Implantar componente arquitetural para assegurar a entrega de novas versões e novos produtos |
CÓDIGO | VER03 |
ÁREA | Versão |
TAREFA | Gerar build da aplicação |
PRODUTO | Código-fonte e demais artefatos previstos na implementação ou implantação da solução |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Versão |
UST | 4 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | VER04 |
ÁREA | Versão |
TAREFA | Gerar script de banco de dados para publicação de versão |
PRODUTO | Desenvolvedor/Analista de Dados |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Versão |
UST | 4 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | VER05 |
ÁREA | Versão |
XXXXXX | Xxxxxxxx documentação de procedimentos para publicação de versão |
PRODUTO | Desenvolvedor |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Versão |
UST | 6 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | VER06 |
ÁREA | Versão |
TAREFA | Configurar sistema e ambientes |
PRODUTO | Registro de realização de trabalho baseado em evidências. |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Ambiente |
UST | 10 |
ORIENTAÇÕES ADICIONAIS | Inclui trabalho completo de configuração nos servidores, geração de builds, scripts e todo o necessário para que a aplicação esteja funcional nos ambientes (desenvolvimento, homologação ou produção). |
CÓDIGO | VER07 |
ÁREA | Versão |
TAREFA | Realizar Deploy de Sistema |
PRODUTO | Registro do deploy em ferramenta automatizada ou registro de atividades realizadas por meio de chamado em ferramenta de registro de operações. |
PERFIL PROFISSIONAL | Desenvolvedor |
UNIDADE DE MEDIDA | Ambiente |
UST | 2 |
ORIENTAÇÕES ADICIONAIS | Implantar o sistema, e suas versões, em ambiente previamente configurado. |
CÓDIGO | AP01 |
ÁREA | Apoio |
TAREFA | Apoiar a resolução de incidentes (chamados) |
PRODUTO | Registro das atividades e produtos atrelados ao processo de resolução de incidentes da CONTRATADA. |
PERFIL PROFISSIONAL | Chamado/Incidente |
UNIDADE DE MEDIDA | Ambiente |
UST | 2 |
ORIENTAÇÕES ADICIONAIS | Realizar eventual diagnóstico do incidente a um serviço de TI, coletar evidências e atuar na solução de incidentes que não envolvam diretamente a implementação de manutenções corretivas em aplicações. Os serviços contemplados são relativos ao catálogo de produtos de software (sistemas) passível de atuação pela CONTRATADA. Os incidentes são oriundos do processo de suporte aos usuários e eventualmente escalonados para a CONTRATADA. |
CÓDIGO | AP02 |
ÁREA | Apoio |
TAREFA | Apoiar a resolução de incidentes de infraestrutura (chamados) |
PRODUTO | Registro das atividades e produtos atrelados ao processo de resolução de incidentes da CONTRATADA. |
PERFIL PROFISSIONAL | Chamado/Incidente |
UNIDADE DE MEDIDA | Ambiente |
UST | 2 |
ORIENTAÇÕES ADICIONAIS | Realizar eventual diagnóstico do incidente a um serviço de TI, coletar evidências e atuar na solução de incidentes que envolvam diretamente itens relacionados à infraestrutura das aplicações associadas ao serviço de TI em questão. Os serviços e infraestruturas contemplados são relativos ao catálogo de produtos de software (sistemas) passível de atuação pela CONTRATADA. Os incidentes são oriundos do processo de suporte aos usuários e eventualmente escalonados para a CONTRATADA. |
CÓDIGO | MAN01 |
ÁREA | Manual |
TAREFA | Elaborar manual de usuário em formato de texto e imagens |
PRODUTO | Manuais de operação e suporte ao usuário e equipes |
PERFIL PROFISSIONAL | Todos os perfis |
UNIDADE DE MEDIDA | Processo elementar principal |
UST | 2 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | MAN02 |
ÁREA | Manual |
XXXXXX | Xxxxxxxx manual de usuário em formato de vídeo e narração |
PRODUTO | Manuais de operação e suporte ao usuário e equipes |
PERFIL PROFISSIONAL | Todos os perfis |
UNIDADE DE MEDIDA | Processo elementar principal |
UST | 2 |
ORIENTAÇÕES ADICIONAIS |
CÓDIGO | PBI01 |
ÁREA | Paineis de Informação |
TAREFA | Elaborar Protótipos de Paineis de Informação |
PRODUTO | Protótipo de tela em arquivo no formato PDF ou outro formato a ser definido pelo MPPE. Esse serviço deve ser preferencialmente produzido por meio de ferramentas de design digital. O formato original do arquivo padrão na ferramenta de design, se for o caso, ou o mesmo arquivo exportado em outros formatos podem ser requeridos. |
PERFIL PROFISSIONAL | Analista UX/ Especialista em Paineis de Informação (BI) |
UNIDADE DE MEDIDA | Painel |
UST | 8 |
ORIENTAÇÕES ADICIONAIS | Desenvolvimento de protótipo funcional e/ou não funcional de painéis de informação (painéis de BI), exibindo como as informações estarão organizadas, quais serão os componentes visuais, as cores, a tipografia e imagens estarão dispostos em um painel. |
CÓDIGO | PBI02 |
ÁREA | Paineis de Informação |
TAREFA | Implementar Painéis de Informação |
PRODUTO | Arquivos relacionados à implementação de produtos na plataforma de BI da CONTRATADA. |
PERFIL PROFISSIONAL | Analista UX/ Especialista em Paineis de Informação (BI) |
UNIDADE DE MEDIDA | Componente |
UST | 2 a 4 por componente |
ORIENTAÇÕES ADICIONAIS | Envolve a criação completa de paineis de informação (paineis de BI), com base nas plataformas de Business Intelligence atualmente utilizadas no MPPE, incluindo modelagem e carga de dados, extrações e transformações de dados, implementação de componentes visuais e utilização de recursos da plataforma de BI do MPPE. |
Catálogo de Serviços de TI
XXXXX XX PERFIL PROFISSIONAL
1. A CONTRATANTE, de forma a garantir a qualidade do processo e dos entregáveis resultantes dele, exigirá da CONTRATADA a utilização de profissionais compatíveis com as exigências a seguir listadas, de acordo com os critérios da CONTRATANTE e das necessidades das demandas.
2. Não há previsão quanto à utilização do total de perfis estabelecidos, devendo a mobilização dos profissionais da CONTRATADA ocorrer com base nas demandas da CONTRATANTE.
1.1 PERFIL: SCRUM MASTER
1.1.1 Formação: Nível superior completo em curso reconhecido pelo Ministério da Educação;
1.1.2 Experiência: Experiência mínima de 3 (três) anos na coordenação de projetos de Tecnologia da Informação e experiência mínima de 1 (um) ano atuando como Scrum Master;
1.1.3 Certificado Professional Scrum Master PSM I (Professional Scrum Master I) emitido pela Xxxxx.Xxx ou CSM (Certified Scrum Master) emitido pela Scrum Alliance.
1.2 PERFIL: GERENTE DE PROJETOS
1.2.1 Formação: Nível superior completo em curso reconhecido pelo Ministério da Educação em uma das seguintes áreas: Análise de Sistemas, Ciência da Computação, Processamento de Dados, Sistemas de Informação, Informática ou Engenharia da Computação; com curso de pós-graduação lato sensu (especialização) na área de Tecnologia da Informação com duração mínima de 360 (trezentos e sessenta) horas;
1.2.2 Experiência comprovada de no mínimo 5 (cinco) anos em coordenação ou gestão de sistemas de informação; f) Capacitação: Princípios que regem a Gerência de Projetos (PMBoK) com carga-horária mínima de 40 horas.
1.2.3 Conhecimento em análise e projeto orientados a objetos; princípios que regem a Gerência de Projetos (PMBoK); e princípios que regem os modelos de maturidade em desenvolvimento e manutenção de software (RUP, e CMMI);
1.3 PERFIL: ANALISTAS DE SISTEMAS
1.3.1 Formação: Nível superior completo em curso reconhecido pelo Ministério da Educação em uma das seguintes áreas: Análise de Sistemas, Ciência da Computação, Processamento de Dados, Sistemas de Informação, Informática ou Engenharia da Computação;
1.3.2 Experiência mínima de 5 (cinco) anos em desenvolvimento de software na linguagem de programação do projeto contratado e conhecimento em orientação a objetos;
1.3.3 Experiência comprovada de no mínimo 2 (dois) anos em levantamento e especificação de requisito.
1.3.4 Experiência comprovada de no mínimo 2 (dois) anos em análise e projeto de sistemas e modelagem de dados.
1.3.5 Conhecimentos: Processo RUP (Rational Unified Process) e UML, ferramentas e técnicas de desenvolvimento e manutenção de sistemas; Modelagem de dados; Modelagem de processos; Modelo relacional; Modelagem orientada a objetos; Linguagem SQL; SGBD SQL Server 2008 ou superior; Ferramentas de engenharia de software assistida por computador (CASE); e Teste unitário/integrado de software.
1.4 PERFIL: DESENVOLVEDOR
1.4.1 Formação: Nível superior completo ou em andamento em curso reconhecido pelo Ministério da Educação em uma das seguintes áreas: Análise de Sistemas, Ciência da Computação, Processamento de Dados, Sistemas de Informação, Informática ou Engenharia da Computação;
1.4.2 Experiência mínima comprovada de 3 (três) anos em desenvolvimento de software na linguagem de programação do projeto contratado e com conhecimento em orientação a objetos;
1.4.3 Conhecimentos: Testes unitários; mapeamento objeto-relacional com Hibernate, Entity Framework ou outro framework similar; conhecimento em Service-Oriented Architecture – SOA e desenvolvimento de web services - REST; conhecimento em ferramentas de geração de relatórios (Report Service ou outras); conhecimento em linguagem SQL e desenvolvimento com o SGBD SQL Server 2008 ou superior; HTML5; CSS3; Jquery; Bootstrap; Angular; Python; Docker; Kubernetes; Elasticsearch; PHP, Java; Struts-MVC; JavaScript e utilização de ferramentas de controle de versões; Javascript, HTML e CSS, dados estruturados em XML ou JSON; Conceitos de interfaces de usuário e User eXperience (Experiência do Usuário); Princípios e práticas de desenvolvimento de software ágil, incluindo o Manifesto Ágil, Scrum, Extreme Programming (XP) e Kanban; Publicação de aplicações em plataformas como serviço (Platform as a service - PaaS);Integração contínua (continuous integration), test-driven development (TDD), acceptance test- driven development (ATDD), especificação por exemplo, refactoring, entrega contínua (continuous delivery);
1.4.4 Atender a pelo menos um dos sub-perfis abaixo:
1.4.4.1 Desenvolvedor FULL-STACK
1.4.4.1.1 03 (três) anos como programador de Sistemas em tecnologia PHYTON ou Java, com SGBD ORACLE OU SQL SERVER;
1.4.4.1.2 Implementação de código do back-end e front-end; Em infraestrutura e nuvem; Modelagem e estruturação de dados;
1.4.4.1.3 Conhecimento de tecnologias como Angular, Javascript, HTML e CSS, dados estruturados em XML ou JSON;
1.4.4.1.4 Conceitos de interfaces de usuário e User eXperience (Experiência do Usuário);
1.4.4.2 Desenvolvedor FRONT-END
1.4.4.2.1 03 (três) anos como programador de Sistemas em tecnologia JSF ou Angular e HTML5;
1.4.4.2.2 Implementação de código em front-end;
1.4.4.2.3 Ferramentas de desenvolvedor disponíveis nos browsers de aplicações (Google Chrome e Mozilla Firefox);
1.4.4.2.4 Conceitos de interfaces de usuário e User eXperience (Experiência do Usuário);
1.4.4.2.5 Prototipação e ferramentas de edição de imagem;
1.4.4.3 Desenvolvedor BACK-END
1.4.4.3.1 03 (três) anos como programador de Sistemas em tecnologia JAVA EJB e SGBD ORACLE;
1.4.4.3.2 Implementação de código do back-end;
1.4.4.3.3 Segurança de aplicações e serviços;
1.4.4.3.4 Integração com webservices e APIs;
1.5 PERFIL: ANALISTA DE REQUISITOS/PRODUCT OWNER
1.5.1 Formação: curso superior completo na área de TI ou em outra área com especialização (mínimo de 360h) em Análise de Sistemas ou Engenharia de Software, reconhecidos pelo Ministério da Educação (MEC);
1.5.2 b)Capacitação: Certificação Certified Scrum Product Owner; treinamento em requisitos ágeis com, no mínimo, 16 (dezesseis) horas;
1.5.3 Experiência comprovada de 6 (seis) meses com o cargo de Analista de Sistemas ou Requisitos, nível sênior, desenvolvendo atividades de análise de requisitos;
1.6 PERFIL: ADMINISTRADOR DE DADOS
1.6.1 Formação: curso superior completo na área de TI, ou em outra área com especialização (mínimo de 360h) em Banco de Dados, Análise de Sistemas ou Engenharia de Software, reconhecidos pelo Ministério da Educação (MEC);
1.6.2 Capacitação: Conhecimento de ferramentas de engenharia de software assistida por computador (ferramenta CASE), por exemplo, Power Designer e Xxxxx;
1.6.3 Experiência comprovada de 6 (seis) meses com o cargo de Administrador de Dados ou Administrador de Banco de Dados, nível sênior, ou similar desenvolvendo as atividades citadas.
1.7 PERFIL: ANALISTA DE TESTES
1.7.1 Formação: Nível superior completo em curso reconhecido pelo Ministério da Educação em uma das seguintes áreas: Análise de Sistemas, Ciência da Computação, Processamento de Dados, Sistemas de Informação, Informática ou Engenharia da Computação;
1.7.2 Capacitação: Análise de teste e qualidade de software ou curso similar com carga-horária mínima de 20 horas;
1.7.3 Experiência mínima comprovada de 3 (três) anos na área de teste e qualidade de software;
1.7.4 Conhecimentos: ferramentas e técnicas de Testes de sistemas; Linguagem SQL; Ferramentas de engenharia de software assistida por computador (CASE); e Teste unitário/integrado de software. Conhecimentos em ferramentas de automação de testes; Conhecimento de ferramentas de testes para gerência e especificação de testes, automação de testes funcionais e de performance e registro de defeitos.
1.8 PERFIL: PROJETISTA/DESENVOLVEDOR BPM
1.8.1 Formação: Diploma de Curso Superior em Informática ou Egresso de Informática;
1.8.2 Experiência : Experiência mínima de 3 (três) anos na atividade de Projetista, Arquiteto, Engenheiro ou Desenvolvedor de Software, atuando no desenvolvimento de projetos de sistemas integrados a plataformas de BPM
- Business Process Management, com amplo conhecimento na modelagem, simulação, construção e testes de processos de trabalho informatizados e nas ferramentas de gestão e monitoria destes processos;
1.8.3 Conhecimento e uso nas notações de BPMN, versão 2 e nas soluções de BPMS; Conhecimento da plataforma Red Hat JBoss BPM Suite; Conhecimento e experiência no desenvolvimento de sistemas nas de plataforma JAVA, EJB, JSF, conforme a arquitetura do sistema;
1.9 PERFIL: ANALISTA DE UX
1.9.1 Formação: Nível superior completo na área de Tecnologia da Informação ou Pós-graduação na área de Tecnologia da Informação com carga horária mínima de 360 (trezentos e sessenta) horas;
1.9.2 Experiência: 03 (três) anos como desenvolvedor web (JSF, Angular, Java Script, Jquery, HTML5, Joomla ou WordPress); 02 (dois) anos como Designer/UX (User Experience); Experiência no uso da ferramenta Apple Sketch e Adobe Illustrator;
1.9.3 Conhecimento: JSF, Angular, Java Script, Jquery, HTML5, Joomla ou WordPress, User Experience;
1.10 ARQUITETO DE SOLUÇÕES
1.10.1 Formação: Nível superior completo na área de Tecnologia da Informação, Ciência da Computação, Informática, Engenharia da Computação ou Pós- graduação na área de Tecnologia da Informação com carga horária mínima de 360 (trezentos e sessenta) horas;
1.10.2 Experiência: 06 (seis) anos de experiência profissional na área técnica de TI, sendo 1 ano como Arquiteto;
1.10.3 Conhecimento: conhecimento em Service-Oriented Architecture – SOA e desenvolvimento de web services - REST; conhecimento em ferramentas de geração de relatórios (Report Service ou outras); conhecimento em linguagem SQL, SGBD SQL Server e SGBD ORACLE; HTML5; CSS3; Jquery; Bootstrap; Angular; Python; Docker; PHP, Java; Struts-MVC; JFS; JavaScript; conhecimento profundo de arquitetura, instalação e configuração de sistemas operacionais e conhecimentos de frameworks de arquitetura de TI.
1.11 AGILE COACH
1.11.1 Formação: curso superior completo na área de TI ou em outra área com especialização (mínimo de 360h) em Análise de Sistemas ou Engenharia de Software, reconhecidos pelo Ministério da Educação (MEC);
1.11.2 Experiência: 03 (três) anos de experiência profissional em implantação de metodologias ágeis;
1.11.3 Certificado Professional Scrum Master PSM I (Professional Scrum Master I) emitido pela Xxxxx.Xxx ou CSM (Certified Scrum Master) emitido pela Scrum Alliance.
1.12 ESPECIALISTA EM PAINEIS DE INFORMAÇÃO (ANALISTA DE BI)
1.12.1 Formação: Nível superior completo ou em andamento em curso reconhecido pelo Ministério da Educação em uma das seguintes áreas: Análise de Sistemas, Ciência da Computação, Processamento de Dados, Sistemas de Informação, Informática ou Engenharia da Computação;
1.12.2 Experiência: Experiência mínima comprovada de 5 (cinco) anos em desenvolvimento de desenvolvimento e extração de dados, correções de erros, workshops técnicos, provas de conceito, desenvolvimento de painéis/relatórios e sustentação de tecnologia DW/BI, incluindo SQL, SSIS, SSAS, SSRS e Power BI;
1.12.3 Conhecimentos: Prototipação de Paineis de BI, implementação de paineis de BI com base na plataforma Microsoft Power BI;
1.12.4 Conhecimentos: linguagem SQL; Modelagem relacional, estrela, floco de neve e linked tables; Extração, Transformação e carga de dados (ETL); Power BI;
1.12.5 Certificação mínima requerida: MCSA - SQL 2016 Business Intelligence Development ou MCSE - Data Management and Analytics.
3. A comprovação dos perfis de qualificação profissional exigidos nesta seção deverá ser feita pela CONTRATADA em até (30) dias após a assinatura do contrato e deverá ser mantida durante todo o período de execução do objeto contratual. A comprovação da qualificação dar-se-á por meio de contratos de trabalho, diplomas, certificados e atestados de entidade idônea em nome dos profissionais. Para as habilidades não comprovadas por meio de certificados e diplomas, poderão ser aplicados testes verbais ou escritos aos profissionais, contemplando conhecimentos compatíveis com as exigências.
4. Na ausência de certificados e diplomas, a CONTRATADA deverá emitir atestado técnico assinado em nome dos profissionais, atestando que estes possuem o perfil exigido nesta contratação.
5. A qualquer tempo, o Fiscal do Contrato poderá solicitar comprovação de qualificação técnica de qualquer profissional que esteja atuando no contrato, podendo solicitar sua substituição em caso de desconformidade com as exigências feitas. A substituição dos profissionais indicados durante a execução do contrato somente será permitida por outros com qualificações iguais ou superiores às exigidas neste Termo de Referência e após aprovação pelo MPPE.
6. Poderão adicionados perfis complementares, comumente encontrados no mercado, à presente lista, com base em eventuais demandas da CONTRATANTE, evoluções tecnológicas e necessidades de ajustes para melhor operação do serviço contratado, mediante acordo entre as partes e as devidas justificativas técnicas.
ANEXO III ARQUITETURA TECNOLÓGICA
Este anexo apresenta uma visão geral das plataformas existentes no Ministério Público de Pernambuco e atualmente sustentadas pelo Departamento de Soluções de TI (DEMSTI) do MPPE.
1. Plataforma JAVA;
2. Plataforma PYTHON;
3. Plataformas BPM.
4. Outras
1. PLATAFORMA JAVA
1.1. Arquitetura e Tecnologias
Plataforma JAVA EE 5, JAVA EE 6 e JAVA EE 8 em especial os componentes:
● SPRING BOT;
● SPRING SECURITY;
● SPRING MVC REST;
● SPRING DATA JPA;
● LIQUIBASE;
● SPRING DATA JPA;
● ELASTICSEARCH;
● ANGULARJS e ANGULAR 5 e superior;
● BOOTSTRAP;
● JSF versões 1.2 e 2.1;
● Primefaces;
● Beans Validation;
● CDI;
● EJB versões 3.0 e 3.1
● Conc. 01/2016 – fábrica de software - 52
● JPA versão 2.x;
● JAX-WS;
● JAX-RS.
● Backbone;
● Typescript;
● HIBERNATE;
1.2. No ambiente de desenvolvimento, utiliza-se também:
● Xxxxx (e outras Ferramentas de ALM - Application Lifecycle Management);
● Redmine;
● GIT;
● GitLab CI;
● Maven;
● Eclipse;
● iReport versões 3.0 e 5.1;
● Jasper;
● Pentaho;
● PowerBi;
● Dbeaver;
● Linux e Windows;
● Apache;
● MySql 5.6.40 ou superior;
2. PLATAFORMA PYTHON
● Python 3.6.1 ou superior
3. PLATAFORMA BPM - RED HAT JBOSS BPM SUITE
3.1. Red Hat JBoss BPM Suite é uma suite de Código Aberto composta de workflow e BPM (Business Process Management). É executado em um servidor de aplicação JBoss e utiliza o banco de dados Oracle.
3.2. As Convenções para serem utilizadas no desenvolvimento de soluções com BPM são as mesmas que já são utilizadas na plataforma de programação JAVA.
4. OUTRAS
● PHP (diferentes versões);
● XXXXXX;
● Pentaho;
● Kubernetes;
● RABBITMQ;
● JAMGO;
● MONGODB
● TASTYPIE;
Departamento Ministerial de Soluções de TI (DSTI) Coordenação Ministerial de Tecnologia de Informação (CMTI) Ministério Público de Pernambuco (MPPE)
ANEXO IV
METODOLOGIA DE DESENVOLVIMENTO DE SOTFWARE (MDS)
1. INTRODUÇÃO
Este documento tem o propósito de descrever e normatizar o processo de desenvolvimento, manutenção e testes de sistemas de informação do MPPE. A Metodologia de Desenvolvimento de Software (MDS) descrita envolve diferentes processos, dentre os quais o processo para desenvolvimento de novos sistemas, baseado no SCRUM, um modelo de desenvolvimento ágil amplamente utilizado e consagrado no mercado mundial, além de adaptações e outras técnicas complementares, incluindo os processos de sustentação de sistemas e de realização de manutenções evolutivas de pequeno porte.
Nas seções a seguir, serão detalhados, dentre outros aspectos, o processo principal de desenvolvimento baseado em SCRUM, denominado Processo de Desenvolvimento Ágil (PDA) e os processos auxiliares, denominados Processo de Sustentação de Sistemas (PDS) e Processo de Evolução de Pequeno Porte (PEP).
Este documento apresenta uma visão de alto nível desta metodologia, podendo sofrer alterações e ajustes visando à otimização dos processos de construção de soluções e do ciclo de vida dos produtos e da implantação dos serviços de Fábrica de Software em contratação.
2. PROCESSO DE DESENVOLVIMENTO ÁGIL (PDA)
Nesta seção será descrito o processo de desenvolvimento ágil baseado em SCRUM, que é utilizado para o desenvolvimento de novos sistemas e também para as evoluções elencadas como projeto, que tipicamente são evoluções de maior porte e/ou de alta criticidade, e cuja categorização fica a cargo do MPPE. O PDA aqui descrito, seguindo as diretrizes que são empregadas no processo SCRUM, tem como principais valores:
▪ Interação e confiança entre os participantes;
▪ Janela fixa de tempo para cada ciclo de desenvolvimento;
▪ Adaptação rápida às mudanças;
▪ Documentação concisa e objetiva;
▪ Entrega rápida de produtos e satisfação das áreas de negócios;
▪ Revisão e melhoria contínuas no processo.
É possível observar que, neste processo, os produtos são continuamente incrementados, agregando valor à área de negócio desde os primeiros ciclos de desenvolvimento. O foco na documentação é reduzido, mas se mantém um conjunto de artefatos plenamente satisfatório para exprimir o sistema em termos documentais. Por fim, todo o trabalho é continuamente avaliado e monitorado, de forma que melhorias são aplicadas constantemente nas experiências entre os participantes.
2.1. Termos Utilizados no PDA
▪ Backlog – coleção de funcionalidades definidas pelo cliente e que geram valor para o negócio;
▪ Sprint – iteração no processo de desenvolvimento, na qual é produzida uma parte do sistema, previamente definida pelo cliente;
▪ Kanban – técnica utilizada em processos industriais que consiste no simples mapeamento das atividades, e as unidades de trabalho responsáveis por elas, sendo aqui aplicada ao desenvolvimento de software através do Quadro Kanban de atividades;
▪ História de usuário – é a menor unidade de funcionalidade que possui valor para o cliente, e que normalmente representa um cenário de uso do sistema.
2.2. Papéis do PDA
2.2.1.Product Owner (PO)
É o representante da COSOL responsável por:
o Conhecer as necessidades relacionadas ao sistema;
o Definir a visão do produto;
o Descrever, priorizar e refinar as necessidades continuamente;
o Estar disponível para dúvidas e questionamentos do time de desenvolvimento;
o Participar das reuniões de demonstração de Sprints e decidir pela aceitação de entregas;
2.2.2.Scrum Master
É o representante da contratada responsável por:
o Priorizar e remover os impedimentos da equipe de desenvolvimento;
o Garantir o funcionamento do processo, ou seja, que a equipe utilize corretamente a MDS;
o Evitar que membros da equipe implementem hierarquias entre eles;
o Atuar como Gerente Operacional de Projetos, incluindo responsabilidades tais como:
▪ Reuniões de alinhamento, status atual e planejamento, incluindo aspectos tais como estimativas de prazo, riscos, expectativas e objetivos com a área de negócios ou com a COSOL;
▪ Discussões ou demonstrações de caráter técnico ou negocial;
▪ Manutenção e busca do atingimento de padrões de qualidade exigidos pela COSOL;
▪ Atuação na interface com a área de Infraestrutura, incluindo quaisquer ações de alinhamento técnico, resolução de dúvidas e apoio necessários à conclusão de etapas do projeto;
▪ Atuação na gestão equilibrada de requisitos junto à área demandante e demais questões relacionadas à boa execução do projeto;
▪ Operação detalhada do sistema de gestão de demandas, incluindo classificação, encaminhamento e acompanhamento de demandas, dentre outros;
▪ Apoio no processo de homologação e implantação de soluções, incluindo execução e/ou supervisão de procedimentos técnicos, operacionais e gerenciais necessários;
2.2.3.Gerente de Sistema
É o representante da COSOL responsável por:
o Reforçar os fundamentos do processo e garantir a correta execução das tarefas, atuando como Scrum Master Interno;
o Garantir apoio ao Product Owner na priorização e demais atividades relacionadas às necessidades do produto, inclusive com o aprofundamento no entendimento do negócio;
o Definição de datas relacionadas ao plano de releases;
o Acompanhamento e discussão das atividades com a equipe de desenvolvimento diariamente, inclusive com inspeção dos resultados diários;
o Participar das reuniões de demo e retrospectiva de Sprints;
o Decidir pela homologação técnica de entregas;
o Definir questões que envolvam caráter técnico;
o Apoiar na resolução de conflitos e dificuldades da equipe contratada.
2.3. Visão Geral do Processo
Neste processo foi definida uma fase de Iniciação, onde se busca representar a visão inicial do produto. Após sua conclusão, se inicia a execução cíclica das Sprints, onde cada Sprint é composta de 3 fases: Discovery, que contempla o refinamento das histórias de cada ciclo; Delivery, que contempla a construção e implantação do produto planejado; e a Homologação, onde o Product Owner verifica em detalhes o produto entregue. Esta visão macro do processo consta na Figura 1.
Figura 1 - Fases do PDA
Aproximando o processo e decompondo as fases envolvidas, é possível observá-lo através de uma perspectiva mais detalhada (Figura 2). A iniciação, abrangendo a definição de visão do produto, compreende, em linhas gerais, os objetivos do sistema a ser desenvolvido, premissas arquiteturais, além do conjunto inicial previsto de histórias de usuário (backlog do produto), um plano de releases e demais necessidades de caráter não-funcional identificadas pela área demandante.
Figura 2 – Visão Geral Detalhada do PDA
Uma vez concluída a iniciação, o ciclo de Sprints começa a ser executado. Cada Sprint possui planejadas (Delivery). Este fluxo permanece até que o produto seja completamente construído.
2.4. Fase de Iniciação
A fase de iniciação, com duração fixa de uma semana, é a primeira fase do projeto, onde se busca nivelar as necessidades e atingir um consenso entre todos os envolvidos sobre qual produto deverá ser desenvolvido. A Figura 3 ilustra as etapas e artefatos detalhados da fase de iniciação.
2.4.1.Definição da Visão do Produto
A visão do produto é um documento contendo a missão do sistema a ser desenvolvido, os conceitos básicos relacionados à sua área de negócio, as necessidades que justificam seu desenvolvimento e macro objetivos a serem cumpridos. Além disso, devem estar explicitados requisitos arquiteturais específicos e demais informações de cunho geral relacionadas à visão do sistema.
Figura 3 – Fase de Iniciação 2.4.2.Definição de Regras de Negócio
Após a delimitação da visão do produto, devem ser elencadas as principais regras de negócio relacionadas ao sistema. Tais regras tem grande importância para entender premissas concretas que orientem o levantamento do Backlog do Produto. Estas regras devem ser revisadas, ampliadas e aprimoradas a cada fase de Discovery.
2.4.3.Estabelecimento do Plano de Releases
O plano de releases envolve definir em alto nível as versões significativas do sistema que devem ser alcançadas. Eventualmente, dependendo do tipo de negócio ou tamanho do sistema, apenas uma versão é desejável. Mas em geral, vários marcos podem ser estabelecidos. Deste modo, é possível visualizar a associação destes objetivos de alto nível e funcionalidades com valor significante para o Product Owner. Um exemplo de relação entre releases e Sprints está demonstrado na Figura 4.
2.4.4.Estabelecimento do Backlog do Produto
O backlog do produto é uma lista de todas as histórias que devem ser necessárias na construção do produto, de maneira ordenada por prioridade. É de responsabilidade do Product Owner elicitar estas histórias, e priorizá-las de maneira que a ordem do backlog reflita o grau de importância de cada história.
Este artefato está em constante evolução e é sempre passível de alterações. A versão concluída na iniciação reflete uma visão geral das funcionalidades que o produto deve conter, de forma a delimitar uma noção de escopo para o projeto. Inclusão e exclusão de necessidades é algo comum e rotineiro, cuja revisão é realizada a cada Sprint. Além do exposto, constam no backlog do produto eventuais correções necessárias e também alterações de funcionalidades existentes.
2.4.5.Artefatos Resultantes
● Documento de Visão;
● Regras de Negócio;
● Plano de Releases.
● Backlog do Produto;
Figura 4 – Sprints e Releases
2.5. Fase de Discovery
A fase de Discovery, que é executada a cada Sprint e tem duração fixa de 2 semanas corridas, compreende a etapa relacionada ao planejamento do conteúdo de cada Sprint, e consequentemente, com o refinamento deste conteúdo. Para isso, são realizadas algumas etapas, descritas a seguir.
2.5.1.Revisões da Visão, Backlog do Produto e Regras de Negócio
A cada Discovery, é realizada uma revisão da Visão do Produto, com o intuito de verificar se a missão, premissas e características gerais estão mantidos conforme foi planejado no início do projeto. Em adição, o backlog do produto também é revisado, tal que novas histórias possam ser incluídas, além de permitir-se a repriorização das histórias existentes, ou mesmo a exclusão de histórias que não se façam mais necessárias. Por último, devem ser revisadas também as regras de negócio do sistema, modificando-se regras existentes ou incluindo-se novas regras. Esta fase tipicamente envolverá até 4 horas.
2.5.2.Planejamento de Discovery
Faz-se necessário, após a ratificação do conteúdo de backlog e visão do produto, realizar o planejamento de discovery da Sprint a ser executada. Neste caso, a equipe se reúne com o PO e Scrum Master para definirem juntos as histórias a serem elencadas como obrigatórias e opcionais naquela Sprint. A quantidade de histórias deve ser ajustada de acordo com a produtividade da equipe. Naturalmente, a produtividade tende a melhorar à medida em que o time compreende mais profundamente o sistema. Delimitado o escopo aproximado da Sprint, deve haver uma contagem estimada das funcionalidades previstas, para que verificar se há viabilidade na realização das histórias selecionadas. Esta fase tipicamente envolverá até 4 horas.
2.5.3.Refinamento do Backlog da Sprint e Modelo de Dados
Uma vez definidas as histórias que devem compreender o backlog da Sprint, estas devem ser refinadas em conjunto com o Product Owner. Nesta fase, haverá reuniões envolvendo toda a equipe para o amplo registro e entendimento de cada história, além da geração do modelo de dados atualizado que reflita aquilo que foi elicitado pela equipe. Várias técnicas podem ser utilizadas neste período de refinamento, incluindo Entrevistas, Brainstorming e Prototipação. Não há artefato documental a ser desenvolvido após a conclusão da fase, ou seja, todos são desenvolvidos em tempo real e de forma incremental, juntamente com o PO, de forma que a conclusão da fase já tem documentação auto-homologada. Juntamente com as histórias, devem ser trazidos os critérios de aceitação providos pelo PO, que serão transformados em testes unitários na fase de Delivery. Além destes, também será considerada a necessidade, em determinadas histórias de usuário, dependendo da criticidade e complexidade das regras de negócio, que sejam feitos Testes Funcionais Automatizados de acordo com tais critérios de aceitação, utilizando ferramenta padronizada pela COSOL/STI. Tipicamente, esta etapa deve durar até 9 dias úteis de trabalho.
Na Figura 5, é possível visualizar a sequência e duração de cada etapa do Discovery.
Figura 5 – Fase de Discovery
2.5.4.Artefatos resultantes
● Visão, Backlog e Regras de Negócio atualizados;
● Histórias de Usuário refinadas, com protótipos de tela e critérios de aceitação, além da indicação de necessidade de testes funcionais automatizados;
● Modelo de Dados atualizado;
2.6. Fase de Delivery
A fase de Delivery, que também é executada a cada Sprint logo após a fase de Discovery, também tem como prazo fixo duas semanas corridas, e compreende a construção das necessidades pactuadas no planejamento da Sprint, ou seja, envolve a codificação e a entrega de um incremento do produto que está sendo tratado no projeto ágil. Para isso, são realizadas algumas etapas, descritas a seguir.
2.6.1.Planejamento de Delivery
No planejamento do delivery, as histórias da Sprint são subdivididas em tarefas, que são distribuídas entre os integrantes do time. Há um planejamento de metas de curto prazo para cada tarefa, para que possa se alcançar a construção do produto.
2.6.2.Criação de Testes Unitários
Esta metodologia preza pelo desenvolvimento orientado a testes (TDD – Test Driven Development), onde os testes unitários são construídos antes mesmo do código executável, para que, utilizando os critérios de aceitação definidos pelo Product Owner nas histórias de usuário, os testes orientem antecipadamente o próprio código a ser desenvolvido, em um processo incremental.
2.6.3.Implementação das Histórias de Usuário
Como objetivo principal do Sprint, serão implementadas as tarefas planejadas de forma a se satisfazer as necessidades expressas nas histórias de usuário previstas para a Sprint.
2.6.4.Criação de Testes Funcionais Automatizados
Esta etapa diz respeito à construção dos testes funcionais automatizados que podem ter sido planejados para a Sprint. Os testes funcionais serão desenvolvidos utilizando ferramenta que esteja padronizada pela DT/MPPE (Ex: Selenium).
2.6.5.Execução de Testes
Antes de liberar o incremento do produto previsto na Sprint, a contratada deve executar os testes desenvolvidos para as histórias em questão, de forma que relatórios com o resultado da execução dos testes estejam disponíveis para verificação por parte da DT/MPPE.
2.6.6.Pré-Homologação
Nesta etapa, a DT/MPPE recebe oficialmente o produto para uma pré-homologação, que tem como finalidade verificar:
● Se o produto entregue atende ao checklist para admissão, conforme subseção a seguir;
● Se todas as histórias planejadas na Sprint estão contempladas no produto entregue;
● Se há defeitos de natureza impeditiva.
2.6.6.1. Definição de PRONTO (Checklist de Admissão do Produto)
Qualquer produto enviado para homologação por parte da DT/MPPE deve atender a uma série de critérios para sua admissão à implantação em ambiente de homologação, sem os quais o produto é rejeitado de imediato. Tais critérios estão listados a seguir:
● Código-fonte submetido ao controle de versões da DT/MPPE;
● Existência de testes unitários e do Relatório de Testes;
● Existência de scripts de banco de dados com dicionário de dados embutido nos metadados (ausência apenas quando não houver mudança no modelo de dados)
● Existência de arquivo para geração de Build (ex: Arquivo de projeto Maven).
● Disponibilização de processos prontos para execução na ferramenta Jenkins ou similar, juntamente com a entrega e configuração de containers Docker configurados pela ferramenta OpenShift ou similares.
● Existência de Manual de Implantação, conforme modelo disponível na MDS.
● Existência de Manual do Usuário, conforme modelo disponível na MDS.
2.6.6.2. Aceitação da Demanda
Após realizar a inspeção do produto quanto à sua admissibilidade (item anterior), o gerente de sistemas, juntamente com o Product Owner, poderá:
● Executar testes funcionais automatizados que tenham sido solicitados, e consequentemente verificar se estão corretamente implementados ou mesmo se existem, além de observar os resultados da execução;
● Executar testes unitários ou verificar relatórios de execução destes e que possam envolver porções críticas do produto;
● Realizar alguns testes funcionais, pelo menos nos principais fluxos do produto entregue. Após a realização destes testes, pode se proceder a uma das ações a seguir:
o Rejeição: caso sejam percebidos defeitos de natureza impeditiva em alguma história implementada ou não tenha coberto o escopo planejado de tal forma que a entrega não seja passível de aceitação;
o Aceitação parcial: caso a demanda possua alguns defeitos significativos de natureza não- impeditiva ou não tenha coberto o escopo planejado de tal forma que ainda seja passível de aceitação;
o Aceitação integral: caso a demanda esteja em nível de qualidade tal que não sejam percebidos defeitos significativos, bem como envolva cumprimento do escopo planejado.
Todos os aspectos julgados relevantes devem ser registrados pelo Gerente de Sistemas e/ou Product Owner no Relatório de Não-Conformidade. Os defeitos percebidos na rejeição e na aceitação parcial devem obrigatoriamente fazer parte de um item de backlog da próxima Sprint, específico para correção dos defeitos, salvo determinação contrária do PO ou Gerente de Sistemas.
2.6.7.Retrospectiva
A etapa de retrospectiva diz respeito à melhoria contínua do processo. Nesta etapa, os integrantes se reúnem para discutir a Sprint que está sendo concluída, com foco nos desafios, oportunidades e problemas ocorridos. Não faz parte do escopo desta etapa a discussão sobre histórias de usuário e backlog do produto, ou seja, discute-se apenas o processo, e como melhorá-lo. Tipicamente, esta reunião leva até 4 horas.
2.6.8.Artefatos Resultantes
Os artefatos resultantes da fase de Delivery são:
● Histórias de Usuário implementadas e cujo código-fonte esteja submetido ao controle de versões;
● Testes unitários e funcionais implementados e executados, com o resultado de testes;
● Demais artefatos relacionados ao deployment do sistema: projeto para criação do build (Ex: Projeto Maven), scripts de banco e manual de implantação.
Na Figura 6, é possível visualizar a sequência e duração das etapas desta fase.
Figura 6 – Fase de Delivery
2.7. Fase de Homologação
Esta fase compreende apenas os testes e experimentação detalhados do produto entregue, por parte do PO e/ou Gerente de Sistemas, em até 5 dias úteis, para que possa haver alguma decisão de ordem negocial, como inclusão de novas regras, melhoria da implementação existente ou mesmo rejeição das regras implementadas. Qualquer problema ou observação deve ser acrescido ao Relatório de Não-conformidade criado na Pré-Homologação.
2.8. Técnicas e Ferramentas Auxiliares ao Processo
Além das fases citadas anteriormente, o PDA envolve a utilização de técnicas e ferramentas auxiliares ao longo do processo, de forma a garantir a correta gestão e minimizar os riscos envolvidos. Tais práticas são detalhadas nas subseções a seguir.
2.8.1.Quadro de Tarefas com Kanban
Todos os projetos desenvolvidos no PDA devem ter um quadro apoiado pela técnica KANBAN contendo as tarefas previstas no projeto, separadas em raias que significam etapas e estados relacionados à execução. Um exemplo deste quadro pode ser visto na Figura 7.
Figura 7 – Quadro de Tarefas Kanban
2.8.2.Reuniões Diárias
Além das reuniões previstas no PDA, tais como Planejamento, Refinamento e Retrospectiva, as equipes devem obrigatoriamente fazer reuniões diárias de 15 minutos, com a participação do Gerente de Sistema, de forma que sejam apresentadas rapidamente e por cada integrante as metas do dia, problemas a serem enfrentados e pendências previstas.
Esta deve ser uma reunião transparente, onde todos os riscos são mapeados, e onde todos os integrantes apresentam sua visão diária do projeto.
2.8.3.Gráfico de Burndown
Além do quadro Kanban, um gráfico de produtividade deve ser mantido visível para a equipe de desenvolvimento, exibindo, ao longo do tempo, a relação entre o trabalho planejado e efetivamente realizado. Na figura 8 é possível visualizar um exemplo de gráfico de Burndown. Este gráfico pode ser feito com diferentes índices que representem quantidade de trabalho, como por exemplo, o número de histórias restantes existentes. À medida que o time ganha maturidade, índices mais exatos podem ser utilizados, como horas ou Pontos de Função previstos.
Figura 8 – Gráfico de Burndown
2.9. Paralelismo entre as Sprints
O modelo ágil permite que alguns passos entre as Sprints subsequentes sejam paralelizados. Este paralelismo depende da maturidade da organização, do projeto e da disponibilidade do PO, dentre outros fatores. Nesta metodologia, por padrão, será adotado o paralelismo conforme Figura 9.
Neste modelo, a fase de homologação acontece em paralelo à primeira semana da fase de Discovery da próxima Sprint. Na referida figura, as semanas estão representadas em raias verticais, e as fases coloridas representam etapas de Sprint, conforme legenda.
Tal paralelismo implica, naturalmente, que quaisquer alterações negociais decorrentes desta fase de homologação (percepção de mudança de negócio, novas regras relacionadas às funcionalidades implementadas, entre outros.) podem ser incorporadas diretamente na Sprint em andamento.
Figura 9 – Paralelismo entre as Sprints
2.10. Artefatos
Embora o Processo de Desenvolvimento Ágil preconize objetividade e código pronto, há uma série de artefatos a serem produzidos no processo, além do produto em si. Tais artefatos podem ser expressos em formato de documento, cujo template é fornecido, ou através de registro na ferramenta de projeto de software em uso na DT/MPPE.
Ainda existem, além dos artefatos gerais, artefatos específicos para desenvolvimento de componentes e webservices, e por fim os guias operacionais, que são padrões tecnológicos e metodológicos a serem adotados pela contratada.
2.10.1. Artefatos Gerais de Desenvolvimento
LISTA DE ARTEFATOS | DESCRIÇÃO | NOME DOS TEMPLATES | I | D I | D E |
Documento de Visão | Descreve uma visão geral do projeto, seus produtos e suas características | TP – Sigla Projeto – Visão | x | ||
Backlog do Produto | Lista das funcionalidades a serem desenvolvidas para o produto, em ordem decrescente de prioridade. | Registrado em ferramenta de projeto | x | x | x |
História de Usuário | Especifica uma necessidade do Product Owner e seus critérios de aceitação, além de esboços de tela (quando necessário, pode ser protótipo navegável). | Registrado em ferramenta de projeto | x | ||
Regras de Negócio | Especifica as regras de negócio que farão parte das Histórias de Usuário | TP - Sigla Projeto - Regras de Negócios | x | x | |
Modelo de dados | Projeto de modelo de dados para a aplicação | TP - Sigla Projeto – Modelagem de Dados | x | x | |
Manual de Implantação | Recursos de instalação, hardware, software | TP - Sigla Projeto - Manual de Implantação | x | ||
Manual do Usuário | Descreve as funcionalidades do sistema para ajuda ao usuário | TP WEB - Sigla Projeto - Manual do Usuário.doc | x | ||
Relatório de Testes | Artefato gerado por ferramenta que execute os testes unitários | Não se aplica | x | ||
Relatório de Não- conformidade | Relatar as não-conformidades detectadas. | Registrado em ferramenta de projeto | x |
2.10.2. Artefatos para Desenvolvimento de Componentes e WebServices
LISTA DE ARTEFATOS | DESCRIÇÃO | NOME DOS TEMPLATES |
Especificação Técnica de Componente | Especifica linguagens de programação, componentes, logs e tratamento de erro. | ET - Sigla Projeto - Especificação Técnica Componente |
Especificação Técnica para Consumo WebService | Especifica a arquitetura para consumo WebService | ET - Sigla Projeto - Especificação Técnica para Consumo Webservice |
Especificação Técnica Webservice | Especifica a representação da arquitetura WebService | ET - Sigla Projeto - Especificação Técnica Webservice |
2.10.3. Padrões Tecnológicos – Guias Operacionais
GUIAS OPERACIONAIS | DESCRIÇÃO | NOME DOS TEMPLATES |
Manual de Padrão de Telas | Define um padrão de telas para os sistemas do MPPE | GO/Camada de Apresentação de Telas |
Arquitetura de referência JAVA | Documento que define a arquitetura base para os sistemas | GO/Sigla Projeto - Arquitetura de Referência Java |
Arquitetura de Referência de Componentes Corporativos | Descrever a arquitetura padrão utilizada no desenvolvimento de componentes corporativos pelos fornecedores de sistemas da COSOL/STI | GO/Arquitetura de Referência Componentes Corporativos |
Padrões de Nomenclaturas para Banco de Dados | Padronizar a Nomenclatura para Banco de Dados | GO/Nomenclatura para Banco de Dados |
Orientações sobre a confecção de modelos de dados | Orientar a criação de modelos de dados | GO/Elaboração de Modelos de Dados |
Dicionário de dados | Dicionário de dados do sistema | GO/Dicionário de Dados Mainframe |
Padrão de codificação | Padrão de codificação Mainframe | GO/Codificação Ambiente |
Documentação de Sistemas Legados | Adoção de uma documentação mínima para os sistemas legados garantirá maior produtividade, qualidade e facilidade nos processos de manutenção | GO/Documentação de Sistemas legados |
Versionamento de Código | Descrever as atividades do Processo de Controle de Versionamento de Programas a ser adotado no Processo de Desenvolvimento de Software utilizado na COSOL, de forma que a evolução dos sistemas ocorra de modo controlado. | GO/Versionamento de Código |
3. PROCESSO DE SUSTENTAÇÃO DE SISTEMAS (PDS)
Trata-se do processo que envolve as atividades de sustentação de sistemas, tratando-se de manutenção continuada e estendendo-se desde sua implantação até o momento em que for substituído ou descontinuado.
3.1. Atividades de Sustentação
Dentro deste processo, estão englobadas uma série de atividades distintas, detalhadas a seguir.
3.1.1.Manutenção corretiva
Consiste na eliminação de comportamentos do software que divirjam de suas especificações ou que provoquem a interrupção inesperada de seu funcionamento.
3.1.2.Manutenção adaptativa tecnológica
Consiste na alteração do sistema para adaptá-lo às mudanças do ambiente computacional onde foi desenvolvido ou onde é executado, considerados aí os componentes tecnológicos passíveis de adaptação: Sistema Gerenciador de Bancos de Dados, Servidor de Aplicações, bibliotecas e/ou frameworks utilizados e as evoluções da própria linguagem computacional utilizada.
3.1.3.Manutenção cosmética localizada
Consiste na alteração de interface de usuário que não implique alteração das regras de negócio do Caso de Uso e que seja realizada de forma localizada, isto é, pela intervenção em um único arquivo ou em um pequeno conjunto de arquivos. Tal manutenção pode ser exemplificada da forma que se segue:
● Fontes de letra, cores, logotipos, mudanças de botões, alteração na posição de campos e texto na tela;
● Mudanças de texto em mensagens do sistema, título de um relatório ou labels de uma tela de consulta;
● Mudanças de texto estático em e-mail enviado pelo sistema.
3.1.4.Apurações especiais
Consiste na preparação de roteiros de execução em linguagem SQL, ou outra adequada ao caso, destinados às extrações de dados não cobertas pelos relatórios do sistema, à correção de inconsistências nos dados mantidos pelo sistema e não realizáveis por meio das interfaces de usuário disponíveis (ou cujo volume inviabilize a sua execução de forma manual), ou à inserção de dados não automatizada no sistema.
3.1.5.Atendimento
Trata-se de prestação de esclarecimentos, à DT/MPPE, quanto à forma como foram implementados os requisitos do sistema, aos procedimentos requeridos ao seu correto funcionamento ou aos dados mantidos por ele. Em adição, também se enquadra nesta atividade o apoio à identificação e isolamento de falhas e problemas na execução do software.
3.1.6.Rotinas operacionais
Consiste na execução de quaisquer procedimentos operacionais rotineiramente requeridos pelo sistema em função de suas regras de negócio ou forma de construção.
3.2. Tratamento de Demandas de Sustentação
Todas as atividades descritas anteriormente seguem fluxos a serem tratados pela contratada, que têm como ponto de partida o registro do incidente ou solicitação no Sistema de Gestão de Demandas em uso na DT/MPPE, que a partir de então deverá ser tratado pela contratada de acordo com as cláusulas de nível de serviço (que não são escopo desta metodologia) e tipo da demanda. Uma visão geral deste tratamento pode ser vista na Figura 10.
3.2.1.Manutenções Corretivas, Adaptativas e Cosméticas
Após a execução do serviço, a contratada deverá tomar as seguintes providências:
● Providenciar que o código com a mudança solicitada (correção, adaptação ou manutenção cosmética) seja enviado para geração de build em homologação, ou eventualmente diretamente em produção (dependendo da urgência ou tipo demanda, tratado a cada caso);
● Atualizar a versão do sistema conforme o guia operacional de versionamento;
● Registrar tudo o que for realizado no sistema de gestão de demandas, relacionando, se possível, com casos semelhantes já conhecidos.
3.2.2.Apurações Especiais
Após a execução do serviço, a contratada deverá tomar as seguintes providências:
● Providenciar que a intervenção em base de dados com a apuração solicitada (correção de registros, inclusão de dados em CODE TABLE, relatórios direto de base de dados, dentre outras) seja enviada para execução em base de dados de homologação, ou eventualmente, diretamente em base de produção (dependendo da urgência ou tipo demanda, tratado a cada caso);
● Registrar tudo o que for realizado no Sistema de Gestão de Demandas, relacionando, se possível, com casos semelhantes já conhecidos.
3.2.3.Atendimento e Rotinas Operacionais
Após a execução do serviço, a contratada deverá tomar as seguintes providências:
● Anexar evidências, caso possível, do atendimento realizado ou rotinas executadas;
● Registrar tudo o que for realizado no Sistema de Gestão de Demandas, relacionando, se possível, com casos semelhantes já conhecidos.
Figura 10 – Visão Geral do Processo de Sustentação de Sistemas
4. PROCESSO DE EVOLUÇÃO DE PEQUENO PORTE (PEP)
Trata-se de processo para lidar com situações em que as evoluções necessárias e/ou desejadas são de pequeno porte e não são elencadas como projeto. Cabe ressaltar que evoluções categorizadas como projeto são tratadas pelo PDA (Processo de Desenvolvimento Ágil).
Este processo, cuja visão geral pode ser observada na Figura 11, é composto de duas partes:
Figura 11 – Visão Geral do Processo de Evolução de Pequeno Porte
4.1. Abertura da solicitação
A necessidade de evolução deve ser relatada por um usuário demandante no Sistema de Gestão de Demandas, que tipicamente pode ser um Gestor ou Gerente de Sistema. Devido ao pequeno porte envolvido, não há formato fixo para tal relato, que é livre.
4.2. Refinamento da solicitação
Após o recebimento da solicitação, deve haver uma reunião para refinar o entendimento sobre seu teor. Nessa reunião, quaisquer detalhes devem ser coletados e registrados no caso aberto no Sistema de Gestão de Demandas.
4.3. Implementação
Seguinte ao refinamento da solicitação, deve haver então a implementação conforme solicitado. Neste passo, é importante seguir boas práticas tais como desenvolver ou evoluir testes unitários correspondentes, e seguir as premissas arquiteturais existentes na DT/MPPE. Ao final da implementação, devem ser executados os testes unitários correspondentes, cuja evidência deve ser anexada ao Sistema de Gestão de Demandas.
4.4. Manutenção da Documentação Existente
Em caso de haver documentação existente para o projeto em questão, esta deverá ser atualizada conforme as novas regras implementadas na evolução em questão.