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 [1] 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 [2], 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 [3]. 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 [4], 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 [4]:
  • 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 [5], não há em propostas como o CMMI ou MPS.br [6] 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 [7]. 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 [5], 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).



Marcadores: , , , , ,

segunda-feira, 11 de dezembro de 2006 | | Compartilhe: Adicionar esta notícia no Linkk

neste post

 

Anonymous Anônimo disse:

É realmente muito maléfico os modelos CMMI e MPS.br não tratarem o reuso de software em seus processos (ou áreas de processo). Isso prova somente que esses modelos são apenas a materialização de um estágio inicial da maturidade em uma organização intensiva em software, isto é, uma empresa nível 5 do CMMI ou nível A do MPS.br na verdade está engatinhando em se tratando de melhoria de processos.

Felizmente, tem gente pensando nisso no mundo e exemplo disso são as normas NBR ISO/IEC 12207 (Definição de Processos do Ciclo de Vida de Software) e NBR ISO/IEC 15504-5 (Modelo para Melhoria e Avaliação de Processo de Software).

A ISO/IEC 15504-5 (que é baseada na ISO/IEC 12207) define um grupo de processos voltados ao reuso. São eles: Gerência de Ativos Reusáveis, Gerência do Programa de Reuso e Engenharia de Domínio.

Para mais informações:
- Silva, Leandro de Paula. Adaptação dos Processos do Grupo de Reuso da ISO/IEC 15504-5 para as Áreas de Processo do CMMI. Monografia de grauação, Lavras/MG, 2006.

- Arruda, Saulo. ISo/IEC 12207 Processos Fundamentais, Consultado em 12/12/2006.

- Iso/IEC 12207, Wikipedia. Consultado em: 12/12/2006.

 
 

Blogger Paulo Vasconcellos disse:

Meu caro Saulo,

agradeço muito sua colaboração. Tenho certeza de que as referências serão de muita utilidade em meus estudos.

Agradeço também os elogios e o link colocado em seu site - que, diga-se de passagem, é muito bom!

Abraços,

 
 

Anonymous Cristiano Schwening disse:

Boa Tarde,

A versão atual do MPS.BR já está incorporando um processo de reuso nos moldes das ISO 12207 e 15504.

A questão agora é se conseguiremos implementar o reuso nas empresas de software brasileiras... Se processo já é um tabu para elas o que dirão sobre reuso...

 
 

Blogger Paulo Vasconcellos disse:

Oi Cristiano,

Meu caro, se não falarmos sobre o "bolso", nada acontecerá. Por mais sentido que faça o reuso; por óbvio que ele seja, sua implantação não é nada fácil. Muito menos barata.

Não vejo outra forma de viabilizá-lo em uma empresa que não comece pelo estudo e comprometimento com objetivos financeiros, com o retorno sobre o investimento.

Grato pela participação.

Abraços

 

Qual é a sua opinião?

A T E N Ç Ã O

Esta é uma versão antiga do finito. Só é mantida aqui porque o Google ainda direciona algumas buscas para cá. E eu seria louco se simplesmente o desativasse, certo? Mas, por favor, não deixe de visitar o finito certo. Todo o conteúdo aqui disponível está lá também.
  • Catálogo de Serviços

  • Contato Imediato

    • My status

    Assine & Compartilhe

    Busca

    Technorati


  • Temas & Tags

  • Lista completa no del.icio.us
  • Últimos Posts

  • Créditos & Débitos