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:
- Object Solutions
Grady Booch
Addison-Wesley (1996). - Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002). - Rapid Development
Steve McConnell
Microsoft Press (1996). - 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). - CMMI Performance Results
Exemplo de um caso específico (Boeing).
Carnegie Mellon / Software Engineering Institute (SEI). - 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). - Decline and Fall of the American Programmer
Edward Yourdon
Yourdon Press (1992). - 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…
