Nome do Projeto: Revisão do processo de Homologação de Modelo de Dados Tema: Tecnologia da Informação Responsável: SEAD

Transcrição

1 Apresentação TRIBUNAL SUPERIOR ELEITORAL SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO COORDENADORIA DE LOGÍSTICA SEÇÃO DE ADMINISTRAÇÃO DE DADOS Nome do Projeto: Revisão do processo de Homologação de Modelo de Dados Tema: Tecnologia da Informação Responsável: SEAD Delimitação da ação: Refere-se ao projeto de revisão do processo de Homologação de Modelo de Dados da Seção de Administração de Dados (SEAD) do TSE. Objetivos e metas O trabalho de homologação de modelos de dados efetuado pela equipe de administração de dados (AD) da SEAD considera, sobretudo: que o dado é um ativo organizacional que deve ser gerenciado de forma corporativa, coordenada e integrada; a necessidade de dados íntegros, precisos, completos e corretos para a tomada de decisão no âmbito do TSE; a necessidade de homogeneizar e alinhar as atividades cotidianas relacionadas à gestão de dados e de metadados da Justiça Eleitoral no âmbito do TSE. No início do trabalho de homologação dos modelos de dados, todo o processo era manual e, portanto, suscetível a erros, a diferenças de acordo com o profissional envolvido na tarefa, impossível de ser medido/gerenciado e focado apenas em questões sintáticas. O projeto de revisão do processo de homologação de modelo de dados surgiu como uma necessidade natural, no intuito de tornar a tarefa mais ágil, menos parcial, mais focada no requisito do negócio envolvido, mais simples e possibilitando, desta forma, uma melhoria na qualidade dos modelos de dados e, consequentemente, dos sistemas de informação (SIs) a partir deles construídos. Atualmente, o processo de homologação: é efetuado em grande parte de forma automatizada; parte de um conjunto mínimo de requisitos de negócio; está praticamente desvinculado do profissional envolvido na homologação; possibilita a identificação dos objetos já homologados pela AD; baseia-se em uma lista de quesitos mínimos de qualidade, incluindo aspectos de padronização de nomes, dicionarização de objetos, normalização, reusabilidade e integração entre sistemas;

2 possui como saída um relatório de homologação gerado de forma automática; possibilita a medição da qualidade do modelo de dados e, portanto, uma melhor gerência do processo, de acordo com a quantidade de modelos homologados, o que municia inclusive as equipes de desenvolvimento e de gerência de projeto em relação à necessidade de uma remodelagem dos SIs; visa a gravação do resultado da avaliação dos modelos em uma base de dados para geração automática de indicadores. Este trabalho visa detalhar a revisão no processo de homologação de modelos de dados efetuado pela AD, apresentando os ganhos obtidos com o novo processo e a sua potencial reutilização por outras unidades do Poder Judiciário. A seção a seguir apresenta em detalhes a evolução do processo de homologação de modelos de dados, descrevendo os detalhes. Evolução do Processo de Homologação de Modelos de Dados O processo de homologação de modelos de dados destaca-se como um dos principais da área de AD na SEAD do TSE. Consiste na análise das estruturas de banco de dados dos SIs propostas pelas equipes de desenvolvimento incluindo aspectos de padronização de nomes, dicionarização de objetos, normalização, reusabilidade e integração entre sistemas. No ambiente do TSE, os desenvolvedores têm a característica de efetuarem: o levantamento dos requisitos do sistema que irão desenvolver ou alterar; a modelagem física do banco de dados sobre o qual o sistema vai funcionar; o desenvolvimento da aplicação em si, dando suporte aos diversos usuários muitas vezes espalhados pela Justiça Eleitoral. Neste cenário, o desenvolvedor é o responsável por enviar as solicitações de alteração de estruturas de banco para a SEAD e esta encaminhá-las para a SEBD (Seção de Administração de Banco de Dados). Dessa forma, os modelos são construídos pela equipe de desenvolvimento com pouca atuação da Administração de Dados. Assim, quando julgar oportuna ou necessária a alteração do banco de dados, a equipe de desenvolvimento encaminha a solicitação de homologação do modelo para a SEAD. Cabe à AD, após análise da solicitação, o envio da mesma para a SEBD, área responsável por aplicar as alterações homologadas nos respectivos bancos de dados. Identificação do problema O processo de homologação de modelos de dados, como um dos principais processos da área de administração de dados se mostrou, desde o princípio, ineficaz em relação ao objetivo maior que é garantir a qualidade dos modelos e, portanto, também dos dados e dos SIs envolvidos. Além disso, esse processo, em

