Nº 032/2020
Nº 032/2020
COMPONENTE – GESTÃO DO PROJETO CONTRATO DE EMPRÉSTIMO Nº 4597/OC-BR
Autores
Nome | Cargo | Área | |
Xxx Xxxxx Xxxxxxxx Xxxxxxxxx | Assessora de TIC | UCP/CONEMAE/SEFAZ | |
Xxxxx Xxxx Xxxxxxxxxx xx Xxxxxxxxxxx | Coordenador-Técnico | UCP/CONEMAE/SEFAZ |
OUTUBRO/2020
1. NECESSIDADE DA CONTRATAÇÃO
1.1. IDENTIFICAÇÃO DA NECESSIDADE DA CONTRATAÇÃO
1.1.1. A Equipe de Planejamento da Contratação, composta por integrantes constantes na Resolução/Sefaz Nº 3.036, de 23 de agosto de 2019 e na Resolução/Sefaz “P” Nº 331, de 21 de outubro de 2020, elaborou este Estudo Técnico Preliminar com o objetivo de pesquisar uma Solução de Tecnologia da Informação e Comunicação (TIC) que proporcione à Coordenadoria do Núcleo Especial de Modernização da Administração Estadual (CONEMAE/SEFAZ/MS), identificar a melhor forma de garantir a manutenção e evolução, em termos técnicos e tecnológicos, dos módulos e serviços integrados ao Sistema de Gestão de Projetos de Modernização - SGPM, para análise de sua viabilidade e levantamento dos elementos essenciais que servirão para compor o Termo de Referência, de forma que melhor atenda às necessidades da CONEMAE, em conformidade com o disposto no art. 8º do Decreto Estadual n. 15.477 de 20 de julho de 2020.
1.1.2. A contratação será via Licitação na modalidade Pregão Eletrônico, conforme a Lei Federal nº 8.666/93, Lei Federal nº 10.520/2002 e Decreto Estadual 15.327/2019;
1.1.3. Na contratação do objeto, serão considerados os seguintes normativos vigentes:
a) Decreto Estadual nº 14.683/2017, que dispõe no art. 11, inciso II, que compete à Superintendência de Gestão da Informação - SGI “o planejamento e a coordenação das atividades relativas à tecnologia de informações, no que tange à sistemática, modelos, técnicas e às ferramentas, bem como definição e desenvolvimento da configuração física e lógica dos sistemas usados ou operados em rede de computadores pela SEFAZ, pelos órgãos e pelas entidades do Poder Executivo”.
b) Lei n. 8666, de 21 de junho de 1993, e suas alterações.
c) Lei n. 10.520, de 17 de julho de 2002, que institui, no âmbito da União, Estados, Distrito Federal e Municípios, nos termos do art. 37, inciso XXI, da Constituição Federal, modalidade de licitação denominada pregão, para aquisição de bens e serviços comuns, e dá outras providências.
d) Lei Complementar n. 123, de 14 de dezembro de 2006, que institui o Estatuto Nacional da Microempresa e da Empresa de Pequeno Porte.
1.2. JUSTIFICATIVA DA NECESSIDADE DA CONTRATAÇÃO
1.2.1. Na esteira da boa administração dos recursos públicos, a implementação de aprimoramentos no software de Gestão de Projetos de Modernização deve propiciar a automação das ações referentes a administração, gestão e auditoria dos projetos de financiamento contratados pelo Estado, atividades estas que, eram feitas de forma totalmente manual antes do início do desenvolvimento do referido software. A necessidade de gerir tais projetos de forma segura, a promover o controle de forma eficiente e propiciar a emissão de relatórios exigidos pelo banco e demais órgãos de controle internos e externos de forma célere, além de prover a gestão das informações de forma transparente, torna essencial a continuidade e aprimoramento do software em questão.
1.2.2. O sistema SGPM tem como principal objetivo garantir a boa operação dos processos administrativos e financeiros dos projetos de financiamento, gerando os relatórios de desempenho de cada um deles com informações das finanças e tramitações internas, buscando eficiência e rápido acesso aos dados gerenciais de suas operações. Permitirá ter um controle do planejamento orçamentário, financeiro, patrimonial e fluxo de caixa devidamente adequados e registrados. Além disso, será responsável por atender aos relatórios exigidos pelo banco e demais órgãos de controle internos e externos.
1.2.3. Sistema pioneiro em diversos aspectos relevantes, principalmente ao contemplar toda a complexa gestão financeira e de aquisições do projeto, com a possibilidade de integração ao sistema de administração financeira do estado. Permite a gestão de recursos com mais de uma moeda e a geração de todos os relatórios para a prestação de contas junto ao banco e aos demais órgãos de controle.
1.2.4. O SGPM certamente impactará em aperfeiçoamento da gestão dos projetos de financiamento, em específico do PROFISCO II - MS, facilitando a tomada de decisão e reduzindo consideravelmente o trabalho operacional necessário atualmente para atender às normas e exigências.
1.2.5. Ademais, existe a necessidade de se oferecer para uso oficial os dados de maneira consolidada sobre os projetos de financiamento do Estado de Mato Grosso do Sul. Nesse sentido, a efetivação do projeto SGPM volta-se às necessidades da Fazenda Pública quanto ao cumprimento do seu dever de gerir, acompanhar e auditar os projetos de financiamento em andamento, facilitando o cruzamento de informações entre os sistemas legados e garantindo a veracidade, o sigilo e a rastreabilidade sobre esses dados e a sua utilização oficial.
1.2.6. O Sistema SGPM é responsável por atividades que são essenciais ao funcionamento da UCP (Unidade de Coordenação do Projeto). Assim, uma plataforma e uma metodologia de trabalho dinâmica e completa propiciarão à UCP/CONEMAE/SEFAZ/MS condições de manter o funcionamento das atividades referentes ao controle e gestão dos projetos de financiamento, resultando em efetividade, sob pena de prejuízo ao interesse público.
1.2.7. Cabe ressaltar que para o atendimento do item (b) do Artigo 6.0 das Normas Gerais do Contrato de Empréstimo n. 4597 OC/BR, o Mutuário se compromete a manter e a que o Órgão Executor e a Agência de Contratações, se houver, mantenham um sistema de gestão financeira aceitável e confiável que permita oportunamente, no que diz respeito aos recursos do Projeto: (i) o planejamento financeiro; (ii) o registro contábil, orçamentário e financeiro; (iii) a administração de contratos; (iv) a realização de pagamentos; e (v) a emissão de relatórios de auditoria financeira e de outros relatórios relacionados com os recursos do Empréstimo, da Contrapartida Local e de outras fontes de financiamento do Projeto, se for o caso.
1.2.8. Diante do exposto, solicitamos a contratação dos serviços de tecnologia da informação para o aprimoramento e desenvolvimento das demandas relacionadas à gestão dos projetos de financiamento (modernização), com o fornecimento de melhorias na operacionalização do software de gestão e controle, de modo a acompanhar as inovações tecnológicas do mercado de informática e comunicação, garantindo assim a boa qualidade dos serviços prestados.
1.3. CLASSIFICAÇÃO DO OBJETO DA CONTRATAÇÃO COMO SOLUÇÃO DE TIC (Art. 5º, Parágrafo Único)
1.3.1. O Decreto Estadual n. 15.477 de 20 de julho de 2020, em seu Art. 2º, XI, assim considera:
“XI-Solução de Tecnologia da Informação e comunicação (STIC): conjunto de bens e/ou de serviços que apoiam processos de negócio, mediante a conjugação de recursos, processo e técnicas utilizados para obter, processar, armazenar, disseminar e fazer uso de informações”.
1.3.2. Em virtude disto, o entendimento acerca da conceituação apresentada se baseia na utilização de bens (hardware), sistemas de informação (software) e/ou serviços de TIC, tendo como finalidade o processamento de dados e informações digitais para o alcance dos resultados pretendidos pela contratação.
1.3.3. Considerando que a solução em estudo engloba elementos com as características descritas acima, de modo a atender à necessidade que a desencadeou, pode-se afirmar que esta contratação compreende uma solução de tecnologia, e assim sendo deverá seguir as diretrizes estabelecidas no Decreto Estadual supracitado.
2. REQUISITOS DA CONTRATAÇÃO
2.1. REQUISITOS DE NEGÓCIO
2.1.1. A implementação de aprimoramentos nos softwares deve contemplar as etapas de instalação, migração de dados (se houver necessidade), acompanhamento, treinamentos de pessoal em novas funcionalidades, manutenção corretiva, evolutiva, suporte técnico in loco, melhorias e criação de novas ferramentas para a execução adequada do objeto contratado;
2.1.2. A CONTRATADA deverá efetuar o desenvolvimento dos módulos e serviços por meio dos quais os processos de negócio serão executados. Estes módulos integrarão o Sistema de Gestão de Projetos de Modernização.
2.1.3. Busca-se também a ampliação e criação de novas ferramentas tecnológicas que proporcionem uma melhoria na gestão, operação, auditoria e monitoramento dos projetos de financiamento, além de facilidade de inserção de dados, interação com o público interno/externo e gestão do conhecimento;
2.1.4. Elaboração e aperfeiçoamento das bases para utilização nos Sistemas de BI;
2.1.5. Para o desenvolvimento dos módulos, a CONTRATADA deverá utilizar a plataforma e o processo de desenvolvimento de software indicado pela SGI, gerando os artefatos pertinentes a cada fase do ciclo de desenvolvimento de sistemas previsto;
2.1.6. A execução das atividades deverá respeitar o ciclo de 2 semanas, ou seja, quinzenalmente deverão ser apresentados produtos/entregas aferíveis e consistentes;
2.1.7. Entre as novas funcionalidades ou ferramentas, podemos destacar:
2.1.7.1. Definição de metodologia para o processo estratégico de projeção, priorização e alocação de recursos de médio prazo;
2.1.7.2. Elaboração de manuais dos procedimentos de planejamento, orçamento, finanças, contabilidade e patrimônio, em atenção às normas contábeis aplicadas ao setor público;
2.1.7.3. Implantação de sistema integrado com módulos de: planejamento; execução orçamentária, contábil, financeira e patrimonial, com a conformidade contábil e prestação de contas eletrônicas;
2.1.7.4. Implantação de módulos de gestão operacional, monitoramento e auditoria;
2.1.7.5. Gestão financeira, com fluxo de caixa, controle de saldos, conciliações bancárias, controle de contas por pagar;
2.1.7.6. Gestão do patrimônio; e
2.1.7.7. Gestão documental.
2.1.8. Conforme apregoa a metodologia ágil, a qualquer momento a relação poderá sofrer acréscimo (s) ou decréscimo (s), conforme a CONTRATANTE descontinue determinado serviço, sistema ou módulo ou ocorra o desenvolvimento de novo sistema/módulo pela CONTRATADA, devendo este compor o arcabouço de sistemas a serem mantidos e atualizados pela CONTRATADA, sem que haja qualquer ônus à CONTRATANTE;
2.1.9. As entregas estarão relacionadas com a base de informações consolidadas advindas das diversas fontes da Administração Pública, com mecanismos para consolidar nessa base de dados informações advindas de fontes externas, como por exemplo, o Sistema de Gestão de Finanças e o Sistema Gestor do Patrimônio, com facilidades (interfaces, aplicativos ou similares) amigáveis e prontamente disponíveis para consulta, manejo e utilização dos dados e com mecanismos tecnológicos que garantam a segurança e a rastreabilidade de acesso aos dados.
2.2. REQUISITOS LEGAIS
2.2.1. O presente Estudo Preliminar se refere a item de contratação vinculado ao Componente Gestão do Projeto, do Contrato de Empréstimo Nº 4597/OC-BR - Projeto de Modernização da Gestão Fiscal do Estado de Mato Grosso do Sul (PROFISCO II-MS), celebrado junto ao Banco Interamericano de Desenvolvimento (BID) e está alinhado aos seguintes documentos:
2.2.1.1. POA (Plano Operativo Anual).
2.2.1.2. PEP (Plano de Execução Plurianual).
2.2.1.3. Plano Financeiro.
2.2.1.4. PA (Plano de Aquisições) 002 - Item 3.8 – Aprovado em 08/09/2020 (CBR-1710/2020).
2.2.1.5. Lei Nº 5.488, de 18 de dezembro de 2019 (PPA 2020-2023).
2.2.1.6. Lei Nº 5.488, de 18 de dezembro de 2019 (PPA 2020-2023).
2.2.1.7. Manual de Gestão Financeira do BID;
2.2.1.8. Manual de Gestão Financeira do Estado do Mato Grosso do Sul;
2.3. REQUISITOS DE ARQUITETURA TECNOLÓGICA
2.3.1. A presente contratação deve possibilitar a sustentação e manutenção evolutiva do software (SGPM
– Sistema de Gestão de Projetos de Modernização), em ambiente WEB, com a seguinte estrutura de desenvolvimento:
2.3.1.1. | Servidor Web: Apache: 2.4; | |
2.3.1.2. | Linguagem: PHP 7.3; | |
2.3.1.3. | Framework: Laravel 5.8; | |
2.3.1.4. | Banco de dados: SqlServer. | |
2.3.2. Deverá | também ser aderente ao ambiente tecnológico da Superintendência de Gestão | da |
Informação (SGI), o qual se encontra descrito abaixo:
2.3.2.1. Infraestrutura Computacional:
2.3.2.1.1. Mainframe IBM z/Series, Sistema Operacional IBM z/OSe 1.8;
2.3.2.1.2. Servidores plataforma x86 com Windows Server e Linux Server;
2.3.2.1.3. Microcomputadores PC com Windows XP, Windows 7 e Windows 10.
2.3.2.2. Infraestrutura de Dados (Bases de Dados):
2.3.2.2.1. Adabas ‘C’ (Hierárquico);
2.3.2.2.2. Arquivos de sistemas de produção no mainframe (VSAM e outros);
2.3.2.2.3. Microsoft SQL Server;
2.3.2.2.4. INFORMIX;
2.3.2.2.5. Oracle;
2.3.2.2.6. PostgreSQL;
2.3.2.2.7. MySQL.
2.3.2.3. Infraestrutura de Software:
2.3.2.3.1. Correio Eletrônico: Atmail Server;
2.3.2.3.2. Servidor de Aplicação: Jboss, Tomcat, Glassfish;
2.3.2.3.3. Web Server: MS-IIS e Apache;
2.3.2.3.4. CMS: Wordpress e Sharepoint;
2.3.2.3.5. Desenvolvimento: PHP, ASP / XXX.XXX, Delphi, COBOL, Natural, JCL, AdaSql, Java, MicroFocus COBOL, Lotus Notes, VBScript, JavaScript, Scripts de comandos DOS (BAT/CMD), Powershell;
2.3.2.3.6. Conversão de Interface: Applinx;
2.3.2.3.7. Integrador de aplicações (middleware): EntireX;
2.3.2.3.8. BI e datawarehouse: QlikView, Tableau, Cognos;
2.3.2.3.9. Monitor de Transações (mainframe): Com-plete; 2.3.2.3.10. Emulador de Terminais: Extra! Personal Client e TN3270.
2.4. REQUISITOS DE PROJETO E DE IMPLEMENTAÇÃO
2.4.1. SOLICITAÇÃO DOS SERVIÇOS:
2.4.1.1. O fluxo de solicitação de serviços obedecerá ao fluxo do processo de gestão de demandas da SGI – SEFAZ/MS. Este processo se inicia na CONEMAE, quando da necessidade de serviços em Tecnologia da Informação;
2.4.1.2. Como primeiro passo do projeto de desenvolvimento, deverá ser construído entre as partes (CONTRATANTE E CONTRATADA), um Backlog prévio, com previsão de funcionalidades a serem desenvolvidas. Tal Backlog não impossibilita sua alteração, através de inclusão ou extinção de funcionalidades, de acordo com a necessidade do CONTRATANTE, desde que devidamente registrado.
2.4.1.3. A Metodologia de Desenvolvimento de Software tem por objetivo orientar a estruturação, execução, gestão, fiscalização e governança das entregas de soluções de TI e deverá ser seguido pela CONTRATADA. Consiste em um conjunto de atividades executadas ao longo das fases do processo de forma iterativa e incremental prevendo seu respectivo marcos e artefatos de entrega. Ressalta-se que essa metodologia foi definida seguindo as boas práticas já adotadas pelo mercado.
2.4.1.4. Serão utilizados como instrumentos de formalização de demandas, uma vez constituída a sua necessidade, o Ofício, a Comunicação Interna – CI ou o Canal de Atendimento ao Cliente em suas diversas vias (e-mail, site ou telefone);
2.4.1.5. Uma vez identificada, a demanda é dividida em uma ou mais tarefas que também são registradas no Sistema de Gestão de Tarefas vinculadas a essa demanda. Essas tarefas são encaminhadas eletronicamente ao setor responsável por executá-las, aqui chamados de unidade executora;
2.4.1.6. Uma vez recebida a tarefa repassada, a unidade executora inicia seu processo de execução de tarefas.
2.4.2. FLUXO DE EXECUÇÃO E ACOMPANHAMENTO:
2.4.2.1. As unidades de execução serão divididas em equipes funcionais. Essas equipes serão responsáveis por um conjunto específico de tipos de atividades;
2.4.2.2. Uma vez registrada a tarefa no Sistema de Gestão de Tarefas é identificada a equipe que irá atendê-la. Toda equipe possui um responsável por receber, analisar e tratar com o Demandante, e discutir suas tarefas, ordená-las em prioridades, posicioná-las na fila de execução e repassá-las para a equipe de desenvolvimento.
2.4.2.3. Esse ordenamento de prioridades junto ao demandante, gerará para a reunião de planejamento de sprint, o detalhamento do que irá ser desenvolvido no próximo ciclo, ou ainda o que irá compor um incremento de software (Product Backlog);
2.4.2.4. O Product Backlog é o acordo firmado entre demandante e demandado, devendo, portanto, ser assinado pelos representantes das partes;
2.4.2.5. O Product Backlog poderá ser alterado, com consentimento de ambas as partes, em razão de surgimento de outras prioridades, normativas, legislativas ou de adequações não previstas;
2.4.2.6. Ao posicionar uma tarefa na fila de execução, a equipe técnica realiza um processo de detalhamento da tarefa, muitas vezes dividindo-a em tarefas menores e mais simples. Esse processo é chamado de refinamento da fila de tarefas e executado com toda tarefa que chega para uma determinada equipe;
2.4.2.7. As tarefas resultantes do refinamento da fila de tarefas, ou seja, as tarefas menores e mais simples, serão doravante denominadas atividades – Sprint Backlog;
2.4.2.8. Após o refinamento da fila de tarefas é realizada uma avaliação técnica de cada atividade quanto a sua complexidade. A equipe avalia tecnicamente cada atividade de acordo com seu grau de complexidade. Essa classificação deve ser registrada no sistema de gestão de tarefas. Uma atividade não pode ser executada sem ter sua classificação de complexidade aferida e registrada;
2.4.2.9. Após a atividade estar detalhada e com sua classificação de complexidade aferida e registrada, ela está pronta para ser executada por um membro da equipe;
2.4.2.10. O acompanhamento da execução das tarefas é feito através do Sistema de Gestão de Tarefas, onde todas as tarefas detalhadas e não detalhadas estão registradas. Esse sistema permite o acompanhamento de todas as tarefas solicitadas para uma equipe, quais tarefas estão em execução e quais foram finalizadas;
2.4.2.11. É dever de todo profissional, registrar suas atividades no Sistema de Gestão de Tarefas;
2.4.2.12. Uma tarefa só deve ser executada por um profissional da CONTRATADA se houver um registro eletrônico para a mesma;
2.4.2.13. Ao término da execução da atividade, o profissional da CONTRATADA deverá registrar no sistema o encerramento da mesma;
2.4.2.14. A CONTRATADA deverá utilizar o seu próprio Sistema de Gestão de Tarefas, se assim desejar, ou poderá utilizar a ferramenta da SGI/SEFAZ/MS, caso esteja disponível;
2.4.2.15. Deve-se notar que a existência do sistema na SGI/SEFAZ/MS não exime a CONTRATADA de fornecer a ferramenta de controle de atividades executadas, porém, é permitido que a ferramenta fornecida se conecte ao sistema indicado e busque informações na mesma.
2.4.3. ATIVIDADES MEIO
2.4.3.1. O fluxo de demandas descrito anteriormente atende plenamente a avaliação e acompanhamento de atividades fim, como desenvolvimento de código de sistemas e testes dos mesmos. No entanto, existem tipos de atividades que são executadas ao longo do fluxo para que seja possível a realização da atividade fim, tal como o refinamento da fila de trabalho de uma equipe;
2.4.3.2. Para registro das UST destas atividades, os profissionais que as executarem tem a obrigação de lançá-las no sistema fornecido pela empresa para acompanhamento de tarefas. O profissional realizará a avaliação da complexidade de cada atividade lançada, garantindo assim o fiel retrato do seu esforço despendido;
2.4.3.3. As atividades meio são avaliadas pelos profissionais da etapa seguinte no fluxo de demandas, ou seja, o próximo ator no fluxo do processo deverá homologar a etapa anterior e dar o seu aceite. Caso uma atividade seja recusada, a mesma não é mais considerada concluída e deve ser corrigida e submetida a nova avaliação, até que seja aprovada.
2.4.3.4. Os serviços deverão ser executados nas dependências da CONTRATADA, ou pela sua natureza, em local a ser designado pela CONTRATANTE, podendo ser realizado inclusive nas dependências da CONTRATANTE;
2.4.3.5. A CONTRATADA deverá designar os profissionais conforme as necessidades que se verificarem, observado o volume e complexidade dos trabalhos, conforme perfil e qualificação definidos;
2.4.3.6. A CONTRATANTE poderá solicitar a substituição do profissional que não execute os serviços de forma adequada, a seu critério, por outro de mesma qualificação;
2.4.3.7. Para os serviços realizados no ambiente da CONTRATANTE, os profissionais deverão executá-los conforme jornada de trabalho da CONTRATANTE e a legislação trabalhista em vigor, o que será controlado pela CONTRATADA e supervisionado pela CONTRATANTE.
2.4.4. DA MANUTENÇÃO CORRETIVA, MANUTENÇÃO EVOLUTIVA E SUPORTE TÉCNICO
2.4.4.1. A manutenção corretiva deverá ser realizada de forma a garantir a permanência ininterrupta da operacionalidade da solução quanto a sua especificação original, corrigindo quaisquer eventuais anomalias de funcionamento, correção de erros ou de falhas técnicas;
2.4.4.2. As manutenções corretivas compreendem a detecção, o diagnóstico e a correção de erros ou falhas ocorridas em ambiente de produção. Como erro ou falha entende-se a geração de resultado diferente do previsto, em decorrência da não observância de regra de negócio ou em decorrência de problema no ambiente computacional onde a aplicação é executada e que para sua solução exija intervenção na aplicação;
2.4.4.3. Durante a vigência do Contrato, as manutenções corretivas, que foram oriundas especificamente de anomalias de funcionamento, correção de erros ou falhas técnicas, são objeto de garantia da solução de gestão dos programas, de responsabilidade exclusiva da CONTRATADA e não devem resultar em aumento de despesas para a CONTRATANTE;
2.4.4.4. As manutenções de caráter legal compreendem a implementação de regras de negócio definidas por normativos de órgãos regulamentadores, fiscalizadores e/ou de controle aos quais a instituição está subordinada. Tem por objetivo manter o software atualizado em termos de legislação e decorrente aplicabilidade ao negócio;
2.4.4.5. Durante a vigência do Contrato, a manutenção de caráter legal que porventura venha a ser exigida por órgãos regulamentadores e que demande adequação no software será executada pela CONTRATADA dentro de prazo pactuado entre as partes, sendo que a implementação das demandas legais ocorrerá após comunicação da equipe da CONEMAE;
2.4.4.6. A manutenção evolutiva tem por intuito melhorar a qualidade do software, acrescentando novas funcionalidades limitadas ao objeto contratado, melhorando seu desempenho e buscando obter melhor legibilidade ou adequação a alguns paradigmas de programação;
2.4.4.7. As manutenções contratadas serão realizadas através do desenvolvimento que deverá ser executado de forma interativa e incremental, por meio de ciclos de no máximo trinta dias (15 dias por default), que terão como resultado um produto ou serviço utilizável pela CONEMAE;
2.4.4.8. As publicações de novas legislações que impactam em alterações ou implementações ocorrerão após comunicação da equipe da CONEMAE, dentro do prazo razoável a ser definido;
2.4.4.9. Os serviços englobam o levantamento de requisitos, gerenciamento, desenvolvimento da arquitetura, análise e projeto, codificação, validação, verificação, gerenciamento de boas práticas de testes e a gestão de configuração das diversas funcionalidades que compõem o software;
2.4.4.10. No início de cada ciclo deverá ser realizada reunião de planejamento, pré-agendada, que ocorrerá preferencialmente nas dependências da CONTRATADA, em Campo Grande/MS, para o alinhamento das funcionalidades de maior prioridade que serão desenvolvidas
com o respectivo entendimento do objetivo deste ciclo através dos itens que serão trabalhados;
2.4.4.11. Deverão estar presentes os usuários do software, se necessário, e toda a equipe técnica do projeto devidamente qualificada para realizar as atividades constantes no objeto desta contratação;
2.4.4.12. As reuniões dos ciclos deverão ser preferencialmente presenciais, com a participação de todos os envolvidos no projeto;
2.4.4.13. As datas de realização das reuniões serão definidas na reunião de encerramento do ciclo planejado elaborado em conformidade com o intervalo temporal para os ciclos estabelecido neste documento;
2.4.4.14. O serviço de desenvolvimento envolverá atividades diárias de monitoramento para sincronizar as atividades de desenvolvimento com as necessidades da CONEMAE, assim será possível minimizar os riscos, identificar impedimentos e inspecionar o progresso do projeto em direção ao objetivo do ciclo planejado;
2.4.4.15. Ao final do ciclo planejado, deverá ser realizada reunião para apresentação das novas funcionalidades que serão implantadas e que já estarão disponíveis para serem utilizadas conforme as necessidades específicas da CONEMAE, com possibilidade de análise para verificar se o projeto está obtendo o êxito esperado;
2.4.4.16. A CONTRATADA poderá escolher as funcionalidades que serão desenvolvidas durante o ciclo, para atender as necessidades da CONEMAE, segundo as prioridades definidas na reunião de planejamento ou segundo outro critério devidamente justificado, cabendo ao CONEMAE/SEFAZ/MS aceitar a proposta ou indicar mudanças ainda nessa reunião;
2.4.4.17. A entrega dos produtos pela CONTRATADA e a aceitação destes pela CONEMAE/SEFAZ/MS evidenciarão a execução dos serviços em conformidade com os requisitos e padrões de qualidade especificados para a contratação, não sendo, portanto, aceitos, sob nenhuma hipótese, produtos não conformes;
2.4.4.18. A implantação da solução deverá ocorrer ao final de cada ciclo ou interação, garantindo assim a inclusão do usuário final no desenvolvimento do projeto, visando minimizar os impactos nos processos organizacionais;
2.4.4.19. Para implantação, deverá haver aprovação de todas as funcionalidades, sem a existência de pendência em qualquer fase dos ciclos de desenvolvimento, sendo que após análise e aprovação, deverá ser disponibilizado o software no ambiente de produção;
2.4.4.20. O treinamento deverá ser realizado preferencialmente nas dependências da CONTRATADA, que será responsável por todo planejamento do treinamento;
2.4.4.21. O treinamento será realizado sempre que necessário com o objetivo de capacitar os usuários para utilizar o software e que eles possam atuar como multiplicadores de conhecimento dentro da instituição;
2.4.4.22. O suporte técnico da solução descrito neste termo deve garantir a plena operacionalidade da solução durante toda a vigência contratual;
2.4.4.23. O suporte técnico deve prestar o atendimento em dias úteis, de segunda-feira a sexta- feira em horário compreendido entre 08:00 e 18:00 horas (horário local) através de consultas in loco, telefone, chamados ou e-mail dirigidos por funcionários da CONEMAE/SEFAZ/MS sobre questões de operacionalidade do software, dúvidas que possam surgir durante os trabalhos ou qualquer outro problema, visando garantir a permanência ininterrupta da operacionalidade do software;
2.4.4.24. Deverá possuir atendimento local no município de Campo Grande/MS, oferecendo suporte técnico a todos os componentes da solução ofertada;
2.4.4.25. Deverá prover infraestrutura necessária ao desenvolvimento das atividades objeto desta contratação no local de trabalho do CONTRATANTE, com materiais adequados, tais como computadores, rede, internet, mesas e cadeiras.
2.5. REQUISITOS DE IMPLANTAÇÃO
2.5.1. A distribuição é a maneira utilizada para realizar o processo de implantação em ambiente de produção. Devido a característica da aplicação será necessária a abertura de uma demanda específica para cada necessidade apresentada. Na distribuição ajustes específicos ao ambiente operacional podem ser realizados, afim de garantir o comportamento funcional da aplicação.
2.6. REQUISITOS TEMPORAIS
2.6.1. A assinatura do contrato será realizada no prazo de até 5 (cinco) dias úteis, após regular convocação da licitante adjudicatária, podendo este prazo ser prorrogado, mediante justificativa fundamentada e aceita;
2.6.2. O contrato deverá ser assinado pelo representante legal da licitante adjudicatária, que deverá apresentar documento de procuração pública ou particular com firma reconhecida, que comprove os necessários poderes para firmar Contrato. Em sendo sócio, proprietário, dirigente ou assemelhado da empresa, deverá apresentar cópia do respectivo Estatuto ou Contrato Social no qual estejam expressos seus poderes para exercer direitos e assumir obrigações em nome da empresa;
2.6.3. Para esta demanda, deverá ser observado ainda, o seguinte prazo:
2.6.3.1. Reunião Inicial: A contratada será convocada para reunião inicial correspondente ao contrato, a ser marcada pela equipe de fiscalização em até 5 (cinco) dias úteis após a publicação da Portaria de Fiscalização. A reunião inicial poderá ser realizada por meio de Skype ou Ligação telefônica, também chamado ‘call’;
2.6.4. A solução será instalada nos computadores da Superintendência de Gestão da Informação (SGI/SEFAZ/MS) (aplicativo e banco de dados), sito à rua Delegado Osmar de Camargo, s/n, no município de Campo Grande/MS.
2.7. REQUISITOS DE GARANTIA E MANUTENÇÃO
2.7.1. Todos os serviços entregues pela CONTRATADA deverão ser cobertos por garantia técnica durante a vigência do contrato e, adicionalmente, durante 3 (três) meses após o encerramento contratual;
2.7.2. Durante o prazo de garantia do serviço, a CONTRATADA deverá manter canal de comunicação por telefone, e-mail ou sistema informatizado e cumprir os prazos definidos no Acordo de Nível de Serviço para as atividades de garantia técnica;
2.7.3. A não observância do prazo para correção de defeito implica execução das penalidades cabíveis estabelecidas em contrato. Havendo necessidade motivada, a área requisitante poderá definir prazos singulares para determinadas soluções. No entanto, tal decisão deverá ser tecnicamente embasada e os prazos específicos deverão constar no Termo de Referência, uma vez que todas as condições de prestação dos serviços deverão ser conhecidas dos potenciais provedores previamente à contratação. Deverá ser verificada junto à área competente a viabilidade de retenção da garantia contratual (art. 56 §2º da Lei nº 8.666/93) até o encerramento dos prazos de garantia técnica, visando a proteger a Administração de eventuais danos provocados pelo não atendimento dos requisitos relacionados à garantia técnica;
2.7.4. Os serviços de manutenção previstos contarão com garantia de 90 dias contados do aceite do Gerente de Produto. Caso seja detectado erro em aplicativo já distribuído, cujo código ainda está em garantia elaborado pela CONTRATADA, cabe a essa a correção, independentemente de o sistema encontrar-se em regime de monitoramento. Esta correção se dará por uma Demanda Corretiva e estará vinculada com os níveis de serviços de um incidente, sendo necessária a classificação do incidente para obter o tempo de resposta para a prestação do serviço;
2.7.5. No caso de erro detectado nos últimos 30 dias da vigência do contrato, incluída os possíveis aditivos, a garantia será prorrogada, de modo que o novo término da garantia se dê 30 dias após a implantação da correção do erro em produção. É facultado a SGI (Superintendência de Gestão da Informação), em situações excepcionais ou emergenciais, realizar intervenções em código produzido ou mantido pela CONTRATADA. Nestes casos, as classes ou arquivos fonte alterados ou impactados pela alteração perderão a garantia. A abertura de Demanda de Manutenção Evolutiva, Adaptativa, Corretiva ou Perfectiva (equalização, performance) para que a CONTRATADA realize de forma definitiva as alterações executadas em caráter excepcional pela CONEMAE, restabelece a garantia das classes ou arquivos fonte alterados ou impactados por novos 90 dias.
2.8. REQUISITOS DE CAPACITAÇÃO
2.8.1. Quando aplicável, a CONTRATADA deverá realizar capacitação de usuários internos e/ou da equipe técnica do requisitante nas soluções entregues, conforme definição, sem custo adicional;
2.8.2. Deverá ser observada a necessidade de transferência do conhecimento das soluções desenvolvidas para a área de tecnologia da SGI, a fim de garantir a necessária independência do requisitante em relação a CONTRATADA. Essa transferência se dará ao longo do projeto, minimamente, através do repasse de toda documentação e código-fonte da solução produzida logo após a sua entrega em ambiente de produção ou quando for mais conveniente para o requisitante. Ademais, nos últimos 3 (três) meses precedentes ao encerramento do contrato entre a CONTRATADA e o CONTRATANTE
deverá haver repasse de conhecimentos sobre processos e tecnologias, com o objetivo de garantir a continuidade do serviço pelo requisitante ou por terceiros por ele indicados.
2.9. REQUISITOS DE EXPERIÊNCIA PROFISSIONAL DA EQUIPE
2.9.1. Caberá à CONTRATADA manter profissionais capacitados a desenvolver as atividades pertinentes para a plena execução do objeto contratual. Sendo-lhe, exigível, no mínimo, profissionais com experiência comprovada, titulação e grau de escolaridade compatível com o nível de serviço a ser desenvolvido. Tais comprovações se darão no momento de assinatura do Contrato.
2.9.2. Considerando a complexidade do ambiente computacional da SGI/SEFAZ/MS e a criticidade das informações existentes, não é razoável permitir que a manutenção dos sistemas em operação seja realizada por profissional sem o preparo técnico adequado. Com vistas a reduzir o risco de falhas nos sistemas, a CONEMAE/SEFAZ/MS juntamente com a SGI, buscou formas de assegurar o nível de conhecimento do profissional que será encarregado de tratar cada área do desenvolvimento de sistemas. Essa medida não elimina os riscos, mas os mitiga de forma considerável;
2.9.3. Os serviços deverão ser executados por especialistas habilitados, considerando os perfis definidos nas tabelas de perfis profissionais, a capacitação deve ter base em programas de formação, em diligência de capacidade técnica e certificações oficiais, oferecendo indícios de capacidade técnica mínima para atender as complexidades especificadas neste Estudo Técnico, requisito este em consonância com o Tribunal de Contas da União:
“Em diversas assentadas, este Tribunal reconheceu como válida a exigência de comprovação de ambos os ângulos da capacitação técnica, que deverá abranger tanto o aspecto operacional (demonstração de possuir aptidão para o desempenho de atividade pertinente e compatível com o objeto do certame) como o profissional (deter, no quadro permanente, profissionais aptos a executar serviço de características semelhantes àquele pretendido pela Administração). Nesse sentido, vale destacar as Decisões nº 395/95- Plenário, 432/96-Plenário, 217/97-Plenário, 285/00Plenário, 2.656/2007- Plenário, bem como o Acórdão nº 32/20031ª Câmara. (Acórdão nº 1.265/2009, Plenário, rel. Min. Xxxxxxxx Xxxxxx)”
“O inciso I do § 1º do art. 30 da Lei nº 8.666/93 disciplina justamente a capacitação técnico-profissional, não havendo dúvidas nesse aspecto. A controvérsia que poderia ser levantada relaciona-se à possibilidade de exigência de capacidade técnico operacional, tendo em vista o veto presidencial ao inciso II do § 1º do art. 30, que disciplinava essa questão. No entanto, tanto a doutrina como a jurisprudência desta Corte propugnam por
sua possibilidade. (Acórdão nº 1.332/2006, Plenário, rel. Min. Xxxxxx Xxxxxxx Xxxxxxxxx). ”
2.9.4. Desta forma, a execução dos serviços exigirá uma equipe técnica composta de profissionais com experiência em serviços similares, indispensáveis para o desempenho dos trabalhos. Na tabela abaixo são informadas as exigências mínimas de formação, certificação e experiência dos perfis requisitados para atuar nos perfis durante a execução do contrato:
Perfil | Formação / Certificação | EXPERIÊNCIA COMPROVADA1 |
Analista Product Owner (PO) - Sênior | • Formação Superior Completa, reconhecida pelo MEC em Processamento de Dados, Sistemas de Informação, Informática, Ciências da Computação, Engenharia da Computação ou outra formação correlata; • Certificado CSPO – (“Certified Scrum Product Owner”); | • Com experiência profissional na área afim ao Negócio (comprovação poderá ser através de currículo) |
Analista Scrum Master (SM) - Sênior | • Formação Superior Completa, reconhecida pelo MEC em Processamento de Dados, Sistemas de Informação, Informática, Ciências da Computação, Engenharia da Computação ou outra formação correlata; • Certificado CSM – (“Certified Scrum Master”); | • Com experiência profissional na área afim ao Negócio (comprovação poderá ser através de currículo). |
Analistas Gerais/Programadores Sênior | • Formação Superior Completa, reconhecida pelo MEC em Processamento de Dados, Sistemas de Informação, Informática, Ciências da Computação, Engenharia da Computação ou outra formação correlata; | • Com experiência profissional na área afim ao Negócio; |
1 Para comprovação da capacitação técnica dos analistas gerais e analistas programadores, os currículos deverão ser apresentados no ato da assinatura do contrato, sendo necessário a apresentação de pelo menos um para cada função informada.
Analistas Gerais/Programadores Pleno | • Formação Superior Completa, reconhecido pelo MEC em Processamento de Dados, Sistemas de Informação, Informática, Ciências da Computação, Engenharia da Computação; | • Com experiência profissional na área afim ao Negócio. |
Analistas Gerais/Programadores Junior | • Formação Superior Completa, reconhecida pelo MEC em Processamento de Dados, Sistemas de Informação, Informática, Ciências da Computação, Engenharia da Computação ou outra formação correlata; | • Com experiência profissional na área afim ao Negócio. |
Web Designer | • Formação Superior Completa, reconhecida pelo MEC em Processamento de Dados, Sistemas de Informação, Informática, Ciências da Computação, Engenharia da Computação, web designer ou outra formação correlata; | • conhecimentos em design responsivo e flat design; • pleno domínio de softwares do pacote Adobe, como Photoshop, Illustrator, InDesign e WordPress; • boas noções de programação front-end (CSS, HTML5 e JavaScript), usabilidade e Arquitetura de Informação. |
Analista de Negócios | • Formação superior completa; | • Desejável experiência em segmentos de TI com visão comercial e gestão. (comprovação poderá ser através de currículos) |
2.10. REQUISITOS DE FORMAÇÃO DA EQUIPE
2.10.1. Nenhum profissional envolvido na contratação poderá acumular perfil/função, ou seja, a CONTRATADA deverá disponibilizar de forma fixa e dedicada, profissionais para cada perfil exigido, sendo no mínimo 3 profissionais mais um preposto. Portanto, deverá a CONTRATADA compor sua equipe técnica com no mínimo, os seguintes perfis:
2.10.1.1. Preposto - responsável técnico-administrativo com poderes de representante legal para tratar de todos os assuntos relacionados ao contrato, atuando à luz da MP-IN nº 04/2014 e suas revisões, e em atenção aos arts. 68 da Lei nº. 8.666/93 e art. 4o do Decreto nº 2.271/97.
2.10.1.2. Analistas sênior;
2.10.1.3. Analistas Pleno.
2.10.2. Havendo necessidade, outros perfis profissionais poderão ser convocados, desde que os perfis sejam os citados acima e o quadro mínimo seja mantido.
2.10.3. CARACTERÍSTICAS DOS PROFISSIONAIS
2.10.3.1. Por seguir orientação majoritariamente ágil, a metodologia da SGI não transforma funções do desenvolvimento de software (como análise de requisitos, testes etc.) em cargos. Por isso, não há cargos específicos para cada uma dessas funções (como, por exemplo, Analista de Requisitos, ou Analista de Interface). Toda a equipe deverá ter, de maneira conjunta, a competência necessária para executar todas as camadas incluídas no processo de desenvolvimento de software. Conforme afirmado anteriormente, espera-se multidisciplinaridade dos funcionários da CONTRATADA. Tal perfil de funcionário é comumente conhecido como “full stack developer”, e visa a valorizar as habilidades e os conhecimentos de computação da equipe, em linha com o que pregam as orientações “ágil” e o movimento do “software craftsmanship”. Dentre os conhecimentos e habilidades requisitados, incluem-se:
a) Servidor e “hosting” da aplicação
i. Conhecimentos sobre a camada de rede, necessários ao diagnóstico de problemas;
ii. Conhecimentos sobre constrangimentos de performance possivelmente causados por hardware;
iii. Desenho da arquitetura para escalabilidade da aplicação;
iv. Desenho para, eventualmente, prever sistemas com redundância e sincronização de dados.
b) Modelagem de dados
i. Conhecimentos sobre vantagens e desvantagens de uso de dados estruturados e não-estruturados, relacionais e não-relacionais;
ii. Capacidade de normalizar o banco de dados de acordo com as necessidades de negócio;
iii. Capacidade de criar modelo de dados completo, com suas chaves primárias e estrangeiras, índices, “views” etc.
c) Camada de mapeamento
i. Capacidade avançada de trabalhar com orientação a objeto;
ii. Capacidade de propor soluções técnicas adequadas aos problemas de negócio do projeto.
d) Camada de serviços
i. Conhecimentos de padrão MVC;
ii. Conhecimentos de REST, Micro Serviço e API’s.
e) Experiência e Interface do usuário
i. Conhecimentos sobre usabilidade;
ii. Otimização da navegação no sistema;
iii. Interação completa com o usuário (com mensagens de erro úteis, por exemplo);
iv. HTML5/CSS v. Javascript.
f) Camada de negócios
i. Entendimento da função negocial geral do software;
ii. Entendimento da relação entre funcionalidades e o valor de negócio;
iii. Entendimento de quando determinada decisão técnica tem impacto negocial e vice-versa.
2.10.3.2. O time de desenvolvimento (TD) deverá ser tecnicamente flexível, sendo composto por analistas que tenham capacidade de trabalhar fora de sua área principal de especialização. Por exemplo, imaginemos um analista-geral cuja principal especialização é o levantamento de requisitos. Para que o TD mantenha sua agilidade e os Sprints possam ser executados nos prazos combinados, espera-se que esse profissional possa ajudar em outras funções, como por exemplo, na parte de testes ou na modelagem do banco de dados.
2.10.3.3. Ter um profissional 100% dedicado a requisitos não seria eficiente, pois não haveria demanda suficiente para esse profissional em apenas um projeto ou um Sprint. Uma possível solução seria alocar esse profissional para vários projetos ao mesmo tempo, mas isso seria contrário à metodologia Scrum adotada pela SGI, que preconiza que uma pessoa deve estar inteiramente voltada para apenas um projeto por vez. A formação multidisciplinar dos colaboradores da CONTRATADA é, assim, fundamental.
2.11. REQUISITOS DE METODOLOGIA DE TRABALHO
2.11.1. Deverá ser considerada a execução dos serviços baseado no modelo de desenvolvimento iterativo-incremental, com a adoção de práticas ágeis seguindo modelos de mercado adotadas pela SGI;
2.11.2. No caso da execução dos serviços na sede da CONTRATADA, esta poderá adotar sua própria metodologia, desde que os artefatos a serem entregues sigam rigorosamente as especificações técnicas e prazos solicitados pela CONEMAE.
2.12. REQUISITOS DE SEGURANÇA DA INFORMAÇÃO
2.12.1. Os requisitos de segurança a serem observados nas aplicações em desenvolvimento ou em manutenção deverão observar as políticas, os padrões, as arquiteturas, os métodos e as técnicas previamente estabelecidas pelo SGI (Superintendência de Gestão da Informação) – a serem divulgados nas reuniões de planejamento;
2.12.2. A CONTRATADA deverá garantir a segurança das informações da CONEMAE/SEFAZ/MS e se compromete a não divulgar ou fornecer a terceiros quaisquer dados e informações que tenha recebido deste instituto no curso da prestação dos serviços, a menos que autorizado formalmente e por escrito para tal;
2.12.3. Deverá ser celebrado TERMO DE CONFIDENCIALIDADE DE INFORMAÇÕES entre a CONTRATADA e a CONTRATANTE para garantir a segurança das informações;
2.12.4. A CONTRATADA, após a assinatura do contrato, por meio de seu representante, assinará TERMO DE CONFIDENCIALIDADE DA INFORMAÇÃO em que se responsabilizará pela manutenção de sigilo e confidencialidade das informações a que possa ter acesso em decorrência da contratação;
2.12.5. Além do termo citado, a CONTRATADA deverá apresentar para cada funcionário que vier a executar atividades referentes ao objeto da contratação, TERMO DE CIÊNCIA em que seus profissionais declaram estar cientes das responsabilidades pela manutenção de sigilo e confidencialidade;
2.12.6. A contratada deverá submeter-se às políticas de segurança da SGI e assumir todos os possíveis danos físicos e/ou materiais causados a CONEMAE/SEFAZ/MS ou a terceiros, advindos de imperícia, negligência, imprudência ou desrespeito às normas de segurança, quando da execução dos serviços, sempre atentando aos princípios de:
a) Disponibilidade – garantir aos usuários, autorizados pelo gestor do contrato, acesso às informações e aos locais de instalação dos ativos de rede, quando necessário, disponibilizando, ainda, todas as informações solicitadas pelo gestor ou fiscais quanto aos serviços executados e as condições atuais da estrutura da rede (fragilidade, oportunidades de implementações e melhorias, etc);
b) Integridade - guardar a exatidão e inteireza das informações e, ainda, documentar as atividades realizadas, objetivando manter a consistência das informações contidas nos arquivos com as condições reais das instalações;
c) Confidencialidade - garantir que as informações sejam acessíveis somente ao pessoal autorizado, não fornecendo arquivos digitalizados ou mesmo impressos a pessoas que não foram autorizadas pelo gestor do contrato;
d) Autenticidade - todas as comunicações entre a contratada e a CONTRATANTE deverão ser formalizadas e todos os documentos devidamente identificados com os dados pessoais dos responsáveis, garantindo a autenticidade dos documentos e a possibilidade de auditoria das atuações das partes envolvidas;
2.12.7. A CONTRATADA deve comunicar formal e imediatamente ao representante da CONEMAE/SEFAZ/MS qualquer ponto de fragilidade percebido que exponha a confidencialidade, integridade ou disponibilidade das informações e do serviço.
2.13. REQUISITOS SOCIAIS, AMBIENTAIS E CULTURAIS
2.13.1. Os produtos gerados em função da prestação dos serviços, bem como todas as documentações, deverão ser entregues no idioma Português do Brasil (pt-BR), com exceção de termos técnicos usuais que poderão ser apresentados em língua estrangeira;
2.13.2. A CONTRATADA deverá atender no que couber, os critérios de sustentabilidade ambiental. Destaca-se, as recomendações contidas no Capítulo III, DOS BENS E SERVIÇOS, com ênfase no art. 5º da Instrução Normativa nº 01/2010 STI/MPOG, bem como, o Decreto nº 7.746/2012 que estabelece critérios, práticas e diretrizes para a promoção do desenvolvimento nacional sustentável e a Lei nº 12.305/2010 que institui a política de resíduos sólidos, no que couber;
2.13.3. É dever da CONTRATADA observar entre outras:
a) o menor impacto sobre recursos naturais como flora, fauna, ar, solo e água;
b) preferência para materiais, tecnologias e matérias-primas de origem local;
c) maior eficiência na utilização de recursos naturais como água e energia;
d) maior geração de empregos, preferencialmente com mão de obra local;
e) maior vida útil e menor custo de manutenção do bem e da obra;
f) uso de inovações que reduzam a pressão sobre recursos naturais; e
g) origem ambientalmente regular dos recursos naturais utilizados nos bens, serviços e obras.
3. ESTIMATIVA DAS QUANTIDADES
3.1. RELAÇÃO ENTRE DEMANDA PREVISTA E QUANTIDADE A CONTRATAR
3.1.1. A demanda consiste na contratação de fornecedor para realização dos serviços de informática para aprimoramento do Sistema de Gestão de Projetos de Modernização, através de:
3.1.1.1. Análise, desenvolvimento, documentação e testes de novas funcionalidades, recursos, relatórios, repositórios de dados, tabelas, scripts, APIs ou outras rotinas de processamento e armazenamento de dados;
3.1.1.2. Manutenção corretiva e preventiva nas rotinas de software, para saneamento de eventuais erros de código ou melhoria de desempenho, armazenamento ou processamento;
3.1.1.3. Manutenção adaptativa para garantir a operacionalidade e adaptabilidade do sistema de informação frente a mudanças nos processos ou no arcabouço legal que o sustenta;
3.1.1.4. Desenvolvimento de Painéis e Dashboards, utilizando ferramenta de BI, para gestão e apresentação dos dados;
3.1.1.5. Manutenção evolutiva para garantir a atualização tecnológica da ferramenta; e
3.1.1.6. Suporte técnico aos usuários do sistema de informação.
3.1.2. Para definição do quantitativo a ser contratado foi feita análise comparativa com os demais contratos de desenvolvimento de sistemas vigentes na SEFAZ (Contrato n. 11/2019 – PSG Tecnologia Aplicada Ltda.; contrato n. 08/2018 – Mil Tec Tecnologia da Informação Ltda.; e contrato
n. 10/2019 – Infortech Informática Eireli-EPP), e que estão vinculados à medição por resultados.
3.1.3. Diante do escopo constante no item 2.1.7, estima-se um período de 18 (dezoito) meses para a prestação dos serviços, correspondendo a aproximadamente 19.000 UST´s, Unidade de medida a ser adotada por essa contratação.
4. ANÁLISE COMPARATIVA DE SOLUÇÕES EXISTENTES NO MERCADO
4.1. Dentro do presente estudo, foram analisados processos de contratações semelhantes feitas por outros órgãos e entidades, por meio de consultas a outros editais, com a finalidade de identificar a existência de novas metodologias, tecnologias ou inovações que melhor atendessem às necessidades, e as que forma identificadas foram incorporadas nesta contratação em análise.
4.2. Não restam dúvidas que existem alternativas de soluções de tecnologia da informação a serem consideradas neste processo licitatório. Entretanto, considerando as particularidades do sistema e o cenário econômico atual, alguns pontos devem ser destacados.
4.3. Por exemplo, uma alternativa seria formada pela contratação, via concurso público, de servidores com expertise em tecnologia da informação. No entanto, essa alternativa deve ser desconsiderada, tendo em vista que não há viabilidade financeira, na medida em que o Estado está no limite prudencial dos gastos com pessoal previsto na Lei de Responsabilidade Fiscal. Logo, não haveria possibilidade jurídica de realização de concurso público neste momento;
4.4. No entanto, a área de tecnologia de informação não é a atividade fim da Secretaria de Estado de Fazenda (SEFAZ/MS), de modo que a legislação permite a terceirização da atividade meio à empresa especializada, com vistas à maior eficiência e ganhos de performance;
4.5. Outra alternativa seria a aquisição de um novo software. Neste contexto, como o intuito é o alcance de melhor performance, de agilidade, de confidencialidade, de segurança e de redução de custos operacionais, esta alternativa é economicamente inviável dado que já existe um sistema desenvolvido que atende aos processos de trabalho do presente estudo, mas que necessita ser aprimorado. Desse modo,
há de se tratar da vantagem econômica na contratação de uma empresa para dar continuidade no desenvolvimento de uma tecnologia existente ao invés de adquirir uma nova tecnologia que seria incipiente.
4.6. Em adição a isso, não se pode perder de vista que foram aportados recursos públicos para desenvolvimento do atual sistema e como forma de evitar a perda desses recursos, seria de bom alvitre que o sistema existente fosse aproveitado com as devidas manutenções e com a criação de novas funcionalidades a fim de não se tornar obsoleto.
4.7. Essa solução encontra-se implementada em outro órgão ou entidade da Administração Pública Estadual. A título de exemplo, cita-se a Secretaria de Estado de Fazenda do Maranhão, sistema esse que só atende a integração dos dados financeiros, não contemplando todo o ciclo de gestão de um projeto de financiamento.
4.8. Mas também, é de ser ressaltado que a contratação de equipe especializada não tomará o trabalho de forma incipiente, mas evoluirá o sistema a partir de uma plataforma já implementada e madura, sendo que a contratação de um novo software mostrar-se-ia mais custosa do que a melhoria de um programa existente.
4.9. Desse modo, sopesando as particularidades e percebendo que não há similaridade entre as soluções existentes e aquela que a presente contratação visa atingir, não resta nesga de dúvida de que a alternativa de adesão a estas soluções não é viável tecnicamente ao caso.
4.10. Cabe ressaltar, que houve uma busca na plataforma de softwares livres, mas não localizamos nenhum sistema que atendesse ao escopo do presente estudo técnico preliminar.
4.11. Por se tratar de desenvolvimento, manutenção e suporte técnico à sistema de informação de propriedade do Estado, em pesquisa junto aos modelos de prestação de serviços existentes no mercado, verificamos que os mais comumente contratados são os seguintes:
a) Cenário I – Contratação de serviços de desenvolvimento, manutenção e sustentação de sistemas (que inclui todas as fases do ciclo de vida) aferidos pela técnica de Análise de Pontos de Função, com remuneração por produto entregue após verificada a qualidade;
b) Cenário II – Contratação de serviços de desenvolvimento e manutenção de sistemas (que inclui todas as fases do ciclo de vida), com alocação de postos de trabalho com remuneração pela hora trabalhada (homem-hora);
c) Cenário III – Contratação de serviços de sustentação de sistemas na modalidade de fábrica de software, por meio de desembolso mensal fixo baseado em percentual do tamanho funcional de cada sistema sustentado;
d) Solução IV – Contratação de serviços de sustentação de sistemas com Unidade de Serviço Técnico (UST).
4.11.1. A análise comparativa das soluções observou as seguintes diretrizes:
Diretriz | Cenário (1) - APF | Cenário (2) - HH | Cenário (3) - FIXO | Cenário (4) - UST |
Aderência aos padrões tecnológicos adotados pelo Estado (Decreto n. 15.477/2020, Anexo I, Item 3.1) | Solução não é aderente ao padrão tecnológico adotado no Estado. | Solução não é aderente ao padrão tecnológico adotado no Estado. | Solução é aderente ao padrão tecnológico adotado no Estado. | Solução é aderente ao padrão tecnológico adotado no Estado. |
Disponibilidade de solução de TIC similar em outro órgão ou entidade da Administração Pública (Decreto n. 15.477/2020, Anexo I, Item 3.2) | Encontramos este modelo de solução de TIC em diversos outros editais e contratos da Administração Pública. | Encontramos este modelo de solução de TIC em diversos outros editais e contratos da Administração Pública. | Encontramos este modelo de solução de TIC em diversos outros editais e contratos da Administração Pública. | Encontramos este modelo de solução de TIC em diversos outros editais e contratos da Administração Pública. |
Alternativas do mercado, inclusive quanto a existência de software livre ou gratuito (Decreto n. 15.477/2020, Anexo I, Item 3.3) | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. |
Aderência às regulamentações da ICP-Brasil e modelo eARQ (Decreto n. 15.477/2020, Anexo I, Item 3.4) | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. |
Necessidades de adequação do ambiente (Decreto n. 15.477/2020, Anexo I, Item 3.5) | A solução demanda capacitação e formação de equipe especializada para contagem de pontos de função | Não são necessárias adequação do ambiente para viabilizar a execução do contrato. | Não são necessárias adequação do ambiente para viabilizar a execução do contrato. | Não são necessárias adequação do ambiente para viabilizar a execução do contrato. |
Diferentes modelos de prestação dos serviços (Decreto n. 15.477/2020, Anexo I, Item 3.6) | Modelo integralmente baseado em prestação de serviço. | Modelo integralmente baseado em prestação de serviço. | Modelo integralmente baseado em prestação de serviço. | Modelo integralmente baseado em prestação de serviço. |
Diferentes tipos de soluções em termos de especificação, composição ou características (Decreto n. 15.477/2020, Anexo I, Item 3.7) | Este modelo preconiza a contratação através da contagem de pontos de função (APF), baseado no tamanho funcional do software. | Este modelo preconiza a contratação de pontos de trabalho remunerados por hora-homem. | Este modelo preconiza a contratação através de valor fixo mensal, baseado no volume de trabalho estimado. | Este modelo preconiza a contratação de unidades de serviço técnico (UST), baseado no esforço de execução das atividades previstas em catálogo. |
Possibilidade de aquisição na forma de bens ou contratação como serviço (Decreto n. 15.477/2020, Anexo I, Item 3.8) | Contratação como serviço. | Contratação como serviço. | Contratação como serviço. | Contratação como serviço. |
Ampliação ou substituição da solução implantada | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. | Não se aplica ao objeto em estudo. |
(Decreto n. 15.477/2020, Anexo I, Item 3.9) |
5. ESCOLHA DA SOLUÇÃO DE TECNOLOGIA DA INFORMAÇÃO E JUSTIFICATIVA DA OPÇÃO ADOTADA
5.1. Dentre as soluções passíveis de atendimento às necessidades levantadas, optamos pela constante no Cenário (4) - Desenvolvimento, manutenção e suporte técnico à sistema de informação de propriedade do Estado, considerando as seguintes motivações:
5.1.1. Em análise aos modelos, aos requisitos e a demanda prevista, e segundo as melhores práticas para as contratações de TIC estabelecidas pelos diversos órgãos de controle e pela Administração Pública Federal, orientamos a contratação através do modelo de remuneração baseada em UST (Unidade de Serviço Técnico).
5.1.2. Ao longo dos últimos anos, o serviço público adotou diferentes modelos de contratação de serviços. A Secretaria de Fazenda de Estado do Mato Grosso do Sul, seguindo o que preconiza a Súmula 269 do TCU – Tribunal de Contas da União, está adotando para esta contratação o modelo baseado em UST – Unidade de Serviços Técnicos, de modo semelhante ao já adotado por outros órgãos de governo.
“O Acórdão 47/2013-Plenário TCU, do relator Ministro Xxxxx Xxxx xx Xxxxxxxx, retrata que a jurisprudência é pacífica quanto à importância de se vincular a prestação a resultados ou ao atendimento de níveis de serviço conforme revela o enunciado da Súmula-TCU 269, lavrado nos seguintes
termos: “Nas contratações para a prestação de serviços de tecnologia da informação, a remuneração deve estar vinculada a resultados ou ao atendimento de níveis de serviço, admitindo-se o pagamento por hora trabalhada ou por posto de serviço somente quando as características do objeto não o permitirem, hipótese em que a excepcionalidade deve estar prévia e adequadamente justificada nos respectivos processos
administrativos”
5.1.3. Assim, verificou-se que, em consonância com essa Súmula, as boas práticas do mercado para a contratação de serviços de desenvolvimento e manutenção de sistemas apontam alguns caminhos possíveis: contratação de fábrica de software, com a execução preferencialmente externa dos serviços, mediante abertura de ordem de serviço e remuneração por ponto de função ou por hora de serviço técnico; ou contratação de serviços de desenvolvimento e manutenção de sistemas, com a execução externa ou interna, mediante abertura de ordem de serviço, com remuneração por ponto de função ou por unidade de serviço técnico.
5.1.4. É cediço que os contratos, sobretudo os de Tecnologia da Informação e Comunicação (TIC), possam ser celebrados nas mais diversas modalidades. Nessa linha de ideia, as clássicas aquisições de hardware, compras de licenças de uso e a contratação de horas ou postos de trabalho para desenvolvimento de sistemas, ambas tão comuns em décadas passadas, têm se tornado cada vez menos usuais no âmbito dos departamentos de TIC, sendo gradativamente substituídos por outros modelos menos estáticos e que gerem melhor relação custo x benefício.
5.1.5. Neste aspecto, cabe destacar que os novos modelos, apesar de apresentarem diversos benefícios na grande maioria das contratações de TIC, não se tratam genericamente de inovação e tampouco se apresentam conflitantes com o ordenamento jurídico aplicável à Administração, pois apesar das siglas contemporâneas, tratam tão somente da terceirização de serviços de TIC ou então de locação
de equipamentos ou infraestrutura de terceiros, já previstas na legislação vigente. A contratação de serviços em forma de terceirização tem sido adotada por diferentes órgãos governamentais, com o objetivo de sanar as dificuldades encontradas no modelo tradicional de aquisição de software. Os novos modelos apresentaram um novo paradigma às contratações de TIC e vêm sendo utilizados em exponencial crescimento nas entidades públicas e privadas, principalmente após a virada do milênio, devido a diversas vantagens se comparadas aos modelos tradicionais, incluindo: o foco nos serviços públicos e no cidadão. Isto é, o Estado não é uma empresa de TI. Ao contratar uma solução como um serviço, não há necessidade de investir tanto com a infraestrutura própria, manutenções periódicas e emergenciais, backups de dados e atualizações de software. As equipes técnicas ganham mais tempo para focar no trabalho diário e no conhecimento na evolução das soluções que disponibilizam os serviços públicos ao cidadão (foco no negócio).
5.1.6. A decisão de se utilizar UST em detrimento da contagem por Ponto de Função (UPF), decorre da dificuldade de se contar pontos de função de todas as manutenções a serem realizadas nos sistemas, além do fato de que deve tornar menos oneroso financeiramente o custo da administração do contrato, pois reduz a necessidade, de ambas as partes, de dispor de técnicos especialistas em pontos de função ao longo da execução contratual. Apesar de exigir grande trabalho de gestão, o modelo de contratação por UST deve permitir mensurar melhor os resultados e possibilitar um planejamento mais adequado de prazos.
5.2. DESCRIÇÃO DA SOLUÇÃO:
5.2.1. Contratação de empresa especializada na prestação de serviços técnicos de informática para sustentação, análise, desenvolvimento, manutenção, documentação, treinamento, suporte e teste de software, na forma de serviços continuados presenciais e/ou não presenciais, nos módulos e serviços integrados ao Sistema de Gestão de Projetos de Modernização (SGPM), para atender as necessidades da CONEMAE/SEFAZ/MS, pelo período de 18 meses (dezoito).
5.3. ALINHAMENTO EM RELAÇÃO ÀS NECESIDADES E REQUISITOS INDICADOS:
5.3.1. No caso da demanda a ser atendida nesta contratação, devido à alta criticidade do sistema a ser mantido e pela variedade de atividades que podem compreender a sustentação de sistemas, optou- se pela contratação de serviços de desenvolvimento e de manutenção de sistemas, com a execução externa ou interna, demandada por meio de ordem de serviço e remuneração por unidade de serviço técnico (UST).
5.3.2. A unidade de medida escolhida está ligada à entrega da funcionalidade ou à manutenção de um item de sistema, de forma que ela tem a sua remuneração vinculada a resultados, na forma de entregas específicas e a níveis de serviço. Em nenhuma hipótese a CONTRATADA será remunerada pelo número de horas empenhadas em determinado escopo. A remuneração será feita, exclusivamente, pela dimensão do projeto em UST’s, conforme aprovado pela CONEMAE/SEFAZ/MS anteriormente ao início do desenvolvimento.
5.3.3. Ademais, considerando a grande demanda de serviços, é fundamental a utilização de tecnologias de alto desempenho e ao mesmo tempo flexíveis e capazes de acomodar crescimentos repentinos, como as mudanças de legislação e incorporar novas tecnologias. Para que os projetos obtenham os
resultados esperados, é fundamental que contem com eficiência, segurança, qualidade e celeridade.
5.3.4. Desta forma, entende-se que a solução escolhida seja mais adequada às necessidades do negócio e aos requisitos tecnológicos, em termos de economicidade e melhor aproveitamento dos recursos humanos, materiais e financeiros disponíveis, ou seja, a solução escolhida é totalmente aderente às necessidades e requisitos do objeto deste estudo.
5.4. IDENTIFICAÇÃO DOS BENEFÍCIOS A SEREM ALCANÇADOS:
5.4.1. Sustentação e a evolução do Sistema de Gestão de Projetos de Modernização (SGPM) através de: desenvolvimento de novas funcionalidades no seu portal web; desenvolvimento de plataformas analíticas de BI (Business Intelligence) e Big Data, integração com outros sistemas legados, atividades estas imprescindíveis à continuidade da prestação de serviços públicos de sua competência, garantindo o seu bom funcionamento, aperfeiçoamento e a adequação às mudanças que venham a ser requeridas pela Secretaria de Fazenda de Mato Grosso do Sul;
5.4.2. Melhorar o atendimento da SEFAZ/MS com maior aproveitamento dos recursos financeiros, redução dos prazos de resolução de problemas e construção de produtos solicitados.
5.4.3. Incremento da qualidade dos serviços prestados a CONEMAE/SEFAZ/MS por meio de uma contratação utilizando uma metodologia de software ágil e perfis de profissionais adequados;
5.4.4. Evolução no atual modelo de gestão e o consequente aumento do nível de maturidade, por meio da Governança de TIC;
5.5. DECLARAÇÃO:
5.5.1. Declaramos que foram observadas as vedações constantes no art. 2º do Decreto Estadual n. 15.477 de 20 de julho de 2020, notadamente a impossibilidade de não ser objeto de Solução de TIC mais de uma solução em um único contrato, e gestão de processos de Tecnologia da Informação e Comunicação (incluindo gestão de segurança da informação).
5.6. METODOLOGIA DE AVALIAÇÃO DA QUALIDADE E DA ADEQUAÇÃO :
5.6.1. A avaliação da qualidade e da adequação da Solução de Tecnologia da Informação às especificações funcionais e tecnológicas serão realizadas através de verificações, as quais serão melhor especificadas no Termo de Referência, na forma de:
a) Emissão de Termos de Aceite, provisórios e definitivos, a depender da aferição dos requisitos estabelecidos, à cada entrega de demanda planejada;
b) Aferição periódica dos Níveis de Serviço Estabelecidos;
c) Acompanhamento e cobrança de atingimento dos indicadores de desempenho estabelecidos;
d) Atesto mensal de relatório de produção e produtividade, antes do consequente pagamento;
5.7. DEFINIÇÃO DA FORMA DE REMUNERAÇÃO :
5.7.1. A remuneração da empresa deverá ser na forma de Unidades de Serviço Técnico-UST, consumidas mensalmente;
5.7.2. O pagamento só se dará após atesto da Nota Fiscal, que deverá se fazer acompanhar do Relatório de Atividades executadas no período, com seus respectivos valores quantitativos de UST, baseado no Catálogo de Serviços UST, ponderados pelo fator complexidade;
5.7.3. O catálogo de UST´s que estará em vigor para a contratação é o constante na tabela abaixo, sendo possível sua alteração no decorrer do contrato, se ambas as partes, CONTRATANTE e CONTRATADA, estiverem de acordo;
ÁREA | ATIVIDADE | DESCRIÇÃO | COMPLEXIDADE | TIPO | ESTIMATIVA |
Análise e Projeto | Elicitar requisitos e | Especificar regra de negócio | Simples | Por épico | 3 |
elaborar ou manter | (Épico) | Médio | Por épico | 6 | |
documentação de | Complexo | Por épico | 9 | ||
software segundo | Especificar funcionalidade | Simples | Por história | 3 | |
modelo ágil. | (histórias do usuário) | Médio | Por história | 6 | |
Complexo | Por história | 9 | |||
Definir conjuntos de tarefas | Simples | Por história | 3 | ||
por história do usuário | Médio | Por história | 6 | ||
Complexo | Por história | 9 | |||
Especificar glossário | Complexidade | Por item do | 1 | ||
(vocabulário de negócio) | Única | glossário | |||
utilizando linguagem | |||||
ubíqua de domínio por | |||||
meio do Projeto Dirigido | |||||
por Modelo. | |||||
Especificar glossário | Complexidade | Por item do | 1 | ||
(vocabulário de negócio) | Única | glossário | |||
utilizando linguagem | |||||
ubíqua de domínio por | |||||
meio do Projeto Dirigido | |||||
por Modelo. | |||||
Elaborar Diagrama | Especificar diagramas dos | Simples | Por épico | 6 | |
BPMN | macroprocessos, processos | Médio | Por épico | 12 | |
e subprocessos de negócio | Complexo | Por épico | 18 | ||
em notação BPMN | |||||
Cerimônias/Reuniões | Reunião de Planejamento | Complexidade | Por Sprint e | 12 | |
de Sprint | Única | por | |||
profissional | |||||
envolvido | |||||
Reunião de Revisão de | Complexidade | Por Sprint e | 12 | ||
Sprint | Única | por |
profissional envolvido | |||||
Reunião de Retrospectiva de Sprint | Complexidade Única | Por Sprint e por profissional envolvido | 6 | ||
Reunião Diária | Complexidade Única | Por dia útil da Sprint e por profissional envolvido | 1 | ||
Reunião de Alinhamento | Complexidade Única | Por dia e por profissional envolvido | 12 | ||
Elaborar backlog | Elaboração do backlog do produto | Simples | Por história | 1 | |
Médio | Por história | 2 | |||
Complexo | Por história | 3 | |||
Elaboração do backlog da Iteração (Sprint). | Simples | Por história | 1 | ||
Médio | Por história | 2 | |||
Complexo | Por história | 3 | |||
Prototipação mobile/web | Baixa Fidelidade | Complexidade Única | Criar, por tela | 18 | |
Complexidade Única | Alterar por tela | 9 | |||
Média Fidelidade | Complexidade Única | Criar, por tela | 18 | ||
Complexidade Única | Alterar por tela | 9 | |||
Alta Fidelidade | Complexidade Única | Criar, por tela | 24 | ||
Complexidade Única | Alterar por tela | 12 | |||
Especificação de teste | Criação de critérios de aceitação | Simples | Por história | 3 | |
Médio | Por história | 6 | |||
Complexo | Por história | 9 | |||
Definição de cenário de BDD (Behavior Driven Development) | Simples | Por história | 3 | ||
Médio | Por história | 6 | |||
Complexo | Por história | 9 | |||
Arquitetura de software | Documento de arquitetura de software e infraestrutura, ou parecer técnico arquitetural. | Simples | Por Épico | 12 |
DOCUMENTAÇÃO | Manual do usuário | Criação de manuais de uso dos sistemas por macroprocesso, processos e subprocessos de negócio com as regras e procedimentos | Simples | Elaboração, por história | 3 |
Manutenção, por história | 1 | ||||
Xxxxx | Xxxxxxxxxx, por história | 6 | |||
Manutenção, por história | 3 | ||||
Complexo | Elaboração, por história | 9 | |||
Manutenção, por história | 3 | ||||
Documentação | Documento de revisão da Iteração demonstrando tudo que foi alcançado durante a Interação em termos técnico e de negócio. | Complexidade Única | Elaboração por Iteração | 6 | |
Elaboração de documento de retrospectiva. | Complexidade Única | Elaboração por Iteração | 3 | ||
Relatório | Elaboração de relatório de não conformidade contendo testes realizados com suas respectivas evidências que demonstram as não conformidades relatadas. | Simples | Elaboração, por iteração | 6 | |
Xxxxx | Xxxxxxxxxx, por iteração | 12 | |||
Complexo | Elaboração, por iteração | 18 | |||
DESENVOLVIMENTO | Elaboração de tela (html/css) | _ | Complexidade Única | Nova | 18 |
Adaptação baseada em existente | 6 | ||||
Adaptação baseada em existente, mas que contenha itens que exijam diagramação única (como um mapa ou | 9 |
imagem específica) | |||||
Por campo distinto envolvido na tela | 1 | ||||
Desenvolvimento de uma funcionalidade de sistema a partir de descrição técnica pré- elaborada, compreendendo codificação da funcionalidade e integração do código no repositório definido; | Nova | Simples | por funcionalidad e | 9 | |
Média | por funcionalidad e | 18 | |||
Complexa | por funcionalidad e | 27 | |||
Manutenção de uma funcionalidade de sistema a partir de descrição técnica pré- elaborada, compreendendo codificação da funcionalidade e integração do código no repositório definido; | Manutenção evolutiva | Simples | por funcionalidad e | 9 | |
Média | por funcionalidad e | 18 | |||
Complexa | por funcionalidad e | 27 | |||
Criação de relatório, listagem ou gráficos de itens e sua paginação. | Novo | Complexidade Única | Novo | 18 | |
Complexidade Única | Alteração em existente | 9 | |||
Complexidade Única | Por campo distinto envolvido | 1 |
manutenção de relatório, listagem ou gráficos de itens e sua paginação. | Manutenção evolutiva | Complexidade Única | Novo | 18 | |
Complexidade Única | Alteração em existente | 9 | |||
Integração com sistemas externos | _ | Complexidade Única | Novo | 36 | |
Complexidade Única | Alteração em existente | 24 | |||
Implementar processos automatizados | _ | Complexidade Única | Por processo | 24 | |
Elaboração de documentação de uma API disponibilizada por web service; | _ | Complexidade Única | por domínio | 9 | |
MODELAGEM DE DADOS | Modelagem conceitual | Realizar modelagem de dados conceitual a partir dos requisitos do sistema e regras de negócio. Realizar a construção do modelo de dados conceitual tendo por objetivo identificar o correto conceito do requisito e sua modelagem conceitual e seu relacionamento com outras entidades de negócio. | Complexidade Única | Elaborar, por entidade | 2 |
Complexidade Única | Manter, por entidade | 1 | |||
Modelo Relacional | Elaborar ou manter modelo de dados. Especificação do modelo de dados lógico e físico do sistema. | Complexidade Única | Elaborar, por tabela | 2 | |
Complexidade Única | Manter, por tabela | 1 | |||
Recursos do banco de dados - triggers | Complexidade Única | Criar, por trigger | 3 | ||
Complexidade Única | Manter, por trigger | 2 | |||
Recursos do banco de dados - Store procedures e Functions | Simples | Por recurso | 6 | ||
Médio | Por recurso | 12 | |||
Complexo | Por recurso | 18 | |||
TESTES | Teste de unidade | Em nível de componente ou classe | Complexidade Única | Planejamento e execução por | 2 |
funcionalidad e | |||||
Teste de regressão | Execução do Re-teste de todo o sistema toda vez que algo foi mudado, corrigindo inconsistências | Complexidade Única | Por Iteração | 9 | |
Teste funcional | Tem por objetivo avaliar se o sistema funciona adequadamente, obtendo os resultados esperados de acordo com determinados conjuntos de dados de entradas que visam a testar determinados casos de uso. | Complexidade Única | Planejamento , por história | 2 | |
Complexidade Única | Execução, por história | 9 | |||
Teste de usabilidade | Tem por objetivo avalia o sistema do ponto de vista do usuário final. | Complexidade Única | Planejamento e execução, por história | 6 | |
Teste de carga | Tem por objetivo verifica o funcionamento da aplicação com a utilização grandes quantidades de acessos simultâneos | Complexidade Única | Planejamento | 3 | |
Complexidade Única | Execução, acumulado de 3 iterações | 9 | |||
Teste de desempenho | Teste dos requisitos não funcionais relacionados ao desempenho do software, como, por exemplo, requisitos associados a tempo de resposta, volume de dados, quantidade de acessos por unidade de tempo. | Complexidade Única | Planejamento | 3 | |
Complexidade Única | Execução | 9 | |||
Complexidade Única | Relatório com resultados | 6 | |||
Teste de segurança | Tem por objetivo listar as diversas condições de teste dos requisitos não funcionais relacionados à segurança do software. | Complexidade Única | Planejamento | 12 | |
Complexidade Única | Execução, acumulado de 3 iterações | 24 | |||
Teste de aceitação | Tem por objetivo avaliar se o sistema funciona adequadamente, obtendo os resultados esperados de acordo com determinados conjuntos de dados de | Complexidade Única | Planejamento , por iteração | 3 | |
Complexidade Única | Execução, por iteração | 3 |
entradas que visam a testar determinada funcionalidade. | |||||
Teste Exploratório | Teste exploratório é uma abordagem de testes que enfatiza as habilidades do testador em tomar decisões sobre o que será testado durante a execução do teste ao invés de seguir um roteiro previamente planejado. | Complexidade Única | Execução, por iteração | 6 | |
Preparar dados de teste | Elaboração e preparação de dados de teste contemplando geração automática de dados de testes | Complexidade Única | Por iteração | 3 | |
Importar e exportar base de dados | Geração de massa de dados para testes | Complexidade Única | Por iteração | 6 | |
MONITORAMENTO | Implantação do sistema (trabalho completo, incluindo geração de builds, scripts etc.) | _ | Complexidade Única | Por ambiente | 6 |
Monitoramento diário | _ | Complexidade Única | Por módulo monitorado | 2 | |
DADOS | Execução de atividades de Administração de Dados, com suporte de ferramenta automatizada | _ | Simples | por atividade | 9 |
Média | por atividade | 18 | |||
Complexa | por atividade | 36 | |||
Execução de tarefas correlatas a tunning de queries, objetos e serviços de banco de dados | Simples | por atividade | 9 | ||
Média | por atividade | 18 | |||
_ | Complexa | por atividade | 36 | ||
Execução de tarefas de monitoramento dos serviços dos SGBDs | _ | Simples | por atividade | 9 | |
Média | por atividade | 18 | |||
Complexa | por atividade | 36 |
Execução, implementação e investigação de auditoria em logs dos SGBDs | _ | Complexidade Única | Por demanda | 18 | |
Execução, implementação de planos e rotinas de backups dos dados e metadados dos SGBDs | _ | Simples | Por plano/rotina | 9 | |
_ | Médio | Por plano/rotina | 18 | ||
_ | Complexo | Por plano/rotina | 27 | ||
Execução, implementação de planos e rotinas de restore dos dados e metadados dos SGBDs | _ | Simples | Por plano/rotina | 9 | |
Médio | Por plano/rotina | 18 | |||
Complexo | Por plano/rotina | 27 | |||
Execução, implementação de planos e rotinas de manutenção dos SGBDs; | _ | Simples | Por plano/rotina | 9 | |
Médio | Por plano/rotina | 18 | |||
Complexo | Por plano/rotina | 27 | |||
Implementação e manutenção de planos de segurança da informação para os SGBDs | _ | Simples | Por plano | 9 | |
Médio | Por plano | 18 | |||
Complexo | Por plano | 27 | |||
Realização e manutenção de ETL/Fato/dimensão/ afins | _ | Simples | Por atividade | 12 | |
Médio | Por atividade | 18 | |||
Complexo | Por atividade | 24 | |||
Desenvolvimento/M anutenção de uma API a partir de descrição técnica pré- elaborada, compreendendo codificação da funcionalidade e integração do código | _ | Simples | por API | 3 | |
Médio | por API | 6 | |||
Complexo | por API | 9 |
no repositório definido; | |||||
Suporte e manutenção de painéis em ferramentas de BI | _ | Simples | Por Painel | 3 | |
Médio | Por Painel | 6 | |||
Complexo | Por Painel | 9 | |||
Elaboração de painéis em ferramentas BI | _ | Simples | Por Painel | 3 | |
Médio | Por Painel | 6 | |||
Complexo | Por Painel | 9 | |||
Execução, implementação e manutenção das bases OLAP | _ | Simples | por atividade | 3 | |
Média | por atividade | 6 | |||
Complexa | por atividade | 9 | |||
Execução, implementação e manutenção dos serviços de Data Warehouse | _ | Simples | por atividade | 3 | |
Média | por atividade | 6 | |||
Complexa | por atividade | 9 | |||
Construção de Modelos Preditivos (p/ modelo) | _ | Complexidade Única | Por modelo | 24 | |
OUTRAS ÁREAS | Atendimento especializado área de negócio e/ou área técnica | _ | Simples | Por atendimento | 1 |
Médio | Por atendimento | 2 | |||
Complexo | Por atendimento | 3 | |||
Capacitação de um técnico para uso de uma tecnologia; | _ | Complexidade Única | Por hora de capacitação e por técnico | 4 | |
Suporte em ferramenta ECM/BPM ou equivalentes | _ | Complexidade Única | Por atividade | 4 | |
Desenvolvimento de treinamentos, palestras e outros eventos de interesse da SGI (hora); | _ | Complexidade Única | Por hora de treinamento | 4 |
Realizar prova de conceito, homologação de novas ferramentas de testes e qualidade de software ou avaliação de uma nova tecnologia para uso em um projeto; | _ | Complexidade Única | Por tecnologia | 18 |
5.7.4. Maiores detalhamentos serão especificados no Termo de Referência.
6. JUSTIFICATIVA PARA O PARCELAMENTO OU NÃO DA SOLUÇÃO
6.1. É sabido que o parcelamento da solução é a regra, devendo a licitação ser realizada por item sempre que o objeto for divisível, desde que se verifique não haver prejuízo para o conjunto da solução ou perda de economia de escala, visando propiciar a ampla participação de licitantes, que embora não disponham de capacidade para execução da totalidade do objeto, possam fazê-lo com relação a itens ou unidades autônomas.
6.2. Contudo, a contratação dos serviços em apreço em item único sem parcelamento é a que melhor atende as necessidades do objeto descrito, considerando que a contratação citada atua sobre produto indivisível, não havendo possibilidade de fragmentar a prestação para fornecimento parcelado, visto que:
6.3. Não há viabilidade técnica para fracionar parte específica do software para fornecedores distintos, visto que se trata de produto que possui características intrínsecas de interoperabilidade e interdependência de seus diversos módulos;
6.4. Os serviços de desenvolvimento e manutenção são comumente realizados em paralelo, muitas vezes sobre uma mesma demanda, não havendo meios de dividir estes em diferentes entregas sem que haja sobreposição de tarefas ou retrabalho;
6.5. O risco de falhas catastróficas ou irreversíveis quando a mais de um fornecedor atuando em um mesmo produto de software é extremamente alta, o que pode, ao invés de melhorar o produto, ajudar a criar diversas falhas e erros críticos na ferramenta.
6.6. Não há viabilidade para formação de consórcios, visto que a estrutura da solução é única, com mesma arquitetura e plataforma tecnológica, não cabendo tal formação para fornecimento de objeto uno e indivisível.
7. AVALIAÇÃO DAS NECESSIDADES DE ADEQUAÇÃO DO AMBIENTE DO ÓRGÃO
7.1. Não foram identificadas necessidades de adequação do ambiente do Órgão para viabilizar a execução contratual da Solução de Tecnologia da Informação e Comunicação definida neste estudo.
8. ESTIMATIVA DE CUSTO
8.1. Comparação entre os custos totais de propriedade (TCO – Total Cost Ownership):
8.1.1. A definição e documentação da estimativa de preços referenciais foram baseadas nas seguintes premissas:
8.1.1.1. Valores de UST praticados em contratos vigentes da SEFAZ/MS para desenvolvimento de sistemas de informação, conforme consta na memória de cálculo:
Contratos de desenvolvimento de sistemas baseados em UST vigentes na SEFAZ/MS
Cotação | Valor por UST no Contrato | Estimativa de UST no ETP | Valor Estimado Anual |
Contrato n. 10/2019 - Infortech Informática Eireli EPP | R$ 44,00 | 72.000 | R$ 3.168.000,00 |
Contrato n. 11/2019 - PSG Tecnologia Aplicada Ltda | R$ 53,12 | R$ 3.824.640,00 | |
Contrato n. 09/2017 - GEOI2 Tecnologia da Informação Ltda EPP | R$ 51,36 | R$ 3.697.920,00 | |
Contrato n. 08/2018 - MIL TEC Tecnologia da Informação Eireli | R$ 51,30 | R$ 3.693.600,00 |
8.2. Estimativa do custo total da contratação:
8.2.1. O valor estimado do contrato é de R$ 1.008.273,00 (um milhão, oito mil, duzentos e setenta e três reais), para o período de 18 (dezoito) meses.
8.2.2. Esse valor equivale a aproximadamente 19.416 UST´s, Unidade de medida a ser adotada por essa contratação.
9. DECLARAÇÃO DA VIABILIDADE OU NÃO DA CONTRATAÇÃO
9.1. Com base nos elementos apresentados anteriormente, esta equipe de planejamento declara que a contratação é viável, além de ser necessária para o atendimento das necessidades e interesses da Secretaria de Estado de Fazenda de Mato Grosso do Sul (SEFAZ/MS).
9.2. A contratação será custeada com recursos de financiamento do Banco Interamericano de Desenvolvimento (BID), através do Projeto de Modernização da Gestão Fiscal do Estado de Mato Grosso do Sul (PROFISCO II-MS), Contrato de Empréstimo Nº 4597/OC-BR), através da Unidade Gestora Fundo Especial de Desenvolvimento e Aperfeiçoamento das Atividades Fazendárias (FUNFAZ), da Fonte de Recursos 0113030003, Funcional Programática 10.11901.04.123.2041.3020.0001, Natureza da Despesa 44903905 – Serviços Técnicos Profissionais e encontra-se aprovada pelo Banco.
9.3. A contratação obedece às disposições do Decreto Nº 15.477 de 20 de julho de 2020 e está em harmonia com o Planejamento Estratégico Estadual do Estado.
10. AVALIAÇÃO QUANTO À NECESSIDADE DE CLASSIFICAÇÃO DA INFORMAÇÃO (LEI Nº 4.416/2013)
10.1. Nos termos da Lei nº 4.416, de 16 de outubro de 2013, o presente Estudo não se classifica como sigiloso.
11. ASSINATURA
Campo Grande, 08 de outubro de 2020.
XXXXX XXXX XXXXXXXXXX XX XXXXXXXXXXX COORDENADOR TÉCNICO PROFISCO II-MS | XXXXXXX XXXXXX XXXXXXXXX ASSESSOR TÉCNICO SGI/SEFAZ |
XXXXXXX XXXXXXX XX XXXXX DORBAÇÃO SÁ COORDENADORA ADMINISTRATIVO-FINANCEIRO PROFISCO II-MS
Aprovado em: / / |
XXXXXX XXXXXX XX XXXX XXXXXXX SECRETÁRIO DE ESTADO DE FAZENDA ORDENADOR DE XXXXXXX XXXXX/MS |
Anexo Único
ANÁLISE DE RISCOS
IDENTIFICAÇÃO DO RISCO | ANÁLISE DO RISCO | RESPOSTA AO RISCO | |||||||
RISCO | FASE | DESCRIÇÃO | CONSEQUÊNCIA | PROBABILIDADE | GRAU DE IMPACTO | NÍVEL DE RISCO | MEDIDAS PREVENTIVAS | MEDIDAS CORRETIVAS | RESPONSÁVEL |
R#01 | PLA | Interveniência de outras demandas com maior prioridade. | Atraso no processo de contratação e perda de prazo para publicação do edital de licitação. | MÉDIA | ALTO | ALTO | Aumentar o nível de priorização da contratação, buscando a harmonia das demandas prioritárias | Reiniciar o processo de contratação com priorização desta. | SUCOMP/SAD |
R#02 | SEL | Intercorrências no processo de contratação. | Atraso na finalização do processo de contratação. | MÉDIA | MÉDIO | MÉDIO | Durante o planejamento da contratação, utilizar listas estruturadas de verificações e documentos padrões. Monitorar o processo de contratação em conjunto com o BID | Priorizar as possíveis correções no ETP, TR e outros artefatos utilizados no processo de contratação. | LÍDER DO PRODUTO |
R#3 | GES | Necessidades ou empecilhos não mapeados pela consultoria. | Atraso na entrega dos produtos previstos para cada etapa, e no projeto como um todo. | BAIXA | MÉDIO | MÉDIO | Estabelecer agenda e escopo suficientes para os levantamentos e diagnósticos iniciais da consultoria | Realizar reuniões frequentes de monitoramento para adequar o escopo e o cronograma do projeto sempre que necessário. | LÍDER DO PRODUTO |
R#4 | GES | Não realização efetiva da execução do Contrato. | Não recebimento do objeto que satisfaça às necessidades que originaram a contratação. | BAIXA | ALTO | ALTO | Fiscalizar efetivamente a execução contratual. | Intensificar as rotinas de fiscalização contratual. Se necessário, instaurar processo para aplicação de penalidades. | LÍDER DO PRODUTO / FISCAL DO CONTRATO |