Abro o workshop e o livro falando do Analista de Negócios (AN), dizendo que ele praticamente não existe. Profissão ou função mal definida, muito mal apresentada e representada. Mas reforço: ao lado do Arquiteto (ou Arquiteto Corporativo), é a profissão mais promissora da área de TI. Aposta que faço há algum tempo.

Engraçado é que o estopim para todo esse trampo veio da noção do fundo do poço: num grupo de discussão, no 2º semestre do ano passado, alguém falou que o AN não serve para nada. Ou, em outras palavras, disse que "não via utilidade nos AN's".

Contei a "estorinha" no workshop e muitos pegaram carona na provocação: "você acredita nos AN's e em sua aposta?" Eu disse que a melhor evidência estava na sala: lotada. Quando a Tempo Real Eventos lançou o workshop não tínhamos a menor idéia sobre qual seria a aceitação. Foi uma aposta mesmo. Seguida de uma gratificante surpresa.

"Abrir a 'caixa preta' que é a organização de TI das empresas"
- Gilson Silva [1]

"Alinhar TI com o negócio"

• "O Alinhamento deve mostrar evoluções no plano de negócios"
• "O Alinhamento se mantém atualizado na medida em que o negócio evolui"
• "O Alinhamento ultrapassa obstáculos aos seus propósitos"
• "O Alinhamento é planejado"

- Paul Strassmann [2]

E aí vieram SOA, BPM, ITIL, SOX... todas buscando, de uma forma ou de outra, o tal "alinhamento". Por isso eu acredito tanto nos Arquitetos e Analistas. Arquitetos Corporativos (ou De Negócios) e Analistas de Negócios. Por isso eu acho que o BABoK desperdiça uma grande oportunidade. E que os trabalhos que falam que AN's e AN's de TI são "negócios" diferentes estão um tanto equivocados [3]. Negócio é negócio. Ponto.


Momento "Catorze Zero Meia"

Leitores do finito interessados em participar da próxima edição do workshop "Formação para Analistas de Negócios" acabam de ganhar um belo incentivo: desconto de 10% em cima do preço promocional* (para inscrições realizadas até o dia 13/jul).

Para tanto, basta informar o código promocional (cpvfan) na página de inscrições.

1406 + "modelito vivarina": todos os participantes terão acesso ao exclusivo grupo de discussões, e terão garantia de atualização da apostila até ela se transformar no prometido livro.

"Desgraça pouca é bobagem", como a gente costuma falar aqui nas Geraes.


* Válido para os 20 primeiros.
(ps: Nunca pensei que fosse utilizar as detestáveis letrinhas miúdas...)

1. Talvez seja o primeiro AN de facto do Brasil. É um dos melhores, não tenho dúvidas. Aliás, ele é bem mais que um AN. Não sei se foi sorte dele ou azar nosso, mas alguns de seus maiores trabalhos foram realizados em Portugal, Espanha, Austrália, Nova Zelândia, África do Sul...
   
   
2. The Squandered Computer
   Paul A. Strassmann - The Information Economics Press (1997).
   
   
3. UML for the IT Business Analyst
   Howard Podeswa - Thomsom / PTR (2005).
   

Marcadores: analista_de_negócios, babok, bpm, cursos_e_palestras, evento, livro, soa

Faz pouco tempo que descobri o BABoK (Business Analysis Body of Knowledge). Quem cuida dele é o IIBA (International Institute of Business Analysis). A descoberta aconteceu por acidente, no meio das minhas pesquisas. Usando o Google, não consegui achar nenhuma referência em língua portuguesa. Estranhei. Afinal, a versão atual (1.6) está disponível para download desde 12/jul do ano passado. A versão 2.0 está programada para este trimestre. Mas, como escrevi no meu material, "o analista de negócios não existe. Particularmente aqui no Brasil". Normal. Quantos gerentes de projetos existiam há uns 10 anos? E quem conhecia o PMI?