3 comparação com a prática de mercado, se mostrava ainda incipiente, pouco automático e não era transparente no que diz respeito aos critérios de avaliação. Sendo assim, a AD se viu motivada a proceder com uma revisão desse processo de homologação de modelos, cuja evolução é apresentada a seguir. Primeiro processo de homologação de modelos de dados implantado No início dos trabalhos da área de administração de dados a AD, com o intuito de realizar a atividade de homologação de modelos de dados, publicou, em setembro de 2008, um documento de Padrões de Nomenclaturas de Modelos de Dados. Neste documento estavam descritas todas as regras de formação de nomes dos objetos de banco de dados que a Administração de Dados gerenciava. Além da implantação do documento de padrões, o processo evoluiu com a institucionalização da ferramenta case PowerDesigner para a modelagem de dados. Isso gerou menor custo de licença e do contrato de suporte e uma maior facilidade do gerenciamento dos modelos de dados entre as equipes de desenvolvimento. Com a finalidade de facilitar o trabalho do desenvolvedor em relação ao modelo de dados, de acordo com o documento de padrões vigente à época, a AD disponibilizou um aplicativo denominado AnalisaPDM, desenvolvido em linguagem VBScript, dentro do PowerDesigner. Este aplicativo tinha por objetivo apresentar ao desenvolvedor um laudo, em formato texto, com as inconformidades do seu modelo físico de dados (PDM). Este laudo era também gerado pela própria AD para cada modelo de dados submetido a sua análise e era o principal instrumento desta seção para indicar ao desenvolvedor a qualidade do modelo apresentado. Desta forma, a qualidade do modelo estava basicamente atrelada a aspectos sintáticos, o que não garantia a qualidade dos SIs envolvidos. A avaliação do modelo de dados era solicitada à AD geralmente no momento em que o sistema ia entrar em homologação, isso porque, em ambiente de desenvolvimento o desenvolvedor tinha a liberdade para efetuar qualquer tipo de alteração na sua base de dados, desde a manutenção de estruturas de dados até a criação e a depuração de rotinas de banco. A avaliação de modelos se pautava, sobretudo, em critérios sintáticos descritos no documento de padrões citado. O fluxo de avaliação iniciava quando o desenvolvedor descrevia a solicitação no e a enviava para a SEAD. Neste e- mail, era definido um padrão que contemplava o assunto e os itens que deveriam nele estar contidos. O desenvolvedor incluía, na maioria das vezes, o script de alteração do banco de dados. E assim, não havia qualquer tipo de justificativa do pedido de alteração, como um caso de uso alterado ou a solicitação do cliente para a alteração, por exemplo. O desenvolvedor também precisava, todas as vezes, incluir no o arquivo PDM com o modelo de dados relativo à solicitação. Entre outras implicações, isso significava um grande volume de dados trafegando pela rede e a necessidade de maior gerência por parte da AD em relação à versão do modelo a ser avaliado.

