Linha de produtos de software

Uma linha de produtos de software (em inglês software product line ou SPL) é um conjunto de sistemas de software que têm um determinado conjunto de funcionalidades em comum, e que satisfazem as necessidades de um determinado segmento de mercado ou missão, e que são desenvolvidos tendo a mesma base (core).

Definição de Software Product Lines[editar | editar código-fonte]

A abordagem das linhas de produtos de software (software product lines - SPL) centra-se no uso de técnicas de engenharia que permitem criar um grupo de sistemas de software similares a partir de um conjunto de especificações de software comuns a todos esses sistemas, usando para tal um meio comum de produção. Assim, é uma transposição para a produção de software de técnicas utilizadas noutras áreas da engenharia, como por exemplo no fabrico de certos produtos, em que é criada uma linha de produtos semelhantes usando a mesma fábrica e que na qual são montadas e configuradas partes que serão reutilizadas nos produtos variantes na linha de produção.

As SPL estão a emergir rapidamente, tornando-se num importante paradigma de desenvolvimento de software que permite às empresas de desenvolvimento otimizar os seus processos de engenharia de software. Apesar da ideia de criar software a partir de partes reutilizáveis ser discutida há bastante tempo, apenas recentemente, graças aos avanços feitos na área de linhas de produção, é que se pode considerar que foi demonstrado que o uso deste conceito pode de facto alcançar os objetivos a que se propôs, para os produtos de software.

Seguem-se algumas das áreas da Engenharia de Software em que a abordagem SPL pode ser utilizada:

Engenharia de Requisitos
Definição da Arquitetura
Avaliação da Arquitetura
Desenvolvimento de componentes
Integração de Sistemas de Software
Testes

Diferenças entre Software Product Lines e Engenharia de Software Convencional[editar | editar código-fonte]

A principal diferença entre engenharia de linhas de produção de software e a engenharia de software convencional é a presença de variação em alguns ou até todos os requisitos de software. Na fase inicial do ciclo de vida de uma SPL, o software contem pontos de variação que caracterizam o comportamento do software. Ao longo de todo o processo de desenvolvimento os vários pontos de variação são analisados, e são escolhidos os comportamentos necessários para a concretização do produto final de software. Este processo de decisão sobre quais os comportamentos de cada ponto de variação são escolhidos para o software é chamado normalmente de _binding time_..

Objetivos do uso de Software Product Lines[editar | editar código-fonte]

Os principais objetivos das SPL são o de juntar semelhanças e gerir as variações por forma a originar melhorias na qualidade, tempo e esforço de desenvolvimento, custo e complexidade na criação e manutenção de linhas de produtos de sistemas de software similares, e ainda um aumento do número de produtos dessa linha que podem ser desenvolvidos. A junção de semelhanças pode ser conseguida através da consolidação e partilha entre os vários inputs dos recursos de software por forma a evitar duplicações e divergências. A gestão das variações faz-se com a utilização de uma definição clara sobre qual o modelo de decisão e quais os pontos de variação, apresentando as suas localizações e dependências.

Em suma, estes benefícios podem ser atribuídos à reutilização estratégica do software. Assim o único real esforço de engenharia necessário para a concepção de cada produto da linha de produtos dirá respeito às variações que são realmente únicas para esse produto, e à devida selecção de comportamentos característicos de cada ponto de variação.

No entanto, é necessário ter em conta que a reutilização, enquanto estratégia de software para diminuir os custos de desenvolvimento e aumentar a qualidade, não é uma ideia nova, e de facto as Linhas de Produtos de Software envolvem muita reutilização, sempre que o novo produto de software seja indicado para existir a reutilização. Mas a diferença reside no facto de a reutilização ser um processo que apenas dava ênfase à reutilização de pequenas partes de código. No caso da abordagem SPL, a reutilização é planeada, não sendo meramente oportunista, sendo assim todo o código que a ser reutilizado é desenhado e concebido tendo em conta a possibilidade de reutilização, modificação e optimização por forma a se enquadrar em vários sistemas [1].

Benefícios[editar | editar código-fonte]

