Na 1ª parte ele fixa as 3 áreas que devem ser ‘atacadas’ no início de um programa SOA:

• Gerenciamento do Portfólio
• Arquitetura Corporativa
• Gerenciamento da Informação

No gráfico acima ele mostra o ‘ataque’ e suas derivações mais específicas, ilustrando em alto nível os principais papéis e responsabilidades que existem em uma equipe formada para implementação de uma SOA.

Na 2ª parte ele sugere a criação de um “SOA Steering Comittee”. No desenho abaixo os membros do comitê e respectivas disciplinas:

A sugestão do Schneider tem algumas semelhanças com aquele desenho que apresentei aqui há quase 2 anos:

O Gerenciamento do Portfólio é uma das áreas críticas, segundo Schneider. No meu ponto de vista, deveria ser uma responsabilidade do próprio Gestor do Programa (“SOA Leader” na nomenclatura utilizada por ele). Auxiliam no gerenciamento do portfólio o Arquiteto de Negócio e o Gestor da Biblioteca de Ativos (GBA), além do representante do PMO (Escritório de Projetos). Entendo que portfólio são os projetos e os ativos existentes. É grande demais para uma cabeça só. Aproveito para insistir que uma boa ferramenta de apoio para tal gerenciamento, sintética e objetiva, é o Mapa Estratégico. Desde que devidamente adaptado para o programa.

Foto de Bryan Furnace.

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 : 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 :

• 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 :

• 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 :

Clique para ampliar.

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

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).
   

Neste ponto eu começaria a escrever sobre os processos necessários para a administração de ativos de software e para o reuso. O ponto de partida e um dos fatores mais importantes e críticos tanto para o reuso quanto na implementação de uma SOA é a Engenharia de Requisitos — ou, colocando em outro padrão, o Desenvolvimento e o Gerenciamento de Requisitos. Para explicar a importância desta disciplina no contexto da série, basta lembrar uma frase que citei em um dos primeiros capítulos: “Oportunidades de reuso são como bugs: quanto antes elas forem encontradas, melhor” .

As similaridades e as diferenças entre aplicações são encontradas em dois lugares principais: nos requisitos e na arquitetura. O primeiro delimita o problema. A segunda aponta uma forma de solução. Foi aqui que esbarrei numa questão que acabou ‘forçando’ este post: afinal, como coletar requisitos com o objetivo de detectar oportunidades de reuso?

A busca pela resposta acabou me levando de volta para uma antiga briga*: sem uma base de conhecimentos bem estruturada, esse levantamento é uma tarefa hercúlea, cara e nada ágil. Se boa parte das ferramentas para administração de requisitos ainda não achou uma boa solução para a rastreabilidade*, o que esperar então da forma como elas tratarão essa “nova” demanda?

Porque não se trata apenas de recuperar os requisitos. Devemos ter condições de analisar todo o histórico de construção – observar todas as derivações (modelos, código etc) e conhecer as decisões tomadas. Conhecer todo o ciclo de vida de um ativo pode ser um fator determinante para a sua reutilização.

As etiquetas RAS, apresentadas anteriormente, suprem uma parte dessas necessidades. Mas tanto as suas informações quanto a sua forma de persistência não atenderiam plenamente a demanda pela busca e comparação de requisitos.

Uma deficiência do padrão, apontada anteriormente, é o fato dele não contemplar o histórico de (re)uso do ativo. Se considerarmos então tudo o que precisamos saber sobre os requisitos, definitivamente o padrão RAS não é suficiente. Sua forma de armazenamento (arquivos XML em um sistema de arquivos tradicional) também não facilita as tarefas de busca. Precisamos de uma base de conhecimentos bem estruturada. E sua persistência em um sistema gerenciador de bancos de dados parece ser a melhor alternativa.

Clique para ampliar.

O padrão RAS é extensível. E ele já recebe informações sobre requisitos na entidade/classe “Artefato”. O que eu sugiro no diagrama acima é uma extensão do padrão, de forma que ele possa contemplar informações mais específicas sobre os requisitos e sobre o negócio. Utilizei três fontes para traçar o diagrama conceitual: a base que descrevi no artigo supra-citado*, o “Requirements Knowledge Model” de Suzanne e James Robertson , e o meta-modelo básico de conceitos de modelagem de negócios proposto por Hans-Erik Eriksson e Magnus Penker .

Todos os requisitos são associados aos casos de uso que, por sua vez, são vinculados à processos de negócio. A caracterização e descrição dos processos é apoiada por quatro elementos básicos: seus Objetivos, Recursos, Eventos e Regras. Informações básicas sobre o negócio podem facilitar a busca e a comparação de requisitos.

