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