4 Esse processo preliminar de homologação de modelos de dados (ou parte dele) possuía inúmeras falhas, conforme abaixo: as solicitações eram encaminhadas por e, portanto, havia dificuldade de: gerenciamento das solicitações; ordenação e priorização do atendimento; rastreamento e pesquisa das sugestões/pareceres da AD e das explicações do desenvolvedor em relação ao modelo apresentado para análise; medição da quantidade de solicitações e do tempo de atendimento de cada uma delas; alto volume de dados trafegados por e conseqüente dificuldade de gerência das versões dos modelos a serem avaliadas; impossibilidade de identificação, no modelo, dos objetos homologados pela AD; inexistência de vínculo entre a alteração de banco solicitada e a regra de negócio do sistema envolvido; inexistência de ferramenta de apoio à homolagação dos modelos por parte da AD, exceto pelo aplicativo AnalisaPDM; resistência da equipe de desenvolvimento em acatar as sugestões da AD, dado que, normalmente, quando o modelo chegava à AD, já havia bastante código pronto da aplicação, o que é decorrente do fato do ambiente de desenvolvimento ser aberto aos desenvolvedores; inexistência de uma análise de impacto quando a solicitação envolve a remoção de objetos de banco, o que pode causar inconsistência em outros SIs. Esse processo de avaliação, no entanto, permitia a geração automática de indicadores de qualidade do modelo, baseada exclusivamente nos critérios sintáticos descritos no documento de padrões e automaticamente avaliados pelo AnalisaPDM. Visando alcançar modelos de melhor qualidade e uma maior eficiência do processo de homologação e acompanhamento de solicitações, submetemos o processo a uma nova revisão. Segundo processo de homologação de modelos de dados implantado Visando minimizar os problemas decorrentes do uso do para o encaminhamento de solicitações à SEAD, observou-se a necessidade de criar uma ferramenta que suportasse e controlasse o fluxo de solicitações tanto para a SEAD quanto para a SEBD. Desta forma, a primeira alteração no processo, que ocorreu em maio de 2008, foi a criação do aplicativo intitulado SOLICITA, construído na ferramenta Apex. Por meio deste aplicativo o desenvolvedor cria solicitações de avaliação de modelos de dados e indica o número da revisão do arquivo do modelo de dados constante repositório da ferramenta de controle de versão de documentos, o SVN. Por fim o desenvolvedor pode incluir algum tipo de justificativa da alteração ou criação solicitada. Por meio do aplicativo SOLICITA, foi possível:

5 o melhor gerenciamento do atendimento de solicitações; o acompanhamento do andamento da solicitação pelas áreas envolvidas, uma vez que as mudanças de fase são registradas automaticamente no aplicativo; a maior integração entre as áreas de desenvolvimento, o administrador de dados e o administrador de banco de dados; a rastreabilidade das alterações nos modelos de dados por ambiente (homologação, produção), possível em função da funcionalidade de pesquisa por sistema, solicitante (desenvolvedor), número da solicitação e período disponível no aplicativo; a geração de indicadores automáticos como, por exemplo, a quantidade de solicitações e o tempo de atendimento; a diminuição do volume de dados trafegados via rede durante o atendimento de uma solicitação, já que os modelos de dados não são inseridos no aplicativo, mas sim indicado o seu número de revisão no SVN a ser avaliada. Nesta nova remodelagem do processo de homologação, foi criado primeiramente um modelo de documento em Word, no qual a AD incluía as suas considerações em relação aos objetos do modelo a ser avaliado, de forma completamente manual e livre. O desenvolvedor, por sua vez, para cada observação sobre a qual ele queria tecer suas considerações, incluía uma nova linha e devolvia a solicitação para a SEAD, com o arquivo alterado em anexo. Em um segundo momento, dada a dificuldade de gerência deste documento em Word, definiu-se um padrão, na ferramenta Excel, de documento para o envio do relatório de homologação dos modelos. Neste padrão, a AD incluía as observações relativas à homologação do modelo de forma manual e livre, porém com maior objetividade. A AD versionava este documento em um repositório da ferramenta SVN de seu domínio, para preservação do histórico de alterações/recomendações. No entanto, continuava sem ser possível a identificação dos objetos já homologados de forma automatizada. Desta forma, para saber se um objeto já havia sido homologado pela AD, era necessário efetuar uma busca pelo seu nome dentro do arquivo e assim verificar as considerações da AD. Nesse processo também não havia o conceito de homologação de objetos, mas apenas de homologação da solicitação. Além do AnalisaPDM, a AD também efetuava algumas verificações subjetivas, sem a transparência de quais critérios estavam sendo aplicados. Isso porque para cada objeto havia um conjunto de considerações da AD para as quais não havia associado um resultado explícito. Desta forma, não havia, exceto pelos critérios do AnalisaPDM, a transparência em relação aos outros critérios subjetivos. Uma outra alteração que impactou positivamente no processo de homologação de modelos de dados foi a elaboração do Documento de Padrões de Formação de Nomes para Modelagem de Dados, elaborado com base no documento Padrões de Nomenclaturas de Modelos de Dados vigente à época, e publicado em outubro de Este novo documento foi elaborado com o intuito de definir regras de padrões de nomes para objetos que tornassem mais fácil para os desenvolvedores, em especial, a identificação da funcionalidade dos objetos com base em seu nome. Ele foi elaborado retirando-se do documento anterior detalhes, por exemplo, de

