Avaliação de Qualidade de Linha de Produto de Software baseada em Arquitetura e Métricas Prof. Dr. Edson A. Oliveira Junio...
Palestrante <ul><li>Edson A. Oliveira Junior </li></ul><ul><li>Vínculo Institucional: </li></ul><ul><ul><li>Prof. Adjunto ...
Agenda do Mini-curso <ul><li>Contextualização </li></ul><ul><li>Linha de Produto de Software (LPS) </li></ul><ul><ul><li>D...
Contextualização <ul><li>Desenvolvimento tradicional de software: </li></ul><ul><ul><li>um processo/método é realizado ger...
Contextualização <ul><li>Engenharia de domínio: </li></ul><ul><ul><li>Dá suporte ao desenvolvimento de software </li></ul>...
Contextualização <ul><li>Como é possível: </li></ul><ul><ul><li>aumentar a resusabilidade </li></ul></ul><ul><ul><li>dimin...
Contextualização <ul><li>Avaliação de Qualidade de software </li></ul><ul><ul><li>Como saber se um produto de software tem...
Linha de Produto de Software (LPS)
Linha de Produto de Software (LPS) <ul><li>Não é um assunto “novo” </li></ul><ul><li>Desenvolvimento customizado: </li></u...
Linha de Produção de H. Ford Ford T. (EUA) 1903
Linha de Produção de H. Ford Ford de Bigode (Brasil) 1908  (US$850)  – 1927  (US$290) <ul><li>Características: </li></ul><...
Linha de Produção de H. Ford Linha completa do Ford T. 5 Passageiros Carro de Passeio Totalmente Equipado 3 Passageiros To...
 
Linha de Produção <ul><li>Hoje encontramos linhas de produção para: </li></ul><ul><ul><li>Carros </li></ul></ul><ul><ul><l...
Objetivo de LPS <ul><li>Resumidamente, LPS visa estabelecer uma capacidade de produção que possa: </li></ul><ul><ul><li>Ra...
Alguns Número Reais sobre LPS <ul><li>Melhoria de Produtividade: ~10x </li></ul><ul><li>Aumento de Qualidade: ~10x </li></...
Casos de Sucesso de LPS <ul><li>Segundo o  Hall of Fame  do SEI: </li></ul><ul><ul><li>Overwatch Textron Systems </li></ul...
Linha de Produto de Software (LPS) <ul><li>Definições de LPS: </li></ul><ul><li>Termos importantes e sinônimos: </li></ul>...
Linha de Produto de Software (LPS) <ul><li>Sinônimos de LPS: </li></ul><ul><ul><li>Linha de Produção  (production line) </...
Linha de Produto de Software (LPS) <ul><li>LPS constitui uma forma prática de: </li></ul><ul><ul><li>Aumentar a  reutiliza...
Linha de Produto de Software (LPS) <ul><li>Custo e Esforço de Desenvolvimento </li></ul>
Linha de Produto de Software (LPS) <ul><li>Redução do  time to market </li></ul>
Outros Benefícios de LPS <ul><li>Redução do esforço de manutenção </li></ul><ul><li>Estimativa mais precisa de custos </li...
Características ( Features ) <ul><li>Conceito tem origem na Eng. de Domínio </li></ul><ul><li>“...capacidade do sistema qu...
Modelo de Características <ul><li>Representa a organização das características de forma hierárquica </li></ul><ul><li>Perm...
Exemplo de Modelo de Caract. (1)
Exemplo de Modelo de Caract. (2)
Exemplo de Modelo de Caract. (3) Media Management Mobile Media Delete Media Create Media View Photo Copy Media SMS Transfe...
Desenvolvimento de LPS <ul><li>Etapas principais: </li></ul><ul><ul><li>Engenharia de domínio: </li></ul></ul><ul><ul><ul>...
Desenvolvimento de LPS Modelo  Product Line Practice  – PLP (SEI) Engenharia de Domínio Engenharia de Aplicação Técnico e ...
Engenharia de Domínio Modelo  Product Line Practice  – PLP (SEI)
Engenharia de Aplicação Modelo  Product Line Practice  – PLP (SEI)
Abordagens de Desenvolvimento de LPS <ul><li>Pró-Ativa: </li></ul><ul><ul><li>Análise prévia dos possíveis produtos a part...
Principais Metodologias de LPS <ul><li>Feature-Oriented Development Analysis (FODA) </li></ul><ul><li>Product Line Practic...
Gerenciamento de Variabilidades <ul><li>Variabilidade é: </li></ul><ul><ul><li>“ ... a forma como os membros de uma famíli...
Gerenciamento de Variabilidades <ul><li>O gerenciamento de variabilidades está diretamente relacionado </li></ul><ul><ul><...
Principais Abordagens de Gerenciamento de Variabilidades <ul><li>Morisio et al. (2000): </li></ul><ul><ul><li>Estereótipos...
Representação de Variabilidades com  SMartyProfile
Gerenciamento de Variabilidades com  SMartyProcess
Representação de Variabilidades com  SMarty
Avaliação de LPS
Definições <ul><li>Avaliar: </li></ul><ul><ul><li>Elaborar um juizo de valor, qualitativo ou quantitativo, sobre uma ação ...
Avaliação de LPS <ul><li>Aspectos a considerar: </li></ul><ul><ul><li>[Arquitetura da LPS / Arquiteturas dos Produtos] +  ...
Avaliação de LPS <ul><li>Momento de Avaliar Arquitetura(s): </li></ul><ul><ul><li>Antes da concepção da Arquitetura da LPS...
Avaliação de LPS
Avaliação de LPS <ul><li>Técnicas Quantitativas: </li></ul><ul><ul><li>Elaboração de Cenários </li></ul></ul><ul><ul><li>Q...
Avaliação de LPS <ul><li>Panorama de Avaliação de LPS: </li></ul><ul><ul><li>Avaliação de Atributos de Qualidade de Arquit...
Avaliação de LPS <ul><li>Neste mini-curso focaremos a avaliação de LPS: </li></ul><ul><ul><li>qualitativa e quantitativa <...
Avaliação de LPS <ul><li>Avaliação de Arquitetura de LPS deve </li></ul><ul><ul><li>garantir que a arquitetura seja flexív...
Avaliação de LPS  Métodos de Avaliação de Arquitetura de LPs <ul><li>Durante a Eng. De Domínio: </li></ul><ul><ul><li>Fami...
Avaliação de LPS  Métodos de Avaliação de Arquitetura de LPs <ul><li>Arquiteturas de LPS Existentes: </li></ul><ul><ul><li...
Avaliação de LPS <ul><li>Métodos tradicionais de avaliação de arquitetura de software vem sendo usados para avaliar arquit...
Avaliação de LPS O Método ATAM <ul><li>Revelar como uma arquitetura de software satisfaz os seus atributos de qualidade </...
Avaliação de LPS O Método ATAM <ul><li>Decisões arquiteturais dependem de alcançar ou não os atributos de qualidade </li><...
Avaliação de LPS O Método ATAM <ul><li>Etapas do Método ATAM: </li></ul><ul><ul><li>Apresentação do método ATAM </li></ul>...
Avaliação de LPS O Método ATAM <ul><li>Árvore de utilidade   ( utility tree ) </li></ul><ul><ul><li>Relacionam as metas de...
Avaliação de LPS O Método ATAM <ul><li>Benefícios possíveis: </li></ul><ul><ul><li>Financeiro – economia de $$$ </li></ul>...
Avaliação de LPS Extensões do ATAM para Arq. de LPS <ul><li>Extended ATAM  (EATAM) </li></ul><ul><ul><li>Baseia-se em 4 et...
Avaliação de LPS Extensões do ATAM para Arq. de LPS
 