O IIBA segue os passos do PMI. Ou seja, lança um 'guia para o corpo de conhecimentos' e, na cola, uma certificação. Tenho minhas restrições ao formato, mas elas ficam para outra hora. O lado bom é que a iniciativa pode ajudar a divulgar e, de certa forma, consolidar a profissão. Em tempos de altas ondas (SOA e BPM), passa da hora de percebermos que o Analista de Negócios desempenha funções cruciais.
[Meu próximo post falará sobre BDUF e a perigosa insistência de alguns que acham que 'super-programadores' generalistas dão conta do recado - dispensam os AN's].


Mas o BABoK me assustou um pouco e decepcionou um tanto. Ainda não vi as alterações previstas para a versão 2.0, mas a versão 1.6 cobre, na minha opinião, apenas 50% do trabalho de um AN. Dos seus 8 capítulos, 5 cobrem exclusivamente as atividades de planejamento, desenvolvimento e gerenciamento de requisitos. O gráfico abaixo ilustra as áreas de conhecimento cobertas pelo BABoK:



"Enterprise Analysis", segundo capítulo do BABoK, é descrita como "uma coleção de atividades pré-projeto que servem para capturar uma visão futura do negócio, formando assim uma base a a elicitação de requisitos e para o desenho da solução [...]".

Como já comentei aqui, e talvez seja uma falha minha, mas não consigo dissociar a Modelagem de Negócios da Engenharia de Requisitos. Lógico, são duas disciplinas diferentes. Mas elas compartilham "momentos", independente do modelo de processo utilizado. E o BABoK não fala nada sobre Modelagem de Negócios. Se ela não é uma responsabilidade do AN, então é de quem?

Quero crer que, com a demanda gerada pelas 'ondas' BPM e SOA, o BABoK passe a contemplar atividades para modelagem de negócios e de processos de negócios em suas futuras versões. Melhor seria se a incorporação fosse motivada pela percepção de que o trabalho do AN não se restringe à coleta, análise e documentação de requisitos.


Como mostra o conteúdo programático do workshop promovido pela Tempo Real Eventos, a primeira metade do evento tratará exclusivamente da modelagem do negócio e seus processos. Apresentarei algumas práticas sugeridas pelo BABoK na segunda parte do evento.

Marcadores: analista_de_negócios, bpm, cursos_e_palestras, evento, soa

In the existing IT environments, I believe we moved from being Server-centric to OS-centric to Application-centric. In the next generation, we become more network-centric but fundamentally (for the first time I might note) start building Information Technology actually around the Information. This is powerful. It means that Information is no longer captive to a single application but can be leveraged across any number of applications.

- Mark S. Lewis, VP da EMC

Vale a pena ler toda a sua série chamada "Flat IT".

Marcadores: meme, soa

Nossa área parece ter uma 'quedinha' especial por polarizações. Algumas são necessárias (REST vs SOAP). Seriam menos chatas se fossem breves e mais produtivas (Open Source vs Software Proprietário ou Agile vs Classic). Mas alguns embates parecem não fazer nenhum sentido. Um que descobri só recentemente é o duelo UML ou BPMN. Taí uma discussão muito 'nada a ver', na minha opinião. Vamos aos fatos.

A UML, particularmente sua versão 2.0, é muito extensa? Muito genérica? Sim. Mas isso não é um acidente - um defeito. O ponto mais forte da UML, fora a coerência e legibilidade de seus artefatos, é a sua extensibilidade. Qualidade óbvia, já que ela é genérica. Tipo: "não faz mais do que a obrigação". Várias extensões foram desenvolvidas desde o nascimento da linguagem, no final da década passada. Uma delas é muito relevante para esta discussão: a EPBE, ou "Eriksson-Penker Business Extensions".

Apresentada por Hans-Erik Eriksson e Magnus Penker no livro "Business Modeling with UML" (Wiley, 2000), a EPBE cobre todos os aspectos da modelagem de negócios. Ou quase todos. É curioso, por exemplo, que ela não contemple diagramas de casos de uso. Na visão dos autores, tanto o diagrama de casos de uso quanto os diagramas de componentes e de distribuição (deployment) "são utilizados na análise e projeto de sistemas de informação, mas são pouco relevantes na modelagem de negócios". Por não conseguir dissociar a modelagem de negócios da engenharia de requisitos (falha minha), coloquei aquele "quase" acima.

Mas a EPBE realmente cobre o essencial na modelagem de negócios, estruturando-se em torno de 4 visões:

• Visão do Negócio: uma visão geral do negócio, destacando aspectos estratégicos e táticos (problemas a combater ou oportunidades a aproveitar);
  
  
• Processos de Negócio: mostra a dinâmica da organização, inclusive seu relacionamento com entidades externas.
  
  
• Estrutura do Negócio: apresenta a estrutura da organização, a divisão de recursos e a carteira de produtos e/ou serviços;
  
  
• Comportamento do Negócio: o comportamento individual de cada recurso ou processo no modelo do negócio.

Apenas nesta breve descrição já fica claro que não é possível comparar UML com BPMN. Seria algo como comparar uma bela melancia com uma simpática jaboticaba. BPMN, como o próprio nome indica, é uma Notação para Modelagem de Processos de Negócio. Ou seja, cobre apenas 1/4 do que é possível realizar com a UML devidamente extendida. Mas a questão não se encerra aqui.

Muitos lembrarão: "ah, mas o debate verdadeiro é BPMN versus o Diagrama de Atividades da UML". De forma simples e direta: não há nada que eu faça em BPMN que eu não consiga representar em UML. Sim, com BPMN eu consigo diagramas mais 'bonitinhos', mas acho que este, definitivamente, não é o caso. Agora vamos elencar algumas coisas que conseguimos representar em UML e que não estão previstas na especificação BPMN:

• Know-Why: um processo de negócio bem documentado justifica sua existência. Precisamos conhecer os objetivos e metas atrelados àquele dado processo. É fácil extender o diagrama de atividades para armazenar essas informações. Mas para que reinventar a roda? O Diagrama de Processos da EPBE já prevê e obriga a inserção desses atributos do processo.
  
  
• Métricas: apelando para a batida máxima, "não se gerencia o que não se mede". Pode não ser verdadeira para tudo mas, em se tratando de processos de negócio, a afirmação é mais que verdadeira. Cada tipo de processo pode ter um conjunto muito específico de medidas relevantes. Mas existem duas que deveriam estar em todo mapa de processo: Custo e Tempo de Ciclo. Para conhecer os custos de um processo é imperativo que mapeemos todos os recursos utilizados em sua realização. BPMN simplesmente ignora-os.
  
  
• Informação: na EPBE as informações são tratadas como um tipo de recurso que municia um processo. BPMN, como dito anteriormente, não se preocupa com recursos.
  
  
• Pessoas: ou stakeholders, também são recursos na notação EPBE.
  
  
• Requisitos: sim, a EPBE também não contempla artefatos para a captura e gerenciamento de requisitos. Mas ela, ao contrário da BPMN, não ignora sua existência. Há um diagrama muito útil na EPBE, o Diagrama de Linha de Montagem (Assembly Line - veja exemplo abaixo), que permite associar processos de negócios (diretamente de seu respectivo diagrama), com pacotes de objetos (ou serviços!) e casos de uso. Ou seja, consigo rastrear - navegar entre o domínio do problema e o domínio da solução. Com uma vantagem imbatível: usando a mesmíssima linguagem: UML.

Conclusão

Não é o caso de simplesmente dizer que BPMN não é útil. Suas boas idéias, particularmente o maior detalhamento de alguns elementos (só obtidos através do uso de estereótipos no Diagrama de Atividades), podem e devem ser aproveitadas. BPMN e UML estão sob os cuidados do OMG. Acredito que num futuro próximo veremos uma mixagem das duas especificações. Ou então a transformação de BPMN em uma extensão da UML. Algo fácil e natural.

Se BPEL é o seu sonho de consumo, saiba que já existem tradutores de diagramas de atividades para ela. Portanto, BPEL não é desculpa para a adoção da BPMN.

Por fim é arriscado mas necessário dizer que não podemos confundir Modelagem de Negócios com a Modelagem de Processos de Negócios. A primeira é uma disciplina muito mais ampla e complexa. Que é muito importante em projetos para desenvolvimento de sistemas. E nada menos do que VITAL em iniciativas SOA.

Marcadores: bpmn, modelagem_de_negócios, soa, suporte_a_projetos, uml

Jeff Schneider, há tempos, escreve sobre SOA. Dicas valiosas. Percebendo um certo descompasso - carência mesmo - em fevereiro começou uma série chamada "Starter SOA". Tem 3 partes até agora. Não se sabe se continuará. Mas o pouco que foi para o ar é de enorme valia.



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:


Fui mais detalhista em alguns pontos, mas pequei por ignorar por completo a Arquitetura da Informação. Na verdade, joguei nas costas do Arquiteto de Serviços essa responsabilidade. Um serviço encapsula dados e lógica. Mas isso não tem nada a ver com a proposta de Schneider. Como bem explicou Todd Biske, "o gerenciamento da informação é a fonte de consistência entre todos os serviços". Sendo assim, no gráfico acima, o Arquiteto da Informação ficaria logo abaixo do Arquiteto SOA. É seu braço direito e fiscal.

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.

Marcadores: gerenciamento_de_ativos, soa

No mundo de TI, tudo que é realmente novo gera mudanças culturais. SOA propõe e depende muito de uma série de mudanças culturais. A forma como uma organização percebe e gerencia seus processos de negócio talvez seja uma das mudanças mais visíveis - mais claras. Mas existem outros tipos, relativamente menores, que também são críticos para o sucesso da iniciativa.

Alguns princípios que regem o gerenciamento de projetos, por exemplo, precisam ser revistos. Recentemente aconteceu uma boa discussão no grupo CMM-Brasil que envolveu, entre outras coisas, o balanceamento do 'trio de ferro: Preço x Prazo x Escopo'. Resumindo: quem defende uma abordagem Ágil* diz que, após a negociação e contratação formal, o único item que deveria variar na equação acima é o escopo. Deveríamos eliminar algumas funcionalidades com o intuito de manter intactos o valor e o prazo inicialmente acordados.

De uma maneira geral, e não exclusivamente no caso de um programa SOA, a regra é questionável e polêmica. Agilidade combina com flexibilidade. E regras escritas em pedra não combinam com flexibilidade. Está aí um tipo de princípio que não deveria ser adotado no nível da organização. Alguns projetos podem exigir o total atendimento dos requisitos apresentados. Neste caso, clientes e usuários podem concordar com uma flexibilização dos preços e prazos apresentados. A negociação do(s) ponto(s) de variabilidade do 'trio de ferro' deveria fazer parte do acordo inicial, seja ele um contrato ou um convênio. Ao contrário do que foi dito naquela thread do grupo de discussão, não deixo de ser ágil porque concordei com a entrega de todas as funcionalidades requeridas por um cliente. Mesmo que isso signifique algum atraso em relação aos prazos acordados anteriormente.

Agora, quando se trata especificamente de uma iniciativa SOA, a fixação do escopo como o único fator variável do 'trio de ferro' pode ser um engano ainda mais nocivo. Um engano bastante comum que, segundo Todd Biske, deriva de uma mentalidade 'schedule-driven'. Vou surrupiar seus argumentos:

Muitas organizações com as quais trabalho têm a tendência de ser 'guiadas pelos cronogramas' (schedule driven). Ou seja, o elemento menos flexível do projeto é o cronograma. Assim, a coisa que mais 'sofre' é o escopo. Infelizmente, não se trata do escopo propriamente dito e sim da diferença entre o caminho mais rápido (tático) versus o melhor caminho (estratégico). Se você está tentando implementar uma SOA, saiba que esse tipo de governança de TI tornará sua vida bem difícil. Você está premiando o sucesso do cronograma, não o sucesso da arquitetura.

Todd encerra dizendo que se trata de uma "grande mudança cultural". É sim, particularmente onde impera o imediatismo. SOA deve, de alguma forma, ser vacinada contra esse mal. E isso não significa, de forma alguma, deixar de ser ágil.

Marcadores: ágil, agile, gerenciamento_de_projetos, soa

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


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

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

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

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

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


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

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

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


Distribuindo Responsabilidades

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

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

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

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

[continua]



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


Referências:

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

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

Extensão do capítulo "Etiquetando Ativos de Software", penúltimo capítulo publicado até agora na série "Gerenciando Ativos de Software".

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" [1].

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.



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 [2], e o meta-modelo básico de conceitos de modelagem de negócios proposto por Hans-Erik Eriksson e Magnus Penker [3].

Todos os requisitos são associados aos casos de uso do negócio 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 do produto ou serviço que, 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).
   
   

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

