finito

Tag: SOA

  • Transformando Etiquetas em uma Base de Conhecimentos

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

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

  • Ativos: O Cofre e o Guardião

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

    Foto de Kk+.

    A classificação e organização dos ativos de software sugeridas no capítulo anterior indicam claramente a necessidade de um repositório. Um misto de ‘cofre’ e estoque que deve armazenar e facilitar a recuperação de todo o patrimônio catalogado. O padrão RAS apresenta uma especificação relativamente simples para a implementação de um repositório, que visa exclusivamente o armazenamento e a recuperação de ativos . 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.

  • Ativos de Software

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

    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.

  • Reuso: Prática Sistemática

    Continuação de “Reuso: Conceitos, Justificativas e Desculpas“.

    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…

  • Reuso: Conceitos, Justificativas e Desculpas

    Continuação de “Gerenciando Ativos de Software“.

    Obs importante: por se tratar de um compilação de idéias que estou realizando em “run time”, a seqüência e conteúdo dos artigos desta série podem ser consideravelmente modificados em sua versão final, um PDF que espero publicar até o dia 11/jan/2007. Nem todas as revisões se refletirão no blog. Optei por falar sobre REUSO nesta 2ª parte por se tratar do grande objetivo da série. O capítulo seguinte, que deve ser publicado na próxima semana, falará sobre Ativos de Software de uma maneira mais específica. Inclusive (re)apresentando* a proposta RAS (Reusable Assets Specification) do OMG e fazendo uma relação da especificação com os elementos que compõem uma SOA.

    * A primeira vez que publiquei um material sobre RAS foi em 2004. Está no artigo “Gestão Estratégica de Ativos de Software” . Desta vez espero ser um tanto mais específico.

    Foto da Crystal.

    Reuso é a prática sistemática de se desenvolver software a partir de um conjunto de ‘blocos de construção’, de forma que as similaridades dos requisitos e/ou da arquitetura entre as aplicações possa ser explorada para que sejam alcançados benefícios substanciais na produtividade, qualidade e na performance do negócio.

    O texto acima, transcrito diretamente de “Practical Software Reuse” , é uma das mais recentes (re)definições do termo Reuso de Software. É forte porque desconsidera aquilo que Steve McConnell chamou de “reuso oportunista” . O reuso oportunista/casual parece ser a única alternativa oferecida na versão original do RUP, por exemplo . A definição acima também é completa, porque encerra em uma única frase aquilo que seus autores consideram as 4 características-chave do reuso:

    • É uma prática sistemática para o desenvolvimento de software;
    • Emprega um conjunto de ‘blocos de construção’ (artefatos reutilizáveis);
    • Explora similaridades dos requisitos e/ou da arquitetura entre as aplicações; e
    • Oferece benefícios substanciais para a produtividade, qualidade e performance do negócio.

    Antes de uma análise de cada uma das características listadas, é interessante confrontar a definição acima com o Reuso prometido pela proposta SOA. O artigo anterior citou uma pesquisa que diz que as empresas esperam reutilizar apenas 30% dos serviços implementados. É interessante notar que trata-se de um tipo de reuso relativamente diferente daquele apresentado acima.

    Assim como em propostas anteriores, notadamente Orientação a Objetos (OO) e Componentização, o reuso em uma SOA pode acontecer em dois momentos muito distintos:

    • Em Tempo de Construção, realizado diretamente por um analista ou programador; e
    • Em Tempo de Execução, realizado por outro ativo.

    O reuso em tempo de execução é parte central na implementação de uma SOA. Todos os serviços, particularmente aqueles que representam entidades ou processos de negócios, devem encapsular um ativo existente, independente da sua tecnologia. Uma SOA propõe dar sobrevida para todos os sistemas legados de uma organização. Por isso não faria muito sentido falar de níveis de reuso em tempo de construção de uma SOA.

    A pesquisa, encomendada pela Bea , não fala explicitamente mas leva a entender que se trata do reuso em tempo de execução. De qualquer forma, a meta (30% de reuso) parece bastante modesta. Os ‘blocos de construção’ em uma SOA são os seus serviços que, conceitualmente, podem ser categorizados da seguinte maneira:

    • Básicos: representam entidades (clientes, produtos) ou pequenas atividades (validação de crédito, verificação de disponibilidade em estoque);
    • Intermediários: únicos que mantêm relação direta com a parte tecnológica da arquitetura (fornecendo pontes, conversores etc);
    • Processos: representam diretamente atividades ou processos de negócios (vendas, baixa de duplicatas etc).

    Espera-se que um serviço em uma SOA seja único na função ou conjunto de dados que oferece. Não faz sentido, por exemplo, que existam dois serviços representando a entidade Clientes. Por isso parece estranha a expectativa de que apenas 1/3 dos serviços seja reutilizado por outros em tempo de execução. De qualquer maneira, os dados disponíveis sobre implementações SOA existentes ou em andamento ainda são raros e vagos.

    Experiências com a adoção do reuso sistemático anteriores à SOA mostram que é factível a colocação de metas mais ambiciosas. Alguns casos reportam níveis de reuso entre 50% e 95%! Mais relevantes que as taxas de reutilização são os benefícios gerados diretamente por ela: ganhos de produtividade de 58% por ano em um período de 4 anos ; redução de 84% nos custos de desenvolvimento ; redução de 70% no tempo de desenvolvimento . Um programa SOA não deve alcançar números tão altos, mas eles devem servir, no mínimo, como uma boa referência para os projetos SOA.

    ===

    ===

    Referências:
    1. Practical Software Reuse
      Michel Ezran, Maurizio Moricio e Colin Tully
      Springer (2002).
    2. Rapid Development
      Steve McConnell
      Microsoft Press (1996).
    3. The Rational Unified Process – An Introduction (Second Edition)
      Philippe Kruchten
      Addison-Wesley (2000).
    4. SOA Research – SOA Justification (PDF – Requer registro)
      GCR Custom Research
      Patrocinada pela Bea Systems.

  • Gerenciando Ativos de Software

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

    Reuso: Um Tabu

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

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

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

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

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

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


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

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

    Viabilidade

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

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

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

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

    ===

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

    ===

    Referências:

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

  • Como montar Times e influenciar Projetos

    Série “De Brooks a Berkun” – 2ª Parte

    A experiência prática de Fred Brooks, como citado anteriormente, foi com projetos mastodônticos: 1000 pessoas envolvidas ou mais. Mas ele lembra que desde aquela época os ‘gerentes de programação’ preferiam “pequenos e ‘agudos’ times formados por pessoas de ‘primeira classe’”. Brooks cita um estudo (de Sackman, Erikson e Grant) que mostra que um programador de ‘primeira classe’, que recebia US$20.000/ano, podia ser até 10 vezes mais produtivo que um programador de US$10.000/ano. Mas um pequeno grupo de ‘estrelas’ seria capaz de desenvolver um OS/360? Talvez em 10 ou 25 anos, segundo cálculos do autor. Por outro lado Brooks lembra que times grandes, orientados para a execução de um trabalho na base da ‘força bruta’, são “lentos, caros, ineficientes, e produzem sistemas que não possuem ‘integridade arquitetônica’. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE, etc. A lista é longa”. E “o dilema é cruel”, escreve Brooks. Haveria solução?

    A sugestão de Brooks, baseada em uma proposta de Harlan Mills , dá título para o terceiro capítulo do seu livro, “O Time Cirúrgico”. Segundo ele, o time ideal é formado por:

    • Programador Chefe (Cirurgião)
    • Co-Piloto
    • Administrador
    • Editor
    • Secretárias (duas)
    • Bibliotecário
    • Almoxarife
    • Testador
    • Advogado (da Linguagem)

    Reparem bem. Nós temos praticamente 9 pessoas trabalhando para o programador! Dando-lhe “todo suporte que fará aumentar sua eficácia e produtividade”. Lembram-se que o Brooks também sugeria que alocássemos apenas 1/6 de nosso cronograma para tarefas de codificação? Outro mundo, não é mesmo? Pode e deve ser factível em um time cirúrgico de verdade mas aplica-se a equipes montadas para o desenvolvimento de sistemas?

    O ‘cirurgião’ seria responsável pela execução de todas as tarefas principais daquela parte do projeto: sua especificação, design, codificação, testes e documentação. Não difere muito de alguns job descriptions e anúncios de vagas que ainda vemos por aí. Seria um “analista-programador” que, segundo Brooks, deveria ter 10 anos de experiência.

    O mundo da programação mudou muito desde os tempos do COBOL e da PL/I. A complexidade e abrangência de nossas linguagens e arquiteturas de aplicações aumentaram ‘para os lados e para baixo’. E é cada vez mais comum que cada uma das tarefas listadas acima seja atribuída a um especialista. Uma divisão que é nítida em ‘fábricas de software’, por exemplo. Em caminho oposto, alguns advogados de métodos ágeis enaltecem a importância de um time formado por ‘generalistas’.

    A analogia com equipes médicas reaparece em um artigo de Peter Drucker publicado pela Harvard Business Review em 1988, “O Advento da Nova Organização” . Segundo Drucker, “informação é dado investido de relevância e propósito. Por conseguinte, a conversão de dados em informação requer conhecimento. E conhecimento, por definição, é especializado. (Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender).”

    Apesar de ser simpático aos chamados métodos ágeis, não acredito na possibilidade ou eficácia de um time composto por ‘generalistas’. Prefiro apostar em uma formação que valorize o perfil e a experiência de cada um de seus membros. No diagrama abaixo apresento um exemplo de um time desenhado para desenvolver uma aplicação web (ou ‘cliente/servidor n camadas’, como queiram):

    O arquiteto é o novo ‘cirurgião’. É o dono e principal responsável por aquele projeto ou módulo. Mas só coloca ‘a mão na massa’, codificando, para transferir conhecimentos. Ocupa-se com a concepção e manutenção da integridade arquitetônica da solução. Ele é diretamente apoiado por cinco especialistas:

    • Analista de Negócios (biz): cuida da coleta e organização dos requisitos, e apóia seu desenvolvimento, fazendo a ponte entre os usuários e a equipe de desenvolvimento;
    • Desenvolvedor de Interfaces (front): é especialista em usabilidade e ‘manda bem’ em conceitos de arquitetura de informações. Hoje deve ‘brincar’ com AJAX (Javascript), Flash, HTML, CSS, ASP, JSP, JSF e afins.
    • Desenvolvedor de Serviços (srv): domina orientação a objetos, componentização e, mais recentemente, serviços. É um programador clássico que, como tal, não leva o menor jeito com as ‘frescuras da camada de apresentação’.
    • Arquiteto de Informações (data): uma versão remoçada dos DBA’s (administradores de bancos de dados). Domina o desenho e desenvolvimento de bases tradicionais, transacionais, mas também sabe quando lançar mão de sistemas gerenciadores de conteúdo e bases analíticas.
    • Nosso antigo inimigo (infraestrutura): são os responsáveis por nossos servidores, redes, firewalls e outros brinquedinhos. Tê-los como parte da equipe de projeto desde os primeiros dias é uma prática que, com certeza, minimiza aquele ‘jogo de empurra’ que costuma acontecer um pouco antes ou um pouco depois do delivery da solução.

    Mas… e o coordenador? No próximo sub-capítulo falo especificamente sobre ele e sua convivência com o arquiteto.

    Agora, seguindo com o time cirúrgico proposto por Fred Brooks. O co-piloto que ele sugere é o ‘alter ego’ do cirurgião, capaz de executar qualquer tarefa atribuída à este. A única diferença é que o co-piloto seria menos experiente. Mas, ainda assim, funcionaria como um backup do cirurgião, inclusive representando-o em reuniões com outras equipes. Porém sua principal função é avaliar e discutir as idéias do programador-chefe. Lembra uma das práticas sugeridas pelo método conhecido como eXtreme Programming (XisPê – para os íntimos), a Pair Programming. A prática é polêmica e eu não disponho de dados que confirmem ou não as promessas de produtividade. Quero crer que a qualidade do código gerado realmente seja superior. Mas tenho algumas considerações que, por questão de tempo e espaço, tratarei em outra oportunidade.

    O ‘Administrador’ sugerido por Brooks é um tipo de Coordenador do Projeto. Apesar do cirurgião ter a palavra final em todas as questões, é o administrador que cuida do dia-a-dia da gestão financeira, de pessoal, suprimentos etc. Mais sobre o assunto no sub-capítulo seguinte.

    O ‘Editor’ é o responsável pela documentação. O cirurgião, segundo a proposta de Brooks, gera os documentos principais, tanto técnicos quanto aqueles para os usuários finais. Mas seria o editor o responsável pela compilação final, anexação de referências, bibliografia etc. É um luxo. Porém, ainda hoje brigamos para obter bons documentos de bons programadores, inutilmente.

    O ‘Bibliotecário’ – ‘escriturário’, ou program clerk, como sugerido por Brooks, não faz muito sentido nos dias de hoje. Mas parecia ser crucial nos tempos dos cartões perfurados e das intermináveis listas impressas em formulários contínuos. No entanto eu acredito que toda organização que esteja buscando o reuso de seus ativos de software, ou implantando uma SOA (Arquitetura Orientada a Serviços), demandará a presença de um bibliotecário, um especialista que em outro artigo eu chamei de GBA (Gestor da Biblioteca de Ativos).

    Se prestarmos atenção na complexidade dos atuais ambientes integrados de desenvolvimento (IDE’s – Integrated Development Environment), com seus frameworks, testes automáticos, integração com ferramentas de modelagem etc, veremos que pode fazer sentido o papel do ‘Almoxarife’, ou toolsmith, na nomenclatura original utilizada por Brooks. Um profissional especializado nas ferramentas e na sua adequação para cada tipo de projeto e função. Em equipes grandes ou em ‘fábricas’, parece ser uma função de grande utilidade.

    O ‘Testador’ é o nosso “Engenheiro de Testes”, uma função que aos poucos vai se tornando mais comum. Pena que muitos ainda o confundam com um ‘programador que não deu certo’. Teste é coisa séria, tanto que Brooks, como mostramos na 1ª parte desta série, dedicaria 50% do esforço de um projeto exclusivamente para ele.

    Por fim Brooks sugere a alocação de um ‘Advogado da Linguagem’. Creio que nossos espertíssimos e modernos IDE’s, nossos ‘testadores’ e, lógico, o arquiteto, eliminam a necessidade de um ‘language lawyer’. Advogado não, né?

    continua…

    ===

    1. Mills, H., “Chief Programmer teams, principles, and procedures”, IBM Federal Systems Division Report FSC 71-5108, Gaithersburg, Md., 1971.
    2. Artigo republicado em “Gestão do Conhecimento” (Harvard Business Review on Knowledge Management), Editora Campus, 2001.

  • Projetos SOA :: Novos & Velhos Desafios

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

  • [SOA # 8] – Processo de Gestão e Desenvolvimento

    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 :

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


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

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


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

  • [SOA # 7] – Os Projetos SOA

    Como apresentado anteriormente, uma iniciativa SOA deve ser conduzida como um Programa, um conjunto de projetos interdependentes. Mas se trata de um programa bastante particular já que a ligação entre os projetos, assim como ocorre com os serviços que formam uma SOA, deve ser fraca. Quer dizer, é fator crítico de sucesso de uma SOA que seus projetos não criem nenhum tipo de impedimento para a realização de outros.

    É natural que cada Serviço seja visto como um Projeto em si. O fato de ser uma tradução direta de um processo de negócio facilita a comunicação com as áreas usuárias. Mas como definir um Serviço?

    Normalmente as organizações e seus sistemas são vistos como estruturas hierárquicas. Departamentos são estruturados verticalmente, e os sistemas que os apóiam acabam se transformando em silos de informações. Mas os processos e atividades de negócio ocorrem horizontalmente, podendo envolver várias áreas e departamentos em sua realização completa. Um processo de venda, por exemplo, pode envolver os departamentos financeiro, almoxarifado e logística, além da própria área de vendas.

    No início dos anos 90 Michael Hammer e James Champy lançaram o livro “Reengenharia – Revolucionando a Empresa” , onde propunham a visualização da empresa como um conjunto de processos. Partiam do pressuposto que apenas uma visão completa e única dos processos poderia ajudar a organização na otimização destes e, conseqüentemente, na obtenção de vantagens competitivas. Hammer e Champy não criaram esta visão, mas a tornaram popular e presente nas agendas das mais diversas organizações.

    Apesar da “onda reengenharia” ter resultado em grandes desastres corporativos, a criação de uma visão da parte realmente dinâmica de uma corporação – seus processos – ainda é um fator de diferenciação no mundo dos negócios. Tanto que além da proposta SOA, outras tendências como BPM (Business Process Management) e BAM (Business Activity Monitoring) são fortemente baseadas nesta visão.

    Todo processo de negócio possui uma hierarquia . Ele é composto de sub-processos que são seqüências de atividades que por sua vez são divididas em duas ou mais tarefas. Voltando ao exemplo de um processo de venda, podemos dizer que a elaboração de uma proposta é um sub-processo; a logística de entrega é uma atividade; e a verificação do crédito do comprador é uma tarefa.

    Relacionando essa hierarquia com os tipos de Serviços existentes em uma SOA podemos dizer que os serviços Básicos representam as tarefas e atividades, enquanto os serviços dos tipos Processo e Público representam processos e sub-processos de negócio. Portanto, um programa SOA pode ser formado por projetos de portes bastante distintos.

    Além do desenvolvimento dos Serviços propriamente ditos há outro projeto em um programa SOA: o desenvolvimento e evolução da Infra-estrutura tecnológica que deve suportar a nova arquitetura. Esta infra-estrutura é composta pelo Repositório e pelo Bus de Serviços.

    Equipes de Projetos

    As equipes que executam os projetos SOA devem ser formadas a partir do modelo do Comitê Gestor. Uma formatação padrão teria as seguintes funções:


    Como será detalhado adiante um dos processos que serviu de base para este estudo foi o Scrum . Portanto a estrutura de equipe apresentada na figura acima reflete, de certa maneira, uma equipe padrão Scrum.

    O Dono do Serviço é equivalente ao Product Owner do Scrum, com algumas diferenças. Ele não é escolhido pelo Scrum Master, o Coordenador do Projeto da estrutura sugerida, e sim pelo Comitê Gestor. Ele deve ser um Arquiteto SOA e suas principais responsabilidades são: i) a Elaboração e Negociação do contrato do serviço com as áreas usuárias; ii) Transformação deste contrato em um Service (Product) Backlog, principal meio de controle e comunicação com o Coordenador e os Desenvolvedores alocados no projeto; e, iii) Gerencia o escopo e define as prioridades do projeto. É o Dono do Serviço que responde pelo projeto perante o Comitê Gestor e toda a organização.

    Já o Coordenador do Projeto equivale, em termos, ao Scrum Master. Ele é indicado pelo Engenheiro do Processo (PMO) que integra o Comitê Gestor. O Coordenador deve garantir que a equipe esteja respeitando o processo de desenvolvimento. E, como prega a metodologia Scrum, é responsável pela eliminação de qualquer impedimento que esteja impactando na performance da equipe.
    Visando facilitar a compreensão dos dois papéis acima, pouco comuns em equipes tradicionais de projetos, Jeff Sutherland apresentou uma feliz analogia com uma equipe de rally . Enquanto o Coordenador do Projeto (Scrum Master) é o “Piloto”, o Dono do Serviço (Product Owner) é o “Navegador”.

    O Analista de Negócio é nomeado pelo Arquiteto de Negócio para representar a equipe perante todas as áreas de negócio envolvidas com o serviço em questão. É ele quem captura os requerimentos e os transcreve de forma a facilitar a compreensão pela equipe de desenvolvimento. Assim como o Arquiteto de Negócio no comitê gestor, o Analista de Negócio deve defender e garantir a satisfação dos requerimentos pelo serviço desenvolvido.

    O grupo de Apoio é populado por integrantes que são alocados esporadicamente na equipe, visando atender necessidades específicas. Um representante do time de Infra-Estrutura Tecnológica pode ser alocado, por exemplo, para garantir que o Serviço será atendido pelos recursos computacionais existentes.

    O Gestor da Biblioteca de Ativos fará uso desta mesma estrutura quando o serviço se encontrar em estágio final de construção, visando sua Certificação (CQ – Controle de Qualidade) e preparação para Publicação, de acordo com o ciclo de vida estipulado no processo.

    Os Desenvolvedores são estruturados em dois grupos: Frontend Apps, que trata do desenvolvimento das interfaces para os usuários dos serviços; e Serviços, que é a implementação do serviço propriamente dito. Tal divisão deve fazer sentido na construção de praticamente todos os tipos de serviços, independente de seu porte. Como será apresentado a seguir, é uma boa prática que tais elementos sejam desenvolvidos em separado, dadas as consideráveis diferenças que existem entre eles e a necessidade de agilidade em sua construção.

    Considerações sobre as Estruturas Propostas

    É interessante notar que uma Equipe de Projeto é um tipo de instanciamento do Comitê Gestor. Assim como é fortemente sugerida a adoção de um Meta-Processo para o Programa que tenha o mesmo formato e atenda os mesmos padrões do Processo adotado para o desenvolvimento e gestão dos projetos, é salutar que as equipes de projetos SOA sejam uma representação (de certa forma abreviada) do Comitê Gestor. Percebem-se duas inequívocas vantagens neste enfoque:

    • Clara distribuição de responsabilidades que respeita, principalmente, as áreas de especialização; e
    • Formação de “Comunidades de Prática” , ou seja, profissionais são agrupados por área de interesse. A troca de conhecimentos pode se dar de maneira mais natural e freqüente.

    >>>>>>>>>> SOA #8 – Processo de Gestão e Desenvolvimento

    11. “Reengenharia – Revolucionando a Empresa”, Michael Hammer e James Champy
    Editora Campus (1994)
    12. “Aperfeiçoando Processos Empresariais”, H. James Harrington
    Makron Books (1993)
    13. “Agile Software Development Methods – Review and Analysis”, Pekka Abrahamsson, Outi Salo, Jussi Ronkainen e Juhani Warsta
    VTT (2002)
    14. “Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects”, Jeff Sutherland
    Artigo (2005)
    15. “Aprendizado Inter-Projetos”, Paulo F. Vasconcellos
    Artigo publicado em Out/2004.