Porque Componentização e Reuso não funcionaram... pelo menos até agora!

1. Porque Componentização e Reuso não funcionaram...pelo menos até agora! Silvio Lemos Meira www.cesar.org.br, silvio@cesar.org.br Eduardo Santana de Almeida www.cin.ufpe.br, esa2@cin.ufpe.br

2. como aumentar a produtividade no desenvolvimento de software? • trabalhe mais rápido • automação, ambientes, ferramentas • substitua trabalho humano • trabalhe mais inteligentemente • melhore o(s) processo(s) • evite/reduza tarefas de pouco valor • EVITE O TRABALHO! • REUSE ARTEFATOS do CICLO DE VIDA • evite/reduza o desenvolvimento de artefatos específicos para cada projeto…

3. resultados: boehm {dod, 1999} • working-faster savings: • 8% • working-smarter savings: • 17% • work-avoidance savings: • 47%

4. Agenda • Reuso de Software • Desenvolvimento Baseado em Componentes • Reuso Sistemático de Software • Casos de Sucesso e Falhas • Mitos • Inibidores

5. Reuso de Software • “Software reuse is the use of existing software knowledge or artifacts to build new software artifacts” [Frakes, 1995] • Vantagens (em POTENCIAL) • MAIS Qualidade • MENOS Tempo de desenvolvimento • MENORES custos TOTAIS no ciclo de vida... implementação, testes... integração, documentação, manutenção... evolução...

6. Artefatos reusáveis [D’Souza, 1999] • Código compilado [fonte] • Casos de testes • Modelos e projetos: frameworks e padrões • Interface de usuário • Planos, estratégias e regras arquiteturais • ...

7. Desenvolvimento Baseado em Componentes (DBC)

8. Desenvolvimento Baseado em Componentes (DBC) • Visão clássica de desenvolvimento • SW = “Blocos” monolíticos • Grande número de partes inter-relacionadas • num mundo “integral” • ...um cenário em que DBC • “quebra” tais blocos {simplificar!}… • para reduzir complexidade e custo de desenvolvimento… • num mundo distribuído…

9. Componentes de Software • Definições Diversas/Divergentes • Bertrand Meyer [1999]: “a software element that must be usable by developers who are not personally known to the component’s author to build a project that was not foreseen by the component’s author.” • Visões de um componente • Elemento arquitetural • Elemento implementacional • Componente de negócio

10. Componentes de Software • Aspectos de um componente • Descrever ou realizar uma função específica • Estar em conformidade e prover um conjunto de interfaces definidas • Ter uma documentação adequada • Estar inserido no contexto de um modelo que oriente a composição deste componente com outros • Categorias [Williams, 2001] • Componentes GUI • Componentes de Serviços • Componentes do Domínio [Negócio]

11. Componentes de Software “Componentes reutilizáveis são artefatos autocontidos, claramente identificáveis, que descrevem ou realizam uma função específica e têm interfaces claras em conformidade com um dado modelo de arquitetura de software, documentação apropriada e um grau de reutilização definido.” Sametinger, 1997

12. Mass Produced Software Components, Doug McIlroy NATO Software Engineering Conf., Garmisch, Germany, 1968 a idéia NÃO é nova... http://cm.bell-labs.com/cm/cs/who/doug/components.txt

13. Mass Produced Software Components, ‘68 • McIlroy e a indústria de componentes: ...to see standard catalogues of routines, classified by precision, robustness, time-space performance, size limits, and binding time of parameters ...to apply routines in the catalogues to any one of a larger class of often quite different machines; to have confidence in the quality of the routines ...[I want] different types of routine in the catalogue that are similar in purpose to be engineered uniformly, so that two similar routines should be available with similar options and two options of the same routine should be interchangeable in situations indifferent to that option

14. Systematic Software Reuse De McIlroy até agora... • pesquisa/desenvolvimento/evolução de • Domain Engineering • Component-Based Development • Repository Systems • Product Lines • ... • cujo principal objetivo é atingir...

15. Systematic SoftwareReuse “Systematic Software Reuse is domain focused, based on a repeatable process, and concerned primarily with the reuse of higher level lifecycle artifacts, such as requirements, design, and subsystems” William B. Frakes, 1994

16. O caso da Hewlett-Packard Griss [94, 95] • Objetivos, 1980 • Reduzir time to market • Melhorar a produtividade dos desenvolvedores • Melhorar a qualidade do produto • 1990: Corporate Reuse Program • entender reuso de SW dentro da HP e de outras empresas • Metas • Empacotar o conhecimento adquirido • Desenvolver guidelines

17. Corporate Reuse Program • Constatações fundamentais • Gerenciamento é um fator crítico • Fatores não técnicossão extremamente importantes • {Administração deProjetos de SW énormalmenteconsiderada uma POST-NORMAL SCIENCE!...}