"I think that right now we’re at a stage where the tools and accepted architectures do not fit the job that programmers have to do. We have three factors that are not going to change in the near future, and they all live on the client: HTML, the browser, and Javascript. Everything else is negotiable. It’s up to programmers to figure out how to deliver the best application they can using any back-end they want, as long as it works with those three front-end technologies. Programmers have done some really cool stuff on top of those three technologies, but things are still pretty awkward."

...

"The big problem, I think, is that the front-end is still very disconnected from the back-end. Because of SOA, people are still thinking very much in terms of sending and receiving messages rather than thinking about how to create a smooth and seamless application that exists both on the client and the server. I don’t know if it’s because of the fact that the Web was very disconnected in the early days, but most programmers still don’t think of the Web browser as a connected client."

...

"However, there is no longer any good reason to keep the client disconnected from the server in terms of software architecture. Broadband penetration is now 75% of active Internet users in the U.S., and much higher in countries that are not as backwards as we are. For some reason, programming techniques have not yet adapted to this fact. And what’s more, everyone is on their way to becoming an always-on node on the Internet network. One third of Blackberry owners are not using their phones for business. The iPhone from Apple (if it gets to keep its name) is a tiny OS X computer with Internet connectivity. In places where Wi-fi hotspots aren’t present, Wi-Max will be soon. In other words, we can no longer get around the fact that the client is once again part of the architecture equation, and our programming practices need to support that fact."

