Linha de Produto de Software (LPS). O que é e quais vantagens?

O sonho da massificação do reuso de software é contemporânea ao início da engenharia de software. Diversas tentativas ou iniciativas de reuso foram feitas, mas inicialmente, com pouco sucesso. As propostas iniciais de reutilização eram, em geral, abordagens de pequena escala que promoviam a reutilização de código de forma localizada, mas ainda sem um foco no processo de desenvolvimento como um todo.

A proposta de se concentrar em um domínio específico como base para o desenvolvimento de artefatos reusáveis somente foi introduzido um pouco mais tarde (Neighbors, 1984). No entanto, os trabalhos neste contexto eram quase todos focados em desenvolvimento automatizado de software baseado em ferramentas de geração de código. Estes trabalhos focavam-se em linguagens de domínio específico, mas nunca escalando para o desenvolvimento em larga escala. Já o conceito de família de sistemas foi introduzido por Parnas (Parnas, 1976) na década de 70.

O conceito de linhas de produto de software foi introduzido no início da década de 90. Uma das primeiras contribuições foi a descrição do método Feature-Oriented Domain Analisys (FODA) por Kang et al (Kang et al., 1990). Na mesma época várias empresas começaram a tratar deste problema de forma mais sistemática. A Philips, por exemplo, introduziu um dos primeiros métodos (Linden &. Muller, 1995) na área e depois diversas outras empresas investiram na engenharia de linha de produtos, assim como a comunidade científica.

A diferença chave entre o processo de desenvolvimento de software tradicional e o de uma linha de produto de software é o foco de uma visão estratégica de um segmento de mercado, ao invés de gerar produtos individuais para atender um determinado contrato. Diferentes razões levam as empresas a adotar métodos, técnicas e práticas de engenharia de LPS, dentre as quais estão o custo e o tempo, pois há uma redução geral nos custos, uma diminuição no tempo de entrega do produto ao mercado e um aumento na qualidade do produto, bem como de sua confiabilidade. A diminuição dos custos e redução do tempo de entrega do produto ao mercado está fortemente correlacionada à abordagem de reuso em larga escala durante o desenvolvimento de software. Em oposição às abordagens tradicionais (Poulin,1997), o reuso proporcionado pela LPS pode representar 90% do software como um todo. A reutilização traz um melhor custo-benefício quando comparada com o desenvolvimento sob demanda. Dessa forma, tanto o custo de desenvolvimento quanto o tempo de entrega do produto podem ser reduzidos na engenharia de linha de produto. Infelizmente, este incremento não é gratuito, é necessário um investimento inicial maior do que a estratégia tradicional, porém, em muitos casos, é equivalente ao investimento de desenvolvimento de três produtos individuais (Linden et al., 2007), conforme ilustra a Figura  1. A partir de então, a estratégia de engenharia de linhas de produto de software pode torna-se economicamente mais vantajosa.

lps_figura1
Figura 1 Economia da Engenharia de Linha de Produto de Software
(Linden et al., 2007)

Métodos de engenharia de linhas de produto de software propõem uma distinção fundamental entre o desenvolvimento de software para reuso e o desenvolvimento de software com reuso, como mostrado na Figura 2 2. Na engenharia de domínio (desenvolvimento para reuso) a base é fornecida para o desenvolvimento de produtos individuais. Ao contrário de várias abordagens tradicionais de reuso focadas em artefatos de código, a infraestrutura da linha de produto engloba todos artefatos que são relevantes ao ciclo de desenvolvimento. Estes artefatos vão desde os requisitos à arquitetura até a implementação aos testes. Esta coleção de artefatos define a infraestrutura da LPS. Outra importante distinção do modelo tradicional é que os vários artefatos contém variabilidades explícitas. Por exemplo, a representação dos requisitos deve conter descrições explícitas das variabilidades que se aplicam somente aos subconjuntos dos produtos.

lps_figura2
Figura 2 O modelo de dois ciclos da Engenharia de Linha de Produto
(Linden et al, 2007)

Os artefatos individuais na infraestrutura da LPS são inter-relacionados assim como os artefatos do desenvolvimento tradicional de software. Por exemplo, a rastreabilidade é definida entre artefatos individuais, permitindo obter requisitos e identificar todas as implementações e casos de testes relacionados. A engenharia de aplicação (desenvolvimento com reuso) desenvolve o produto final usando como base a infraestrutura da LPS. A infraestrutura define previamente a maioria das funcionalidades requeridas para um novo produto. As variabilidades explicitamente modeladas nesta infraestrutura fornecem a base para a derivação de produtos individuais. Basicamente, quando um novo produto é desenvolvido, ele é gerado a partir do núcleo de artefatos da LPS que definem as funcionalidades comuns de todos os produtos. Os requisitos são levantados e então categorizados em três tipos: (i) comum a todos os produtos, (ii) variáveis de acordo com o produto gerado ou (iii) específicos de um determinado produto. A partir desta análise, os vários artefatos de software (arquitetura, implementação, dentre outros) devem ser corretamente relacionados à categorias de requisitos para que possam ser instanciados de forma correta permitindo a derivação de um produto de software desejado.

Vários princípios são fundamentais para o sucesso de uma abordagem de engenharia de linha de produto de software. Os principais são descritos a seguir (Liden et al, 2007):

  • Gerenciamento de Variabilidades: sistemas individuais são considerados como variações de um tema comum. A variabilidade é explícita e deve ser sistematicamente desenvolvida;
  • Centrado no Negócio: a engenharia de linhas de produto de software deve estar conectada com a estratégia de longo prazo do negócio;
  • Centrado na Arquitetura: a estrutura do software deve ser desenvolvida de forma a permitir obter vantagens das similaridades entre os sistemas individuais;
  • Abordagem de Ciclo de Vida Duplo: Os sistemas individuais são desenvolvidos baseados em plataforma de software. Estes produtos – como também a plataforma – devem ser desenvolvidos e ter seus ciclos de vidas individuais.

Referências:

Kang, K., Cohen, S., Hess, J., Novak, W. & Peterson, S., 1990. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, November,

Parnas, D.: On the design and development of program families. IEEE Transactions on Software Engineering, 2(1):1–9, March 1976.

Poulin, J, 1997. Measuring Software Reuse — Principles, Practices, and Economic Models. Addison-Wesley.

Linden, F. van der & Muller, J, 1995. Creating architectures with building blocks. IEEE Software, 12(6):51–60.

Linden, F. van der; Schmid, K. & Rommes, E., 2007. Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering, Springer.

 

gleydson

Autor:

Gleydson Lima, PhD
Diretor de TI e Inovação
SIG Software e Consultoria em TI

 

Publicado em Artigos

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*