Os requisitos também são associados aos elementos que formam a solução. A vinculação direta é com os casos de uso, segundo o padrão RAS, também são cadastrados como “Artefatos”. Desta forma é possível rastrear todas as derivações que ocorreram durante o desenvolvimento de determinada solução.

Na parte inferior do diagrama eu apenas sinalizo a possibilidade de classificar e detalhar melhor os requisitos.

É importante salientar que nós não reusamos UM requisito. Não buscamos isso. O que se reutiliza é um conjunto (cluster) de requisitos. Todos os descritores e entidades sugeridas acima existem para possibilitar a formação um conjunto. Por exemplo: podemos selecionar todos os requisitos de um determinado processo de negócio; todos os requisitos funcionais que referenciem determinado recurso; os requisitos não-funcionais de determinado produto / serviço; e assim por diante.

Não é minha intenção aprofundar muito nas questões colocadas neste post. Tanto que ele nem está no ‘padrão de escrita’ da série. Posteriormente, na versão editada desta série e em outros artigos, falarei mais sobre a construção de uma Base de Conhecimentos para organizações que desenvolvem software.

* Obs.: Na realidade, preciso reescrever e corrigir este artigo. É de 2003, e até hoje tá ali no canto, falando de “requerimentos”.

Referências:

1. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
2. Requirements-Led Project Management
   Suzanne Robertson e James Robertson
   Addison-Wesley (2005).
3. Business Modeling with UML – Business Patterns at Work
   Hans-Erik Eriksson e Magnus Penker
   Wiley (2000).
   
   

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 . 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 :

• 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 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 , 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” . 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.

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.

No artigo anterior foi apresentada a “etiqueta” RAS (Reusable Asset Specification) , na sequência de uma definição sobre ativos de software e suas principais características. Neste post o padrão RAS será apresentado em maiores detalhes. O modelo abaixo apresenta uma visão geral dos elementos do Core RAS:

Clique para ampliar.

Existem 4 grandes grupos de informações sobre os ativos: Classificação, Solução, Uso e Ativos Relacionados. Abaixo serão apresentados os elementos de cada um dos grupos. Cabe lembrar que o Perfil e os Perfis Relacionados são extensões específicas de um ativo. Serão apresentados aqui apenas os elementos do Core RAS, ou seja, aqueles obrigatórios segundo o padrão.

Classificação

Trecho do padrão que trata da definição, identificação e contextualização de um ativo de software. Ele possui uma série de Descritores que apresentam suas características e qualidades. Enquanto o padrão RAS sugere o uso de uma descrição livre, alguns autores indicam o uso de uma classificação baseada em conjuntos de atributo+valor, como por exemplo: “tipo do ativo: Código”, “linguagem: Java” . Uma correta e ampla classificação facilita a busca por ativos em um repositório.

Assim como a apresentação de um ou mais Contextos. Na última versão publicada do padrão são apresentados alguns exemplos de categorias para contextos, como core, negócios, desenvolvimento, documentação etc. Interessante é que todos os exemplos referem-se a Artefatos e em sua maioria estão relacionados com produtos gerados em determinado momento do ciclo de vida de um ativo. São mais relevantes para a classificação de um ativo as informações acerca do ambiente (ambientes de desenvolvimento, testes e produção) e, em caso de ativos verticais, a descrição do(s) problema(s) de negócio que o ativo endereça.

Outra qualificação aparentemente ausente no padrão RAS* é uma indicação direta do Tipo do Ativo. Essa informação relaciona-se diretamente com o tipo de uso que pode ser feito daquele ativo. A lista abaixo apresenta exemplos de tipos de ativos, mostrando seu Tipo seguido do Tipo de Uso :

• Executável: Chamada direta.
• Biblioteca: Integração.
• Padrão (Pattern): Imitação.
• Frameworks: Customização.
• Pacotes de Software: Integração.
• Requisitos: Comparação.

*Obs.: Porém nada impede que esse tipo de classificação seja realizada através dos elementos Descritor e Grupo de Descritores.

Por fim há um grande elemento chamado Descrição que compila todas as informações sobre a classificação de um ativo, além de outras capturadas em outros grupos. Segundo o padrão, trata-se de um simples container para uma descrição apresentada em linguagem natural.

Solução