- Jason Kolb (em "Network-Oriented Architecture")

Marcadores: graffiare, meme, soa

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


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


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

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

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

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

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


O Gestor da Biblioteca de Ativos (GBA)

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

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

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

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

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

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

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

[continua]



Referências:

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

Observações:

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

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

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

Continuação do artigo "Ativos de Software". Integrante da série "Gerenciando Ativos de Software".


No artigo anterior foi apresentada a "etiqueta" RAS (Reusable Asset Specification) [1], 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:



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" [2]. 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 [2]:

• 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" [1].

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, ...)" [2].


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 [1]:

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

[continua]


Referências:

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

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.

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

Pesquisa da McKinsey com 72 executivos de TI confirma: SOA está no topo da agenda de 64% deles. Espero que a tendência também apareça nas pesquisas com os CIO's tupiniquins. E em seus orçamentos, é claro.

Interessante do estudo da McKinsey é a justificativa apresentada por 48% dos executivos: eles querem implementar uma SOA para facilitar a integração com seus parceiros de negócios. Das duas, uma:

• Seus sistemas internos estão Ok (bem integrados) e não justificariam a adoção de uma SOA; ou
• Trata-se de uma estratégia para facilitar a obtenção de investimentos - aliás, uma boa estratégia. SOA não impõe um ponto de partida, e a priorização de processos de negócios mais críticos pode acelerar o ROI e melhorar a percepção dos benefícios. Processos 'públicos' (que ultrapassam as fronteiras da empresa) são sempre críticos. Risco: confundir SOA com um conjunto de web services.
  

