A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Porque Componentização e Reuso não funcionaram... pelo menos até agora! Silvio Lemos Meira Eduardo Santana de Almeida.

Apresentações semelhantes


Apresentação em tema: "Porque Componentização e Reuso não funcionaram... pelo menos até agora! Silvio Lemos Meira Eduardo Santana de Almeida."— Transcrição da apresentação:

1 Porque Componentização e Reuso não funcionaram... pelo menos até agora! Silvio Lemos Meira Eduardo Santana de Almeida

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 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 autocontidos interfaces documentação “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 autocontidos interfaces documentação “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 a idéia NÃO é nova... Mass Produced Software Components, Doug McIlroy NATO Software Engineering Conf., Garmisch, Germany, 1968

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 De McIlroy até agora... pesquisa/desenvolvimento/evolução de Domain Engineering Component-Based Development Repository Systems Product Lines... cujo principal objetivo é atingir... Systematic Software Reuse

15 “ 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 Corporate Reuse Program 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écnicos são extremamente importantes {Administração de Projetos de SW é normalmente considerada 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 None Code leverage Black box code reuse Managed workproducts Architecture reuse Systematic Domain- specific reuse Reduced Development time Reduced maintenance costs Broader coverage High reuse levels Reuse enabled business Investment, experience Benefit

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: 1. Grass-roots {na engenharia} 2. Senior-Management Involvement 3. 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 capacidades desiguais 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

25 Reuso de Software: Casos de Sucesso e 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 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 75% of respondents do not agree even somewhat that CASE tools have promoted reuse Respostas 79 Média 1.8 Mediana 1 Desvio Padrão

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

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 Respostas 94 Média 2.3 Mediana 2 Desvio Padrão

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 Organizational reuse levelCorrelation between reuse levels and agreement that a common software process promotes reuse across projects Requirements0.24 Design0.40 Code0.24 Test plans0.31 Test cases0.34 User documentation0.15

40 Legal problems inhibit reuse Para 68%, os problemas legais são irrelevantes Respostas 92 Média 2.0 Mediana 2 Desvio Padrão

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 [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…

46

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, [CBSE, 2002] 5th ICSE Workshop on Component-Based Software Engineering, Benchmarks for Predictable Assembly, In conjunction with the 24 th International Conference on Software Engineering, (ICSE), May, [D’Souza, 1999] D’Souza, D., F., Wills, C., A. Objects, Components, and Frameworks with UML – The Catalysis Approach. Addison- Wesley, [Favaro, 1991] Favaro, J. What Price Reusability? A Case Study, ADA Letters, Mar, [Frakes, 1994] Frakes, W., B., Isoda, S. Success Factors of Systematic Software Reuse. IEEE Software, Sep, [Frakes, 1995] Frakes, W., B., Fox, C., J. Sixteen Questions about Software Reuse. Communications of the ACM, June, [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, 16 th International Conference on Software Engineering, (ICSE), May, [Griss, 1995] Griss, M., Wosser, M. Making Reuse Work at Hewlett- Packard, IEEE Software, [Heineman, 2001] Heineman, G., T., Council, W., T. Component- Based Software Engineering: Putting the Pieces Together, Addison-Wesley [ICSR, 2002] 7 th International Conference on Software Reuse (ICSR), Austin, Texas, USA. April [Joos, 1994] Joos, R. Software Reuse at Motorola, IEEE Software, Sep, [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, [Morisio, 2002] Morisio, M., Ezran, Tully, C. Success and Failure Factors in Software Reuse, IEEE Transactions on Software Engineering, Apr, [Rine, 1997] Rine, D, C. Success Factors for Software Reuse that are applicable across Domains and Businesses, ACM symposium on Applied Computing, Mar, [Sametinger, 1997] Sametinger, J. Software Engineering with Reusable Components. Springer-Verlag, [SEI, 2000] Software Engineering Institute. Market Assessment of Component-Based Software Engineering, Technical Report, May, [Visser, 1987] Visser, W. Strategies in Programming Programmable Controllers: A field study of Programmers, Workshop, [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.

51 Referências Bibliográficas [Werner, 2000] Werner, C.; Braga, R. Desenvolvimento Baseado em Componentes, In XVI Simpósio Brasileiro de Engenharia de Software, Minicursos, João Pessoa, Paraíba, [Williams, 2001] Williams, J. The Business Case for Components, In Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley, 2001.

52 Obrigado Contato …

53


Carregar ppt "Porque Componentização e Reuso não funcionaram... pelo menos até agora! Silvio Lemos Meira Eduardo Santana de Almeida."

Apresentações semelhantes


Anúncios Google