A solução oferecida por um ativo é representada por um ou mais Artefatos. Um artefato, segundo a especificação RAS, “é um produto que pode ser criado, armazenado e manipulado por produtores / consumidores de ativos e por ferramentas. Ele pode ser um arquivo armazenado no pacote do ativo ou uma entidade lógica que possui pelo menos um artefato que existe na forma de um arquivo” .

Na prática, a solução sempre será representada por um conjunto de artefatos com diferentes tipos de relacionamentos entre si. As relações de dependência são formalizadas em um elemento específico (Dependências / artifact-dependency)*. O tipo de dependência (em tempo de compilação ou em runtime, por exemplo) também pode ser especificado.

O padrão RAS fixa dois níveis de Tipos de Artefatos: Primários e Secundários. O primeiro vincula o artefato diretamente a um programa, usando a extensão do arquivo (.jar, .ppt, .htm, .js etc). Os tipos secundários são utilizados apenas para descrição. Como exemplos a especificação cita: Casos de Uso, Modelos etc.

Faz mais sentido que sejam colocadas aqui, no Contexto do Artefato (contexto-artefato / artifact-context), informações sobre o momento no ciclo de vida do ativo aquele artefato foi gerado. Outras informações, como ferramentas utilizadas, detalhes do ambiente (que se diferenciem daqueles fixados para o Ativo como um todo – na seção Classificação), também devem ser cadastradas neste elemento.

Finalmente, na seção Solução, há o Ponto de Variabilidade. Trata-se da indicação do(s) local(is) onde o artefato pode ser alterado. É indicado que se forneça um contexto, bem como uma referência que detalhe os tipos de alterações que podem ou devem ser feitas.

Uso

Nesta seção são fornecidas informações sobre a(s) forma(s) de uso e manipulação dos ativos. Condensa-se aqui, particularmente no elemento Atividade, todas as ações que podem ou devem ser executadas para o efetivo uso de um ativo e de seus artefatos. Uma atividade por ser vinculada a um artefato específico (atividade-artefato / artifact-activity) ou a todo o ativo (atividade-ativo / asset-activity). A atividade pode se referir a um contexto (ref-contexto / context-ref) específico, e pode ou deve indicar o ponto de variabilidade (variability-point-binding) ao qual se aplica.

É interessante como a descrição oficial da especificação RAS faz referências ao uso de ferramentas, particularmente nesta seção. Parece ser reflexo direto do perfil dos principais patrocinadores do padrão. No entanto, graças à extensibilidade da especificação, é relativamente simples ‘corrigir’ o padrão ou, colocando de outra forma, adequá-lo para as necessidades específicas de uma organização.

Nesta seção Uso, por exemplo, faz falta um Histórico de Uso do Ativo. Conhecer a história de um ativo é fundamental para uma eficaz avaliação do seu potencial e do retorno gerado por ele. O Histórico deveria indicar o “Contexto de Uso e os resultados obtidos (sucesso ou fracasso, facilidade de uso, melhorias necessárias, problemas encontrados no entendimento do ativo, testes, integração e adaptação do ativo, esforço requerido nessas tarefas, …)” .

Ativos Relacionados

A última seção do Core RAS cuida de vincular o ativo com todos os outros ativos que se relacionam direta ou indiretamente com ele. Um ativo de software, como colocado na especificação, “raramente existirá em isolamento”. Apesar do padrão indicar que o tipo de relacionamento entre ativos é totalmente aberto, ele indica que para quatro tipos de relacionamentos existem Valores Reservados. São eles :

• Aggregation: indica que o ativo ‘contém’ o ativo relacionado;
• Similar: o ativo possui características similares às daquele relacionado;
• Dependency: indica que o ativo referencia ou depende dos serviços ou artefatos do ativo relacionado;
• Parent: o ativo ‘é contido’ ou pertence ao ativo relacionado.

Cabe neste ponto alertar para a possibilidade de um risco: gerar um repositório de ativos bastante confuso. Um artefato pode ser tratado como um ativo em determinado contexto, mas pode ser um componente de outro ativo maior em outro momento. Vale lembrar que até um requisito pode ser tratado como um ativo propriamente dito. Tem-se assim a noção do tamanho que um repositório de ativos pode atingir. Parece indicado que a organização defina – particularmente nos momentos iniciais da implantação de processos de gestão e reuso de ativos de software – características mínimas e porte mínimo para que um determinado artefato ou conjunto de artefatos sejam tratados como ativos.

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).

Observação importante: Para uma visão completa da especificação RAS, recomendo a sua leitura integral. A versão 2.2, publicada em novembro/2005, é um arquivo PDF com 121 páginas.