6 formatação visual do modelo. Em adição a este documento, foi criado um folder para referência rápida, facilitando a divulgação dos padrões e o seu uso pelas equipes de desenvolvimento. Visando extinguir o problema da inexistência de uma análise de impacto quando a solicitação envolve a remoção de objetos de banco, uma outra melhoria no processo de homologação de modelos foi a criação do script denominado Análise de Impacto. Este script roda um procedimento de banco nos ambientes informados para verificar se o objeto a ser excluído, conforme informado na solicitação, é referenciado por algum outro objeto de banco de dados, mesmo que em outro esquema de banco de dados. A saída é um arquivo contendo a indicação dos objetos com tipo, nome e owner (dono de esquema de banco de dados) dos objetos afetados pela exclusão solicitada. Esse script possibilita, portanto, uma análise mais criteriosa da alteração de banco, evitando que a remoção de um objeto venha a impactar no funcionamento do SI envolvido ou mesmo de outros SIs. Esse processo de homologação de modelos de dados ainda possuía inúmeras falhas, conforme abaixo: impossibilidade de identificação, no modelo, dos objetos homologados pela AD; inexistência de vínculo entre a alteração de banco solicitada e a regra de negócio do sistema envolvido, e a justificativa da alteração; inexistência de ferramenta de apoio à homologação dos modelos por parte da AD, exceto pelo AnalisaPDM; inexistência de critérios objetivos e transparentes para a homologação do modelo de dados encaminhado pelo desenvolvedor, exceto aqueles utilizados pelo aplicativo AnalisaPDM; pouca agilidade no preenchimento manual das sugestões da AD em relação ao modelo de dados, no documento Excel gerado após a homologação; resistência da equipe de desenvolvimento em acatar as sugestões da AD, dado que, normalmente, quando o modelo chegava à SEAD, já havia bastante código pronto da aplicação, o que é decorrente do fato do ambiente de desenvolvimento continuar aberto aos desenvolvedores. Terceiro processo de homologação de modelos de dados implantado Visando automatizar ainda mais o processo e dar a ele transparência e objetividade, essa nova etapa de revisão do processo de homologação de modelos de dados consistiu na análise dos seguintes itens: regras de validação customizadas na ferramenta AnalisaPDM; modelo da planilha Excel de avaliação; críticas ao atual processo de homologação e lições aprendidas publicadas em documentação interna da SEAD. Para resolver o problema da falta de critérios objetivos e transparentes para a homologação do modelo de dados, com base em melhores práticas de mercado e levando em consideração a realidade do TSE, foi publicado em outubro de 2010 um