18. Corporate Reuse Program • Mitos quebrados: • “First step: To build a repository” • “Produce that product, and on the way, produce components too” • “Reuse requires using object technology” • “Reusable components are always slow, because its generalization” • “The need for such optimization makes reuse not worth the development effort” • “You should not even considerer systematic reuse until your organization is at level 3 in the Software Engineering Institute's Capability Maturity Model”

19. Modelo Incremental para adoção de Reuso Reuse enabled business Benefit High reuse levels Systematic Domain- specific reuse Broader coverage Architecture reuse Reduced maintenance costs Managed workproducts Blackbox code reuse Reduced Development time Code leverage None Investment, experience

20. O caso da Motorola Software Reuse at Motorola [Rebecca Joos, IEEE SW 94] Transição inicial: • Mudança hardware – software... • ...implicava em transformar engenharia de software numa prioridade para o negócio fases do plano de reuso: • Grass-roots {na engenharia} • Senior-Management Involvement • future markets and Tools

21. Primeira fase • Criação da força tarefa para reuso • Formada por líderes de cada setor da empresa • para... investigar e fazer recomendações sobre reuso na Motorola • Principais atividades • Educar e disseminar conhecimento sobre reuso • Definir métricas, prêmios,job descriptions • Duas abordagens de reuso • Reengenharia de análise, projeto e implementação para popular o repositório • “forward engineering”

22. Segunda e Terceira fases • Senior-Management Involvement • Relutância dos gerentes • altos custos iniciais e • baixo retorno de investimento (3+ anos) • CEO manteve a iniciativa • Mais uma vez, o problema foi mais cultural do que tecnológico • Terceira fase • ferramentas de automação

23. Problemas • descompasso • conhecimento vs. velocidade • educação para reuso • gerentes!... difícil, toma muito tempo... • gente! • voluntários demais... • conceitos e capacidadesdesiguais • era preciso educar/treinar mais...

24. Systematic Reuse – Fatores de Sucesso [Frakes, 1994] • Management • Measurement • Legal issues • Economics • “Componentes devem ser reusados mais de 13 vezes para recuperar o investimento...” [Favaro, 1991] • Design for reuse • Libraries http://www.fes.uwaterloo.ca/u/mbldemps/meth/pnsresearch/index.html

25. Reuso de Software: Casos de Sucessoe de Falhas...

26. Os Problemas [Rine, 1997] • Não existe um conjunto de fatores de sucesso comuns entre empresas • reuso É vantagem competitiva... • pouco incentivo para compartilhar lições • carência de DADOS • Estudos recentes: • Rine [1997] • Morisio [2002]

27. Rine [1997]– Success Factors for Software Reuse that are applicable across domains and businesses • Survey conduzido em 1995 • Determinar os fatores de sucesso para reuso de software em domínios de aplicação • Fatores de sucesso • Abordagens de linha de produto, Arquiteturas com interfaces padrão • Engenharia de domínio, Gerenciamento • Métodos, ferramentas • Reutilização de artefatos do ciclo de vida • Traceability

28. Morisio [2002]– Success and Failures Factors in Software Reuse • Conduzido durante 1994-1997 • Estudo empírico sobre empresas européias em processo de evolução • 24 projetos analisados ao longo do período • Fatores de sucesso • Introdução de processos de reuso • Modificação de processos visando o reuso • Gerenciamento • Fatores humanos • Software staff e Overall staff • Maturidade do processo

29. Morisio [2002]– Success and Failures Factors in Software Reuse • FALHAS...

30. Porque muitos programas de reuso falham? • [Griss, 1994]: • Tratamento de reuso como um problema de aquisição tecnológica • estratégias de reuso nos negócios são ruins • programas de reuso não são orientados ao mercado • Glass [1999]: • Existem poucos componentes que podem ser reusados {?...}

31. Morisio [2002]– Success and Failures Factors in Software Reuse • cerca de 1/3 dos projetos falhou • principais motivos: • Não introduzir processos específicos de reuso • Não modificar processos existentes que não consideravam reuso • Não considerar fatores humanos como parte do processo

32. Reuso de Software:os Mitos

33. Frakes [1995]– Sixteen Questions about Software Reuse • Pesquisa realizada em 1991/2 • 113 engenheiros de software, gerentes, pesquisadores • 28 empresas EUA, 1 EU

34. CASE tools promoted reuse across projects in our organization 40 Respostas 79 Média 1.8 Mediana 1 Desvio Padrão 1.0 19 13 6 1 75% of respondents do not agree even somewhat that CASE tools have promoted reuse

35. It’s more fun to write my own software than to try to reuse Respostas 104 Média 2.0 Mediana 2 Desvio Padrão 1.2 44 31 19 7 3 72% of respondents do not have The Not Invented Here (NIH) syndrome

36. EDUCAÇÃO e EXPERIÊNCIA... • Does reuse education influence reuse? • Comparando a educação em reuso, entre indivíduos… • os mais “informados” obtém maiores níveis de reuso de código e projeto • Does software engineering experience influence reuse? • Não foi identificada nenhuma correlação direta entre experiência e nível de reuso

