Autores: Carl Shapiro é professor de Estratégia de Negócios na Haas Scholl of Business e do Depto. de Economia da Universidade da Califórnia, em Berkeley. Hal R. Varian é professor da School of Information Management da Universidade da Califórnia e colega de Shapiro na Haas.

Editora: Campus, 1999. Tradução de Ricardo Inojosa.

Do que se trata: defesa consistente e bem amparada de uma tese: “A tecnologia muda. As leis da economia não“.

É um belo presente para:

• Executivos de qualquer negócio baseado em informações;
• Gente que vende software;
• Profissionais que precificam produtos ou serviços de informação.

Recomendações:

“A Economia da Informação é o primeiro livro a explicar a economia em rede, a nova economia de nossas vidas. Shapiro e Varian explicam as loucuras que ocorrem todos os dias no Vale do Silício e em outras partes do mundo. Este livro é leitura obrigatória para toda pessoa de negócios do novo milênio.”
– Eric Schmidt, quando ainda era CEO da Novell.

“Excelente livro! Ao combinar uma linguagem clara e sem jargões, com exemplos bem definidos e específicos do mundo real, A Economia da Informação mostra como os princípios econômicos aplicam-se à era da Internet.”
– Andrew Grove, presidente do conselho da Intel.

Prós:

• Leitura fácil, clara e objetiva.
• Repleto de exemplos reais.
• Bem estruturado em seus 10 capítulos e 400 páginas.

Contra:

• A tradução, pra variar, peca. Ver commodity aparecendo como “mercadoria” o tempo todo irrita. Se estava tão preocupado em trazer tudo para o português, por que manteve inalterado o termo “feedback”, que aparece até em título de capítulo?

Trechos:

“Ao gerir sua propriedade intelectual, você deve ter por objetivo escolher os termos e as condições que maximizem o valor de sua propriedade intelectual, não os termos e condições que maximizem a proteção.” (pág. 18)

“A infraestrutura está para a informação assim como a garrafa está para o vinho: a tecnologia é a embalagem que permite entregar a informação aos consumidores finais.” (pág. 21)

“O que há de novo é nossa habilidade de manipular informação, não a quantidade total de informação disponível.” (pág. 22)

“Não deixe que seu produto de informação se transforme em mercadoria .” (pág. 42)

Acompanhamentos:

• A Vida Digital
  Nicholas Negroponte. Companhia das Letras (1995).
• Wikinomics – Como a Colaboração em Massa pode Mudar o seu Negócio
  Dan Tapscott & Anthony D. Williams. Nova Fronteira (2007).
• Cultura da Convergência
  Henry Jenkins. Editora Aleph (2008).

O Blog

Alguns costumes e manias não resistem a um bom teste unitário. Sei lá porque um dia decidi que publicaria aqui apenas artigos mais trabalhados que, invariavelmente, também são longos (quase sempre com mais de 1000 palavras). Artigos assim costumam demandar algo entre uma e quatro semanas de elaboração. Não de redação e edição, claro, mas de pesquisa e compilação. O problema com este enfoque é que deixo de falar sobre um monte de assuntos que, desconfio, também interessariam aos leitores fiéis ou ocasionais. Portanto, aguardem mais e menores blues, digo posts. O que não significará o fim daqueles verborrágicos, para tristeza dos apressados.

Outro velho projeto que deve finalmente vingar é a criação de outras seções aqui no finito. Duas aparecem no topo do blog backlog: 1) Bibliografia Comentada, com dicas de leitura e trilhas de estudo; e 2) Bate-papo com profissonais da área e usuários. Penso na transcrição totalmente sem edição de prosas facilitadas por IM’s e afins. O primeiro convidado parece não ter gostado muito da ideia mas insistirei. As duas novas seções pretendem trazer vozes e pontos de vista distintos deste que aqui rabisca.

Cursos e Palestras

Não foi o que planejei 4 anos atrás, quando iniciei a carreira solo. Mas os Cursos e Palestras se transformaram em minha vaca leiteira – no Lucro e não no Troco¹. Ao invés de nadar contra a maré, é preferível que eu reforce minhas ofertas. Principalmente para tentar me distanciar do oceano vermelho de sangue que caracteriza esse mercado. Gosto do modelo utilizado no FAN – eventos curtos e práticos. Mas a estabilidade dos times que estão ganhando é uma perigosa ilusão. Está aqui o desafio que mais tem ocupado meu tempo nas últimas semanas.

