Linha de Produto de. Luciana Nascimento Peter Lupo. Software

Transcrição

1 Linha de Produto de Luciana Nascimento Peter Lupo Software

2 Roteiro Motivação Definições Gerais Desenvolvimento de Linha de Produto Exemplos e Ferramentas Pesquisa em Linha de Produto

3 Motivação Panorama Industrial Abordagem inicial de desenvolvimento de produtos: Produto individual, feitos para um cliente conforme suas necessidades. Surgimento da Produção em Massa: Linhas de produção: produtos padronizados construídos em larga escala.

4 Produção em Massa Linhas de produção Menor custo Menor diversificação

5 Customização em Massa Produção em larga escala de produtos customizados/adaptados segundo as necessidades dos clientes.

6 Customização em Massa

7 Customização em Massa Cliente Possibilidade de ter produtos individualizados. Organização Maior investimento em tecnologia levando a: Aumento do preço dos produtos personalizados, ou Menores lucros Plataforma Comum!!!

8 Plataforma Comum Uma plataforma é qualquer base de tecnologias sob a qual outras tecnologias ou processos são criados. [TechTarget 2004] apud [Pohl 2005] Plataforma comum + Customização em massa: Permite a reutilização de uma tecnologia e ao mesmo tempo a construção de produtos de acordo com gosto/necessidade específicas de usuários.

9 Customização em Massa e Plataforma Comum Ex: Montadoras de carros Ar Condicionado: opcional Cores: Sólida, Metálica ou Perolizada Câmbio: automático ou manual Motor: 1.0 ou 1.6 Portas: 3 ou 5

10 Por que investir em Linha de Produto? Aumento de produtividade Produtos entregues mais rápidos Aumento de Qualidade Redução de custos Modelos 757 e 767 da Boeing compartilham 60% de componentes comuns - Economia de produção e manutenção!!

11 Conceitos e Definições Gerais

12 Linha de Produto de Software A Engenharia de Linha de Produto de Software é um paradigma para desenvolver aplicações de software (sistemas de software-intensivo e produtos de software) usando plataforma e customização em massa. [Pohl et al, 2005]

13 Linha de Produto de Software Uma Linha de Produto de Software é um conjunto de sistemas com uso intensivo de software que compartilham um conjunto gerenciável de características comuns que satisfazem necessidades específicas de um determinado segmento de mercado ou missão, e que são desenvolvidos a partir de um conjunto comum de ativos principais de uma forma préestabelecida. [Clements and Northrop, 2002].

14 Linha de Produto de Software Uso de uma base comum de assets para produção de um conjunto de produtos relacionados Arquitetura Plano de Produção Definição de Escopo

15 Produto x Linha de Produto de Software PRODUTO DE SOFTWARE Componentes específicos do produto Componentes compartilhados Componentes compartilhados configurados para o produto Componentes desenvolvidos externamente. LINHA DE PRODUTO Arquitetura da Linha de Produto Componentes compartilhados Modelo de variabilidade e commonality Conjunto de produtos derivados dos ativos compartilhados.

16 LPS - Tecnologias Tecnologias que habilitam Linhas de Produto Orientação a Objetos Encapsulamento, ocultação de informação Desenvolvimento baseado em Componentes Baixo acoplamento. Componentes podem ser desenvolvidos, compilados, ligados e carregados separadamente Técnicas de ligação tardia (late-binding) Permite adiar escolhas de configuração: facilita a implementação da plataforma e permite customização em massa. Gerência de Configuração Pré-requisito necessário para lidar com a complexidade de grandes aplicações construídas por várias partes em diferentes versões.

17 LPS Conceitos Envolvidos Plataforma ou Core Assets: Conjunto de subsistemas de software e interfaces que formam uma estrutura comum da qual um conjunto de produtos deriváveis podem ser construídos e produzidos de forma eficiente. [Meyer and Lehnerd 1997] Em LPS inclui: Arquitetura, Componentes reutilizáveis, Modelos de domínio Requisitos, documentos e especificações, Modelos de desempenho, Planos e casos de teste, Descrição de processos, planos de trabalho, cronogramas e orçamento. A arquitetura é a chave entre esses elementos.

18 LPS Conceitos Envolvidos Análise de Domínio. Visa coletar informações sobre um domínio e explicitar seus aspectos similares e diferentes Variabilidade! Variabilidade: Habilidade que um sistema ou artefato de software possui de ser alterado, customizado, ou configurado para um contexto em particular. (BOSCH, 2004).

19 Variabilidade Conceitos Inerentes Ponto de Variação: Refletem a parametrização no domínio de uma maneira abstrata. São configuráveis por meio das variantes. Variantes: são as alternativas de configuração de um ponto de variação. Invariantes ou Commonalities: Características fixas/comuns dos elementos de um domínio.