Avaliação de LPS Extensões do ATAM para Arq. de LPS <ul><li>Holistic Product Line Software Architecture Assessment  (HoPLS...
Avaliação de LPS Extensões do ATAM para Arq. de LPS Holistic Product Line Software Architecture Assessment  (HoPLSAA)
Avaliação de LPS <ul><li>Resumindo: </li></ul><ul><ul><li>Existem várias abordagens... </li></ul></ul><ul><ul><li>Existem ...
 
Avaliação de LPS <ul><li>Resposta: </li></ul><ul><ul><li>Não existe uma “receita de bolo”... </li></ul></ul><ul><ul><li>Fa...
Exemplo de Avaliação de LPS
Exemplo de Avaliação de LPS <ul><li>Será avaliada a LPS  Arcade Game Maker  (AGM): </li></ul><ul><ul><li>LPS de jogos do t...
Exemplo de Avaliação de LPS
Brickles
Pong
Bowling
Arcade Game Maker  (AGM) Modelo de Características <ul><li>Modelo de Características: </li></ul><ul><ul><li>Composto por 4...
Arcade Game Maker  (AGM) Modelo de Características
Arcade Game Maker  (AGM) Modelo de Casos de Uso <ul><li>Atores: </li></ul><ul><ul><li>GamePlayer </li></ul></ul><ul><ul><l...
Arcade Game Maker  (AGM) Modelo de Casos de Uso com Variabilidades
Arcade Game Maker  (AGM) Classes – Ativos Centrais
Arcade Game Maker  (AGM) Classes –  Bowling
Arcade Game Maker  (AGM) Classes –  Brickles
Arcade Game Maker  (AGM) Classes –  Pong
Arcade Game Maker  (AGM) Modelo de Classes com Variabilidades
Arcade Game Maker  (AGM) Arquitetura <ul><li>Formada por vários componentes: </li></ul><ul><ul><li>Game </li></ul></ul><ul...
Arcade Game Maker  (AGM) Arquitetura (Visão Lógica)
Descrição da Avaliação <ul><li>Deseja-se avaliar a arquitetura da LPS AGM: </li></ul><ul><ul><li>com base nos seus potenci...
Estratégia de Avaliação <ul><li>Etapa 1: Planejamento </li></ul><ul><ul><li>Definir/alocar artefatos que serão usados na a...
Estratégia de Avaliação
Planejamento: definição de artefatos <ul><li>Entradas: </li></ul><ul><li>Modelos da AGM </li></ul><ul><li>Atributos de Qua...
Definindo as Metas de Negócio Meta de Negócio Os jogos produzidos, em sua maioria, devem apresentar baixas taxas de comple...
Definindo as Metas de Negócio Meta de Negócio  (MN.1) Complexidade Manter o grau de complexidade dos jogos abaixo de 0.7 (...
Definindo os Cenários  (Complexidade)
Definindo os Cenários  (Extensibilidade)
Classificando os Cenários
Selecionando Atributos de Qualidade
Definindo as Questões Técnicas e Gerenciais
Definindo as Métricas para os A.Q.
 
 
 
 
 
 
 
Modelo GQM para a AGM
Gerando as Configurações AGM e Aplicando as Métricas
Realizando Análises de  Trade-Off <ul><li>Considerar as métricas coletadas </li></ul><ul><li>Analisar as estatísticas desc...
 
 
Análise da Estatística Descritiva Complexidade <ul><li>Análise Nro. 1: </li></ul><ul><ul><li>15 configurações (50%) possue...
 
 
Análise da Estatística Descritiva Extensibilidade <ul><li>Análise Nro. 2: </li></ul><ul><ul><li>15 configurações (50%) pos...
Conclusão Nro. 1 <ul><li>Não é possível dizer, com base na análise das estatísticas descritivas, qual A.Q. priorizar </li>...
 
Analisando os Produtos <ul><li>Os 3 produtos mais interessantes: </li></ul><ul><ul><li>Configuração 3: </li></ul></ul><ul>...
Considerações sobre a Avaliação <ul><li>Com a avaliação da Arquitetura da AGM foi possível: </li></ul><ul><ul><li>Prever o...
Considerações Finais
Considerações Finais <ul><li>Neste mini-curso foram apresentados: </li></ul><ul><ul><li>conceitos de LPS e Avaliação de LP...
Considerações Finais <ul><li>Análises de  Trade-Off  contribuem para: </li></ul><ul><ul><li>definir quais A.Q. podem ser c...
Referências <ul><li>Barbacci, M. R.; Clements, P.; Lattanze, A.; Northrop, L.; Wood, W. Using the Architecture Tradeo_ Ana...
Referências <ul><li>Chastek, G.; Ferguson, R. Toward Measures for Software Architectures. SEI Technical Note CMU/SEI-2006-...
Referências <ul><li>Dincel, E.; Medvidovic, N.; Hoek, A. v. d. Measuring Product Line Architectures. In: Proceedings of th...
Referências <ul><li>Etxeberria, L.; Sagardui, G. Evaluation of Quality Attribute Variability in Software Product Families....
Referências <ul><li>Geppert, B.; Weiss, D. M. Goal-Oriented Assessment of Product-Line Domains. In: Proceedings of the Int...
Referências <ul><li>Jensen, P. Experiences with Software Product Line Development. Crosstalk, v. 22, n. 1, p. 11-14, 2003....
Referências <ul><li>Lamine, S. B. A. B.; Jilani, L. L.; Ghezala, H. H. B. Cost Estimation for Product Line Engineering Usi...
Referências <ul><li>McGregor, J. D. Arcade Game Maker Product Line - Architecture Evaluation Report. 2005. </li></ul><ul><...
Referências <ul><li>Oliveira Junior, E. A.; Gimenes, I. M. S.; Huzita, E. H. M.; Maldonado, J. C. A Variability Management...
Referências <ul><li>Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S., “Empirical Validation of Complexity and E...
Referências <ul><li>Pohl, K.; Böckle, G.; Linden, F. J. v. d. Software Product Line Engineering: Foundations, Principles, ...
Referências <ul><li>SEI Hall of Fame. online, 2010c. Disponível em http://www.sei.cmu.edu/productlines/plp_hof.html  </li>...
Upcoming SlideShare
Loading in...5
×

Mini Curso Avaliação de Linha de Produto de Software

893

Published on

Mini-curso SBQS 2011 - Avaliação de Linha de Produto de Software baseada em Arquitetura e Métricas

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
893
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Mini Curso Avaliação de Linha de Produto de Software

  1. 1. Avaliação de Qualidade de Linha de Produto de Software baseada em Arquitetura e Métricas Prof. Dr. Edson A. Oliveira Junior Universidade Estadual de Maringá (UEM) Departamento de Informática (DIN) [email_address]
  2. 2. Palestrante <ul><li>Edson A. Oliveira Junior </li></ul><ul><li>Vínculo Institucional: </li></ul><ul><ul><li>Prof. Adjunto do Departamento de Informática (DIN) da UEM </li></ul></ul><ul><li>Contato: </li></ul><ul><ul><li>[email_address] ou www.edsonjr.pro.br </li></ul></ul><ul><li>Formação Acadêmica: </li></ul><ul><ul><li>Bacharel em Informática (2003) – UEM </li></ul></ul><ul><ul><li>Mestre em Ciência da Computação (2005) – UEM </li></ul></ul><ul><ul><li>Doutor em Ciências de Computação e Matemática Computacional (2010) – USP </li></ul></ul><ul><ul><li>Visiting Scholar na University of Waterloo , Canadá (2009) </li></ul></ul><ul><li>Área de Pesquisa: </li></ul><ul><ul><li>Engenharia de Software: </li></ul></ul><ul><ul><ul><li>Desenvolvimento baseado em Componentes e Frameworks </li></ul></ul></ul><ul><ul><ul><li>Linha de Produto de Software </li></ul></ul></ul><ul><ul><ul><li>Engenharia de Software Experimental </li></ul></ul></ul><ul><ul><ul><li>Modelagem UML e Metamodelos </li></ul></ul></ul><ul><ul><ul><li>Cloud Computing </li></ul></ul></ul><ul><ul><ul><li>Sistemas Embarcados Críticos </li></ul></ul></ul>
  3. 3. Agenda do Mini-curso <ul><li>Contextualização </li></ul><ul><li>Linha de Produto de Software (LPS) </li></ul><ul><ul><li>Definições </li></ul></ul><ul><ul><li>Desenvolvimento de LPS </li></ul></ul><ul><ul><li>Gerenciamento de variabilidades </li></ul></ul><ul><li>Avaliação de LPS </li></ul><ul><ul><li>Definições e tipos de avaliação </li></ul></ul><ul><ul><li>Principais abordagens de avaliação de LPS </li></ul></ul><ul><ul><li>Métodos relacionados à avaliação de LPS </li></ul></ul><ul><li>Exemplo de Avaliação de LPS </li></ul><ul><ul><li>Apresentação </li></ul></ul><ul><ul><li>Objetivos </li></ul></ul><ul><ul><li>Técnicas possíveis e métodos de análise </li></ul></ul><ul><ul><li>Definição de artefatos </li></ul></ul><ul><ul><li>Planejamento </li></ul></ul><ul><ul><li>Execução </li></ul></ul><ul><ul><li>Análise de dados e documentação </li></ul></ul><ul><li>Considerações Finais </li></ul>
  4. 4. Contextualização <ul><li>Desenvolvimento tradicional de software: </li></ul><ul><ul><li>um processo/método é realizado gerando um único produto de software  Ex. Unified Process </li></ul></ul><ul><ul><li>Todo o ciclo de vida se repete para um novo produto de software: Ex. Elaboração, Concepção, etc </li></ul></ul><ul><ul><li>Complexidade dos sistemas de software vem aumentando a cada ano  consequências: </li></ul></ul><ul><ul><ul><li>Número maior de horas de trabalho </li></ul></ul></ul><ul><ul><ul><li>Número maior de equipes de desenvolvimento </li></ul></ul></ul><ul><ul><ul><li>Re-trabalho </li></ul></ul></ul><ul><ul><ul><li>Cronogramas mais extensos </li></ul></ul></ul><ul><ul><ul><li>Aumento do time to market </li></ul></ul></ul><ul><ul><ul><li>Maior risco e maior custo </li></ul></ul></ul><ul><ul><ul><li>Pode provocar baixa reusabilidade </li></ul></ul></ul><ul><ul><ul><li>Insatisfação do(s) cliente(s) </li></ul></ul></ul>
  5. 5. Contextualização <ul><li>Engenharia de domínio: </li></ul><ul><ul><li>Dá suporte ao desenvolvimento de software </li></ul></ul><ul><ul><li>Permite identificar os requisitos comuns a um determinado domínio. Ex. de domínio? de requisitos? </li></ul></ul><ul><ul><li>Permite identificar variações em requisitos de um mesmo domínio. Exemplos? </li></ul></ul><ul><ul><li>Exige maior esforço (horas + pessoas) e conhecimento do domínio em questão </li></ul></ul><ul><ul><li>Adia decisões de projeto de acordo com o domínio </li></ul></ul><ul><ul><li>Aumenta a possibilidade de reutilização para produtos do mesmo domínio!?!? O que vocês acham? PQ? </li></ul></ul>
  6. 6. Contextualização <ul><li>Como é possível: </li></ul><ul><ul><li>aumentar a resusabilidade </li></ul></ul><ul><ul><li>diminuir esforço de produção </li></ul></ul><ul><ul><li>diminuir o tempo que o produto leva para chegar ao mercado </li></ul></ul><ul><ul><li>aumentar a qualidade do software </li></ul></ul><ul><ul><li>diminuir custos e aumentar o lucro </li></ul></ul><ul><li>Resp.: Equacionando… </li></ul><ul><li>Engenharia de Domínio + Desenvolvimento Tradicional </li></ul><ul><ul><li>+ Outras técnicas = n produtos = Linha de Produto de Software (LPS) </li></ul></ul>
  7. 7. Contextualização <ul><li>Avaliação de Qualidade de software </li></ul><ul><ul><li>Como saber se um produto de software tem a qualidade mínima necessária? </li></ul></ul><ul><ul><li>Quais técnicas podem ser aplicadas para verificar se um produto de software tem qualidade? </li></ul></ul><ul><li>Qualidade e Desenvolvimento Tradicional </li></ul><ul><ul><li>É possível verificar a qualidade de cada produto durante e após o seu desenvolvimento </li></ul></ul><ul><li>Qualidade e LPS </li></ul><ul><ul><li>Como saber se uma LPS tem a qualidade exigida? </li></ul></ul><ul><ul><ul><li>Verifica-se produto por produto ou a LPS como um todo? </li></ul></ul></ul><ul><ul><li>Quais técnicas podem ser aplicadas? </li></ul></ul>
  8. 8. Linha de Produto de Software (LPS)
  9. 9. Linha de Produto de Software (LPS) <ul><li>Não é um assunto “novo” </li></ul><ul><li>Desenvolvimento customizado: </li></ul><ul><ul><li>Ideia de Henry Ford </li></ul></ul><ul><ul><li>Produção de carros com equipamentos customizados (adicionais, acessórios) </li></ul></ul><ul><li>Linhas de produção e montagem </li></ul><ul><li>Produtos com características: </li></ul><ul><ul><li>Comuns </li></ul></ul><ul><ul><li>Variáveis </li></ul></ul>
  10. 10. Linha de Produção de H. Ford Ford T. (EUA) 1903
  11. 11. Linha de Produção de H. Ford Ford de Bigode (Brasil) 1908 (US$850) – 1927 (US$290) <ul><li>Características: </li></ul><ul><li>Pintura: “qualquer cor, desde que seja preta” (H. Ford) </li></ul><ul><li>- Bancos: veludo, tecido, couro </li></ul><ul><li>Carroceria: Pickup, Camionete, Cupês e Sedãs </li></ul><ul><li>Painel: Amperímetro e Odômetro </li></ul><ul><li>Opcionais: Faróis, Buzina </li></ul>
  12. 12. Linha de Produção de H. Ford Linha completa do Ford T. 5 Passageiros Carro de Passeio Totalmente Equipado 3 Passageiros Totalmente Equipado 2 Passageiros Conversível Totalmente Equipado 2 Passageiros 3 Lâmpadas de Óleo Kit de Ferramentas 2 Passageiros Estio Torpedo Totalmente Equipado 6 Passageiros 3 Lâmpadas de Óleo Kit de Ferramentas
  13. 14. Linha de Produção <ul><li>Hoje encontramos linhas de produção para: </li></ul><ul><ul><li>Carros </li></ul></ul><ul><ul><li>Produtos alimentícios (MacDonalds, Burger King, Pizza Hut...) </li></ul></ul><ul><ul><li>Relógios </li></ul></ul><ul><ul><li>Computadores (iMac, Vaio, Pavilion...) </li></ul></ul><ul><ul><li>Impressoras </li></ul></ul><ul><ul><li>SmartPhones </li></ul></ul><ul><ul><li>Aviões </li></ul></ul><ul><ul><li>Mais alguma?? </li></ul></ul><ul><ul><li>- Características Comuns e Variadas </li></ul></ul><ul><ul><li>- Possibilidade de Customização </li></ul></ul><ul><ul><li>- Desenvolvimento em Série </li></ul></ul>
  14. 15. Objetivo de LPS <ul><li>Resumidamente, LPS visa estabelecer uma capacidade de produção que possa: </li></ul><ul><ul><li>Rapidamente, e de forma correta, produzir múltiplos produtos com base em um contexto bem definido </li></ul></ul><ul><ul><li>Alcançar metas de negócio específicas que podem ser afetadas pela forma como uma organização produz seus produtos </li></ul></ul>
  15. 16. Alguns Número Reais sobre LPS <ul><li>Melhoria de Produtividade: ~10x </li></ul><ul><li>Aumento de Qualidade: ~10x </li></ul><ul><li>Redução de Custos: até 60% </li></ul><ul><li>Redução de mão de obra: até 87% </li></ul><ul><li>Redução do time to market : até 98% </li></ul>
  16. 17. Casos de Sucesso de LPS <ul><li>Segundo o Hall of Fame do SEI: </li></ul><ul><ul><li>Overwatch Textron Systems </li></ul></ul><ul><ul><li>Nokia </li></ul></ul><ul><ul><li>Philips Medical </li></ul></ul>
  17. 18. Linha de Produto de Software (LPS) <ul><li>Definições de LPS: </li></ul><ul><li>Termos importantes e sinônimos: </li></ul><ul><ul><li>Característica (feature) </li></ul></ul><ul><ul><li>Características comuns  similaridades </li></ul></ul><ul><ul><li>Segmento de mercado particular  domínio </li></ul></ul><ul><ul><li>Customização em massa  desenvolvimento em série </li></ul></ul><ul><ul><li>“ conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades específicas de um segmento de mercado particular ou missão , desenvolvidas a partir de ativos centrais comuns de maneira prescritiva ” </li></ul></ul>“ paradigma para desenvolver aplicações de software usando customização em massa e de plataforma ”
  18. 19. Linha de Produto de Software (LPS) <ul><li>Sinônimos de LPS: </li></ul><ul><ul><li>Linha de Produção (production line) </li></ul></ul><ul><ul><li>Família de Produtos ( product family ) </li></ul></ul><ul><ul><li>Família de Produção (production family) </li></ul></ul><ul><li>Sinônimo para Produto: </li></ul><ul><ul><li>Membro da família (family member) </li></ul></ul><ul><ul><li>Configuração de LPS </li></ul></ul><ul><li>Sinônimos para Ativos Centrais ( core assets ): </li></ul><ul><ul><li>Plataforma ( platform ) </li></ul></ul><ul><ul><li>Núcleo de Artefatos </li></ul></ul><ul><ul><li>Infraestrutura central (infrastructure) </li></ul></ul>
  19. 20. Linha de Produto de Software (LPS) <ul><li>LPS constitui uma forma prática de: </li></ul><ul><ul><li>Aumentar a reutilização </li></ul></ul><ul><ul><li>Diminuir o time to market </li></ul></ul><ul><ul><li>Reduzir custos e esforço de desenvolvimento </li></ul></ul><ul><ul><li>Melhor qualidade por conta da reutilização </li></ul></ul><ul><li>Reutilização de software: </li></ul><ul><ul><li>Subrotinas (anos 60) </li></ul></ul><ul><ul><li>Módulos (anos 70) </li></ul></ul><ul><ul><li>Objetos (anos 80) </li></ul></ul><ul><ul><li>Componentes (anos 90) </li></ul></ul><ul><ul><li>LPS (2000 em diante) </li></ul></ul>
  20. 21. Linha de Produto de Software (LPS) <ul><li>Custo e Esforço de Desenvolvimento </li></ul>
  21. 22. Linha de Produto de Software (LPS) <ul><li>Redução do time to market </li></ul>
  22. 23. Outros Benefícios de LPS <ul><li>Redução do esforço de manutenção </li></ul><ul><li>Estimativa mais precisa de custos </li></ul><ul><li>Retorno de investimento após a produção de poucos produtos </li></ul><ul><li>Contribui para a evolução da linha </li></ul><ul><li>Reduz a complexidade inerente </li></ul><ul><li>Cliente recebe produtos adaptados às suas necessidades </li></ul>
  23. 24. Características ( Features ) <ul><li>Conceito tem origem na Eng. de Domínio </li></ul><ul><li>“...capacidade do sistema que é relevante e visível para o usuário final...” </li></ul><ul><li>Podem ser: </li></ul><ul><ul><li>Obrigatórias </li></ul></ul><ul><ul><li>Alternativas (1..n) </li></ul></ul><ul><ul><li>Opcionais (0..1) </li></ul></ul>
  24. 25. Modelo de Características <ul><li>Representa a organização das características de forma hierárquica </li></ul><ul><li>Permite a identificação das primeiras variabilidades de uma LPS </li></ul><ul><li>Várias notações propostas </li></ul>
  25. 26. Exemplo de Modelo de Caract. (1)
  26. 27. Exemplo de Modelo de Caract. (2)
  27. 28. Exemplo de Modelo de Caract. (3) Media Management Mobile Media Delete Media Create Media View Photo Copy Media SMS Transfer Send Media Receive Media Sorting Favourites Basic Media Operations View Favourites Edit Media Label Media Selection Photo Music Video Play Music Play Video Album Management Create Album Delete Album
  28. 29. Desenvolvimento de LPS <ul><li>Etapas principais: </li></ul><ul><ul><li>Engenharia de domínio: </li></ul></ul><ul><ul><ul><li>Desenvolvimento de ativos centrais </li></ul></ul></ul><ul><ul><li>Engenharia de aplicação: </li></ul></ul><ul><ul><ul><li>Desenvolvimento do produto </li></ul></ul></ul><ul><ul><li>Gerenciamento: </li></ul></ul><ul><ul><ul><li>Técnico e Organizacional </li></ul></ul></ul>
  29. 30. Desenvolvimento de LPS Modelo Product Line Practice – PLP (SEI) Engenharia de Domínio Engenharia de Aplicação Técnico e Organizacional
  30. 31. Engenharia de Domínio Modelo Product Line Practice – PLP (SEI)
  31. 32. Engenharia de Aplicação Modelo Product Line Practice – PLP (SEI)
  32. 33. Abordagens de Desenvolvimento de LPS <ul><li>Pró-Ativa: </li></ul><ul><ul><li>Análise prévia dos possíveis produtos a partir das características estabelecidas </li></ul></ul><ul><ul><li>Desenvolve-se uma LPS “do início” </li></ul></ul><ul><li>Extrativa: </li></ul><ul><ul><li>LPS desenvolvida a partir de produtos existentes </li></ul></ul><ul><ul><li>As características para uma LPS são extraídas dos produtos existentes </li></ul></ul><ul><ul><ul><li>Tem-se a primeira release da LPS </li></ul></ul></ul><ul><li>Reativa: </li></ul><ul><ul><li>Desenvolvimento baseado em evolução da LPS </li></ul></ul><ul><ul><li>Ex.: Novas características são adicionadas </li></ul></ul>
  33. 34. Principais Metodologias de LPS <ul><li>Feature-Oriented Development Analysis (FODA) </li></ul><ul><li>Product Line Practice (PLP) </li></ul><ul><li>Feature-Oriented Reuse Method (FORM) </li></ul><ul><li>Family-Oriented Abstraction, Specification and Translation (FAST) </li></ul><ul><li>Product Line UML-based Software Engineering (PLUS) </li></ul><ul><li>Método de Klauss Pohl (2005) </li></ul>
  34. 35. Gerenciamento de Variabilidades <ul><li>Variabilidade é: </li></ul><ul><ul><li>“ ... a forma como os membros de uma família de produtos podem se diferenciar entre si...” </li></ul></ul><ul><ul><li>descrita por: </li></ul></ul><ul><ul><ul><li>pontos de variação – local específico em que uma decisão de projeto foi adiada </li></ul></ul></ul><ul><ul><ul><li>variantes – alternativas de projeto para instanciar uma determinada variabilidade </li></ul></ul></ul><ul><li>A representação explícita de variabilidade </li></ul><ul><ul><li>Torna possível a geração de produtos específicos de uma LPS </li></ul></ul>
  35. 36. Gerenciamento de Variabilidades <ul><li>O gerenciamento de variabilidades está diretamente relacionado </li></ul><ul><ul><li>a todas as atividades de desenvolvimento de LPS </li></ul></ul><ul><li>Principais atividades: </li></ul><ul><ul><li>Identificação de variabilidades </li></ul></ul><ul><ul><li>Delimitação de variabilidades (multiplicidade e tempo de resolução) </li></ul></ul><ul><ul><li>Rastreamento e Controle de variabilidades </li></ul></ul><ul><ul><li>Identificação de Mecanismos de Implementação </li></ul></ul><ul><ul><li>Análise e Configuração de Produtos </li></ul></ul>
  36. 37. Principais Abordagens de Gerenciamento de Variabilidades <ul><li>Morisio et al. (2000): </li></ul><ul><ul><li>Estereótipos <<V>> e <<xorV>> em classes </li></ul></ul><ul><li>Clauss (2001): </li></ul><ul><ul><li>Adiciona 2 estereótipos <<inclusive>> e <<exclusive>> em classes à abordagem de Morisio </li></ul></ul><ul><li>Gomaa (2005): </li></ul><ul><ul><li>Representação de variabilidade em casos de uso, classes e colaborações </li></ul></ul><ul><li>Korherr e List (2007): </li></ul><ul><ul><li>Perfil UML para classes e diagramas de atividades </li></ul></ul><ul><li>SMarty (2010): </li></ul><ul><ul><li>Perfil UML ( SMartyProfile ) para casos de uso, classes e componentes </li></ul></ul><ul><ul><li>Processo ( SMartyProcess ) e diretrizes para realizar as atividades de gerenciamento e aplicar o perfil UML </li></ul></ul><ul><li>Outras abordagens não-UML </li></ul><ul><ul><li>Notações particulares, não padronizadas, mas importantes </li></ul></ul>
  37. 38. Representação de Variabilidades com SMartyProfile
  38. 39. Gerenciamento de Variabilidades com SMartyProcess
  39. 40. Representação de Variabilidades com SMarty
  40. 41. Avaliação de LPS
  41. 42. Definições <ul><li>Avaliar: </li></ul><ul><ul><li>Elaborar um juizo de valor, qualitativo ou quantitativo, sobre uma ação </li></ul></ul><ul><ul><li>Estimar, aquilatar, aferir, apreciar </li></ul></ul><ul><li>Avaliação: </li></ul><ul><ul><li>Ato de avaliar, apreciação, estimativa </li></ul></ul><ul><li>Avaliador: </li></ul><ul><ul><li>Que avalia, apreciador </li></ul></ul><ul><li>Evaluation: </li></ul><ul><ul><li>To determine the value of; to assess </li></ul></ul><ul><li>Assessment: </li></ul><ul><ul><li>The act of determining an amount to be paid; an official evaluation of property, or income, for the purpose of taxation </li></ul></ul>
  42. 43. Avaliação de LPS <ul><li>Aspectos a considerar: </li></ul><ul><ul><li>[Arquitetura da LPS / Arquiteturas dos Produtos] + Atributos de qualidade </li></ul></ul><ul><ul><li>Momento em que a(s) Arquitetura(s) é(são) avaliada(s) </li></ul></ul><ul><ul><li>Técnicas qualitativas e/ou quantitativas a serem adotadas ou propostas </li></ul></ul>
  43. 44. Avaliação de LPS <ul><li>Momento de Avaliar Arquitetura(s): </li></ul><ul><ul><li>Antes da concepção da Arquitetura da LPS (Existing PA) </li></ul></ul><ul><ul><li>Durante a Eng. Domínio </li></ul></ul><ul><ul><li>Durante a Evolução da Arquitetura de LPS ( Evolution Related PLA ) </li></ul></ul><ul><ul><li>Durante a Instanciação dos Produtos ( During Derivation ) </li></ul></ul><ul><ul><li>Durante a Eng. Aplicação </li></ul></ul><ul><ul><li>Durante a Evolução da Arquitetura dos Produtos (Evolution Related PA) </li></ul></ul>
  44. 45. Avaliação de LPS
  45. 46. Avaliação de LPS <ul><li>Técnicas Quantitativas: </li></ul><ul><ul><li>Elaboração de Cenários </li></ul></ul><ul><ul><li>Questionários </li></ul></ul><ul><ul><li>Checklists </li></ul></ul><ul><li>Técnicas Quantitativas: </li></ul><ul><ul><li>Simulação </li></ul></ul><ul><ul><li>Prototipagem </li></ul></ul><ul><ul><li>Modelos Matemáticos e Experimentais </li></ul></ul><ul><ul><li>Métricas </li></ul></ul>
  46. 47. Avaliação de LPS <ul><li>Panorama de Avaliação de LPS: </li></ul><ul><ul><li>Avaliação de Atributos de Qualidade de Arquitetura de LPS </li></ul></ul><ul><ul><ul><li>Cenários, GQM, ATAM, SAAM, ADL, Casos de Uso </li></ul></ul></ul><ul><ul><li>Avaliação Estrutural de Arquitetura de LPS </li></ul></ul><ul><ul><ul><li>Métricas: tempo de resposta entre componentes, latência, utilização de CPU, tempo de execução, structural soundness (utilização de serviços de componentes individuais e da arquitetura) </li></ul></ul></ul><ul><ul><li>Definição e Avaliação de Contexto de LPS: </li></ul></ul><ul><ul><ul><li>Análise de riscos e benefícios, adoção de LP, melhoria no processo de desenvolvimento, manutenção de LP, modelos de custos e estimativas, análise de domínios candidatos </li></ul></ul></ul>
  47. 48. Avaliação de LPS <ul><li>Neste mini-curso focaremos a avaliação de LPS: </li></ul><ul><ul><li>qualitativa e quantitativa </li></ul></ul><ul><ul><li>por meio de sua arquitetura </li></ul></ul><ul><ul><li>com a aplicação de métricas para apoiar análises de trade-off de atributos de qualidade </li></ul></ul><ul><ul><li>Considerando os potenciais produtos da LPS </li></ul></ul>
  48. 49. Avaliação de LPS <ul><li>Avaliação de Arquitetura de LPS deve </li></ul><ul><ul><li>garantir que a arquitetura seja flexível o suficiente para suportar diferentes produtos e permitir a sua evolução </li></ul></ul><ul><li>Em LPS temos 2 níveis de abstração arquitetural: </li></ul><ul><ul><li>Arquitetura da LPS </li></ul></ul><ul><ul><li>Arquitetura de todos os produtos da LPS </li></ul></ul><ul><li>Avaliar a arquitetura de todos os possíveis produtos de uma LPS não é viável </li></ul><ul><ul><li>Porém, é possível avaliar uma amostra significativa dos produtos com relação à arquitetura de LPS </li></ul></ul>
  49. 50. Avaliação de LPS Métodos de Avaliação de Arquitetura de LPs <ul><li>Durante a Eng. De Domínio: </li></ul><ul><ul><li>Family Architecture Assessment Method (FAAM) </li></ul></ul><ul><ul><ul><li>Arquiteturas de LPS para de sistemas de informação </li></ul></ul></ul><ul><ul><li>Architecture Quality Analysis (AQA) </li></ul></ul><ul><ul><ul><li>Análise Qualitativa de Arquitetura de LPS </li></ul></ul></ul><ul><ul><li>Reliability Evaluation of Domain Architectures (REDA) </li></ul></ul><ul><ul><li>Distributed SAAM (D-SAAM) </li></ul></ul><ul><ul><ul><li>Variação do SAAM para arquiteturas de referência </li></ul></ul></ul>
  50. 51. Avaliação de LPS Métodos de Avaliação de Arquitetura de LPs <ul><li>Arquiteturas de LPS Existentes: </li></ul><ul><ul><li>Abordagem de Gannod e Lutz: </li></ul></ul><ul><ul><ul><li>Avaliação de requisitos funcionais e de qualidade </li></ul></ul></ul><ul><ul><li>Abordagem de Maccari </li></ul></ul><ul><ul><ul><li>Avaliar evolução </li></ul></ul></ul><ul><ul><li>Abordagem de Riva e Rosso </li></ul></ul><ul><ul><ul><li>Adaptação da abordagem de Maccari </li></ul></ul></ul><ul><li>Avaliação Específica de Variabilidade: </li></ul><ul><ul><li>Scenario-based Architecting (SBA) </li></ul></ul><ul><ul><ul><li>Quantifica potenciais benefícios de diferentes opções de arquiteturas com relação às variabilidades </li></ul></ul></ul>
  51. 52. Avaliação de LPS <ul><li>Métodos tradicionais de avaliação de arquitetura de software vem sendo usados para avaliar arquiteturas de LPS: </li></ul><ul><ul><li>Architecture Tradeoff Analysis Method (ATAM) </li></ul></ul><ul><ul><ul><li>Realiza análises de trade-off para priorizar atributos de qualidade e fornecer uma visão comportamental da arquitetura </li></ul></ul></ul><ul><ul><li>Software Architecture Analysis Method (SAAM) </li></ul></ul><ul><ul><ul><li>Compara duas ou mais arquiteturas de software com relação a alguns critérios pré-estabelecidos </li></ul></ul></ul>
  52. 53. Avaliação de LPS O Método ATAM <ul><li>Revelar como uma arquitetura de software satisfaz os seus atributos de qualidade </li></ul><ul><li>Identificar como atributos de qualidade interagem entre si </li></ul><ul><li>Pode ser aplicado em estágios iniciais de desenvolvimento </li></ul><ul><li>Pode ser aplicado em sistemas legados e sistemas em evolução </li></ul>
  53. 54. Avaliação de LPS O Método ATAM <ul><li>Decisões arquiteturais dependem de alcançar ou não os atributos de qualidade </li></ul><ul><ul><li>Para tanto, é necessário estabelecer previamente os atributos de qualidade, que são motivados pelas metas de negócio (business drivers ou business goals) </li></ul></ul><ul><li>As metas de negócio... </li></ul><ul><ul><li>... representam os objetivos de negócio que uma arquitetura de software deve atingir, com base nos seus atributos de qualidade. </li></ul></ul>
  54. 55. Avaliação de LPS O Método ATAM <ul><li>Etapas do Método ATAM: </li></ul><ul><ul><li>Apresentação do método ATAM </li></ul></ul><ul><ul><li>Apresentação das metas de negócio </li></ul></ul><ul><ul><li>Apresentação da arquitetura </li></ul></ul><ul><ul><li>Identificação das abordagens arquiteturais </li></ul></ul><ul><ul><li>Geração da árvore de utilidade dos A.Q. </li></ul></ul><ul><ul><li>Análise das abordagens arquiteturais (Fase 1) </li></ul></ul><ul><ul><li>Brainstorming e priorização de cenários </li></ul></ul><ul><ul><li>Análise das abordagens arquiteturais (Fase 2) </li></ul></ul><ul><ul><li>Apresentação dos resultados </li></ul></ul>
  55. 56. Avaliação de LPS O Método ATAM <ul><li>Árvore de utilidade ( utility tree ) </li></ul><ul><ul><li>Relacionam as metas de negócios aos atributos de qualidade por meio de cenários. </li></ul></ul><ul><li>Cenários ( scenarios ) </li></ul><ul><ul><li>Descreve brevemente a interação de um stakeholder com o sistema. </li></ul></ul><ul><li>Stakeholders </li></ul><ul><ul><li>Um indivíduo, equipe ou organização com interesse ou relacionado a um sistema. </li></ul></ul>
  56. 57. Avaliação de LPS O Método ATAM <ul><li>Benefícios possíveis: </li></ul><ul><ul><li>Financeiro – economia de $$$ </li></ul></ul><ul><ul><li>Preparação, documentação e entendimento do sistema </li></ul></ul><ul><ul><li>Captura do Rationale </li></ul></ul><ul><ul><li>Identificar erros arquiteturais antes da construção do sistema </li></ul></ul><ul><ul><li>Garante que a arquitetura satisfaz os cenários, A.Q. e metas de negócio estabelecidas </li></ul></ul><ul><ul><li>Torna a arquitetura mais flexível e geral </li></ul></ul><ul><ul><li>Reduz riscos </li></ul></ul>
  57. 58. Avaliação de LPS Extensões do ATAM para Arq. de LPS <ul><li>Extended ATAM (EATAM) </li></ul><ul><ul><li>Baseia-se em 4 etapas: </li></ul></ul><ul><ul><ul><li>Identifica os 4 A.Q. comuns à uma arquitetura de LPS: modificabilidade, portabilidade, escalabilidade e extensibilidade </li></ul></ul></ul><ul><ul><ul><li>Descobre as visões arquiteturais com base nos 4 A.Q. </li></ul></ul></ul><ul><ul><ul><li>Marca pontos de variação nos A.Q. com tags </li></ul></ul></ul><ul><ul><ul><li>Repete as etapas do ATAM para validar as arq. dos produtos </li></ul></ul></ul><ul><ul><li>Duas fases: </li></ul></ul><ul><ul><ul><li>Avaliação da arquitetura de LPS </li></ul></ul></ul><ul><ul><ul><li>Avaliação das arquiteturas dos produtos </li></ul></ul></ul>
  58. 59. Avaliação de LPS Extensões do ATAM para Arq. de LPS
  59. 61. Avaliação de LPS Extensões do ATAM para Arq. de LPS <ul><li>Holistic Product Line Software Architecture Assessment (HoPLSAA) </li></ul><ul><ul><li>Cobre avaliação de arquitetura de LPS e dos produtos </li></ul></ul><ul><ul><li>Assim como o EATAM, possui 2 estágios: </li></ul></ul><ul><ul><ul><li>Análise da arquitetura de LPS </li></ul></ul></ul><ul><ul><ul><li>Análise das arquiteturas dos produtos </li></ul></ul></ul><ul><ul><li>Focada em metas de negócio, contexto da LPS, similaridades e variabilidades para estabelecer cenários </li></ul></ul>
  60. 62. Avaliação de LPS Extensões do ATAM para Arq. de LPS Holistic Product Line Software Architecture Assessment (HoPLSAA)
  61. 63. Avaliação de LPS <ul><li>Resumindo: </li></ul><ul><ul><li>Existem várias abordagens... </li></ul></ul><ul><ul><li>Existem várias técnicas... </li></ul></ul><ul><ul><li>Existem vários momentos de avaliação... </li></ul></ul><ul><ul><li>Existem vários conceitos envolvidos... </li></ul></ul><ul><ul><li>Existem vários “exemplos” na literatura... </li></ul></ul><ul><ul><li>Existem muitos “silver bullets”... </li></ul></ul>Enfim, como avaliar uma LPS com relação à arquitetura?
  62. 65. Avaliação de LPS <ul><li>Resposta: </li></ul><ul><ul><li>Não existe uma “receita de bolo”... </li></ul></ul><ul><ul><li>Faz-se necessário: </li></ul></ul><ul><ul><ul><li>1. Definir o que se espera da avaliação (FINS): </li></ul></ul></ul><ul><ul><ul><ul><li>Quais (tipos de) resultados queremos? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Quais ativos se quer como saída? </li></ul></ul></ul></ul><ul><ul><ul><li>2.1 Analisar os recursos disponíveis: </li></ul></ul></ul><ul><ul><ul><ul><li>Quais stakeholders participarão? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Quais ativos serão usados? </li></ul></ul></ul></ul><ul><ul><ul><li>2.2 Definir como chegar aos resultados (MEIOS): </li></ul></ul></ul><ul><ul><ul><ul><li>Quais abordagens/técnicas serão consideradas/adaptadas/estendidas/propostas? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Como os stakeholders participarão? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Como os ativos serão usados? </li></ul></ul></ul></ul>
  63. 66. Exemplo de Avaliação de LPS
  64. 67. Exemplo de Avaliação de LPS <ul><li>Será avaliada a LPS Arcade Game Maker (AGM): </li></ul><ul><ul><li>LPS de jogos do tipo arcade para dispositivos móveis: </li></ul></ul><ul><ul><ul><li>Brickles , Pong e Bowling (~80 variações) </li></ul></ul></ul><ul><ul><li>Desenvolvida pelo Software Engineering Institute (SEI) </li></ul></ul><ul><ul><li>LPS pedagógica para o ensino de conceitos de LPS e experimentação </li></ul></ul><ul><ul><li>Fornece documentação completa e código fonte dos ativos centrais e dos jogos </li></ul></ul><ul><ul><li>Variabilidades representadas com UML (SMarty) </li></ul></ul>
  65. 68. Exemplo de Avaliação de LPS
  66. 69. Brickles
  67. 70. Pong
  68. 71. Bowling
  69. 72. Arcade Game Maker (AGM) Modelo de Características <ul><li>Modelo de Características: </li></ul><ul><ul><li>Composto por 4 características principais: </li></ul></ul><ul><ul><ul><li>services : define os serviços play , pause e save ; </li></ul></ul></ul><ul><ul><ul><li>rules : define regras seguidas pelos jogos; </li></ul></ul></ul><ul><ul><ul><li>action : ações necessárias para movimentação e colisões; e </li></ul></ul></ul><ul><ul><ul><li>configuration : configurações básicas dos ambientes e dos jogos. </li></ul></ul></ul>
  70. 73. Arcade Game Maker (AGM) Modelo de Características
  71. 74. Arcade Game Maker (AGM) Modelo de Casos de Uso <ul><li>Atores: </li></ul><ul><ul><li>GamePlayer </li></ul></ul><ul><ul><li>GameInstaller </li></ul></ul><ul><li>Casos de Uso: </li></ul><ul><ul><li>Play Selected Game </li></ul></ul><ul><ul><li>Play Bowling, Play Brickles e Play Pong </li></ul></ul><ul><ul><li>Install Game </li></ul></ul><ul><ul><li>Uninstall Game </li></ul></ul><ul><ul><li>Save Game </li></ul></ul><ul><ul><li>Save Score </li></ul></ul><ul><ul><li>Check Previous Best Score </li></ul></ul><ul><ul><li>Exit Game </li></ul></ul><ul><ul><li>Animation Loop </li></ul></ul><ul><ul><li>Initialization </li></ul></ul>
  72. 75. Arcade Game Maker (AGM) Modelo de Casos de Uso com Variabilidades
  73. 76. Arcade Game Maker (AGM) Classes – Ativos Centrais
  74. 77. Arcade Game Maker (AGM) Classes – Bowling
  75. 78. Arcade Game Maker (AGM) Classes – Brickles
  76. 79. Arcade Game Maker (AGM) Classes – Pong
  77. 80. Arcade Game Maker (AGM) Modelo de Classes com Variabilidades
  78. 81. Arcade Game Maker (AGM) Arquitetura <ul><li>Formada por vários componentes: </li></ul><ul><ul><li>Game </li></ul></ul><ul><ul><li>DBClient </li></ul></ul><ul><ul><li>Operating System </li></ul></ul><ul><ul><ul><li>DisplayDriver </li></ul></ul></ul><ul><ul><ul><li>MouseDriver </li></ul></ul></ul><ul><ul><ul><li>SoundDriver </li></ul></ul></ul><ul><ul><ul><li>KeyBoardDriver </li></ul></ul></ul><ul><li>Somente o componente Game é formado por classes com variabilidades identificadas </li></ul>
  79. 82. Arcade Game Maker (AGM) Arquitetura (Visão Lógica)
  80. 83. Descrição da Avaliação <ul><li>Deseja-se avaliar a arquitetura da LPS AGM: </li></ul><ul><ul><li>com base nos seus potenciais produtos </li></ul></ul><ul><ul><li>verificando se as metas de negócio estabelecidas são satisfeitas </li></ul></ul><ul><ul><li>por meio de análises de trade-off sobre os A.Q. </li></ul></ul><ul><ul><li>gerando resultados qualitativos e quantitativos </li></ul></ul><ul><ul><li>para que possam ser usados como parâmetro </li></ul></ul><ul><ul><ul><li>para avaliar a LPS como um todo </li></ul></ul></ul><ul><li>Avaliação apoiada por: </li></ul><ul><ul><li>ATAM, EATAM e HoPLSAA </li></ul></ul>
  81. 84. Estratégia de Avaliação <ul><li>Etapa 1: Planejamento </li></ul><ul><ul><li>Definir/alocar artefatos que serão usados na avaliação </li></ul></ul><ul><ul><ul><li>Atributos de qualidade, metas de negócio, cenários, questões a serem respondidas e métricas </li></ul></ul></ul><ul><li>Etapa 2: Coleta de Dados </li></ul><ul><ul><li>Gerar configurações de da arquitetura </li></ul></ul><ul><ul><li>Coletar dados e métricas sobre as configurações </li></ul></ul><ul><li>Etapa 3: Análise de Dados e Documentação </li></ul><ul><ul><li>Analisar os dados coletados quantitativa e qualitativamente </li></ul></ul><ul><ul><li>Documentar a avaliação </li></ul></ul>
  82. 85. Estratégia de Avaliação
  83. 86. Planejamento: definição de artefatos <ul><li>Entradas: </li></ul><ul><li>Modelos da AGM </li></ul><ul><li>Atributos de Qualidade: </li></ul><ul><li>- Complexidade </li></ul><ul><li>- Extensibilidade </li></ul><ul><li>Saídas: </li></ul><ul><li>- Metas de Negócio </li></ul><ul><li>Cenários </li></ul><ul><li>Questões Gerenciais e Técnicas </li></ul><ul><li>- Métricas (Básicas e de A.Q.) </li></ul>
  84. 87. Definindo as Metas de Negócio Meta de Negócio Os jogos produzidos, em sua maioria, devem apresentar baixas taxas de complexidade, assim como altas taxas de extensibilidade.
  85. 88. Definindo as Metas de Negócio Meta de Negócio (MN.1) Complexidade Manter o grau de complexidade dos jogos abaixo de 0.7 (70%), comparado a complexidade geral da ALP, para, pelo menos, 50% dos produtos produzidos. Meta de Negócio (MN.2) Extensibilidade Manter o grau de extensibilidade dos jogos acima de 0.75 (75%), comparado a extensibilidade geral da ALP, para, pelo menos, 50% dos produtos produzidos.
  86. 89. Definindo os Cenários (Complexidade)
  87. 90. Definindo os Cenários (Extensibilidade)
  88. 91. Classificando os Cenários
  89. 92. Selecionando Atributos de Qualidade
  90. 93. Definindo as Questões Técnicas e Gerenciais
  91. 94. Definindo as Métricas para os A.Q.
  92. 102. Modelo GQM para a AGM
  93. 103. Gerando as Configurações AGM e Aplicando as Métricas
  94. 104. Realizando Análises de Trade-Off <ul><li>Considerar as métricas coletadas </li></ul><ul><li>Analisar as estatísticas descritivas de cada métrica </li></ul><ul><li>Priorizar atributos de qualidade </li></ul>
  95. 107. Análise da Estatística Descritiva Complexidade <ul><li>Análise Nro. 1: </li></ul><ul><ul><li>15 configurações (50%) possuem valores de CompPLA menores ou iguais a 0,5895 </li></ul></ul><ul><ul><li>15 configurações (50%) possuem valores de CompPLA maiores que 0,5895 </li></ul></ul><ul><li>Questões: </li></ul><ul><ul><li>A MN.1 foi satisfeita? </li></ul></ul><ul><ul><li>Devemos priorizar complexidade em vez de extensibilidade? </li></ul></ul>
  96. 110. Análise da Estatística Descritiva Extensibilidade <ul><li>Análise Nro. 2: </li></ul><ul><ul><li>15 configurações (50%) possuem valores de ExtensPLA menores ou iguais a 0,7060 </li></ul></ul><ul><ul><li>15 configurações (50%) possuem valores de ExtensPLA maiores que 0,7060 </li></ul></ul><ul><li>Questões: </li></ul><ul><ul><li>A MN.2 foi satisfeita? </li></ul></ul><ul><ul><li>Devemos priorizar extensibilidade em vez de complexidade? </li></ul></ul>
  97. 111. Conclusão Nro. 1 <ul><li>Não é possível dizer, com base na análise das estatísticas descritivas, qual A.Q. priorizar </li></ul><ul><li>O que fazer então? Considerar ambos os A.Q. para o desenvolvimento e evolução da AGM? </li></ul><ul><li>Alternativa: </li></ul><ul><ul><li>Analisar os produtos individualmente </li></ul></ul><ul><ul><li>Identificar quais produtos são mais interessantes para a AGM  CompPLA < 0,7 e ExtensPLA > 0,75 </li></ul></ul><ul><ul><li>Definir qual A.Q. priorizar </li></ul></ul>
  98. 113. Analisando os Produtos <ul><li>Os 3 produtos mais interessantes: </li></ul><ul><ul><li>Configuração 3: </li></ul></ul><ul><ul><ul><li>CompPLA = 0,50 </li></ul></ul></ul><ul><ul><ul><li>ExtensPLa = 0,81 </li></ul></ul></ul><ul><ul><li>Configuração 9: </li></ul></ul><ul><ul><ul><li>CompPLA = 0,67 </li></ul></ul></ul><ul><ul><ul><li>ExtensPLa = 0,80 </li></ul></ul></ul><ul><ul><li>Configuração 25: </li></ul></ul><ul><ul><ul><li>CompPLA = 0,62 </li></ul></ul></ul><ul><ul><ul><li>ExtensPLa = 0,80 </li></ul></ul></ul><ul><li>ExtensPLA = ~0,80 </li></ul><ul><li>0,50 <= CompPLA <= 0,67 </li></ul>Priorizar Complexidade
  99. 114. Considerações sobre a Avaliação <ul><li>Com a avaliação da Arquitetura da AGM foi possível: </li></ul><ul><ul><li>Prever o comportamento de seus produtos </li></ul></ul><ul><ul><li>Estimar complexidade e extensibilidade </li></ul></ul><ul><ul><li>Identificar quais produtos devem ser desenvolvidos </li></ul></ul><ul><ul><li>Mostrar empiricamente que a arquitetura atende às metas de negócio estabelecidas </li></ul></ul><ul><ul><li>Preparar um ambiente para que futuras avaliações possam ser realizadas/replicadas </li></ul></ul><ul><li>É possível ainda com os resultados da avaliação: </li></ul><ul><ul><li>gerar versões diferentes da arquitetura da AGM e compará-las </li></ul></ul><ul><ul><li>aplicar um modelo de custos e estimativas de LPS, tendo como parâmetros: </li></ul></ul><ul><ul><ul><li>A.Q. priorizados [Complexidade] x metas de negócio, potenciais produtos, código fonte, métricas </li></ul></ul></ul>
  100. 115. Considerações Finais
  101. 116. Considerações Finais <ul><li>Neste mini-curso foram apresentados: </li></ul><ul><ul><li>conceitos de LPS e Avaliação de LPS </li></ul></ul><ul><ul><li>um exemplo de como avaliar uma LPS com base em arquitetura e métricas </li></ul></ul><ul><li>Existem várias abordagens e técnicas para avaliação de LPS </li></ul><ul><ul><li>a maioria permite somente análises qualitativas </li></ul></ul><ul><li>A aplicação de métricas para A.Q. é importante para prever o comportamento dos produtos: </li></ul><ul><ul><li>porém exigem validação teórica e empírica </li></ul></ul><ul><ul><li>devem ser compartilhadas em um repositório </li></ul></ul>
  102. 117. Considerações Finais <ul><li>Análises de Trade-Off contribuem para: </li></ul><ul><ul><li>definir quais A.Q. podem ser considerados como parâmetros para adoção de um modelo de custos de estimativas de LPS </li></ul></ul><ul><ul><li>Estimar os produtos mais interessantes para uma LPS </li></ul></ul><ul><ul><li>Economizar recursos no desenvolvimento e evolução de LPS </li></ul></ul><ul><li>Avaliação de LPS em geral: </li></ul><ul><ul><li>Atividade complexa </li></ul></ul><ul><ul><li>Exige vários recursos </li></ul></ul><ul><ul><li>Se bem planejada, se torna menos complexa a cada iteração/replicação </li></ul></ul><ul><ul><li>Se mal planejada, só desperdiça tempo e $$$ </li></ul></ul><ul><ul><li>Justifica o Retorno de Investimento (ROI) esperado </li></ul></ul>
  103. 118. Referências <ul><li>Barbacci, M. R.; Clements, P.; Lattanze, A.; Northrop, L.; Wood, W. Using the Architecture Tradeo_ Analysis Method (ATAM) to Evaluate the Software Architecture for a Product Line of Avionic Systems: a Case Study. Relatório Técnico CMU/SEI-2003-TN-012, Software Engineering Institute (SEI), Pittsburgh, USA, 2003. </li></ul><ul><li>Batory, D.; Johnson, C.; MacDonald, B.; Heeder, D. Achieving Extensibility Through Product-Lines and Domain-Specific Languages: a Case Study. ACM Transactions on Software Engineering Methodologies, v. 11, n. 2, p. 191-214, 2002. </li></ul><ul><li>Böckle, G.; Clements, P.; McGregor, J. D.; Muthig, D.; Schmid, K. Calculating ROI for Software Product Lines. IEEE Software, v. 21, n. 3, p. 23-31, 2004. </li></ul><ul><li>Briand, L.; Emam, K. E.; Morasca, S.; El, K.; Morasca, E. S. Theoretical and Empirical Validation of Software Product Measures. ISERN-95-03, International Software Engineering Research Network, 1995. </li></ul><ul><li>Brooks, A.; Daly, J.; Miller, J.; Roper, M.; Wood, M. Replication of Experimental Results in Software Engineering. Relatório Técnico ISERN-96-10, International Software Engineering Research Network, Germany, 1996. </li></ul>
  104. 119. Referências <ul><li>Chastek, G.; Ferguson, R. Toward Measures for Software Architectures. SEI Technical Note CMU/SEI-2006-TN-013, Software Engineering Institute (SEI), Pittsburgh, USA, 2006. </li></ul><ul><li>Chen, L.; Babar, M. A.; Ali, N. Variability Management in Software Product Lines: a Systematic Review. In: Proceedings of the Software Product Line Conference, Pittsburgh, PA, USA: Carnegie Mellon University, 2009, p. 81-90. </li></ul><ul><li>Clements, P.; Kazman, R.; Klein, M. Evaluating Software Architectures: Methods and Case Studies. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002b. </li></ul><ul><li>Clements, P.; Northrop, L. Software Product Lines: Practices and Patterns. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2001. </li></ul><ul><li>Corder, G. W.; Foreman, D. I. Nonparametric Statistics for Non-Statisticians: A Step-by-Step Approach. Boston, MA, USA: Wiley, 2009. </li></ul><ul><li>Deelstra, S.; Sinnema, M.; Bosch, J. Variability Assessment in Software Product Families. Information and Software Technology, v. 51, n. 1, p. 195-218, 2009. </li></ul>
  105. 120. Referências <ul><li>Dincel, E.; Medvidovic, N.; Hoek, A. v. d. Measuring Product Line Architectures. In: Proceedings of the International Workshop on Product Family Engineering, London, UK: Springer-Verlag, 2001, p. 346-352. </li></ul><ul><li>Dobrica, L.; Niemelä, E. A Survey on Software Architecture Analysis Methods. IEEE Transactions on Software Engineering, v. 28, n. 7, p. 638-653, 2002. </li></ul><ul><li>Dolan, T.; Weterings, R.; Wortmann, J. C. Stakeholder-Centric Assessment of Product Family Architecture. In: Proceedings of the International Workshop on Software Architectures for Product Families, London, UK: Springer-Verlag, 2000, p. 225-245. </li></ul><ul><li>Eskenazi, E. M.; Fioukov, A. V.; Hammer, D. K.; Obbink, H.; Pronk, B. Analysis and Prediction of Performance for Evolving Architectures. In: Proceedings of the EUROMICRO Conference, Washington, DC, USA: IEEE Computer Society, 2004, p. 22-31. </li></ul><ul><li>Etxeberria, L.; Sagardui, G. Product-Line Architecture: New Issues for Evaluation. In: Proceedings of the Software Product Line Conference, Berlin, Germany: Springer-Verlag, 2005, p. 174-185. </li></ul>
  106. 121. Referências <ul><li>Etxeberria, L.; Sagardui, G. Evaluation of Quality Attribute Variability in Software Product Families. In: Proceedings of the Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, Washington, DC, USA: IEEE Computer Society, 2008a, p. 255-264. </li></ul><ul><li>Etxeberria, L.; Sagardui, G. Variability Driven Quality Evaluation in Software Product Lines. In: Proceedings of the Software Product Line Conference, Washington, DC, USA: IEEE Computer Society, 2008b, p. 243-252. </li></ul><ul><li>Ferber, S.; Heidl, P.; Lutz, P. Reviewing Product Line Architectures: Experience Report of ATAM in an Automotive Context. In: Proceedings of the International Workshop on Software Product-Family Engineering, London, UK: Springer-Verlag, 2002, p. 364-382. </li></ul><ul><li>Figueiredo, F.; Figueiredo, A.; Ramos, A.; Teles, P. Estatística Descritiva e Probabilidades. São Paulo-SP: Escolar, 2007. </li></ul><ul><li>Gacek, C.; Anastasopoules, M. Implementing Product Line Variabilities. SIGSOFT Software Engineering Notes, v. 26, n. 3, p. 109-117, 2001. </li></ul><ul><li>Gannod, G. C.; Lutz, R. R. An Approach to Architectural Analysis of Product Lines. In: Proceedings of the International Conference on Software Engineering, New York, NY, USA: ACM, 2000, p. 548-557. </li></ul>
  107. 122. Referências <ul><li>Geppert, B.; Weiss, D. M. Goal-Oriented Assessment of Product-Line Domains. In: Proceedings of the International Symposium on Software Metrics, Washington, DC, USA: IEEE Computer Society, 2003, p. 180. </li></ul><ul><li>Gomaa, H. Designing Software Product Lines with UML: from Use Cases to Pattern-based Software Architectures. Boston, MA, USA: Addison-Wesley, 2005. </li></ul><ul><li>Gurp, J. V.; Bosch, J.; Svahnberg, M. On the Notion of Variability in Software Product Lines. In: Proceedings of the Working IEEE/IFIP Conference on Software Architecture, Washington, DC, USA: IEEE Computer Society, 2001, p. 45. </li></ul><ul><li>Halmans, G.; Pohl, K. Communicating the Variability of a Software-Product Family to Customers. Software and System Modeling, v. 2, n. 1, p. 15-36, 2003. </li></ul><ul><li>Harsu, M. A Survey of Product-Line Architectures. Relatório Técnico 23, Institute of Software Systems, Tampere University of Technology, Finland, 2001. </li></ul><ul><li>Hoek, A. v. d.; Dincel, E.; Medvidovic, N. Using Service Utilization Metrics to Assess the Structure of Product Line Architectures. In: Proceedings of the International Symposium on Software Metrics, Washington, DC, USA: IEEE Computer Society, 2003, p. 298-308. </li></ul>
  108. 123. Referências <ul><li>Jensen, P. Experiences with Software Product Line Development. Crosstalk, v. 22, n. 1, p. 11-14, 2003. </li></ul><ul><li>Kazman, R.; Bass, L. Categorizing Business Goals for Software Architectures. Relatório Técnico CMU/SEI-2005-TR-021, Software Engineering Institute (SEI), Pittsburgh, USA, 2005. </li></ul><ul><li>Kim, K.; Kim, H.; Kim, S.; Chang, G. A Case Study on SW Product Line Architecture Evaluation: Experience in the Consumer Electronics Domain. In: Proceedings of the International Conference on Software Engineering Advances, Washington, DC, USA: IEEE Computer Society, 2008a, p. 192-197. </li></ul><ul><li>Kim, T.; Ko, I. Y.; Kang, S. W.; Lee, D. H. Extending ATAM to Assess Product Line Architecture. In: Proceedings of the IEEE International Conference on Computer and Information Technology, USA: ACM Press, 2008b, p. 790-797. </li></ul><ul><li>Kitchenham, B.; Pfleeger, S. L.; Fenton, N. Towards a Framework for Software Measurement Validation. IEEE Transactions on Software Engineering, v. 21, n. 12, p. 929-944, 1995. </li></ul>
  109. 124. Referências <ul><li>Lamine, S. B. A. B.; Jilani, L. L.; Ghezala, H. H. B. Cost Estimation for Product Line Engineering Using COTS Components. In: Proceedings of the Software Product Line Conference, Berlin, Heidelberg: Springer-Verlag, 2005, p. 113-123. </li></ul><ul><li>Linden, F. J. v. d.; Bosch, J.; Kamsties, E.; Känsälä, K.; Krzanik, L.; Obbink, J. H. Software Product Family Evaluation. In: Proceedings of the International Workshop on Software Product-Family Engineering, Berlin, Heidelberg: Springer-Verlag, 2004, p. 352-369. </li></ul><ul><li>Linden, F. J. v. d.; Schmid, K.; Rommes, E. Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2007. </li></ul><ul><li>Lutz, R. R.; Gannod, G. C. Analysis of a Software Product Line Architecture: an Experience Report. Journal of Systems and Software, v. 66, n. 3, p. 253-267, 2003. </li></ul><ul><li>Maccari, A. Experiences in Assessing Product Family Software Architecture for Evolution. In: Proceedings of the International Conference on Software Engineering, New York, NY, USA: ACM Press, 2002, p. 585-592. </li></ul><ul><li>McCabe, T. J. A Complexity Measure. IEEE Transactions on Software Engineering, v. 2, n. 4, p. 308-320, 1976. </li></ul>
  110. 125. Referências <ul><li>McGregor, J. D. Arcade Game Maker Product Line - Architecture Evaluation Report. 2005. </li></ul><ul><li>McGregor, J. D.; Muthig, D.; Yoshimura, K.; Jensen, P. Successful Software Product Line Practices. IEEE Software, v. 27, n. 3, p. 16-21, 2010. </li></ul><ul><li>Montagud, S.; Abrahão, S. Gathering Current Knowledge About Quality Evaluation in Software Product Lines. In: Proceedings of the Software Product Line Conference, Pittsburgh, PA, USA: Carnegie Mellon University, 2009, p. 91-0100. </li></ul><ul><li>Niemelä, E.; Matinlassi, M.; Taulavuori, A. Practical Evaluation of Software Product Family Architectures. In: Proceedings of the Software Product Line Conference, Berlin, Heidelberg: Springer-Verlag, 2004, p. 130-145. </li></ul><ul><li>Nobrega, J.; Almeida, E.; Meira, S. InCoME: Integrated Cost Model for Product Line Engineering. In: Proceedings of the EUROMICRO Conference on Software Engineering and Advanced Applications, Washington, DC, USA: IEEE Computer Society, 2008, p. 27-34. </li></ul>
  111. 126. Referências <ul><li>Oliveira Junior, E. A.; Gimenes, I. M. S.; Huzita, E. H. M.; Maldonado, J. C. A Variability Management Process for Software Product Lines. In: Proceedings of the Conference of the Centre for Advanced Studies on Collaborative Research, Toronto, ON, Canada: IBM Press, 2005, p. 225-241. </li></ul><ul><li>Oliveira Junior, E. A.; Gimenes, I. M. S.; Maldonado, J. C. A Metric Suite to Support Software Product Line Architecture Evaluation. In: Proceedings of the Conferencia Latinoamericana de Informática, Santa Fé, Argentina, 2008, p. 489-498. </li></ul><ul><li>Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S. Uma Revisão Sistemática sobre Avaliação de Linha de Produto de Software. Relatório Técnico No. 310, Instituto de Ciências Matemáticas e de Computação (ICMC) - Universidade de São Paulo (USP), São Carlos, SP, Brasil, 2007. </li></ul><ul><li>Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S. Uma Revisão Sistemática sobre Avaliação de Linha de Produto de Software: Iteração Jan/2008 a Jul/2010. Relatório Técnico No. 355, Instituto de Ciências Matemáticas e de Computação (ICMC) - Universidade de São Paulo (USP), São Carlos, SP, Brasil, 2010. </li></ul>
  112. 127. Referências <ul><li>Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S., “Empirical Validation of Complexity and Extensibility Metrics for Software Product Line Architectures,” in 2010 Fourth Brazilian Symposium on Software Components, Architectures, and Reuse. Salvador-BA, Brasil: IEEE Computer Society, 2010, pp. 31–40. </li></ul><ul><li>Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S., “A Meta-Process to Support Trade-Off Analysis in Software Product Line Architecture” in Software Engineering & Knowledge Engineering Conference. Miami-FL, USA: IEEE Computer Society, 2010, (to appear) </li></ul><ul><li>Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S., “Systematic Management of Variability in UML-based Software Product Lines,” Journal of Universal Computer Science (J.UCS), vol. 16, no. 17, pp. 2374–2393, 2010. </li></ul><ul><li>Olumofin, F. A Holistic Method for Assessing Software Product Line Architectures. Saarbrucken, Germany, Germany: VDM Verlag, 2007. </li></ul><ul><li>Olumofin, F. G.; Misic, V. B. Extending the ATAM Architecture Evaluation to Product Line Architectures. In: Proceedings of the Working IEEE/IFIP Conference on Software Architecture, Washington, DC, USA: IEEE Computer Society, 2005, p. 45-56. </li></ul>
  113. 128. Referências <ul><li>Pohl, K.; Böckle, G.; Linden, F. J. v. d. Software Product Line Engineering: Foundations, Principles, and Techniques. Secaucus, NJ, USA: Springer-Verlag, 2005. </li></ul><ul><li>Rahman, A. Metrics for the Structural Assessment of Product Line Architecture. Dissertação de Mestrado, School of Engineering - Blekinge Institute of Technology, Sweden, 2004. </li></ul><ul><li>Schmid, K. An Assessment Approach to Analyzing Benefits and Risks of Product Lines. In: Proceedings of the International Computer Software and Applications Conference on Invigorating Software Development, Washington, DC, USA: IEEE Computer Society, 2001, p. 525-530. </li></ul><ul><li>Schmid, K.; Verlage, M. The Economic Impact of Product Line Adoption and Evolution. IEEE Software, v. 19, n. 4, p. 50-57, 2002. </li></ul><ul><li>Schneidewind, N. F. Methodology for Validating Software Metrics. IEEE Transactions on Software Engineering, v. 18, n. 5, p. 410-422, 1992. </li></ul><ul><li>SEI A Framework for Software Product Line Practice. online, 2010a. Disponível em http://www.sei.cmu.edu/productlines/frame_report/index.html </li></ul><ul><li>SEI Arcade Game Maker Pedagogical Product Line. online, 2010b. Disponível em http://www.sei.cmu.edu/productlines/ppl </li></ul>
  114. 129. Referências <ul><li>SEI Hall of Fame. online, 2010c. Disponível em http://www.sei.cmu.edu/productlines/plp_hof.html </li></ul><ul><li>Taylor, R. N.; Medvidovic, N.; Dashofy, E. M. Software Architecture: Foundations, Theory, and Practice. USA: John Wiley & Sons, 2009. </li></ul><ul><li>Zhang, H.; Jarzabek, S.; Yang, B. Quality Prediction and Assessment for Product Lines. In: Proceedings of the International Conference on Advanced Information Systems Engineering, Berlin, Heidelberg: Springer-Verlag, 2003, p. 681-695. </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×