Devo lançar simultaneamente, ainda neste primeiro trimestre, dois novos eventos. Serão dirigidos para públicos diferentes mas vão compartilhar o mesmo formato e nome: “O Jogo dos 7 Erros“. Um será voltado para líderes de projetos e outro para meu público-xodó, os analistas de negócios. O formato é de um jogo realmente. Cada erro merecerá uma hora. Os exercícios tomarão metade do tempo. O restante será utilizado na apresentação do erro, casos e para o debate com a turma. Como o formato é muito novo os eventos serão lançados como ‘beta’ e terão preços especiais. Aliás, tudo será novo e o teste é mais que necessário. Inclusive ou principalmente do material didático. As primeiras turmas devem acontecer em São Paulo.

As novas ofertas não significam que o FAN irá para escanteio, pelo contrário. Novas turmas serão abertas, a partir de abril, em São Paulo e Brasília.

Serviços

É curioso como meus “patinhos feios” atraem atenção quando apresentados de maneira menos formal. Particularmente o conjunto de serviços que identifico como Administração de Ativos. Ou seja: erro feio na mensagem que transmito aqui e no material de marketing que desenvolvi. Duas providências: 1) Alterar a apresentação “formal” dos serviços; e 2) Lançar, no segundo semestre, eventos que mostrem de maneira mais clara a importância de alguns temas, particularmente a Administração de Ativos e a Engenharia de Processos. Pacotes de treinamento + consultoria devem ser a melhor resposta. Mas eu tratei de deixar bem baixas minhas expectativas para 2010.

E o livro, sai ou não sai?

Transparência é jóia e dá retorno. Mas também pode te deixar assim, sem ter onde esconder a cara quando alguma coisa não vai bem. Hoje eu entendo porque Nicholas Negroponte e Louis Gerstner resolveram nunca mais escrever depois de lançarem seus primeiros livros. “É o Negócio, Beócio!” é de longe o pior projeto que já assumi em minha vida. E eu tratei de torná-lo cada vez pior, prometendo prazos mesmo quando não era cobrado por isso. Acabei por transformá-lo em um verdadeiro pesadelo quando deixei os alvos ficarem móveis. Justo eu, que insisto com os 4 ventos que um projeto não pode dar certo se não tem objetivos bem claros.

Pois bem, o livro já foi escrito 4 vezes. Acho que já contei isso aqui. Duas versões não mereceram a luz do sol e foram direto para o lixo (shift+del mesmo). Alguns capítulos da última versão foram publicados. Mas, apesar do feedback relativamente favorável, alterei a estrutura e me perdi novamente. Tudo fica um tanto surreal quando me lembro que em apenas 4 meses, no longínquo 2007, eu escrevi uma versão quase completa. Hoje tenho a sensação de estar muito próximo da estaca zero.
E olha que até capa(s) ele já tem²!

Inicialmente o livro seria um “Guia para a Formação de Analistas de Negócios”. Quando comecei a aceitar que este deve ser também o meu último livro resolvi que ele podia ser um pouco mais abrangente. Ambiguidade é risco. E aquele “pouco” da penúltima frase virou um imenso problema. O lado bom do desabafo aqui é que, além de tirar um grande peso de meus ombros, dá ânimo para pegar no trampo de novo.

Epílogo?

Que nada! Prólogo para um 2010 que promete. Mas antes de começar eu preciso agradecer a todos que fizeram de 2009 um ano bem legal e produtivo: Leitores do finito, participantes do FAN e do grupo AN.br, clientes, parceiros e amigos. Espero que tenhamos boas desculpas para novos encontros.

Observações

1. Lucro | Troco | Truco é uma versão tropicalizada daquele esquema “70% 20% 10%” que seria utilizado pela Google. Dedico 70% do meu tempo em ofertas que representam meu negócio principal, o Lucro. O Troco, que ocupa 20%,  é aquela receita básica e normalmente pequena que serve para pagar despesas fixas. E o Truco é uma ideia maluca qualquer que só merecerá mais de 10% do tempo quando mostrar potencial para virar Lucro ou Troco. Junto com o esquema Conteúdo -> Conversas -> Transações, este conceito dá forma ao núcleo do modelo de negócios do finito.
   Pois é, formalizei lá em cima que Cursos e Palestras passam a merecer 70% do meu tempo. Pelo menos até o início do 2º semestre.