Tempo: Se, tal como foi referido, os novos produtos numa linha de produtos de software puderem ser distribuídos mais rapidamente no mercado, os proveitos que isso originará são vários. Entre os quais a possibilidade de chegar ao retorno dos custos de forma mais rápida; ser capaz de atingir mercados estratégicos; ser capaz de operar em mais mercados; maior capacidade de sobreviver em mercados voláteis.
Qualidade: Os benefícios na qualidade para as SPL podem ser medidos de duas formas. Uma delas é saber qual o nível de satisfação do cliente e avaliando o impacto positivo que o produto tem no cliente, enquanto que a segunda mede-se pela quantidade de defeitos em cada um dos produtos da SPL. Assim, o uso de SPL contribui para a melhoria de qualquer uma das duas medidas, seja, respectivamente, pela sua capacidade de customização em massa, ou pelas técnicas usadas em SPL que contribuem para a diminuição dos erros, conseguida principalmente pela exploração da similaridade de código, em que uma correcção de um único defeito pode ter impacto em todos os produtos que utilizam esse componente de código, não sendo então necessário corrigir vários erros. Este acréscimo na qualidade implica a existência de uma menor necessidade de suporte aos clientes, ciclos de testes menores e menor actividade de correcção de erros/bugs.
Produtividade: as SPL também de igual modo aumentar a produtividade da engenharia de software, já que levam a uma redução do esforço e custo necessários para o desenvolvimento e manutenção de conjuntos de produtos de software similares. Principalmente porque, em geral, os custos da criação de sistemas de software centram-se nos custos da mão-de-obra(equipa de desenvolvimento). Este aumento de produtividade é originado graças à eficiente reutilização do software. Assim, será possível diminuir os preços dos produtos e/ou aumentar as suas margens de lucro.

Riscos[editar | editar código-fonte]

Juntamente aos benefícios apontados, estão de igual modo aliados alguns riscos. Tal acontece pois o uso de linhas de produtos constitui uma nova estratégia técnica para qualquer organização. A criação de uma SPL requer a existência de uma gestão organizacional capaz e boas práticas técnicas de engenharia. Mesmo que uma organização adquira uma SPL, irá necessitar destes requisitos, a fim de poder explorar a similaridade dos produtos e de monitorizar devidamente o esforço de desenvolvimento [1].

Cuidados a ter no Modo de Implementação[editar | editar código-fonte]

O primeiro aspecto a ter em conta, na definição de uma SPL, é a similaridade partilhada pelos produtos quantificando o nível de semelhança, e a forma em que os produtos variam entre si. É também necessário definir a quantidade de produtos a incluir, sendo que, para quantidades bastante elevadas as partes que estes têm comum deverão ser mais genéricas ou então serão apenas usadas numa pequena fracção desses produtos. Por outro lado, se a gama de produtos for muito reduzida, então a SPL não terá todo o seu potencial aproveitado, podendo até, em último caso, não vir a justificar os custos da sua introdução. No entanto, há que ter em conta que a definição desta gama não é algo estático, mas que pode ir sendo alterada e refinada, e ainda que a sua definição não deverá ser muito precisa.

Existem várias técnicas para fazer a definição da gama de produtos, nomeadamente a que se segue: pegando nas especificações de todos os produtos, é efectuado um levantamento de todas as semelhanças entre eles, e é estudada a variabilidade. Para o estudo da variabilidade dos produtos os actores-chave são integrados no processo de avaliação, sendo assim possível obter informação sobre os pontos em comum e as diferenças entre os produtos de software.

Uso de Software Product Lines na fase de Especificação de Requisitos[editar | editar código-fonte]

Tal como salientado anteriormente, o uso de SPL é vantajoso ao longo de todas as fases de Engenharia de Software, nomeadamente na de Análise e Especificação de Requisitos. Nela são apontados requisitos comuns para a linha de produtos, ou seja, os requisitos são escritos para o grupo de sistemas como um todo, sendo que os requisitos específicos para sistemas individuais são apontados como um delta ou um incremento à dita base de requisitos especificada. Assim, a similaridade e a variação serão documentadas explicitamente, o que ajudará a criar uma arquitectura única para a linha de produtos. Além disso, será também muito mais fácil criar novos sistemas na linha de produtos, porque será mais fácil especificá-los, já que os requisitos são reutilizados e adaptados. De outra forma, a captura de requisitos para um grupo de sistemas requer um poder de análise e de negociação elevado, a fim de se obter uma base de requisitos comuns e de variação aceitáveis para todos os sistemas [1].

A especificação de requisitos para uma SPL difere da especificação de requisitos para um único sistema da seguinte forma:

O levantamento de requisitos para uma SPL deve conseguir captar de forma antecipada todas as variações que existem no decorrer do ciclo de vida do software. O levantamento de requisitos é realizado por forma a que os esforços sejam concentrados no âmbito do domínio da aplicação, antecipando e prevendo variações que possam existir no decorrer do ciclo de vida do software, utilizando técnicas de análise de domínio, e utilizando casos de uso para capturar as variações que são esperadas.
Analise de requisitos para uma SPL inclui a procura de pontos de paridade e de pontos de variação entre os vários produtos. Nesta fase os stakeholders estão envolvidos de forma a que sejam identificados factores de vantagem da utilização de uma SPL, e respectivo aproveitamento.
A especificação de requisitos pressupõem um conjunto variado de requisitos para uma SPL, e outros mais específicos de acordo com cada produto. Dado que cada produto pode apresentar pequenas variações em relação à SPL, os requisitos do produto podem por vezes estender outros requisitos do SPL.
A fase de revisão de requisito é realizada de forma mais intensa do que num produto de software independente. É essencial verificar que todos os requisitos da SPL se encontram em conformidade com os requisitos específicos de cada produto.
A gestão de requisitos é importante pois desta forma é essencial gerir quer os requisitos da SPL, quer do produto especifico. É necessário identificar normas para ser possível manter coerência entre requisitos genericos (das SPL) e requisitos que são mais específicos (devido a cada variação de cada produto).

