porque componentização e reuso não funcionaram... pelo menos até agora! silvio lemos meira ,...
Post on 19-Apr-2015
105 Views
Preview:
TRANSCRIPT
Porque Componentização e Reuso não funcionaram...pelo menos até agora!
Silvio Lemos Meirawww.cesar.org.br, silvio@cesar.org.br
Eduardo Santana de Almeidawww.cin.ufpe.br, esa2@cin.ufpe.br
como aumentar a produtividade no desenvolvimento de software?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…
resultados: boehm {dod, 1999}resultados: boehm {dod, 1999}• working-faster savings:
• 8%
• working-smarter savings:
• 17%• work-avoidance savings:
• 47%
AgendaAgenda
• Reuso de Software
• Desenvolvimento Baseado em
Componentes
• Reuso Sistemático de Software
• Casos de Sucesso e Falhas
• Mitos
• Inibidores
Reuso de SoftwareReuso 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...
Artefatos reusáveis [D’Souza, 1999]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
• ...
Desenvolvimento Baseado em Componentes (DBC)
Desenvolvimento Baseado em Componentes (DBC)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…
Componentes de SoftwareComponentes 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
Componentes de SoftwareComponentes 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]
Componentes de SoftwareComponentes de Software
“Componentes reutilizáveis são artefatos autocontidosautocontidos, claramente identificáveis, que descrevem ou realizam uma função específica e têm interfacesinterfaces claras em conformidade com um dado modelo de arquitetura de software, documentaçãodocumentação apropriada e um grau de reutilização definido.”
Sametinger, 1997
“Componentes reutilizáveis são artefatos autocontidosautocontidos, claramente identificáveis, que descrevem ou realizam uma função específica e têm interfacesinterfaces claras em conformidade com um dado modelo de arquitetura de software, documentaçãodocumentação apropriada e um grau de reutilização definido.”
Sametinger, 1997
a idéia NÃO é nova...a idéia NÃO é nova...
• Mass Produced Software Components, Doug McIlroy
• NATO Software Engineering Conf., Garmisch, Germany, 1968
http://cm.bell-labs.com/cm/cs/who/doug/components.txt
Mass Produced Software Components, ‘68Mass 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
De McIlroy até agora...De McIlroy até agora...• pesquisa/desenvolvimento/evolução de
• Domain Engineering
• Component-Based Development
• Repository Systems
• Product Lines
• ...
• cujo principal objetivo é atingir...
Systematic Software ReuseSystematic Software Reuse
Systematic Software Reuse
“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”
“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, 1994William B. Frakes, 1994
O caso da Hewlett-Packard Griss [94, 95]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 ProgramCorporate Reuse Program• entender reuso de SW dentro da HP e
de outras empresas• Metas
• Empacotar o conhecimento adquirido• Desenvolver guidelines
Corporate Reuse ProgramCorporate 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!...}
Corporate Reuse ProgramCorporate 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”
Modelo Incremental para adoção de ReusoModelo Incremental para adoção de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment, experience
Benefit
O caso da Motorola Software Reuse at Motorola [Rebecca Joos, IEEE SW 94] 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
Primeira fasePrimeira 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”
Segunda e Terceira fasesSegunda 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
ProblemasProblemas• 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...
Systematic Reuse – Fatores de Sucesso [Frakes, 1994] 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
• Librarieshttp://www.fes.uwaterloo.ca/u/mbldemps/meth/pnsresearch/index.html
Reuso de Software: Casos de Sucesso
e de Falhas...
Os Problemas [Rine, 1997]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]
Rine [1997] – Success Factors for Software Reuse that are applicable across domains and businessesRine [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
Morisio [2002] – Success and Failures Factors in Software ReuseMorisio [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
Morisio [2002] – Success and Failures Factors in Software ReuseMorisio [2002] – Success and Failures Factors in Software Reuse
• FALHAS...
Porque muitos programas de reuso falham?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 {?...}
Morisio [2002] – Success and Failures Factors in Software ReuseMorisio [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
Reuso de Software:os Mitos
Frakes [1995] – Sixteen Questions about Software ReuseFrakes [1995] – Sixteen Questions about Software Reuse
• Pesquisa realizada em 1991/2• 113 engenheiros
de software, gerentes, pesquisadores
• 28 empresas EUA, 1 EU
CASE tools promoted reuse across projects in our organizationCASE tools promoted reuse across projects in our organization
0
10
20
30
40
Disagree AgreeSomewhat
Agree
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 1.019
13
6
1
40
It’s more fun to write my own software than to try to reuseIt’s more fun to write my own software than to try to reuse
0
10
20
30
40
50
Disagree AgreeSomewhat
Agree
72% of respondents do not have The Not Invented Here (NIH) syndrome
Respostas 104
Média 2.0
Mediana 2
Desvio Padrão 1.2
44
31
19
37
EDUCAÇÃO e EXPERIÊNCIA...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
Do recognition rewards increase reuse?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
A common software development process has promoted reuse across projects in our organizationA common software development process has promoted reuse across projects in our organization
0
10
20
30
40
Disagree AgreeSomewhat
Agree
Respostas 94
Média 2.3
Mediana 2
Desvio Padrão 1.3
38
2117
9 9
A common software development process has promoted reuse across projects in our organiz...A common software development process has promoted reuse across projects in our organiz...
Um processo de desenvolvimento comum promoveo reuso sobre projetos. Assim, ganhos em processos de maturidade PODE refletir-se em ganhos de reuso
Organizational reuse level Correlation between reuse levels and agreement that a common software process promotes reuse across projects
Requirements 0.24
Design 0.40
Code 0.24
Test plans 0.31
Test cases 0.34
User documentation 0.15
Legal problems inhibit reuseLegal problems inhibit reuse
0
10
20
30
40
50
Disagree AgreeSomewhat
Agree
Para 68%, os problemas legais são irrelevantes
Respostas 92
Média 2.0
Mediana 2
Desvio Padrão 1.2
45
1820
5 4
Does having a reuse repository improve code reuse?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
Reuso de Software – Inibidores
Porque ainda não decolou.....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
os inibidores são...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
mesmo assim…
no cesar… ainda em fase inicialno 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}
Referências BibliográficasReferê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.
Referências BibliográficasReferê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.
Referências BibliográficasReferê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.
Referências BibliográficasReferê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, 2000.
• [Williams, 2001] Williams, J. The Business Case for Components, In Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley, 2001.
Obrigado
Contato …esa2@cin.ufpe.br
top related