20 Variabilidade Conceitos Inerentes Elementos Opcionais: Podem ou não estar presentes em produtos desenvolvidos em uma LPS. Elementos Mandatórios: Devem obrigatoriamente estar presentes em produtos desenvolvidos em uma LPS

21 Variabilidade - Modelagem Deve favorecer a identificação das variabilidades, a comunicação e a rastreabilidade entre os outros ativos da Linha de Produto. Gera o Modelo de Domínio Pode ser textual, gráfica ou combinando ambas. Abordagem bem difundida: modelagem de características. Característica:...um aspecto, uma qualidade, ou uma característica visível ao usuário, proeminente ou distinta, de um sistema (ou sistemas)de software. KANG et al. (1990)

22 Variabilidade - Modelagem Modelagem de Características - Diferentes notações existentes: FODA (KANG et al., 1990) FORM (KANG et al., 2002, LEE et al., 2002), FeatuRSEB (GRISS et al., 1998), Notação de RIEBISCH (RIEBISCH et al., 2002), Notação de CECHTICKY (CECHTICKY et al.,2004) Notacao de CZARNECKI (CZARNECKI et al., 2004, 2005), Notacao Odyssey-FEX (OLIVEIRA, 2006) Notacao definida por GOMAA (2004), Etc.

23 Variabilidade - Modelagem Notação FODA (original):

24 Variabilidade - Modelagem Notação FODA:

25 Linha de Produto de Software - Vantagens Redução dos Custos de Desenvolvimento Redução do time-tomarket

26 Linha de Produto de Software - Vantagens Outras Vantagens Aumento da Qualidade Qualidade melhorada através do reuso Redução dos Esforços de Manutenção Propagação da Correção de Erros Melhor estimação de custos Plataforma simplifica estimação de custos Benefícios para Consumidores Maior qualidade, menor preço

27 Linha de Produto de Software - Riscos Maior Nível de Risco Grande investimento inicial que pode se tornar inútil se importantes requisitos mudam Maior time-to-market para o primeiro produto baseado na arquitetura da SPL Requer: Engenharia Experiente Gerenciamento Técnico e Organizacional.

28 LPS - Linha de Produto de Software Importante: O que não é Linha de Produto de Software?

29 O que não é LPS Reutilização de baixa granularidade. Pedaços de código disponíveis em uma biblioteca. Ex.: Algorítmos, classes, módulos, componentes... Benefícios dependem da predisposição do programador em usar o que está na biblioteca, da adequação do que está disponível para ele, e do sucesso da adaptação e integração no sistema que ele está construindo. A reutilização com Linhas de Produtos de Software é planejada, habilitada, imposta, abrangente, planejada e lucrativa.

30 O que não é LPS Desenvolvimento de um único sistema com reutilização. Reutilizar partes semelhantes de outro sistema clone and own Obtém-se 2 sistemas diferentes ao invés de 2 sistemas construídos sobre a mesma plataforma. Em Linha de Produto: Ativos reutilizáveis são construídos explicitamente para reutilização. Não se tem múltiplos produtos construídos e mantidos separadamente. Cada produto é uma adaptação dos ativos comuns. Os ativos é que são projetados, construídos e evoluídos.

31 O que não é LPS Apenas desenvolvimento baseado em componentes. Mais do que isso: Componentes especificados pela arquitetura da linha de produto. A forma da composição é pré-definida. Mecanismos de variação embutidos de forma planejada.

32 O que não é LPS Apenas uma arquitetura reconfigurável. Reconfiguração: Em Linha de Produto a arquitetura é projetada para suportar a variabilidade necessária para os produtos da linha. Mas apesar da sua grande importância, a arquitetura é apenas UM dos ativos da base de ativos da linha de produto

33 O que não é LPS Releases e versões de um produto. Existe reutilização de arquitetura, componentes, planos de teste e outros artefatos de versões anteriores. Versões anteriores são descontinuadas em algum ponto. Em Linha de Produto: Vários produtos simultâneos com seus próprios releases e versões. A evolução ocorre na Linha de Produto de Software. Versões anteriores podem ser instâncias válidas da linha.

34 Abordagens e Frameworks de Processo

35 Abordagens Abordagem Pró-ativa: Considera previamente todos os produtos a serem gerados e desenvolve o conjunto de ativos e processos de Linhas de Produto. Em geral: Análise de Domínio Arquitetura e demais ativos Linha de Produto Produto A Produto B Processos e Planos Produto C

36 Abordagens Abordagem Extrativa: Features variáveis e comuns são extraídas de sistemas préexistentes para derivar uma versão inicial da SPL. Análise de Domínio Produto A Produto B Linha de Produto Produto A Produto C Produto B Arquitetura e demais ativos Processos e Planos Produto N