Práticas específicas:

Técnicas de análise de domínio: Este tipo de técnicas são utilizadas por forma a aumentar todo o domínio relacionado com o levantamento de requisitos, de forma a conferir agilidade para identificar e planear mudanças de forma antecipada, potenciar a criação de arquitecturas robustas, e criar uma base para serem apontadas as semelhanças e pontos de variação proporcionando assim uma base lógica e sustentada para a especificação detalhada dos requisitos quer a nível de semelhanças, quer a nível de variações.
Stakeholder-view modeling: Esta técnica pode ser utilizada de forma a auxiliar de requisitos dos stakeholders para a SPL. Cada stakeholder pode modelar os requisitos que o satisfazem e que necessita de forma separada sendo visto como um conjunto de requisitos, que são agrupadas de acordo com todos os modelos dos vários stakeholders. Esta técnicas facilita a que sejam identificados de forma precoce conflitos entre as necessidades dos vários stakeholders.
Modelação das funcionalidades: Esta técnica pode ser usada como um complemento à especificação de requisitos pois agrupa funcionalidades, e permite ter uma perspectiva de conjunto sobre o todo. Requisitos para uma família de produtos podem ser organizados de acordo com as funcionalidades dessa mesma família, podendo então ser explorados os pontos de semelhança e de variação para a criação de modelos de referencia que podem ser usados para a implementação dos produtos dessa mesma família.
Modelação de casos de uso: Esta técnica pode ser aplicada neste domínio, para capturar e descrever pontos de variação e pontos de semelhança dentro de uma SPL. Um ponto de variação é quando ocorre uma variação num caso de uso. Essa variação é estudada tendo em conta o contexto em que se encontra e a forma como as suas variações levam a diferentes comportamentos.
Change-case modeling: Como já foi referido anteriormente a antecipação e captura de mudanças no sistema é importante, e esta técnica identifica potenciais casos de uso que poderão surgir no sistema. Estes casos de uso específicos estão ligados aos casos de uso existentes, permitindo assim uma visão desde a fase de requisitos sobre o impacto de mudanças que possam ocorrer.
Rastreio de requisitos: Esta técnica pode ser usada para garantir que o design e implementação de um sistema satisfaz os requisitos, e permite realizar uma busca para trás desde o requisito até à sua origem, ou para a frente até ao produto ou comente que irá originar. Esta flexibilidade de "navegar" nos dois sentidos permite que seja mais fácil compreender o impacto que pode ter no sistema de uma mudança ou conjunto de mudanças.

Riscos:

O grande risco que se encontra associado à engenharia de requisitos é a possibilidade de errar na identificação dos requisitos correctos ao longo do ciclo de vida da SPL. Ao longo de todo o processo de engenharia de requisitos podem surgir condicionantes à boa pratica da implementação de uma SPL, tais como a errada documentação dos requisitos, a impossibilidade de actualizar os requisitos de forma atempada e correcta, ou mesmo a não documentação (ou utilização de terminologia impropria) dos requisitos.

Poderá parecer estranho que possa ocorrer uma errada documentação dos requisitos, no entanto existem alguns factores que são importantes de ter em conta:

Incapacidade de adaptação a este paradigma, não sendo clara a distinção entre requisitos para a SPL, e requisitos específicos de cada produto.
Requisitos demasiadamente específicos podem comprometer uma visão alargada de possíveis mudanças ao longo do tempo de vida do produto. É necessário em alguns requisitos manter um nível adequado de abstracção para ser possível tornar o produto e a SPL ágil para casos de uso futuros.
Requisitos demasiadamente abstractos, levam a um esforço maior, pois não existe um nível de especificidade adequado, e determinados requisitos de produtos dado o seu cariz especifico podem ver comprometidos a sua especificação.
Pontos de variação que sejam identificados de forma errada podem levar a que a adaptação e flexibilidade sejam comprometidas. A nível de estrutura a própria SPL poderá não apresentar todas as suas vantagens.
O facto do processo de engenharia de requisitos ser demasiadamente focado em pontos de semelhança e pontos de diferença entre uma SPL e produtos específicos, requisitos não-funcionais podem ser colocados em segundo plano, quando por vezes a sua importância não pode ser ignorada.

Referências[editar | editar código-fonte]