Não obtive NENHUM retorno na pequena pesquisa que fiz sobre a utilização do padrão RAS aqui no Brasil. Sei que as últimas versões das ferramentas IBM/Rational, por exemplo, usam RAS. Sei também que tais ferramentas possuem uma considerável base instalada por aqui. Mesmo assim, desconfio, RAS é uma feature ignorada. Aliás, como parece ser tudo que se relacione a “reuso de ativos de software”.

Aliás, tentei um contato com o RiSE (Reuse in Software Engineering Group), que, apesar do nome, é uma iniciativa tupiniquim vinculada ao CESAR e à UFPE. Resposta rápida: “desculpe a demora. os papers do RiSE voce pode pegar nos sites de ieee, acm, etc.”. Admiro o trabalho dos caras, mas queria entender porque é tudo tão fechado e difícil. Aliás, nem responderam meu último email, enviado em 21/dez. Parece ser mais fácil conversar com Scott Berkun, Martin Fowler e Grady Booch do que com algumas figuras daqui. Estranho, não? Mas deixa pra lá…

Seguinte: não queria “afundar” tanto assim, mas acho que na próxima parte desta série vou falar sobre os repositórios. Tentarei encaixar no mesmo artigo o job description do GBA, o nosso Gestor da Biblioteca de Ativos.

Foto de Rebecca (Kairos Photo).

Um estoque de ativos de software, ou de ‘blocos de construção’, é uma das quatro características-chave do reuso, conforme citado na 2ª parte desta série. Este artigo apresentará uma definição para ativos de software, além de introduzir o padrão RAS (Reusable Asset Specification) para sua classificação. Também serão sugeridas adaptações para que o modelo seja utilizado em uma iniciativa SOA.

Definindo Ativos de Software

Ativos de software, particularmente quando se fala de reuso, não podem ser vistos apenas como códigos, módulos executáveis e licenças de uso. Todos os artefatos gerados durante o ciclo de vida de um software podem ser considerados e gerenciados como ativos. Requisitos, casos de uso, estimativas, modelos e programas para testes, dentre vários outros, podem ou devem ser tratados como ativos de software.

“Ativos são artefatos de qualquer natureza, gerados em qualquer momento do processo de desenvolvimento. ‘Ativo’ é uma palavra adequada já que os artefatos produzidos capturam conhecimentos que são importantes para a organização e, conseqüentemente, possuem um valor potencial. O reuso é uma maneira poderosa de se aproveitar esse potencial para agregação de valor.”

O padrão RAS, tratando especificamente de ativos reutilizáveis, apresenta uma definição ainda mais simples e objetiva: “Ativo reutilizável oferece uma solução para um problema, em determinado contexto.”

Existem dois tipos básicos de ativos de software:

• Verticais: mais voltados para o negócio, são especialistas em determinado domínio. Por representarem conhecimentos que podem ser o diferencial de uma organização, eles são considerados ativos de maior valor.
  Exemplos: Cálculo de seguros; Credit Score; Reposição de estoques; etc.
• Horizontais: representam elementos da arquitetura, sendo portanto mais voltados para a tecnologia. Por serem mais fáceis de serem identificados e reutilizados, são considerados ativos de menor valor.
  Exemplos: Componentes para interface gráfica com usuários; frameworks para acesso a bases de dados; Serviços de autenticação; etc.

O padrão RAS propõe a utilização de três critérios para uma completa classificação de um ativo. São eles:

• Granularidade: determina o número de problemas endereçado por um ativo. Pode ser pequena, quando trata de um único problema. Um algoritmo para cálculo do dígito verificador do CPF ou uma combo box, por exemplo. Ou pode ser grande, apresentando soluções para um ampla gama de problemas. Um serviço de vendas, O framework Hibernate ou a própria especificação Java EE são exemplos de ativos ‘grandes’*.
• Visibilidade (e/ou Variabilidade**): indica quanto de um ativo pode ser visualizado e manipulado. Apesar de algumas diferenças na nomenclatura utilizada, é consenso que existem 4 níveis distintos de visibilidade / variabilidade de um ativo:
  1. Caixa Preta: o ativo não pode ser alterado e seu interior não pode ser visualizado. Normalmente representa código binário – módulos executáveis adquiridos de terceiros.
  2. Caixa de Vidro (ou Limpa): detalhes da implementação são expostos (via modelos, documentação ou até mesmo o código-fonte), mas o ativo não pode ser alterado. A transparência visa exclusivamente o apoio na utilização daquele software.
  3. Caixa Cinza: interior do ativo é parcialmente exposto e manipulado, normalmente através de parâmetros. São componentes ou serviços desenvolvidos com o objetivo de serem reutilizados.
  4. Caixa Branca: o ativo oferece total visibilidade e variabilidade. Além da total disponibilidade do código-fonte, ativos com este nível de visibilidade também apresentam seus requisitos, casos de uso, modelos, e todos os demais artefatos relevantes gerados no processo de desenvolvimento.
