Ativos: Ciclo de Vida e Processos

Seqüência de "Ativos: O Cofre e o Guardião", capítulo da série "Gerenciando Ativos de Software".


Antes que possamos falar especificamente sobre processos de desenvolvimento e administração de ativos, é importante entender o seu Ciclo de Vida. Quando nos preocupamos exclusivamente com o reuso, percebemos apenas duas atividades principais [1]: o desenvolvimento de ativos (dos serviços, em uma SOA); e o desenvolvimento dos produtos / aplicações (ou meta-aplicações em uma SOA), que utilizam os ativos como blocos de construção. No entanto, se a intenção é o completo gerenciamento dos ativos de software, o desenvolvimento de ativos e aplicações é só uma parte do trabalho. Porque devemos gerenciar todo o ciclo de vida dos ativos. E este ciclo é composto por 5 momentos bastante distintos [2*]:

• Identificação: a necessidade ou o potencial de (re)uso de um determinado ativo é identificado. Requisitos e restrições são levantados e a viabilidade de sua produção é estudada. Em um programa SOA, identificamos serviços.
• Produção: momento no qual um ativo é produzido. Como veremos posteriormente, um ativo pode ser produzido no contexto de um projeto ou em uma unidade destacada especificamente para este fim.
• Consumo: o ativo é (re)utilizado na construção de aplicações ou meta-aplicações.
• Manutenção: etapa de duração indeterminada, existe enquanto o ativo estiver disponível para consumo (no repositório) ou em uso por uma ou mais aplicações.
  
• Aposentadoria: quando um ativo é descartado, na maioria das vezes sendo integralmente substituído.

Para cada momento no ciclo de vida de um ativo de software há um processo específico. A lista abaixo apresenta os processos e suas principais responsabilidades [3]:

• Identificação
  
  • Coleta e Análise de Requisitos
  • Análise do Negócio
  • Avaliação Custo / Benefício
    
    
• Produção
  
  • Desenvolvimento do Ativo (ou Aquisição e Customização)
    
  • Testes e Qualificação
  • Classificação (aplicação etiqueta RAS)
    
    
• Consumo
  
  • Busca e Avaliação do Ativo
  • Integração (desenvolvimento da aplicação)
  • Relatório sobre o (re)uso
    
    
• Manutenção
  
  • Cadastramento do Ativo (catálogo e repositório)
    
  • Suporte ao Ativo
  • Administração e Suporte ao Repositório
  • Gerenciamento de Mudanças nos Ativos
    
    
• Aposentadoria
  
  • Análise de (re)uso, redundâncias e oportunidades de melhoria
  • Preparação para descarte do Ativo
  • Remoção do Ativo

É interessante notar que, apesar de algumas semelhanças, os processos acima não sobrepõem nem podem substituir um processo de desenvolvimento tradicional. As atividades listadas extrapolam as fronteiras de um projeto. E devem compor um Programa de Gerenciamento de Ativos (que pode ser um sub-conjunto de um Programa SOA). O diagrama abaixo relaciona alguns dos processos listados com o RUP [2]:


Reparem que a produção de ativos pode ser parte de um projeto ou uma responsabilidade de outro grupo (na parte inferior do gráfico). No entanto, essa possibilidade não deveria ser aceita em iniciativas de reuso sistemático nem em programas SOA.

No primeiro caso, por tranferir para um projeto um conjunto de atividades (e respectivos custos) que raramente se justificam. A pulverização das atividades de produção também pode comprometer a qualidade dos ativos. Para a implantação do reuso sistemático, parece ser mais indicado que um grupo seja criado para tratar exclusivamente das atividades de produção.

Em programas SOA, o cenário sinalizado pelo diagrama acima parece ainda menos factível. A divisão entre o desenvolvimento de ativos (serviços) e aplicações é de certa forma arbitrária. O desenvolvimento de cada serviço deve ser visto como um projeto em si, independente de seu porte. E em um projeto para a construção de uma meta-aplicação (puro consumo de ativos / serviços), a inserção da construção de um serviço em seu escopo pode significar aumento da complexidade sem nenhum benefício que o justifique.


Distribuindo Responsabilidades

Como vimos no capítulo anterior, as atividades de administração e suporte ao repositório, cadastramento de ativos e manutenção do catálogo são de responsabilidade do GBA (Gestor da Biblioteca de Ativos). Esta pessoa ou grupo deve ficar subordinada ao comitê que administra os ativos ou o programa SOA. As atividades de Identificação, Manutenção e Aposentadoria de ativos (serviços) seriam uma responsabilidade deste comitê gestor. É lógico que o porte da iniciativa (principalmente o número de ativos), é que determinará o tamanho desta estrutura. As atividades de suporte e melhoria dos ativos podem ser tratadas como pequenos projetos, e delegadas para a equipe de produção.

Como foi dito anteriormente, é indicado que a equipe de produção seja uma entidade autônoma, principalmente em relação àquelas que desempenham atividades de consumo de ativos. Seguindo um padrão que caracteriza os serviços em uma SOA, o ideal é que todas as equipes sejam "levemente acopladas".

Sendo assim, temos um desenho que apresenta três grandes grupos de pessoas:

• Gerenciamento de Ativos
• Produção de Ativos
• Consumo de Ativos

[continua]



Os próximos 3 capítulos falarão sobre os processos de cada um dos 3 grupos acima. Aumentei consideravelmente o escopo deste trabalho, e por isso o prazo de 11/jan foi sumariamente desconsiderado. Nesta semana mesmo publiquei um breve "desvio" da série, para falar exclusivamente sobre a criação de uma (necessária) base de conhecimentos. Não a considerei uma parte desta série, mas é provável que ela apareça (devidamente ampliada e remodelada) na compilação final. Compilação que eu espero publicar ainda em fevereiro. O desvio que fui obrigado a realizar foi bem maior do que o artigo citado mostra: mergulhei na disciplina "Engenharia de Requisitos" para adaptá-la para programas de reuso e, principalmente, SOA. No próximo capítulo mostro meus achados.


Referências:

1. Objects, Components, and Frameworks with UML - The Catalysis Approach
   Desmond F. D'Souza e Alan Cameron Wills
   Addison-Wesley (1999).
2. Asset Lifecycle Management for Service-Oriented Architectures
   Grant Larsen e Jack Wilber
   IBM / The Rational Edge (2005).
   * O artigo original fala de 4 workflows. Adaptei a terminologia e inseri o momento "Aposentadoria". Justifico as alterações no próximo capítulo.
   
3. Practical Software Reuse
   Michel Ezran, Maurizio Morisio e Colin Tully
   Springer (2002).
   

Marcadores: gerenciamento_de_ativos, mps, qualidade, reuso, soa, spi