Software Product Lines

1. Software Product Lines Geovane Nogueira Lima Prof. Jacques Robin

2. 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 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

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. 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

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? • 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 Product line amortiza o seu investimento e de outros ativos:

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

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. Desenvolvimento de Produto Desenvolvimento de Ativos Gerenciamento 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.

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. 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 A Framework

22. A Framework forSoftware 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 2002 . • 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 2006. <http://www.sei.cmu.edu/productlines/> • CMMI Product Suite. <http://www.sei.cmu.edu/cmmi/products>

48. Dúvidas..