• Articulação: descreve o grau de completitude de um determinado ativo. Ou seja, o quão pronto um ativo está para a solução de um dado problema. Um conjunto de requisitos, por exemplo, está longe de solucionar efetivamente o problema. Diz-se que seu grau de articulação é baixo. Já um componente em sua forma executável apresenta um alto grau de articulação.

O gráfico abaixo ilustra a combinação dos três critérios apresentados acima na classificação de alguns tipos de ativos de software:

Etiquetas de Patrimônio

Como foi colocado na introdução desta série, todos os ativos físicos de uma organização merecem ferramentas e processos de administração e controle. Uma das partes mais visíveis desse controle são as etiquetas de patrimônio, que possuem códigos que facilitam a localização dos ativos em um sistema. Ativos de software podem merecer o mesmo tipo de gerenciamento. Principalmente em organizações que dependem muito de seus sistemas de informação. Mesmo quando o reuso sistemático não é um objetivo da organização, o gerenciamento de ativos de software deveria ser considerado. Trata-se de um item que pode ser relevante quando a organização estiver implantando processos de governança corporativa, por exemplo. (***Veja as observações no final do texto).

O padrão RAS foi criado exatamente para funcionar como essa ‘etiqueta de patrimônio’ para ativos de software reutilizáveis. Ele é estruturado em duas categorias: Núcleo (Core RAS) e Perfis. O núcleo representa todos os elementos fundamentais de um ativo. Os perfis são utilizados para descrever características específicas de um ativo. Por exemplo: podemos ter um ativo que gera orçamentos para o seguro de um automóvel; este ativo possui dois perfis distintos: um para sua versão off-line e outro para a versão web service. Uma etiqueta RAS básica, descrevendo apenas o núcleo, é ilustrada abaixo:

A seção Classificação apresenta todas as características básicas do ativo, inclusive o contexto no qual ele se insere. Solução relaciona todos os artefatos que compõem o ativo. A área chamada Uso contém todas as regras para customização, instalação e reutilização do ativo. Por fim, a seção Ativos Relacionados apresenta todos os ativos que possuem algum tipo de relacionamento com o item em questão.
Obs.: Na próxima parte deste artigo será apresentado o modelo completo para ‘etiquetagem’ de ativos de software.

É grande a similaridade entre uma etiqueta RAS e os contratos que regem o uso dos serviços em uma SOA. Se a primeira for elaborada dentro do padrão, e o segundo obedecer as melhores práticas sugeridas, obtém-se dois documentos (XML) bastante redundantes. Na realidade a etiqueta RAS parece ser um subconjunto de um contrato. Este apresenta um número maior de informações, relevantes principalmente em tempo de execução.
Obs.: Farei uma pequena pesquisa para saber como tal similaridade está sendo tratada.

===

Referências:

1. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
2. RAS – Reusable Asset Specification – Versão 2.2
   Object Management Group (OMG) (05/Nov/2005).

===

Observações:

* Confesso que o termo ‘granularidade’ cria algumas dificuldades. No inglês é trivial o uso das combinações “coarse-grained” e “fine-grained”. Mas a tradução literal não pega muito bem. Sugestões?

** ‘Variabilidade’ eu traduzi literalmente. Mas acho que deve existir uma palavra melhor na língua portuguesa. Mesmo que, como na especificação RAS original, ela continue sendo utilizada em combinação com o termo ‘Visibilidade’.

*** Sobre Gerenciamento de Ativos de Software

É importante notar que o Gerenciamento de Ativos de Software tratado nesta série de artigos difere-se substancialmente daquele que pegou carona na onda Governança, ITIL e afins.

Software Asset Management (SAM), conforme descrição obtida na Wikipédia (em 21/dez/06), significa: “um conjunto de práticas de negócio que incluem a gestão de licenças, gestão da configuração, padronização de imagens e concordância com restrições regulatórias ou legais, como leis de copyright, Sarbanes Oxley…”

O gerenciamento falado nesta série de artigos ‘desce’ o nível, incluindo em seu escopo itens tão pequenos como um requisito ou um componente de tela.