7 documento com os quesitos para homologação, disponível em Adicionalmente, criou-se uma camada que, agregada ao modelo de dados na ferramenta PowerDesigner, possibilitou a automação do processo de homologação com base nos quesitos publicados e nos tipos de objeto avaliados. Essa camada permitiu padronizar a homologação, dado que é fornecido um conjunto de opções válidas de preenchimento para um determinado quesito. Desta forma, qualquer AD efetua a homologação segundo os mesmos critérios e, ainda, o resultado alcançado é uniforme, dado que é calculado automaticamente, por meio desta camada, o resultado da homologação, podendo ser homologado, não homologado ou homologado com ressalvas. Esta camada agregada ao modelo de dados possui outras funcionalidades que também beneficiaram o processo de homologação de modelos de dados: definição da bancada: consiste do escopo da solicitação, que pode abarcar o modelo de dados completo, bem como parte dele. A avaliação, desta forma, é efetuada apenas sobre os objetos disponíveis nesta bancada. Para se efetuar a carga desta bancada, a AD realiza uma comparação, no PowerDesigner, do último modelo avaliado com a versão do modelo indicada pelo desenvolvedor. Do resultado da comparação, são marcados apenas aqueles objetos aos quais o desenvolvedor se referiu na solicitação como novos ou alterados. O arquivo XML gerado na comparação pelo PowerDesigner é então utilizado para o carregamento da bancada, que define o escopo da avaliação; geração automática do relatório de homologação, a partir dos resultados da análise de cada um dos quesitos para cada um dos objetos da bancada. Este relatório indica, ao final, o estado de homologação do objeto e da solicitação como um todo. Este resultado é gerado automaticamente com base na obrigatoriedade ou não dos quesitos de homologação. Atrelada a esta camada, foi instituído, tanto para as equipes de desenvolvimento quanto para a AD, o uso do repositório do PowerDesigner para o armazenamento e o versionamento dos modelos de dados. Foi criada para as equipes de desenvolvimento uma instância e outra para a equipe de AD. No repositório de desenvolvimento, intitulado PRJ, os desenvolvedores mantem os seus modelos de dados. Quando as solicitações de homologação de modelos são enviadas para a AD, o desenvolvedor indica o número da revisão do modelo neste repositório a ser avaliada. Na instância do repositório criada para a equipe de AD são mantidos e versionados os modelos de dados que são homologados. Desta forma, consegue-se identificar os objetos homologados em cada modelo e visualizar, para cada um deles, o resultado da homologação. Este novo processo de homologação, decorrente desta nova revisão, conseguiu alcançar os seguintes benefícios: resultado da homologação tornou-se impessoal e objetivo;

8 integração dos procedimentos de homologação espalhados em ferramentas, dentre elas o AnalisaPDM e o próprio relatório de homologação, na camada criada sobre o modelo de dados; padronização, clareza e transparência dos resultados de uma homologação; manutenção de um repositório central que disponibiliza uma visão do todo ao desenvolvedor, permitindo a visualização dos objetos que foram homologados ou não pela AD; carga do escopo de uma homologação de forma automática; gravação do resultado em uma base de dados de forma consolidada, para acompanhamento e geração de indicadores; geração automática do relatório de homologação; possibilidade de difusão da camada customizada no PowerDesigner entre outros órgãos ou unidades da Justiça, o que já está para acontecer no caso do STF, que solicitou, em uma visita à SEAD, esta camada para uso em sua instituição. Nesta fase também foi implantada rotina denominada AuditoriaDDL, com o objetivo de registrar e companhamento as alterações em bancos dados no ambiente de desenvolvimento de forma a medir a quantidade de instruções DDL efetuadas. Esta rotina auxilia a equipe de AD no entendimento e argumentações quando da homologação das alterações. Verifica-se que, no processo de desenvolvimento de software, a quantidade de alterações em estruturas de dados corresponde a 30% e que 70% (Gráfico 1) referem-se a alterações em código fonte, corroborando a técnica de que, após a construção de um modelo de dados estável o processo de depuração e testes são primordialmente em rotinas procedurais.

