finito

Tag: CBD

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