Joe McKendrick, da ZDNet, também elencou uma série de previsões para SOA em 2007: Melhores ferramentas (no "ano da modelagem") e uma adoção lenta mas consistente estão entre elas. Mas a mais dramática deve preocupar o pessoal daqui também: a falta de profissionais habilitados para trabalhar na implementação e manutenção de uma SOA.

Marcadores: soa

A impressão que tive é que com a quantidade de dinheiro que se está investindo em SOA hoje não dá mais pra chamar de futuro, mas de presente. Claro que há um problema muito grande aí: Este foi o mesmo cenário, por exemplo, com EJBs.

Eu espero sinceramente que tenhamos aprendido a lição e que estudemos os conceitos por trás das coisas antes de sair por aí implementando sistemas que não funcionam utilizando ferramentas caríssimas.

- Philip Calçado (em seu blog Fragmental)

===

Acabei de conhecer o trabalho do Philip. Coisa muito boa, escrita d'uma forma muito legal. Tanto que já tá devidamente assinado e referenciado ali embaixo.

E assim retomo os posts "meme" aqui no finito.

Marcadores: meme, soa

Continuação de "Reuso: Prática Sistemática".



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." [1]

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." [2]

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.


[continua]

===

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.

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

Este post é um "índice" para os (até então) 8 capítulos que compõem o artigo "Projetos SOA - Novos & Velhos Desafios".

