INSTRUÇÃO NORMATIVA Nº 49, DE 10 DE AGOSTO DE 2018.

Transcrição

1 INSTRUÇÃO NORMATIVA Nº 49, DE 10 DE AGOSTO DE Institui os Procedimentos de Manutenção de Sistemas, no âmbito da DPU. A SECRETÁRIA-GERAL EXECUTIVA, usando das atribuições que lhe são conferidas pelo artigo 26, inciso II, da Portaria GABDPGF DPGU nº 286, de 8 de junho de 2018, publicada no Diário Oficial da União em 02 de julho de 2018, que dispõe sobre o Regimento Interno da Defensoria Pública-Geral da União; Considerando o artigo 135 da Portaria GABDPGF DPGU nº 286, de 8 de junho de 2018; Considerando a Portaria nº 203, de 15 de maio de 2014, publicada no Boletim Eletrônico Interno em 19 de maio de 2014, que regulamenta os fluxos operacionais e procedimentos para emissão de Instruções Normativas destinadas ao detalhamento das rotinas necessárias à formalização dos processos de trabalho das áreas da DPU; Considerando os autos do processo / RESOLVE: Art. 1º Instituir, na forma desta Instrução Normativa, a regulamentação dos procedimentos do processo de trabalho de Manutenção de Sistemas da Secretaria de Tecnologia da Informação (STI), na forma do anexo I. Art. 2º Esta Instrução Normativa entra em vigor na data de sua publicação. LIANA LIDIANE PACHECO DANI Secretária-Geral Executiva 1. OBJETIVO Anexo I MANUTENÇÃO DE SISTEMAS 1.1. Atender às demandas de manutenção e suporte de sistemas no âmbito da DPU e amparar a Secretaria de Tecnologia da Informação (STI) na sua operacionalização. 2. REFERENCIAL NORMATIVO 2.1 Regimento Interno da DPU: Cria a estrutura administrativa da Defensoria Pública- Geral da União, suas competências e sua organização; 2.2 Portaria nº 28, de : Institui o Comitê Estratégico Permanente de Tecnologia da Informação no âmbito da Defensoria Pública da União; 2.3 Portaria SGE nº 111, de : Aprova o Plano Diretor de Tecnologia da Informação e Comunicação para o período de DEFINIÇÕES 3.1.Ambiente de Desenvolvimento É o conjunto de ferramentas de apoio para todo o processo de construção do software, incluindo infraestruturas e interface de programação de aplicativos (API's) utilizados pelos desenvolvedores; 13

2 3.2.Ambiente de homologação É toda a infraestrutura onde o sistema é instalado para validação. Deve ser disponibilizado para aceite final do produto; 3.3.Ambiente de Produção É toda a infraestrutura designada para disponibilização de aplicação homologada para utilização do usuário, fase posterior a homologação; 3.4.Ambiente de Teste É toda a infraestrutura onde o teste será executado, compreendendo configurações de hardware, software, ferramentas de automação, bem como os versionamentos envolvidos para a implantação; 3.5.Arquitetura de Software Consiste na definição dos componentes de software, suas propriedades externas e seus relacionamentos com outros softwares; 3.6.Codificação ou Implementação É a transformação de um projeto para um código, sendo essa fase a mais evidente do processo de desenvolvimento/manutenção do sistema, mas não necessariamente a maior porção; 3.7.Comitê Estratégico Permanente de Tecnologia da Informação O Comitê Estratégico de TI é um órgão colegiado formado por membros das áreas finalísticas, administrativas e da área de TI. Compete ao Comitê definir as políticas de informatização e gerenciar as informações decorrentes das atividades da Defensoria Pública da União, bem como acompanhar a execução do PDTIC; 3.8.Comitê Gestor de Sistema Membros colaboradores com o objetivo de coordenar, propor e articular o planejamento e a implementação de software, integração de sistemas, dentre outras questões relacionadas ao Processo de Desenvolvimento de Sistema, além de aprovar manutenções corretivas e evolutivas, manuais e normas do sistema; 3.9.Customização Empregar personalização, adaptação ou adequação conforme às necessidades de requisitos das áreas solicitantes; 3.10.Documento de Arquitetura de Negócio É o documento que fornece uma visão geral da estrutura e da finalidade do negócio. Funciona como um meio de comunicação entre o analista de processo do negócio e outros membros da equipe do projeto e contém as definições das principais capacidades e comportamentos do negócio; 3.11.Documento de Especificação É o documento que tem por objetivo orientar o processo de coleta e elicitação dos requisitos necessários para o desenvolvimento de um software. Nele deverão estar contidas as informações necessárias das funções desejadas do produto, o seu desempenho, aparência, as relações entre as partes interessadas, expectativas, e outras características que se julgar necessárias; 3.12.Escopo Definição de contornos, limites, características e metas, aborda o trabalho necessário para o desenvolvimento/manutenção. A verificação do escopo é o processo de aceitar formalmente o trabalho do projeto, conforme definido em sua documentação. Sua aceitação formal exige a assinatura para aprovação do produto; 3.13.Estudo Técnico Preliminar Constitui a primeira etapa do planejamento de uma contratação (planejamento preliminar) e tem como objetivo assegurar a viabilidade técnica da contratação, bem como o tratamento de seu impacto, a fim de embasar o TR/Projeto Básico; 3.14.Fiscal técnico do contrato É o servidor representante da área de tecnologia da informação, indicado pela autoridade competente da STI para fiscalizar tecnicamente o contrato; 3.15.Funcionalidades ou Atividade É o comportamento ou uma ação, algo passível de execução, sua descrição exprime o que ela faz e como ela faz. É recomendável que o nome atribuído a uma funcionalidade seja formado pela combinação de um verbo e um substantivo; 3.16.Homologação É o processo de validação do software construído como apto a entrar em produção. Inclui elementos de verificação e de validação do produto em comum acordo com as áreas e tem como meta principal a obtenção do aceite do produto; 14

3 3.17.Manutenção de software É o processo de melhoria e otimização de um software já desenvolvido (versão de produção), como também reparo de defeitos. Deverá ser mensurado o tempo/esforço para analisar a complexidade da manutenção: Alta complexidade envolve grandes modificações no sistema, podendo ser em sua arquitetura, funcionalidades ou nas regras de negócio. Necessita de prazo maior para atendimento da solicitação; Baixa complexidade manutenção para reparar defeitos ou melhorias que possibilita o atendimento imediato da solicitação e que não resultem impactos nas regras gerais do sistema; Média complexidade manutenção que pode alterar funcionalidades do software e necessita de prazo razoável para atendimento da solicitação; 3.18.Modelo de Dados Conceitual Representação gráfica conceitual, abstrata, independente de tecnologia que identifica o conjunto de entidades, seus atributos e suas especificações para posterior elaboração do modelo lógico; 3.19.Modelo de Dados Físico É o documento de modelagem física do banco de dados, demostra como os dados são fisicamente armazenados e manipulados, define o banco de dados e é implementado com base nos modelos conceitual e lógico; 3.20.Modelo de Dados Lógico É o Diagrama de Banco de Dados, agrega detalhes de implementação, define as ligações entre as tabelas de banco de dados, as chaves primárias, os componentes de cada uma, normalização e integridade referencial. É construído com base no modelo conceitual; 3.21.Modelo de Processo O objetivo deste documento é estabelecer o detalhamento dos principais agentes, referenciais e ferramentas com os quais o software interage. São expressos por meio de diagramas e cada diagrama consiste em um conjunto de elementos de modelagem, sendo ele: objetos de fluxo, objetos de conexão, divisões e artefatos; 3.22.Ordem de Serviço Meio pelo qual se formaliza a solicitação de um serviço a uma empresa terceirizada; 3.23.PDTIC - Plano Diretor de Tecnologia da Informação e Comunicação O PDTIC é o documento que tem como finalidade a definição do conjunto de metas e ações que deverão nortear os direcionamentos e investimentos em tecnologia da informação, com vistas ao aprimoramento da governança; 3.24.Plano de trabalho Todo e qualquer conjunto sistemático de atividades que tem por objetivo concretizar uma ação. Permite ordenar e sistematizar informações consideradas relevantes para realizar um trabalho, propondo uma forma de inter-relacionar os recursos humanos, financeiros, materiais e tecnológicos disponíveis entre as áreas envolvidas; 3.25.Protótipo de Telas É um produto sem funcionalidades inteligentes que possuem apenas funcionalidades gráficas, utilizado para fins de ilustração e melhor entendimento do que será produzido no desenvolvimento/manutenção do sistema; 3.26.Regras de negócio Definição das regras básicas das funcionalidades particulares do software, facilitando por parte dos programadores o desenvolvimento de métodos de tratamento de exceções; 3.27.Relatório Técnico É o pronunciamento por escrito de uma opinião técnica que deve ser assinado e datado, emitido por um especialista sobre determinada situação que exija conhecimentos técnicos. Deve ser sustentado em bases confiáveis e escrito com o objetivo de esclarecer, interpretar e explicar certos fatos para um interlocutor que não é tão especializado quanto o relator; 3.28.Software Livre É a expressão utilizada para designar qualquer programa de computador que pode ser executado, copiado, modificado e redistribuído pelos usuários 15

4 gratuitamente. Os usuários possuem livre acesso ao código-fonte do software e fazem alterações conforme as suas necessidades; 3.29.Termo de cooperação Instrumento por meio do qual é ajustada a transferência de bem ou serviço de um órgão ou entidade da Administração Pública Federal para outro órgão federal da mesma natureza ou autarquia, fundação pública ou empresa estatal, tendo por finalidade a colaboração mútua em prol do interesse público; 3.30.Termo de Recebimento Definitivo É a declaração formal, emitida pelo Fiscal Técnico, de que os serviços prestados ou bens fornecidos atendem aos requisitos estabelecidos no objeto dos termos contratuais; 3.31.Termo de Recebimento Provisório É a declaração formal, emitida pelo Fiscal Técnico, de que o objeto adquirido foi recebido. Este documento garante que o item ou itens constantes de fornecimento de Bens/serviços foram entregues para avaliação; 3.32.Termo de Referência/Projeto Básico É o documento que deve conter os elementos técnicos capazes de propiciar a avaliação do custo, pela administração, com a contratação e os elementos técnicos necessários e suficientes, com nível de precisão adequado para caracterizar o serviço a ser contratado e orientar a execução e fiscalização contratual. 4. DETALHAMENTO DO PROCESSO DE TRABALHO 4.1. Manutenção de Sistemas O processo de manutenção de sistemas se inicia com a solicitação da área sendo encaminhada à Coordenação de Gerenciamento de Banco de Dados e Sistemas (CBDS/STI), via Sistema Eletrônico de Informação (SEI) ou institucional da área; A CBDS/STI identifica se a demanda de manutenção causará alteração na funcionalidade do sistema. Caso altere, a demanda deve ser submetida ao respectivo Comitê Gestor, caso exista; Caso seja submetido ao Comitê, o mesmo delibera quanto a não aprovação ou aprovação da demanda; Em caso de não aprovação, a deliberação é registrada em ata e encaminhada a CBDS/STI, que dará conhecimento à área demandante; Em caso de aprovação, a deliberação é registrada em ata e encaminhada a CBDS/STI para operacionalização; A CBDS/STI identificará se a demanda é de baixa, média ou alta complexidade; Em se tratando de demanda de baixa complexidade, a CBDS/STI identificará se o sistema foi desenvolvido e/ou mantido pela CBDS/STI ou terceirizada; Em se tratando de demanda a ser operacionalizada pela CBDS/STI: O início do atendimento será feito imediatamente a partir do recebimento da demanda, caso não exista outras demandas em andamento, cujo cronograma de execução será definido com a área; A demanda será analisada, avaliada, especificada, implementada, testada e submetida à área demandante para homologação; A CBDS/STI instala a solução para homologar em ambiente de produção; No caso de não homologação, a demanda será encaminhada a CBDS/STI para ajustes, conforme solicitado pela área demandante, e submetida novamente, até sua homologação Em se tratando de demanda a ser operacionalizada pela empresa terceirizada contratada; A CBDS/STI encaminhará a demanda para a terceirizada; 16

5 O início do atendimento será feito imediatamente a partir do recebimento da demanda, caso não exista outras demandas em andamento, cujo prazo de execução é definido no contrato; A demanda será analisada, avaliada, especificada, implementada, testada, e submetida à CBDS/STI, que analisará e encaminhará a área demandante para homologação; Se homologada, a demanda será encaminhada à CBDS/STI, que solicitará à terceirizada a implantação em ambiente de produção; No caso de não homologação, a demanda será encaminhada à CBDS/STI, que solicitará os ajustes à terceirizada, conforme solicitado pela área demandante, e submetida novamente, até sua homologação Quando a demanda for de média complexidade, a CBDS/STI identificará se o sistema foi desenvolvido e/ou mantido pela terceirizada; Tratando-se de demanda a ser operacionalizada pela CBDS/STI: O início do atendimento será feito imediatamente a partir do recebimento da demanda, caso não exista outras demandas em andamento, cujo cronograma de execução será definido com a área; Para sua execução será atualizado o projeto contendo as seguintes etapas: documento de arquitetura de negócio, documento de especificação, modelo de processo, modelo de dados (conceitual, lógico e físico), protótipos de tela, manual, codificação e testes; A solução manutenida será instalada (em ambiente de homologação) e submetida à área demandante para aprovação; No caso de homologada pela área demandante, será implantada em ambiente de produção; No caso de não homologada, a demanda será encaminhada à CBDS/STI para ajustes, conforme solicitado pela área demandante, e submetida novamente, até sua homologação Tratando-se de demanda a ser operacionalizada pela empresa terceirizada contratada; A CBDS/STI encaminhará a demanda para a terceirizada; O início do atendimento será feito imediatamente a partir do recebimento da demanda, caso não exista outras demandas em andamento, cujo cronograma de execução será definido com a CBDS/STI e a área demandante; Para sua execução, a CBDS/STI solicitará à empresa terceirizada contratada projeto contendo as seguintes etapas: documento de arquitetura de negócio, documento de especificação, modelo de processo, modelo de dados (conceitual, lógico e físico), protótipos de tela, manual, codificação e testes; Na sequência, a manutenção será operacionalizada conforme etapas estabelecidas no projeto; A solução manutenida será instalada (em ambiente de homologação) e submetida à área demandante, via CBDS/STI, para aprovação; No caso de homologada pela área demandante, a CBDS/STI solicitará à empresa terceirizada contratada a implantação em ambiente de produção; No caso de não homologada, a demanda será encaminhada à CBDS/STI, que solicitará os ajustes à empresa terceirizada, conforme solicitado pela área demandante, e submetida novamente até sua homologação; 17

6 Tratando-se de demanda de alta complexidade, a CBDS/STI elaborará relatório técnico de viabilidade e submeterá à Secretaria de Tecnologia e Informação (STI) para validação; Caso o relatório técnico de viabilidade não seja aprovado pela STI, será restituído à CBDS/STI para ajustes, e submetido novamente até sua aprovação; Após aprovado, o relatório pode ou não ser submetido à Secretaria Geral Executiva (SGE), levando em consideração custos, prazos e recursos humanos; Encaminhado à SGE e não aprovado, o relatório será restituído à CBDS/STI, via STI, para comunicar a negativa à área demandante; Em caso de aprovação do relatório pela SGE, será restituído à CBDS/STI, via STI, para operacionalização; Nessa fase, a CBDS/STI identificará se o sistema foi desenvolvido e/ou mantido pela empresa terceirizada; Tratando-se de demanda a ser operacionalizada pela CBDS/STI: A CBDS/STI elabora projeto, com o respectivo planejamento das ações, contendo as seguintes etapas: documento de arquitetura de negócio, documento de especificação, modelo de processo, modelo de dados (conceitual, lógico e físico), protótipos de tela, manual, codificação e testes e submetido à área demandante; Em caso de não aprovação do projeto pela área demandante, será restituído à CBDS/STI para adequação, conforme orientação, e submetido novamente até sua aprovação; Em caso de aprovação do projeto pela área demandante, será restituído à CBDS/STI para implementação da manutenção; O início do atendimento será feito a partir da aprovação do projeto pela área demandante, conforme cronograma; A solução manutenida será instalada em ambiente de homologação e submetida à área demandante para aprovação; No caso de homologada pela área demandante, será implantada em ambiente de produção; No caso de não homologada, a demanda será encaminhada à CBDS/STI para ajustes, conforme solicitado pela área demandante, e submetida novamente, até sua homologação Tratando-se de demanda a ser operacionalizada pela empresa terceirizada contratada: A CBDS/STI solicitará à empresa terceirizada contratada a elaboração de projeto, com o respectivo planejamento das ações, contendo as seguintes etapas: documento de arquitetura de negócio, documento de especificação, modelo de processo, modelo de dados (conceitual, lógico e físico), protótipos de tela, manual, codificação e testes, sendo submetido à área demandante, via CBDS; Em caso de não aprovação pela área demandante, será restituído à CBDS/STI, com vistas à empresa contratada terceirizada, para adequação, conforme orientação, e submetido novamente até sua aprovação; Em caso de aprovação do projeto pela área demandante, será restituído à CBDS/STI, com vistas à empresa terceirizada contratada, para implementação da manutenção, conforme projeto aprovado; O início do atendimento será feito a partir da aprovação do projeto pela área demandante, conforme cronograma constante do mesmo; 18

7 A solução manutenida será instalada em ambiente de homologação e submetida à área demandante para aprovação, via CBDS/STI; No caso de homologada pela área demandante, a CBDS/STI solicitará à empresa terceirizada contratada a implantação em ambiente de produção; No caso de não homologada, a demanda será encaminhada à CBDS/STI, que solicitará os ajustes à empresa terceirizada, conforme solicitado pela área demandante, e submetida novamente, até sua homologação Caso a manutenção não altere a funcionalidade do sistema ou não exista Comitê Gestor, a CBDS/STI avaliará a complexidade da manutenção de sistema, identificando se a demanda é de baixa, média ou alta complexidade; Tratando-se de demanda de baixa complexidade, deverá ser observado o item e seus respectivos subitens; Tratando-se de demanda de média complexidade, deverá ser observado o item e seus respectivos subitens; Tratando-se de demanda de alta complexidade, deverá ser observado o item e seus respectivos subitens; 4.2.Todo trâmite processual de manutenção de sistemas dar-se-á via SEI. 5. INDICADORES 5.1 Índice de Eficácia: Demandas de baixa, média e alta complexidade (Quantidade de demandas solucionadas / quantidade de demandas solicitadas) x 100 para cada tipo de demanda Data Instrução Normativa Finalizada na ASPLAN em 7. APROVAÇÃO 7.1 A evidência de aprovação pode ser consultada no processo SEI 8. CONTROLE DE ALTERAÇÕES Data Revisão Descrição da Alteração XX.XX Emissão inicial 19