9 Quadro comparativo Quantidade de Tipos de Objetos Quantidade de quesitos Quantidade de ferramentas Quantidade de falhas identificadas Primeiro processo de Homologação de Modelos Segundo processo de Homologação de Modelos Terceiro processo de Homologação de Modelos X (levantar as falhas) Trabalhos Futuros Visando o refinamento do processo de homologação de Modelo de Dados surgiu a necessidade de elaboração um plano de ação por meio da ferramenta de planejamento denominada 5W2H. O que fazer Controle efetivo das alterações de estruturas de dados no ambiente de desenvolvimento. Porque será feito Como fazer Quando fazer Quem fará Onde será feito Quanto custará Gerenciar e garantir a qualidade das alterações propostas no ambiente, antes da codificação do aplicativo. Retirada do acesso dos desenvolvedores A partir de 05 de setembro de 2011, incorporando uma seção de desenvolvimento quinzenalmente. SEAD/ SEBD Nas bases de dados de desenvolvimento - O que fazer Definição da meta de atendimento para serviço de homologação de modelos de dados Porque será feito Como fazer Quando Quem Onde será feito Quanto

10 fazer fará custará Publicação do documento da meta de atendimento (SLA) Elaborar proposta de acordo com o atual processo. Implementar a rotina de cálculo de SLA automática. Setembro/20 11 SEAD SEAD - O que fazer Customização de uma camada de abstração na ferramenta Power Designer para validação e ajustes automáticos de critérios sintáticos mínimos no modelo de dados, antes do envio para homologação. Porque será feito Como fazer Quando fazer Quem fará Onde será feito Quanto custará Maior qualidade do modelo de dados. Customização das regras para validação automáticas Novembro/2011 SEAD SEAD Estimado em 60 horas O que fazer Implantação em produção da rotina de gravação das homologações realizadas e disponibilização de painel com indicadores gerenciais. Porque será feito Como fazer Quando fazer Quem fará Onde será feito Quanto custará Acompanhamento da evolução da qualidade dos modelos de dados Finalização dos testes na base de desenvolvimento e configuração do painel com os indicadores gerenciais Outubro/2011 SEAD SEAD Estimado em 20 horas O que fazer Criação do modelo conceitual corporativo

11 Porque será feito Como fazer Quando fazer Quem fará Onde será feito Quanto custará Promover a reutilização de objetos e disseminar o conhecimento na instituição Levantamento e documentação do modelo corporativo na ferramenta Case Designer 2012 SEAD SEAD Conclusão A área de AD possui como missão principal a homologação de modelos de dados observando os critérios de qualidade. Para isso, a mesma estabeleceu ao longo do tempo, desde a sua instituição em 2006, mecanismos de controle e gerencia dos modelos de dados. Pelo que foi descrito ocorreram diversas iniciativas de melhorias no processo. Observa-se que, de início, havia poucas técnicas de contagem e ferramentas que auxiliassem nesse processo. No processo de homologação atual, obtido por meio das revisões citadas neste artigo, podem ser listados os principais benefícios: é efetuado em grande parte de forma automatizada; parte de um conjunto mínimo de requisitos de negócio; está praticamente desvinculado do profissional envolvido na homologação; possibilita a identificação dos objetos já homologados pela AD; baseia-se em uma lista de quesitos mínimos de qualidade, incluindo aspectos de padronização de nomes, dicionarização de objetos, normalização, reusabilidade e integração entre sistemas; possui como saída um relatório de homologação gerado de forma automática; possibilita a medição da qualidade do modelo de dados e, portanto, uma melhor gerência do processo, de acordo com a quantidade de modelos homologados, o que municia inclusive as equipes de desenvolvimento e de gerência de projeto em relação à necessidade de uma remodelagem dos SIs; visa a gravação do resultado da avaliação dos modelos em uma base de dados para geração automática de indicadores.