Trata-se de um trabalho em desenvolvimento e sua publicação aqui visa obter outras colaborações, críticas e sugestões. A ToDo-List "What needs to be done?", ao lado, indicará sempre os próximos passos deste trabalho. A intenção é promover um bate-papo (presencial, obviamente, além de uma provável apresentação) até o final do mês de agosto. Seguem abaixo os links para as 8 partes do artigo:

#1 - Introdução
#2 - Conceitos Básicos
#3 - É o Negócio, Estúpido!
#4 - O Programa SOA
#5 - Processos
#6 - MDA (Model Driven Architecture)
#7 - Os Projetos SOA
#8 - Processo de Gestão e Desenvolvimento

Além de uma série de outros motivos que não merecem tratamento aqui, a amplitude e complexidade do tema me levaram a desistir de inscrever o artigo nos eventos "V Seminário Internacional" do PMI e "Gestão de Projetos" da SUCESU-SP, do qual participei nas duas últimas edições. Há muito por fazer!

E estudar. Olhando especificamente para a "Gestão do Programa SOA" e "Gestão de Projetos SOA" dá para destacar as seguintes disciplinas:

. Mapas Estratégicos - Para a Gestão de Portfólios
. MDA (Model Driven Architecture) - Como complemento do Processo de Desenvolvimento e como framework
. RUP (Rational Unified Process) - Como base do Processo de Desenvolvimento.
. Scrum - Que selecionei como processo de Gestão dos Projetos. Um Meta-Scrum seria utilizado para gestão do Programa SOA.
. Formação de Equipes - Apresento duas estruturas, uma para o Comitê Gestor e outra para as Equipes de Desenvolvimento. Há vários perfis (oportunidades?) novos!

Se considerarmos que as "Arquiteturas Orientadas a Serviços" são, em si, uma macro-disciplina bastante nova, instigante e complexa... Pois é: há muita coisa nova (e boa) a ser estudada e, claro, IMPLEMENTADA!

Espero que o Finito seja uma boa ferramenta para que a gente possa trocar idéias e experiências. Espero mais ainda que o conteúdo apresentado seja um bom "estopim". Let's talk about it?

Marcadores: arquitetura, gerenciamento_de_projetos, soa

Uma implementação SOA não deve significar a adoção de um conjunto totalmente novo de processos e métodos. Principalmente se a empresa contar com uma equipe relativamente estável e um conjunto de melhores práticas comprovadamente eficazes. O processo existente deveria ser customizado de forma a implementar atividades, perfis e produtos específicos de um programa SOA. A principal barreira para a adoção de um processo atual seria o fato deste não prover um ciclo de vida de desenvolvimento que seja iterativo e incremental. Um modelo waterfall, definitivamente, não é adequado para o desenvolvimento de Serviços SOA. Também é desejável que o processo utilizado seja [13]:

• Cooperativo: aproxime a equipe de projeto com os futuros usuários dos serviços;
• Direto: o método deve ser de fácil aprendizado e bem documentado;
• Adaptável: fácil de ser customizado de forma a atender particularidades de determinado projeto;
• Escalável: de forma que possibilite sua adoção em projetos dos mais variados portes e níveis de complexidade;
• Orientado pela Arquitetura: ou seja, pressupõe que os produtos dos projetos em desenvolvimento fazem parte de algo maior e devem, conseqüentemente, respeitar os padrões fixados; e
• Incentivador do Reuso de Ativos: uma conseqüência direta de sua orientação à arquitetura.

Não há um único processo no mercado que, em seu formato padrão, atenda todos os requisitos listados acima. Os 3 primeiros itens da lista mais as características “iterativo e incremental” configuram o que se chama de um “Processo Ágil”. Porém todos os mais conhecidos são indicados para pequenas equipes ou seja, não escalam. Já processos que atendem os 3 últimos requisitos da lista, como o Rational Unified Process (RUP), raramente são considerados “Cooperativos” ou até mesmo “Diretos”.

Uma combinação do RUP, Scrum e eXtreme Programming (XP) pode gerar um excelente processo para a gestão e desenvolvimento de Projetos SOA. Abaixo é apresentada uma visão geral deste modelo customizado.


Visão Geral de um Processo Customizado