37 Abordagens Abordagem Reativa Desenvolvimento incremental: Quando há uma demanda para incorporar novos requisitos ou produtos, artefatos comuns e variáveis são incrementalmente estendidos em reação a eles. Produto A Linha de Produto Linha de Produto Produto A Produto B Produto B Produto C Requisitos para uma nova instância Produto D Produto C

38 Metodologias para Linha de Produto de Software Diferentes Propostas na Literatura FORM PuLSE KobrA FAST PLUS Framework do SEI Framework proposto em Pohl et al, Etc.

39 Framework do SEI As três atividades essenciais para SPL

40 Framework do SEI Desenvolvimento da Plataforma

41 Framework do SEI Desenvolvimento da Plataforma

42 Framework do SEI Derivação do Produto

43 Framework do SEI Gerenciamento Atingir a estrutura organizacional certa Alocar recursos Coordenar e supervisionar Oferecer treinamento Recompensar empregados apropriadamente Desenvolver e comunicar uma estratégia de aquisição Gerenciar interfaces externas Criar e implementar um plano de adoção da linha de produto

44 Framework do SEI Áreas-Práticas Software Engineering Architecture Definition Architecture Evaluation Component Development COTS Utilization Mining Existing Assets Requirements Engineering Software System Integration Testing Understanding Relevant Domains Technical Management Configuration Management Data Collection, Metrics, and Tracking Make/Buy/Mine/Commissio n Analysis Process Definition Scoping Technical Planning Technical Risk Management Tool Support Organizational Management 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

45 Framework de Pohl et al,2005 Dois processos de Desenvolvimento: Engenharia de Domínio: Estabelece a plataforma, define e implementa os pontos comuns e as variabilidades. Engenharia de Aplicação: Deriva as aplicações a partir da LPS. Compõe os pontos comuns e as variabilidades de acordo com os requisitos da aplicação. É um framework! Pode ser combinado com outras métodos/processos (Incremental, RUP, XP, etc..)

46 Framework de Pohl et al,2005

47 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Product Management Sua principal preocupação é a gestão do portfólio de produtos da empresa ou unidade de negócios. Lida com os aspectos econômicos e estratégias de marketing da LPS. Define o que está dentro e o que está fora do escopo da LPS. Aplica técnicas de Scoping

48 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Metas da Organização Product Management Product Roadmap - Características Comuns e Variáveis - Cronograma de releases No que se difere da gerência tradicional? A plataforma é estratégica para a organização Foco na geração de múltiplos produtos com custo razoável. Os produtos são foremente relacionados. Futuras mudanças de características, padrões e restrições legais devem se previstas e modeladas.

49 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Domain Requirements Engineering Engloba todas as atividades de elicitação e documentação de requisitos comuns e variáveis da LPS. Os requisitos são analisados para identificar os que são comuns para todas as aplicações e os que são específicos para certas aplicações (ou seja, que diferem entre várias aplicações). Documentação das possibilidades de escolha: modelo de variabilidade Com base nas definições da gerência do produto, antevê prospectivas mudanças em requisitos como leis, padrões, mudanças de tecnologia e necessidades de mercado das futuras aplicações.

50 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Product Roadmap Domain Requirements Engineering Requisitos Reutilizáveis Textuais e Baseados em Modelos Modelo de Variabilidade

51 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Domain Design Engloba todas as atividades de definição da arquitetura de referência. No que difere do tradicional? Incorpora mecanismos de configuração para suporte à variabilidade. Flexibilidade é essencial: adaptação á futuros requisitos. Define regras para derivação de aplicações. Define partes reutilizáveis desenvolvidas e testadas na engenharia de domínio Define partes específicas de aplicação: desenvolvidas e testadas na engenharia da aplicação.

52 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Requisitos Reutilizáveis Textuais e Baseados em Modelos Domain Design Arquitetura de Referência Modelo de Variabilidade Inclusão de Variabilidades Internas decisões técnicas

53 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Domain Realization Fase de projeto detalhado e construção de componentes de software para reutilização. Não se constrói uma aplicação, mas sim componentes com baixo acoplamento e configuráveis interfaces de suporte à diferentes contextos. Os componentes tem mecanismos de configuração (conforme a arquitetura de referência) para permitir a variabilidade da linha de produto de software.

54 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Arquitetura de Referência Domain Realization Conjunto de Componentes Lista de componentes reutilizáveis

55 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Domain Testing Os componentes são testados em relação às suas especificações. Não há uma aplicação executável a ser testada. Somente componentes individuais ou pequenos partes montadas podem ser testadas. Produz artefatos de teste a serem reutilizados na engenharia de aplicação.

56 Framework de Pohl et al,2005 Atividades da Engenharia de Domínio Requisitos Reutilizáveis Resultados de Teste Arquitetura de Referência Domain Testing Planos de Teste Projeto de Componentes Componentes Cenários de Casos de Teste Casos de Teste

