Porque Componentização e
Reuso não funcionaram...
pelo menos até agora!
Silvio Lemos Meira
www.cesar.org.br, [email protected]
Eduardo Santana de Almeida
www.cin.ufpe.br, [email protected]
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}
• working-faster savings:
•
8%
• working-smarter savings:
•
17%
• work-avoidance savings:
•
47%
Agenda
• Reuso de Software
• Desenvolvimento Baseado em
Componentes
• Reuso Sistemático de Software
• Casos de Sucesso e Falhas
• Mitos
• Inibidores
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...
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)
• Visão clássica de desenvolvimento
• SW = “Blocos” monolíticos
• Grande número de partes interrelacionadas
• 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 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 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 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
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, ‘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...
• pesquisa/desenvolvimento/evolução de
•
•
•
•
•
Domain Engineering
Component-Based Development
Repository Systems
Product Lines
...
• cujo principal objetivo é atingir...
Systematic 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”
William B. Frakes, 1994
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
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!...}
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”
Modelo Incremental para adoção
de Reuso
Reuse
enabled
business
Benefit
High reuse levels
Broader
coverage
Reduced
maintenance
costs
Reduced
Development
time
Systematic
Domainspecific
Architecture reuse
reuse
Managed
workproducts
Black box
code reuse
Code
leverage
None
Investment, experience
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.
2.
3.
Grass-roots {na engenharia}
Senior-Management Involvement
future markets and Tools
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”
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
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...
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
Reuso de Software:
Casos de Sucesso
e de Falhas...
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 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 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 Reuse
• FALHAS...
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 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 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 organization
Respostas 79
40
40
Média 1.8
Mediana 1
30
Desvio Padrão 1.0
19
13
20
6
10
1
0
Disagree
Agree
Somewhat
Agree
75% of respondents do not agree
even somewhat that CASE tools have promoted reuse
It’s more fun to write my own
software than to try to reuse
Respostas 104
50
44
Média 2.0
Mediana 2
40
31
Desvio Padrão 1.2
30
19
20
10
3
7
0
Disagree
Agree
Somewhat
Agree
72% of respondents do not have
The Not Invented Here (NIH) syndrome
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?
• 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 organization
40
38
Respostas 94
Média 2.3
30
Mediana 2
21
Desvio Padrão 1.3
17
20
9
10
9
0
Disagree
Agree
Somewhat
Agree
A common software development process has
promoted reuse across projects in our organiz...
Organizational reuse level
Requirements
Design
Code
Test plans
Test cases
User documentation
Correlation between reuse
levels and agreement that a
common software process
promotes reuse across
projects
0.24
0.40
0.24
0.31
0.34
0.15
Um processo de desenvolvimento comum promove
o reuso sobre projetos. Assim, ganhos em processos de
maturidade PODE refletir-se em ganhos de reuso
Legal problems inhibit reuse
Respostas 92
50
45
Média 2.0
Mediana 2
40
Desvio Padrão 1.2
30
18
20
20
5
10
4
0
Disagree
Agree
Somewhat
Para 68%, os problemas legais são irrelevantes
Agree
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.....
• 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...
• 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 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á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. AddisonWesley, 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á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 HewlettPackard, IEEE Software, 1995.
[Heineman, 2001] Heineman, G., T., Council, W., T. ComponentBased 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á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á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 …
[email protected]