Dos 3 processos listados acima, o RUP é o mais completo. Por isso muitas vezes é tido como excessivamente burocrático e “pesado”. Seus críticos, na maioria das vezes, desconsideram o fato dele ser bastante customizável. O RUP é a base desta sugestão exatamente por sua completitude e adaptabilidade. Geralmente ele é apresentado, em alto nível, da seguinte maneira [16]:


As disciplinas do RUP mais afetadas em uma customização para atendimento dos requisitos de um processo SOA são:

• Modelagem de Negócios: que passa a gerar, como principal produto, o Contrato do Serviço que, por sua vez, é a base para elaboração do Backlog do Serviço (Produto, na terminologia Scrum). A captura de indicadores de qualidade e níveis de serviço esperados também merece destaque;
• Implementação: que deve incorporar algumas práticas XP, particularmente a liberação de produtos em ciclos curtíssimos;
• Teste: que incorpora testes específicos de uma Arquitetura Orientada a Serviços, como a validação da abrangência das interfaces expostas, potencial de reuso, dentre outros;
• Implantação: que deve assimilar também todas as atividades de publicação dos Serviços, dentre elas o encapsulamento final dos artefatos e o agendamento da publicação;
• Gerenciamento do Projeto: que é totalmente trocada pelo método Scrum. Veja mais abaixo.


Gerenciamento de um Projeto SOA

Como adiantado no sub-capítulo “Equipes de Projetos” acima, a responsabilidade pelo Gerenciamento de um Projeto SOA é compartilhada pelo Coordenador do Projeto e pelo Dono do Serviço (Product Owner, na terminologia Scrum original). O primeiro cuida de todas disciplinas previstas no PM-BoK (Project Management – Body of Knowledge) exceto a “Gestão do Escopo”, que seria de responsabilidade exclusiva do Dono do Serviço*. Mas a adoção do Scrum como método para a gestão de um projeto SOA implica em mudanças ainda mais profundas na rotina de trabalho do coordenador de projetos.

Sua principal atividade pode ser vista como uma “obsessiva (extrema) gestão de riscos”. Ele deve buscar e eliminar todas as barreiras que estejam impedindo a equipe de atingir seu ponto máximo de performance. O diagrama abaixo expõe uma visão geral do processo Scrum adaptado para o desenvolvimento de projetos SOA:


Na etapa de Planejamento é compilada a primeira versão do Contrato do Serviço. Em tempo de desenvolvimento é desejável que este contrato seja a principal ferramenta de controle e acompanhamento do projeto. Para tanto ele deve contemplar também [3] :

• Estimativas de Custos e Prazos para o projeto;
• Plano de Desenvolvimento e das Iterações (Sprints);
• Definições de sincronismo com outros projetos;
• Plano de Testes; e
• Plano de Publicação.

O contrato é desenvolvido a partir dos requerimentos coletados pelo Analista de Negócios e de definições prévias oriundas do Comitê Gestor do Programa SOA. O contrato deve respeitar integralmente os Padrões SOA definidos por este comitê nos momentos iniciais do programa. É parte integrante do Contrato um desenho em alto nível da arquitetura do serviço. Por isso ele é elaborado em conjunto pelo Dono do Serviço e pelo Analista de Negócios.

A negociação final do contrato com as áreas usuárias é conduzida diretamente pelo Dono do Serviço. O processo pode prever uma etapa de revisão de contratos pelo Comitê Gestor, que ocorreria antes da elaboração do Backlog do Serviço. Esse backlog é desenvolvido pelo Dono do Serviço. Sua elaboração é acompanhada pelo Coordenador do Projeto, que pode discutir prioridades e definir a estrutura de divisão de tarefas. É também neste momento que as estimativas de prazos e custos podem ser refinadas, com apoio de integrantes das equipes de desenvolvimento.

A partir do Backlog do Serviço o Coordenador do Projeto elabora o Backlog do Sprint (Iteração), que é o plano de trabalho da próxima iteração a ser executada. Um sprint, na concepção original do método Scrum, é uma iteração com duração fixa de 30 dias. Apesar dos benefícios da fixação de um prazo comum para todas as iterações de todos projetos, entende-se que em muitos casos tal “regra” pode se tornar uma barreira a ser derrubada pelo Coordenador de Projetos. Um serviço, dependendo de sua granularidade, pode demandar ciclos de duração mais curta. No entanto trata-se de um excelente balizador para projetos mais complexos.