O reuso de ativos de software é uma daquelas várias promessas da área de TI que parecem gerar mais decepções do que resultados concretos. Antes da onda SOA, as propostas que colocaram a reusabilidade como uma de suas maiores vantagens foram a Orientação a Objetos (OO) e o Desenvolvimento Baseado em Componentes (CBD – Component-Based Development). Ambas as propostas tinham o reuso como uma conseqüência natural. Ou seja, não se preocuparam em fazer do reuso uma prática sistemática, planejada. Autores como Grady Booch transferiam para os programadores a responsabilidade de reutilizar ativos de software: “durante a implementação, procure agressivamente por partes que possam ser reutilizadas” . Hoje é dito que “oportunidades para o reuso são como os bugs, quanto antes elas forem encontradas melhor” .

O reuso não planejado, chamado por Steve McConnell de “reuso oportunista”, careceria de “alguma sorte” para a sua realização . Sendo casual, ele dependeria muito da equipe do projeto e do conhecimento que esse time tem sobre os ativos existentes e projetos anteriores da organização. Hoje pode-se afirmar que os benefícios gerados pelo reuso de ativos de software não podem ser plenamente realizados se dependerem exclusivamente da casualidade – o encontro de coincidências entre dois ou mais projetos – e do conhecimento de uma equipe de projeto.

O reuso sistemático ou planejado de ativos de software significa :

• Compreensão de como o reuso contribui para a realização dos objetivos do negócio como um todo;
• Definição de estratégias técnicas e gerenciais para que se alcance o máximo valor com o reuso;
• Integração do reuso em todo o processo de software e também no programa de melhoria do processo;
• Garantia de que toda a equipe possui as competências e motivação necessárias;
• Estabelecimento do adequado suporte organizacional, técnico e orçamentário; e
• Uso de métricas apropriadas para controle da performance do reuso.

Ao contrário do que se imaginava, o reuso depende muito pouco de tecnologia. Pesquisa realizada com 71 organizações de desenvolvimento mediu o impacto de uma série de fatores na adoção do reuso e concluiu que, das 6 dimensões medidas, a tecnologia é a menos relevante. No reuso sistemático, os fatores mais críticos para o sucesso seriam :

• Planejamento e Melhoria Contínua do Processo;
• Existência de um Processo Formalizado;
• Apoio da Alta Gerência;
• Similaridade entre Projetos; e
• Arquitetura Comum.

Posteriormente esta série de artigos tratará de cada uma das dimensões apresentadas na lista acima. Neste ponto o importante é a constatação de que “a introdução do reuso sistemático é muito mais do que uma mudança tecnológica: ele deve ser compreendido e gerenciado como um grande conjunto de mudanças no processo de software” . As três primeiras dimensões apresentadas acima, do tipo organizacional, aparecem apenas quando o processo de reuso é sistemático e formalizado perante toda a organização.

É importante lembrar que, como foi colocado no primeiro artigo da série, dois dos principais modelos para melhoria dos processos de software, o CMMI e o MPS.br, não contemplam o reuso. Apesar de indicarem que se trata de um nítido sinal de maturidade do processo de uma organização . Algumas propostas sugerem a adaptação dos grupos de reuso da ISO/IEC 15504-5 para as áreas de processo do CMMI . Há ainda a possibilidade do MPS.br incorporar processos de reuso em versão a ser liberada no primeiro semestre de 2007. Organizações interessadas em adotar o reuso sistemático poderiam optar por incorporá-lo ao seu programa de Melhoria de Processos de Software (MPS) ou tratá-lo como uma iniciativa independente.

No entanto, na implementação de uma SOA, o reuso está no núcleo dos trabalhos. O reuso sistemático não é mais uma opção, mas uma condição crítica para o sucesso de uma iniciativa dessa natureza. Pode-se dizer então que a introdução de uma SOA forçará a adoção de práticas sistemáticas de reutilização de ativos de software. Organizações poderão aproveitar a oportunidade e tornar o reuso um componente fixo de seu programa MPS.

Alto Custo

Edward Yourdon sugeriu uma regra que dizia que um “ativo reutilizável exigirá o dobro do esforço requerido por um ativo comum” . Fred Brooks estima que deve ser “o triplo” do número sugerido por Yourdon . Steve McConnell reconhece que o reuso planejado não é uma prática de curto prazo. “Um programa de reuso pode demorar 2 anos para começar a gerar componentes realmente reutilizáveis”. Mas cita que os ganhos de produtividade podem fazer com que a organização passe a realizar 35 pontos de função (PF) / pessoa / mês, contra uma média nacional que seria de 5 PF / pessoa / mês *.

