web
counter
Ativos: O Cofre e o Guardião

Ativos: O Cofre e o Guardião

Continuação de “Etiquetando Ativos de Software“. Parte da série “Gerenciando Ativos de Software“.

Foto de Kk+.

A classificação e organização dos ativos de software sugeridas no capítulo anterior indicam claramente a necessidade de um repositório. Um misto de ‘cofre’ e estoque que deve armazenar e facilitar a recuperação de todo o patrimônio catalogado. O padrão RAS apresenta uma especificação relativamente simples para a implementação de um repositório, que visa exclusivamente o armazenamento e a recuperação de ativos [1]. O diagrama abaixo apresenta uma visão geral do serviço do repositório RAS:


Basicamente são definidos apenas dois serviços: a busca através de palavras-chave ou pelo caminho lógico do arquivo. Já existem algumas ferramentas* que atendem essa necessidade, todas oferecendo mais funcionalidades do que aquelas previstas na especificação RAS. A lista abaixo apresenta as funções que deveriam existir em todo repositório de ativos de software [2]:

  • Identificação e Descrição dos Ativos: todos os ativos devem ser apresentados de maneira homogênea, utilizando uma mesma interface.
  • Cadastramento de Ativos: o repositório deve facilitar a inserção de novos itens.
  • Navegação no Catálogo de Ativos: os usuários devem ter condições de navegar por todo o repositório, refinando as listas por Tipo de Ativo, Contexto, Histórico de Uso e todos os demais atributos que caracterizam um ativo.
  • Busca Textual: os usuários devem ter condições de procurar por ativos a partir de trechos ou palavras que constem de seu nome, descrição ou demais atributos.
  • Recuperação: a recuperação de um determinado ativo deve ser fácil e direta.
  • Informação Completa: é crucial que a interface mostre todos os dados sobre o ativo. Suas dependências, por exemplo, devem ser nítidas para os usuários.
  • Histórico: todo o histórico de uso do ativo (informações que não constam na especificação RAS original, conforme alertado no capítulo anterior) também deve ser de fácil acesso.
  • Contabilidade: todos os números relativos ao uso do ativo (número de acessos, reuso efetivo etc) bem como os números gerais do próprio repositório (total de ativos, número de buscas bem e mal sucedidas etc) devem ser fornecidos.
  • Controle de Acesso: todas as funcionalidades do repositório devem estar disponíveis para perfis específicos. Enquanto o Gestor da Biblioteca (mais sobre ele abaixo) tem controle total do repositório, os desenvolvedores não deveriam ter condições de alterar diretamente informações sobre os ativos, por exemplo.
  • Gerenciamento de Versões: ativos podem ter várias versões diferentes. É fundamental que o repositório faça o controle de versões.
  • Controle de Mudanças: assim como é importante que o repositório forneça suporte automático para a requisição, discussão, aceitação e implementação de mudanças nos ativos.
  • Notificação de Mudanças: por fim, o repositório deveria ‘avisar’ todos os usuários quando uma mudança em determinado ativo for solicitada ou implementada.

É desejável que o repositório ofereça dois tipos distintos de interfaces com os usuários finais:

  1. Totalmente integrada ao ambiente de desenvolvimento (IDE), facilitando a convivência dos desenvolvedores (analistas, programadores e testadores) com os ativos que podem ou devem ser utilizados naquele projeto;
  2. Interface acessível via browser, para todas as tarefas de gerenciamento do repositório: manutenção do cadastro de ativos, relatórios e estatísticas etc.

A implantação de processos que levem ao reuso sistemático de ativos de software requer a existência de um repositório gerenciado. Abaixo são apresentados o perfil e as responsabilidades do profissional que deve gerenciar o repositório de ativos de software.

O Gestor da Biblioteca de Ativos (GBA)

Como foi colocado anteriormente nesta série, se o conteúdo do repositório for confuso e mal estruturado (mal padronizado), corre-se o risco de não aproveitar todas as oportunidades abertas pelo investimento. A organização deve delegar para um profissional ou um pequeno grupo a responsabilidade pelo gerenciamento do repositório de ativos.