57 Framework de Pohl et al,2005 Engenharia de Domínio Modelo Ortogonal de Variabilidade: Define a variabilidade de uma LPS. Relaciona a variabilidade definida a outros modelos. Ex.: modelos de características, de casos de uso, de projeto, de componentes e de teste. Notação Gráfica:

58 Framework de Pohl et al,2005 Engenharia de Domínio Modelo Ortogonal de Variabilidade - Metamodelo Pontos de variação, variantes e suas dependências

59 Framework de Pohl et al,2005 Engenharia de Domínio Modelo Ortogonal de Variabilidade - Metamodelo Escolha alternativa mínimo e máximo

60 Framework de Pohl et al,2005 Engenharia de Domínio Modelo Ortogonal de Variabilidade - Metamodelo Dependências de Restrições

61 Framework de Pohl et al,2005 Engenharia de Domínio Modelo Ortogonal de Variabilidade - Metamodelo Relacionamentos com artefatos

62 Framework de Pohl et al,2005 Engenharia de Domínio Modelo Ortogonal de Variabilidade e outros Artefatos

63 Framework de Pohl et al,2005 Engenharia de Domínio Modelo Ortogonal de Variabilidade e outros Artefatos

64 Framework de Pohl et al,2005 Engenharia de Domínio Modelo Ortogonal de Variabilidade e outros Artefatos

65

66 Exemplos Diversas empresas estão utilizando Linhas de Produtos Boeing Bosch Group Ericsson AXE General Motors Powertrain Hewlett Packard Lucent Nokia Philips Siemens Toshiba U.S. Naval Research Laboratory Entre outras...

67 Exemplos Além de empresas utilizando linhas de produtos, pode-se encontrar ferramentas para a definição e configuração de linhas de produtos: pure::variants SPLOT Gears Eclipse Platform

68 pure::variants Mais utilizada no mercado [Berger, 2013] Baseada em Eclipse, desenvolvida pela pure-systems [pure-systems] Apoia o desenvolvimento de linhas de produtos e famílias de programas Permite realizar análise, modelagem e implementação assim como atividades de deploy É possível selecionar features e gerar produtos

69 pure::variants

70 pure::variants

71 pure::variants

72 pure::variants

73 pure::variants

74 SPLOT Software Product Lines Online Tools, desenvolvida pela University of Waterloo [SPLOT] Conjunto de ferramentas online: Editor de Modelo de Features Configuração de produtos Análise automatizada de features (features mortas, consistência, grau de variabilidade, etc)

75 SPLOT

76 Eclipse Platform A Plataforma Eclipse [Eclipse] define o conjunto de frameworks e serviços comuns que juntos formam a infraestrutura requerida para os diversos componentes. Os serviços incluem um modelo de interface de usuário, modelo de projetos para gerenciar recursos, funcionalidade de busca ente outras funcionalidades.

77 Eclipse Platform

78 Eclipse Platform

79 Eclipse Platform

80 Eclipse Platform

81 Eclipse Platform

82 Eclipse Platform

83 Eclipse Platform

84

85 Pesquisa em Linha de Produto de Software Pesquisa ad-hoc nas bases Scopus e IEEE resultou em propostas recentes (2012) não só nos temas específicos de Linhas de Processos mas também na aplicação/adaptação de métodos e metodologias de Engenharia de Software em geral.

86 Pesquisa em Linha de Produto de Software Temas encontrados ( ) Modelagem e Gerência de Variabilidade Scoping Arquitetura representação e avaliação Derivação de produto Evolução e Manutenção Processo de Desenvolvimento VeV e Teste Atributos de qualidade e métricas em LPS. Modelos de maturidade!!

87 Pesquisa em Linha de Produto de Software Principal Conferência: SPLC International Software Product Line Conference Outras: Principais conferências de Engenharia de Software em geral. ICSE - International Conference on Software Engineering No Brasil: SBCARS: Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software SBES: Simpósio Brasileiro de Engenharia de Software

88 Pesquisa em Linha de Produto de Software Principais Journals Journal of Systems and Software Software and Systems Modeling IEEE Transactions on Software Engineering Software Quality Journal Information and Software Technology

89 Pesquisa em Linha de Produto de Software Principais Pesquisadores Internacionais Paul Clements (SEI) Frank van der Linden (Philips Research ) Klaus Pohl (University of Duisburg-Essen) Jan Bosch (Chalmers University of Technology) Charles Krueger Linda M. Northrop (SEI)

90 Pesquisa em Linha de Produto de Software Principais Pesquisadores Nacionais Cláudia Werner (COPPE/UFRJ) Uirá Kulezza (UFRN) Carlos Lucena (PUC/RJ) Itana Gimenez (Universidade Estadual de Maringá)

91 Obrigada! Duvidas? Linha de Produto de Software Luciana Nascimento Peter Lupo