Os autores de “Practical Software Reuse” colocam o tema de outra forma: “todos os custos com software são sempre considerados um overhead“. “Por isso”, eles continuam, “as avaliações do retorno sobre os investimentos (ROI) em iniciativas de melhorias (seja reuso ou um programa MPS) raramente estão disponíveis e raramente são críveis”. No entanto, “independente da forma como o contabilizemos, reuso é um investimento. E todo investimento envolve incertezas, riscos e ‘chutes'” .

Por tudo isso parece que, sem o envolvimento e o apoio da alta gerência, torna-se quase impossível a implantação de práticas sistemáticas de reuso. E, com certeza, está aqui uma das grandes razões para o fato do reuso nunca ter entregue um mínimo das promessas realizadas nas últimas décadas.

===

Referências:

1. Object Solutions
   Grady Booch
   Addison-Wesley (1996).
2. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
3. Rapid Development
   Steve McConnell
   Microsoft Press (1996).
4. Strategies for Software Reuse:
   A Principal Component Analysis of Reuse Practices
   (PDF – Requer registro e pagamento)
   Marcus A. Rothenberger et al
   IEEE Transactions on Software Engineering, Vol. 29, No 9, (Set/2003).
5. CMMI Performance Results
   Exemplo de um caso específico (Boeing).
   Carnegie Mellon / Software Engineering Institute (SEI).
6. Adaptação dos Processos do Grupo de Reuso do ISO/IEC 15504-5 para as Áreas de Processo do CMMI (PDF)
   Leandro de Paula Silva
   Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras (2006).
7. Decline and Fall of the American Programmer
   Edward Yourdon
   Yourdon Press (1992).
8. The Mythical Man-Month – Anniversary Edition
   Fred Brooks
   Addison-Wesley (1995).
   

===

* Ah, como eu gostaria de conhecer, nem que fosse um pouquinho só, os números tupiniquins…

A crescente aceitação da proposta de Arquiteturas Orientadas a Serviços (SOA) fez com que voltasse para agendas e debates um velho tabu da área de TI: o Reuso de Ativos de Software. Uma pesquisa recente, tratando especificamente de SOA, mostra que a maioria das empresas espera reutilizar apenas 30% dos serviços criados. Apesar de 84% delas dizerem que a possibilidade de reutilização de ativos é uma das maiores promessas de uma SOA; uma das maiores justificativas para sua adoção. Vamos aproveitar o debate para tratar o tema de uma maneira mais aprofundada. Este post inaugura uma série sobre o assunto. Gestão de Ativos; Reuso Sistemático; Adequação de processos; RAS (Reusable Asset Specification); GBA (Gestor da Biblioteca de Ativos); dentre outros, serão tratados de maneira específica nos próximos artigos*.

O assunto é tão antigo e batido, com sucessivas ressurreições e decepções, que fará com que muitos profissionais da área simplesmente ignorem a discussão e a nova fase de oportunidades aberta pelo conceito SOA. Data de 1968 a primeira tentativa para tornar o reuso sistemático uma prática , uma disciplina obrigatória em Engenharia de Software. Muito tempo depois, de maneira menos impositiva, foi a vez da Orientação a Objetos e da Componentização proporem e facilitarem o reuso de ativos de software. A princípio, os resultados sempre foram desprezíveis. Quando havia algum resultado.

A reutilização de experiências e conhecimentos externos – normalmente apresentados como aplicações, frameworks, componentes, design patterns ou até mesmo código fonte – é prática corriqueira na maioria das organizações que desenvolvem sistemas atualmente. O grande problema, o tabu em torno do reuso de software, é o não aproveitamento dos ativos criados internamente. Qualquer tipo de ativo.

O reuso do capital intelectual – do conhecimento e da capacidade de aprendizado e inovação – é um desafio para todas as áreas de praticamente todo tipo de empresa. Não se trata de uma carência específica da área de TI, apesar de sua natural orientação a projetos e sua intimidade com tecnologias indicarem que seria teoricamente mais simples a adoção de métodos e ferramentas para uma excelente gestão de conhecimentos. Trata-se de uma área que tem muito a evoluir. Erros e falhas recorrentes indicam que o conhecimento não está fluindo de forma adequada. “Os que não conseguem lembrar-se do passado estão condenados a repeti-lo“, dizia George Santayana.