Em alguns trabalhos [3] são sugeridos dois perfis distintos: o Gestor de Ativos (Asset Manager) e o Bibliotecário (Asset Librarian). Quando o foco da iniciativa é a implantação do reuso sistemático [2], são sugeridos o Gestor de Reuso (Reuse Manager) e o Gestor da Biblioteca de Ativos (Asset Library Manager). Neste ponto será apresentado apenas o GBA. Os próximos capítulos desta série apresentarão os processos de reuso e o gerenciamento do ciclo de vida dos ativos, bem como os demais perfis demandados por eles.

O GBA “gerencia o repositório e sua configuração, e garante que os ativos estejam sempre disponíveis para os desenvolvedores” [2]. Por ser um perfil pouco comum nas organizações de TI, cabe elencar algumas de suas principais características:

  • É um programador e/ou analista de sistemas;
  • Tem bons conhecimentos da principal arquitetura tecnológica em uso e, consequentemente, dos Ativos Horizontais que compõem o repositório;
  • Domina o uso do repositório e de todas as ferramentas (IDE’s e afins) que o acessam;
  • Domina e respeita o “Guia de Criação, Manutenção e Uso de Ativos”**;
  • Mantém bom relacionamento com todos os desenvolvedores e coordenadores de projetos da organização;
  • É organizado e disciplinado.

O gerenciamento do repositório não significa sua posse. O GBA apenas garante a disponibilidade e ‘limpeza’ do repositório. Mas não é ele quem determina o que pode e o que não pode ser realizado ali. As decisões pela inserção e deleção de ativos, por exemplo, fazem mais sentido quando são da alçada do grupo que cuida da Arquitetura Corporativa (AC). Cada equipe de projeto ou profissional pode sugerir adições ao repositório. Mas a palavra final deveria ser de um comitê central (AC).

O GBA também não tem poderes sobre um ativo. Cada ativo cadastrado possui um autor e um dono. Alterações, sugestões de melhorias ou problemas com um determinado ativo são tratadas diretamente com o seu proprietário (ou com um grupo de suporte, como será apresentado nos próximos capítulos). O GBA pode, no máximo, intermediar o processo. Sendo assim, quais seriam então as principais responsabilidades do GBA? Elas estão sumarizadas abaixo:

  • Gerenciamento do Repositório: garantindo sua disponibilidade e performance. Sendo assim, relaciona-se (nas exceções e dúvidas) com todas as equipes de desenvolvimento;
  • Publicação do Catálogo de Ativos: atualiza e publica o catálogo com todos os ativos constantes do repositório. Espera-se que uma boa ferramenta realize tal serviço, mas sua manipulação é uma responsabilidade do GBA;
  • Manutenção do Catálogo: a inserção, atualização e exclusão de ativos é realizada pelo GBA. É uma forma de garantir que todas as diretrizes fixadas no “Guia”** serão respeitadas.

[continua]

.:.

Referências:

  1. RAS – Reusable Asset Specification – Versão 2.2
    Object Management Group (OMG) (05/Nov/2005).
  2. Practical Software Reuse
    Michel Ezran, Maurizio Moricio e Colin Tully
    Springer (2002).
  3. Asset Lifecycle Management for Service-Oriented Architectures
    Grant Larsen e Jack Wilber.
    IBM/Rational (2005).
.:.

Observações:

* – Ferramentas: A Flashline, recentemente adquirida pela Bea, há tempos oferece um repositório desenhado especificamente para o reuso sistemático de ativos de software. Sourceforge (VA Software) e IBM também possuem produtos que podem ser adaptados para atender os requisitos apresentados neste artigo.

** – Guia de Criação, Manutenção e Uso de Ativos: um documento que seria elaborado pela equipe de Arquitetura Corporativa ou similar. Nos próximos capítulos desta série ele será apresentado em maiores detalhes.