2. As capas foram desenvolvidas pela Sabiá. Me apresentaram 6 sugestões e até hoje o máximo que consegui foi eliminar duas. É provável que o livro saia com 2 capas oficiais, uma para descolados e outra para… hmm… menos descolados, hehe…
3. O finito ganhou chaves?!? {finito}
   Têm algum significado?

Mas, mais do que criar polêmica (essa cansa), eu queria descrever com mais detalhes os 7 princípios que compõem o DEVAGAR:

D)emonstrar Valor de maneira Iterativa
Deveria ser, Iterativa & Incremental. Parece frescura, mas faz diferença. Iterare, no latim, significa repetir. Aqui indicamos que repetimos diversos passos (no processo de desenvolvimento), mas a cada repetição nós agregamos real valor. Numa leitura “ágil”, é o mesmo que dizer “entregamos software rodando” em cada ciclo (ou iteração). Não curto o radicalismo: nas primeiras iterações, ou exclusivamente na 1ª iteração, software rodando pode ser menos importante que uma boa compreensão do negócio. Da mesma forma que ele pode ser muito importante para a equalização de visão entre todos os stakeholders. Mais do que um processo, o que determina o Real Valor a ser entregue em uma iteração é o projeto. E cada projeto é único. Mensagem mais importante (para o negócio e seus usuários): se uma iteração se encerra e você não consegue perceber o Valor, algo errado aconteceu. E é verdade: software rodando tem muito mais valor que uma série de modelos UML ou afins.

E)ntender (e Melhorar) o Negócio
É difícil aceitar que um projeto seja tocado sem que boa parte da equipe tenha uma mínima compreensão sobre o negócio que está sendo automatizado. É difícil entender a razão para tal alienação ser tão comum em nossa área. Mas o princípio aqui vai além: além de uma boa compreensão do negócio e dos projetos afetados pelo projeto, um processo ‘business-centric’ incentiva a busca por melhorias.

V)alorizar os Ativos de Software
Está aqui um princípio que, salvo engano, não vi formalizado em nenhuma proposta de processo. Ele deveria ter dois efeitos:

1. Garantir a qualidade do software que está sendo produzido. Se bem empacotada (documentada e difundida), a aplicação ganha sobrevida. Vale apelar para um velho chavão: ativos de software, ao contrário dos ativos físicos, ganham mais valor quanto mais são utilizados. Todo software (de negócio) deveria ser construído para durar… muito.
2. Dar sobrevida aos ativos existentes (também conhecidos como sistemas legados). Trata-se de um dos principais alvos das iniciativas SOA. Mas, hoje em dia, serão raros os projetos que não estabeleçam um mínimo relacionamento com software existente. Combater a síndrome NIH (Not Invented Here) e dar valor para aplicações (conhecimentos!) existentes é uma boa prática.

A)daptar o Processo
Taí um princípio que, se adotado pela (IBM) Rational desde o início (do RUP), teria evitado uma série de problemas. Se todo projeto é único, como acreditar em um único processo? Toda organização possui e vive seus valores e costumes. Algumas sobrevivem a eles (hehe.. brincadeirinha). Essa base, mais um conjunto de princípios (ou boas práticas, como as descritas aqui), dá forma à um meta-processo. Um framework que seria posteriormente adaptado para cada tipo de projeto e também para cada projeto.

No nível mais baixo (um projeto), quatro variáveis principais afetam a configuração de um processo: O Negócio (sua estratégia, processos, departamentos e pessoas afetados); o Tipo de Aplicação (Transacional, Analítica ou Utilitária); a Tecnologia e o perfil da Equipe. Claro, várias outras questões (regulatórias, SOX, Bacen, Basiléia… por exemplo) também podem gerar considerável impacto no desenho dos processos de desenvolvimento e gerenciamento do projeto.

G)erenciar Requisitos (e Mudanças)
Vira e mexe, há tempos, o dado pipoca por aí: requisitos (e mudanças) estão de alguma forma relacionados com 80% dos problemas dos projetos que fracassam. Como eles (os projetos fracassados) não são poucos, é inaceitável que este princípio não conste de um processo para desenvolvimento de software. Pode parecer chatice (de certa forma o é), mas “balancear prioridades dos stakeholders” não é o termo adequado. Parece até “forçada de barra” para arrumar uma letra B (e assim compor o perfeito ABCDEF). E por falar nisso, gerenciar requisitos não significa lotar paredes com post-its coloridos.

