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

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

Software Product Lines

Apresentações semelhantes


Apresentação em tema: "Software Product Lines"— Transcrição da apresentação:

1 Software Product Lines
Geovane Nogueira Lima Prof. Jacques Robin

2 Agenda Introdução Product Line: Conceitos
O que é Porque Como Conclusão A Framework for Software Product Line Practice Relação entre CMMI and Framework for Software Product Line Practice PuLSE Introdução Product Line: Conceitos O que é Porque Como Conclusão A Framework for Software Product Line Practice Relação entre CMMI and Framework for Software Product Line Practice PuLSE

3 Universal Business Goals

4 The Ultimate Universal Goal

5 Uma Alternativa Poucos sistemas são realmente exclusivos ...
Muitas organizações produzem famílias de produtos similares, diferenciados por algumas características.

6 Nokia Celulares Linha de produto com 25-30 novos produtos por ano!
Variando o número de teclas Variando tamanho do display Variando um conjunto de características Múltiplos protocolos Características configuráveis 58 linguagens suportadas 130 países atendidos

7 Product Line: Conceitos
Introdução Product Line: Conceitos O que é Porque Como Conclusão A Framework for Software Product Line Practice Relação entre CMMI and Framework for Software Product Line Practice PuLSE

8 O que são Linhas de Produto de Software?
“ Uma linha de produto de software é um conjunto de sistemas que usam software intensivamente, compartilhando um conjunto de características comuns e gerenciáveis, que satisfazem as necessidades de um segmento particular de mercado ou missão, e que são desenvolvidos a partir de um conjunto comum de ativos principais e de uma forma preestabelecida” Paulo Clements e Linda Northrop

9

10 Termos de destaque: Segmento particular de mercado:
A definição de um domínio de atuação é fundamental para que a linha traga o retorno esperado. Uma linha deve estipular uma área de atuação para usufruir do reuso. Conjunto comum de ativos: Corresponde ao repositório de elementos necessários para o desenvolvimento dos produtos. Esses elementos são componentes de software e artefatos de processo que podem ser desenvolvidos, comprados ou extraído de produtos legados; Forma preestabelecida: Os planos de produção são os esqueletos de cada produto; indica os passos, ferramentas, modelos e ativos que serão usados em cada produto

11 Software Product Line Product Line
Obter vantagem econômicas da similaridade Aproveitar a variabilidade

12 Como Product Line pode Ajudar?
Product line amortiza o seu investimento e de outros ativos: Requisitos e Análise de requisitos Domain model Arquitetura e projeto de software Construção Documentação Plano de teste, caso de teste Pessoas: Seu conhecimento e habilidade Processo, Metodologias, e Ferramentas Componentes

13 Os conceitos chaves de um Uso de uma Determinado repositório
conjunto de produto Uso de uma repositório comum de ativos Na Produção Arquitetura Plano de Produção Definição de Escopo, Business Case

14 Definição Software Product Lines não são:
Reutilização oportuna de código em pequena escala; Desenvolvimento de um projeto com re-uso; Arquitetura Re-configurável (O.O.); Desenvolvimento baseado em componentes;

15 Definição Product Lines é:
“Product Lines envolve estratégia, reuso planejado que produza resultados esperados.” Paulo Clements e Linda Northrop

16 As Três Atividades Essenciais:
Em sua essência o modelo de Linhas de Produto envolve desenvolver os ativos principais, desenvolver o(s) produto(s) utilizados os ativos e isso sempre de uma maneira tecnicamente e organizacionalmente gerenciada. Desenvolvimento de Ativos de Produto Gerenciamento

17 Desenvolvimento de Ativos
Os ativos principais (core assets) correspondem aos itens reutilizáveis dispostos no repositório da Product Line. Os itens mais importantes nesse processo são: O escopo da Product Line, Os ativos em si, O plano de produção, composto da reunião dos processos anexos (attached processes).

18 desenvolvimento dos ativos principais
Atividade iterativa. As flechas rotativas indicam que não há um ponto de entrada específico, não há uma relação causal única entre as saídas e entradas.

19 Desenvolvimento do Produto
Requisitos de um produto em particular (delta / variação); O escopo da Product Line, julgando se o produto é compatível ou não; Os ativos principais; O Plano de Produção detalhando a utilização dos ativos principais.

20 Gerência Uma gerência adequada interfere diretamente
no sucesso ou fracasso final da Product Line. Prover recurso Coordenar e supervisionar Prover treinamento Recompensar os empregado apropriadamente Gerenciar interfaces externas Criar e implementar um plano de adoção para a Product Line

21 A Framework Introdução Product Line: Conceitos
O que é Porque Como Conclusão A Framework for Software Product Line Practice Relação entre CMMI e Framework for Software Product Line Practice PuLSE

22 A Framework for Software Product Line Practice
Existem três grandes áreas onde as atividades envolvidas na criação e manutenção de Software Produt Line estão agrupadas: Software Engineer (SEPA) Technical management (TMPA) Organizational Management (OMPA)

23 Software Engineer Practice Areas (SEPA)
São atividades necessárias para aplicar as tecnologias apropriadas à criação e evolução dos ativos principais e dos produtos. Áreas: • Architecture Definition • Architecture Evaluation • Component Development • COTS Utilization • Mining Existing Assets • Requirements Engineering • Software System Integration • Testing • Understanding Relevant Domains