Um sprint contempla todas as fases tradicionais de um processo de desenvolvimento de sistemas, ou seja: engenharia de requerimentos, análise, modelagem, codificação, testes e liberação. No entanto, é vital que ao término de cada sprint aja uma nova versão do serviço em condições de uso, mesmo que ainda não estejam satisfeitos todos os seus requerimentos fundamentais.

Como mostrado anteriormente, a construção de um serviço normalmente envolverá o trabalho de dois times distintos: os desenvolvedores dos Frontends das Aplicações e os desenvolvedores dos Serviços propriamente ditos. É crucial que o backlog do Sprint contemple a total sincronização destas duas frentes de trabalho. O gráfico a seguir mostra um zoom de como deve ocorrer o Sprint [3] :


O processo prevê a realização de scrums diários, breves reuniões que ocorreriam sempre no mesmo local e horário. Nelas o Coordenador afere os progressos obtidos desde o dia anterior, refina a lista de riscos e impedimentos e ajusta o planejamento de atividades do dia. Radical, a proposta original do Scrum sugere que estas reuniões tenham a duração máxima de 15 minutos. O coordenador pode optar por realizar duas reuniões diárias, uma com cada time de desenvolvimento.

No último dia do sprint realiza-se uma reunião de revisão com a presença do Dono do Serviço, Analista de Negócios e representantes das áreas usuárias. O Coordenador e a equipe de desenvolvimento apresentam as realizações do último sprint. Neste momento o Dono do Serviço e o Coordenador do Projeto revisam o Backlog do Produto, registrando mudanças ou novas solicitações. A partir desta atualização o Coordenador elabora o Backlog do próximo sprint.

Quando todos os itens do Contrato do Serviço estiverem satisfeitos inicia-se a terceira e última fase do projeto, que na versão original do Scrum é chamada Postgame Phase. Neste momento o Serviço e respectivo Cliente são submetidos ao processo de certificação, que deve garantir a total adequação dos novos artefatos aos Padrões SOA.

Por fim temos o processo de Publicação, que envolverá o encapsulamento de todos os artefatos gerados e o agendamento da publicação do Serviço.

Representantes do Comitê Gestor do Programa SOA envolvem-se em três momentos de um projeto:

• Validando o Contrato elaborado na primeira fase;
• Acompanhando as Reuniões de Revisão, que no formato padrão ocorrem mensalmente; e
• Certificando e Publicando a versão final do Serviço.

O processo Scrum sugere que as equipes de projeto se auto-gerenciem, promovendo a livre interação entre todos os membros. O Coordenador do Projeto, mais que um “controlador”, é um Facilitador. Outra característica marcante do processo é a “blindagem” da equipe, que em seu dia-a-dia fica livre de influências externas. Este desenho valoriza todos os integrantes da equipe e pode representar consideráveis ganhos de produtividade.


Evolução do Processo

O Scrum é um modelo organizacional desenhado para a execução de projetos cuja previsibilidade é limitada [14]. Os princípios básicos que levaram ao seu desenvolvimento foram Flexibilidade, Adaptabilidade e Produtividade. A coincidência com os meta-requerimentos fundamentais de uma iniciativa SOA é total. Mas ambas propostas, tanto o Scrum quanto as Arquiteturas Orientadas a Serviços são relativamente recentes. Praticamente não existem referências do uso do Scrum em projetos SOA.

O trabalho mais recente de Jeff Sutherland [14] descreve a última evolução do Scrum, chamada “Tipo C”. As principais alterações referem-se à adoção de sprints simultâneos e a elaboração de um MetaScrum. Este meta-processo pode ser muito útil na gestão do Programa SOA, como sugerido neste artigo. E a habilidade de gerenciar múltiplos sprints pode ser crucial em uma iniciativa SOA que se encontre em um estágio mais avançado de maturação.


=================

3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).
14. “Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects”, Jeff Sutherland
Artigo (2005)
16. “Rational Unified Process”, IBM Corp.
http://www-306.ibm.com/software/awdtools/rup/


* Na realidade, a versão original do Scrum prevê a existência de um terceiro gestor, não considerado nesta proposta.

Marcadores: arquitetura, gerenciamento_de_projetos, soa