A)tacar os Riscos
Assim como os requisitos, o mau gerenciamento de riscos também está entre as principais causas das falhas em projetos de software. Como Grady Booch já falava em 96 , “se você não atacar os riscos, eles o atacarão”. O verbo é este mesmo: Atacar (a redação de um princípio deve ser clara e direta). E é equivacada a impressão de que riscos são questões exclusivas de arquitetura. Um bom entendimento do negócio (princípio #2 acima), significa também a descoberta de riscos e até uma possível antecipação de mudanças. Aliás, os riscos de negócio são mais perigosos que os riscos de arquitetura (por mais que algumas péssimas aplicações tentem nos provar o contrário).

R)espeitar os Usuários
É chato que algo assim tenha que aparecer numa lista de princípios. Mas, infelizmente, se fez necessário. É bom que seja o item de fechamento da lista. Força a revisão de muitos fatores que podem ter ficado implícitos. Por exemplo: vamos ouvir e gerenciar todas as expectativas dos usuários. Mas não fugiremos da responsabilidade de sugerir melhorias, ou de alertá-los sobre riscos em potencial. Respeitaremos a inteligência e o tempo dos usuários estudando seu negócio, falando sua língua. E, mais importante, nos comprometendo com seus objetivos de negócio.

Por tudo isso eu gostei do DEVAGAR. “DEVAGAR & SEMPRE”, como naquela fábula da tartaruga. Taí, já arrumei até mascote para o ‘business-centric’…

.:.

Notas:

1. Os princípios desenham o perfil de um processo. Quanto mais genéricos forem, mais maleável é o processo. Por isso é preciso ter muito cuidado com processos que se apresentam como de uso geral, mas apresentam princípios que, de certa forma, são ‘intrusivos’. Reparem: trata-se de uma crítica que se aplica à listinha DEVAGAR acima. Com certeza ela não atenderá qualquer tipo de negócio. O que dizer então de projetos?
   O mais importante é ter um bom ponto de partida. E ninguém pode ensiná-lo melhor do que seu próprio negócio.
2. Object Solutions – Managing the Object-Oriented Project
   Grady Booch. Addison-Wesley (1996).

.:.

Estranhei porque, salvo engano, parte da grana que sustenta o CESAR é pública. Mesmo que eles fizessem da venda de artigos uma fonte de receita alternativa, não faz sentido que a venda seja feita em dólar e intermediada por uma entidade dos EUA. Não entendi e também não obtive nenhum tipo de retorno. Ok. Registrei a crítica e esqueci a questão.

Mas eis que agora recebo a notícia do lançamento do CRUISE (Componente Reuse in Software Engineering), uma compilação dos achados do RiSE. O livro foi lançado sob licença Creative Commons (by-sa-nc) e, claro, é distribuído gratuitamente. A porta que parecia fechada a 7 chaves agora está escancarada (no melhor sentido).

Ainda não tive a chance de ler o livro – acabo de baixá-lo. Mas creio que será muito útil na conclusão do meu trabalho. Um trabalho que pode ganhar novo rumo: o pessoal do RiSE, com o lançamento do livro, convoca-provoca participações. Reclama inclusive que nosso meio acadêmico deveria ter mais iniciativas como essa.

Jóia. Mas como tenho que manter minha reputação de “muito chato”, antecipo aqui uma crítica: por que em inglês? Sei que existirão mil justificativas do tipo: “é nossa língua universal!”. Sorry (haha).

Nossa língua oficial é o português. Todo trabalho gerado em universidades públicas deveria estar em sua língua oficial. Depois viriam as traduções. Engraçado é que no e-mail de divulgação eles falam: “contribuições para melhorar a versão original são muito bem vindas. Inclusive porque inglês não é a língua nativa de nenhum dos autores.” Dá pra entender?

De resto, agora é mergulhar no texto, aprender (muito) e colaborar (sempre que possível). Pela iniciativa, parabéns ao pessoal do RiSE. Que seu exemplo seja seguido por muitos.

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…