24 Relacionamento entre as Practice Areas

25 Practice Area Relationships

26 Technical Management Practice Areas (TMPA)
São atividades referentes as práticas de gerenciamento necessárias para estabelecer a criação e evolução dos ativos principais e do produto.. Áreas: • Configuration Management • Data Collection, Metrics, and Tracking • Make/Buy/Mine/Commission Analysis • Process Definition • Scoping • Technical Planning • Technical Risk Management • Tool Support

27 Organizational Management Practice Areas (OMPA)
São atividades referentes as práticas de gerenciamento estratégico para obter máxima vantagens da capacidade da Product Line... Áreas: • Building a Business Case • Customer Interface Management • Developing an Acquisition Strategy • Funding • Launching and Institutionalizing • Market Analysis • Operations • Organizational Planning • Organizational Risk Management • Structuring the Organization • Technology Forecasting • Training

28 Framework

29 Exemplo de uma fábrica

30 Fases da Product Line

31 Fases da Product Line

32 CMMI X Framework for SPL Practice
Introdução Product Line: Conceitos O que é Porque Como Conclusão A Framework for Software Product Line Practice Relação entre CMMI e Framework for Software Product Line Practice PuLSE

33 Aplicando PL Practice e and Software Process Improvement
Lawrence G. Jones & Albert L. Soule July 2002

34 Relação entre CMMI e Framework for SPL Practice

35 Associations Between SPL Practice Areas and CMMI Process Areas ...

36 ...Continuação As Áreas de Processo em negrito suporta uma
correspondência direta com uma Practice Area. Para as Áreas de Processo de PPQA, OPF, OPP,QPM,CAR, OID não existe uma correspondência.

37 Practice do Framework sem correspondência no CMMI
Understanding Relevant Domains Scoping Tool Support Building a Business Case Funding Launching and Institutionalizing Market Analysis Operations

38 PuLSE Introdução Product Line: Conceitos
O que é Porque Como Conclusão A Framework for Software Product Line Practice Relação entre CMMI e Framework for Software Product Line Practice PuLSE

39 PuLSE PuLSE™ provides a customizable framework for product line engineering. The essential components of the framework are: Baselining the organization and customizing the framework. Scoping the application area based on a sound economic analysis. Modeling that area in terms of concepts and their relationships. Transitioning the domain model into a fully reusable design (a reference architecture). Specifying an application engineering process that makes use of the reference architecture and maintains it over time.

40 PuLSE Overview

41 PuLSE™ Component Overview
PuLSE-BC: Baselining and Customization Goal: Create a PuLSE process tailored to the organization’s situation. • PuLSE-Eco: Economic Analysis Goal: Determine an economically viable scope for the product line. – Identify and characterize possible business domains. – Evaluate them economically against the organization’s business objectives. – Create an initial development plan.

42 PuLSE™ Component Overview
• PuLSE-CDA: Product Line Modeling Goal: Elicit and articulate the domain concepts and their interrelationships. – Use customized models to elicit knowledge about products, including anticipated future products. – Consolidate the product knowledge into a model relating all products. – Refine and validate the models. PuLSE-DSSA: Reference Architecture Goal: Define an architecture that supports current and future applications. – Develop a reference architecture for the product line from the information modeled in PuLSE-CDA. – Analyze the architecture wrt. Its correctness, quality and evolvability.

43 PuLSE™ Component Overview
PuLSE-I: Product Instance Development Goal: Develop one product as an instance of the product line. – Define the instantiation process. – For each product, customize the reference architecture using the instance specifications and validate the system. PuLSE-EM: Evolution and Management Goal: Manage development and employ feedback processes for continuous optimization of artifacts and processes.

44 PuLSE Maturity Levels A PuLSE application can be rated using four maturity levels. Initial: PuLSE components are applied independently of one another and customized as necessary. Full: all PuLSE components are applied. The degree of integration between them may vary. Controlled: PuLSE is applied as a full development cycle. Full integration and traceability of the different components is ensured. Optimizing: the PuLSE-based development cycle is refined over a number of product developments using controlled optimization techniques.

45 Conclusão Product Line é uma solução para a adoção das técnicas de reuso. As metodologias para se implantar Product Line estão amadurecendo, mas ainda encontra-se muito restrita. Para a utilização de Product Line as organizações deve ter um alto nível de maturidade em processo.

46 Pensando ... Product Line é realmente uma solução para os problemas das organizações de software?! Ou é uma nova oportunidade de negócio.

47 Referências Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice. Lawrence G. Jones Albert L. Soule, July Framework software product line. Paulo Clements & Linda Northrop, 2003. Linhas de Produto de Software: riscos e vantagens de sua implantação. Roberto C. Durscki1, Mauro M. Spinola1, Robert C. Burnett, Sheila S. Reinehr1,2 Technology Dimensions of Product Line Implementation Approaches. Dirk Muthig, Michalis Anastasopoulos, Roland Laqua, Stefan Kettemann, Thomas Patzke, September 2002 Clements, P. & Northrop, L. A Framework for Software Product Line Practice, Version 4.2 [online]. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, Jully < CMMI Product Suite. <

48 Dúvidas..


Carregar ppt "Software Product Lines"

Apresentações semelhantes


Anúncios Google