37. Do recognition rewards increase reuse? • Algumas empresas pagam por assets colocados e recuperados do repositório mas… • Não foi identificada nenhuma correlação direta entre gratificações e nível de reuso

38. A common software development process has promoted reuse across projects in our organization 38 Respostas 94 Média 2.3 Mediana 2 Desvio Padrão 1.3 21 17 9 9

39. A common software development process has promoted reuse across projects in our organiz... Um processo de desenvolvimento comum promove o reuso sobre projetos. Assim, ganhos em processos de maturidade PODE refletir-se em ganhos de reuso

40. Legal problems inhibit reuse Respostas 92 Média 2.0 Mediana 2 Desvio Padrão 1.2 45 20 18 5 4 Para 68%, os problemas legais são irrelevantes

41. Does having a reuse repository improve code reuse? • analisando empresas com e sem repositórios • chegou-se à conclusão que… • ter um repositório não garante uma melhoria no nível de reuso

42. Reuso de Software – Inibidores

43. Porque ainda não decolou..... • Pesquisa conduzida pelo Software Engineering Institute (SEI) durante 1999-2000 [SEI, 2000] • Economistas, analistas industriais, gerentes e engenheiros de software • Análise de componentes de software • Visão técnica e de negócio

44. os inibidores são... • Carência de componentes disponíveis • para 30%... falta uma indústria • para 20%... faltam comps em domínios • Carência de padrões para tecnologia de componentes • 30% lembraram a instabilidade dos padrões de componentes • Carência de componentes certificados • Carência de métodos para CBSE

45. mesmo assim…

47. no cesar… ainda em fase inicial • reuso EXTERNO a projetos em SLOC • melhor caso: 69% • pior caso: 2% • média {MLOC…}: 17% {J2EE 12%} • ganho de produtividade MÉDIO • componentes WEB: 30% {0 – 50%} • REUSO de PROCESSO: 80 – 100% • METAs de REUSO/PRODUTIVIDADE • SLOC: ? {não importa…} • Esforço: 75% {melhor da NASA, MOT}

48. Referências Bibliográficas • [Brown, 1998] Brown, A., Wallnau, K.The Current State of CBSE,IEEE Software, Oct , 1998. • [CBSE, 2002] 5th ICSE Workshop on Component-Based Software Engineering, Benchmarks for Predictable Assembly, In conjunction with the 24th International Conference on Software Engineering, (ICSE), May, 2002. • [D’Souza, 1999] D’Souza, D., F., Wills, C., A.Objects, Components, and Frameworks with UML – The Catalysis Approach. Addison-Wesley, 1999. • [Favaro, 1991] Favaro, J. What Price Reusability? A Case Study, ADA Letters, Mar, 1991. • [Frakes, 1994] Frakes, W., B., Isoda, S.Success Factors of Systematic Software Reuse. IEEE Software, Sep, 1994. • [Frakes, 1995] Frakes, W., B., Fox, C., J.Sixteen Questions about Software Reuse. Communications of the ACM, June, 1995. • [Glass, 1999] Glass, R. Reuse: What’s wrong with this picture?, IEEE Software, Mar, 1998.

49. Referências Bibliográficas • [Griss, 1994] Griss, M. Software Reuse Experience at Hewlett-Packard, 16th International Conference on Software Engineering, (ICSE), May, 1994. • [Griss, 1995] Griss, M., Wosser, M. Making Reuse Work at Hewlett-Packard, IEEE Software, 1995. • [Heineman, 2001] Heineman, G., T., Council, W., T. Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley. 2001. • [ICSR, 2002]7th International Conference on Software Reuse (ICSR),Austin, Texas, USA. April 2002. • [Joos, 1994] Joos, R. Software Reuse at Motorola, IEEE Software, Sep, 1994. • [Lamers, 1986] Lamers, S. Programmers at Work, Microsoft Press, 1986.

50. Referências Bibliográficas • [Mehta, 2002] Mehta, A., Heineman, G., T. Evolving Legacy System Features into Fine-Grained Components, In 24th International Conference on Software Engineering (ICSE). ACM Press, 2002. • [Morisio, 2002] Morisio, M., Ezran, Tully, C. Success and Failure Factors in Software Reuse, IEEE Transactions on Software Engineering, Apr, 2002. • [Rine, 1997] Rine, D, C.Success Factors for Software Reuse that are applicable across Domains and Businesses, ACM symposium on Applied Computing, Mar, 1997. • [Sametinger, 1997] Sametinger, J.Software Engineering with Reusable Components. Springer-Verlag, 1997. • [SEI, 2000] Software Engineering Institute.Market Assessment of Component-Based Software Engineering, Technical Report, May, 2000. • [Visser, 1987] Visser, W. Strategies in Programming Programmable Controllers: A field study of Programmers, Workshop, 1987. • [WCOP, 2002]7th International Workshop on Component-Oriented Programming (WCOP)in conjunction with the 16th European Conference on Object-Oriented Programming (ECOOP), Málaga, Spain, 2002.