---

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

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 optimizar os seus processos de engenharia de sofware.
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
objectivos 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 [1]:

1. Engenharia de Requisitos
2. Definição da Arquitectura
3. Avaliação da Arquitectura
4. Desenvolvimento de componentes
5. Integração de Sistemas de Software
6. Testes

Diferenças entre Software Product Lines e Engenharia de Software Convencional

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

Objectivos do uso de Software Product Lines

Os principais objectivos 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 juntaçã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 à
devição selecção de comportamentos caracteristicos 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 enfase à 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

Tempo: Se, tal como foi referido, os novos produtos numa linha de
produtos de software puderem ser distribuidos 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 mai rapida; 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 nivel 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

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

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,
entao 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

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 traz 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 modanç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.

DISALLOWED (DmRelatedItem)