No entanto, de todos os ativos que formam o grande inventário da área de TI, aquele que parece mais esquecido ou, colocando de outra forma, relegado a um segundo plano, são os ativos de software. Seus co-irmãos palpáveis, notadamente o hardware e todas as instalações físicas, herdaram métodos e ferramental de controle de todos os outros ativos tangíveis de uma organização. Eles aparecem no controle patrimonial (nos sistemas de Ativo Fixo e Contabilidade) da empresa. Cadeiras, servidores e caminhões merecem uma “etiqueta” de patrimônio. Você usa, e reusa, aquilo que você sabe que possui. Quando conhece sua localização, utilidade, modos de uso, restrições, idade etc.

Autores como Robert Kaplan e David Norton, criadores do Balanced Scorecard, classificam os ativos de software como intangíveis . Talvez sejam exatamente a percebida intangibilidade e a infinita maleabilidade do software que façam com que ele seja um ativo muito mal tratado e pouco controlado. Outro motivo, sugerido por Paul Strassmann , seria a falsa idéia de que o ciclo de vida do software obedece aquele ditado pelo hardware (com uma total depreciação em um prazo de 4 anos). É sabido que algumas empresas, particularmente no ramo financeiro, possuem código com mais de duas décadas de vida.

“Sem o legado, cada geração começaria na idade da pedra.”
– Paul Strassmann

Visando à valorização dos ativos de software, Strassmann sugere que as organizações :

• Adotem ferramentas que forcem a construção de software a partir de um repositório de peças padrão reutilizáveis;
• Façam da acumulação e preservação dos ativos de software úteis um de seus principais objetivos;
• Ofereçam incentivos para que o staff de sistemas inclua a acumulação de ativos de software como um de seus objetivos-chave; e
• Aumentem a longevidade dos ativos de informação ao invés de aceitar a suposição de que eles não valerão nada após o período de breakeven.

Viabilidade

A era industrial se consolidou através do reuso de peças padrão. A economia de escala é indissociável do reuso. As linhas de montagem ganharam a forma que conhecemos hoje após a adoção de conceitos de reuso. O mercado de TI lançou suas “fábricas de software” mas parece ter se concentrado exclusivamente na parte (des)humana da metáfora.

Apesar do reuso sistemático ser considerado um claro indicador de maturidade , não há em propostas como o CMMI ou MPS.br uma área ou processo específico para incentivá-lo e controlá-lo. No RUP, amplamente divulgado e relativamente aceito, o reuso de ativos é citado como “facilitado” pelo processo . No entanto, não há uma única disciplina que tente fazer do reuso uma prática sistemática, intencional.

“Os ativos intelectuais, ao contrário dos ativos físicos, aumentam de valor com o uso.”
– James Brian Quinn

O mesmo se aplica para ativos de software (que são um tipo de ativo intelectual): quanto maior seu uso (e reuso), maior seu valor. Por isso causa estranheza, particularmente naqueles “não-letrados” na área, nossa incapacidade ou resistência em fazer do reuso uma prática central, obrigatória. Assim como parece estranha e extremamente pessimista a meta aferida na pesquisa citada no início deste artigo: a reutilização de 30% dos serviços em uma SOA. Casos documentados , anteriores à onda SOA, reportam ganhos de até 72% em organizações que adotaram o reuso de ativos de software como uma prática sistemática. Se sua viabilidade é provada em empresas que não têm no desenvolvimento de software uma atividade fim, o que dizer então daquelas que vivem de produzir e comercializar software?

===

* Como em alguns casos anteriores, este artigo é parte de um estudo/trabalho em desenvolvimento. Ao término da série será publicada uma compilação, em formato PDF, com as devidas revisões e considerando eventuais críticas e/ou sugestões recebidas. Sinta-se à vontade para participar.

===

Referências:

1. Outside the Box (blog de Todd Biske): Use or Reuse?
2. Software Reuse: Principles, Patterns, Prospects
   Mária Smolárová e Pavol Návrat
   Slovak University of Technology
3. Mapas Estratégicos
   Robert S. Kaplan e David P. Norton
   Editora Campus / Elsevier (2004).
4. The Squandered Computer
   Paul A. Strassmann
   The Information Economics Press (1997).
5. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
6. Hoje (11/Dez/2006) fiz uma consulta ao grupo de discussão CMM-Br. Tudo indica que o MPS.br receberá um processo específico para tratar de Reuso a partir de Abril/2007.
   Agradeço os colegas Rafael Prikladnicki e Marcio Pecegueiro do Amaral pelas informações.
7. The Rational Unified Process – An Introduction (Second Edition)
   Philippe Kruchten
   Addison-Wesley (2000).