Linha de Produto de Software

Uma alternativa para um desenvolvimento mais eficiente em termos de custo, qualidade e tempo consiste em construir softwares baseado em componentes que podem ser reutilizados. Desta forma, o software é projetado como um conjunto de componentes que são interconectados como um quebra-cabeça. Esta alternativa tem como benefícios facilitar:

• a manutenção/evolução, já que se torna mais fácil inserir, modificar e remover necessidades do cliente;
• os testes, pois o mesmo é testado em sob uma perspectiva macro;
• o reuso, pois este se torna mais eficaz uma vez que o software é organizado como componentes que são projetados como módulos de serviços. Estes serviços são relacionados a domínios de negócios e/ou requisitos não funcionais, assim, cada componente fica responsável por tratar apenas um único serviço ou partes de um domínio de forma genérica facilitando a remoção, substituição, inserção no software. Dessa forma, o reuso do componente torna-se mais eficaz para outros softwares que sejam construídos na própria organização ou em outras.

O reuso é uma estratégia importante para agilizar o processo de desenvolvimento. Mas não basta somente reusar componentes de um software ou até mesmo um software inteiro é preciso planejar. O reuso é uma estratégia que já vem sendo utilizada pelas grandes empresas para agilizar e reduzir os custos de desenvolvimento. De uma forma geral, ele pode ser realizado de três formas: reuso de software, onde o software inteiro é reutilizado; reuso de componentes, onde partes do software é reusada; reuso de código, no qual partes de código de um software são reusados.

O reuso de software ainda pode ser organizado sob duas abordagens:

• reuso externo: onde o software é reusado para construção de outros sistemas;
• reuso interno: onde o software é reusado para construção dele mesmo como uma nova versão evolutiva (esta abordagem não é muito aceita como reuso).

Linha de Produto de Software

Uma Linha de Produto de Software (LPS) consiste em uma estratégia de realizar o reuso de forma sistemática para a construção de sistemas com menos esforço desde que estes pertençam a uma mesma família, ou seja, que tenham em comum pertencer a um mesmo domínio de mercado. A definição de linha de produto mais aceita na indústria diz o seguinte: “Uma linha de produto de software é um conjunto de sistemas que usam software intensivamente, compartilhando um conjunto de características comuns e gerenciadas, 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”.

A ideia básica é o trabalho sobre um grupo de sistemas compartilhando um conjunto comum de domínio e gerenciado por features, desenvolvidos a partir de um aglomerado comum de artefatos base e de forma previamente planejada. Os artefatos que são reutilizáveis abrangem todos os tipos tais como documento de requisitos, projeto de arquitetura, componentes de software, planos de testes e etc. Para facilitar a customização em massa, a plataforma deve fornecer os meios para satisfazer as necessidades dos diferentes stakeholders. Para este propósito, o conceito de variabilidade foi criado (explorar as características que variam em relação aos diversos produtos). Como consequência de aplicar este conceito, os artefatos que podem ser diferentes nas aplicações da linha de produtos são modelados usando variabilidade. Uma das características principais da LPS é o reuso, sendo muito presente devido ao reaproveitamento de produtos ou partes de produtos em criação de novos produtos. O processo de desenvolvimento de software, por uma linha de produto de software, ocorre em duas etapas:

• Engenharia de Domínio: processo responsável por estabelecer a plataforma de reutilização definindo o que é comum e o que é variável da linha de produtos. A plataforma consiste em todos os tipos de artefatos de software (requisitos, design, testes, etc.) também chamados de ativos base;
• Engenharia de Aplicação: processo responsável por derivar aplicações concretas a partir da plataforma estabelecida na engenharia de domínio. Ela explora a variabilidade da linha de produtos e assegura sua correta instanciação de acordo com as necessidades específicas das aplicações finais.

Na Figura 1 é ilustrado como ocorre o processo de desenvolvimento seguindo a estratégia de linha de produto de software. Inicialmente é preciso compreender o plano de negócio da empresa, informações sobre os produtos contidos nos ativos bases e dos novos produtos que serão construídos, e os novos requisitos. Depois é feita uma análise sobre os potenciais artefatos para reuso sistematizado pela engenharia de domínio. Na fase de engenharia de domínio, é feita uma análise dos potenciais artefatos para reuso nos ativos bases de acordo com as etapas de processo de desenvolvimento, por exemplo: análise de domínio nos artefatos de requisitos, arquitetura de domínio nos projetos arquiteturais, implementação de domínio nos ativos de implementação e testes de domínio nos documentos de testes reutilizáveis.

Como pode ser observado na figura, o fluxo de informações entre as etapas é feito de forma sequencial. Além disso, é necessário fazer rastreabilidade do produto ou produtos que serão reusados para encontrar os artefatos correspondentes para serem reutilizados. Após verificar os potenciais artefatos para reuso, começa a etapa de engenharia de aplicação. Nesta etapa, é construído um novo produto a partir de reuso de artefatos. Nesta etapa é feita análise de produto com os requisitos recuperados, projeto arquitetural do produto, implementação e testes.

Vale salientar que um novo produto pode ser construído a partir do reuso de artefatos de um ou vários produtos. Por fim, é feito um feedback da evolução de produtos no processo de desenvolvimento. Este feedback é feito analisando o novo produto e verificando se houve evolução de software. Caso isto aconteça, este novo produto pode ser incorporado aos ativos bases para o projeto de novos produtos.

A vantagem do processo de linha de produto ser dividido em duas etapas é que há uma separação de objetivos para a construção de uma plataforma robusta e para garantir que aplicações específicas sejam construídas em curto espaço de tempo. Suas principais características são:

• Conjunto de ativos: são a essência da LPS e correspondem a elementos customizáveis para serem utilizados na construção de software. São comumente conhecidos como ativos base. Estes ativos podem ser de componentes de software, modelos de documentos utilizados em processos, padrões de projeto, documento de requisitos, arquitetura de linha de produto e etc.;
• Forma preestabelecida: a produção de softwares de forma planejada. Este planejamento é definido para cada software que será produzido. Para cada plano de produção se deve estabelecer quais ativos estão relacionados e farão parte do produto para poder estabelecer um vínculo aos processos anexos de cada ativo que será utilizado. Os processos anexos são pequenos processos contidos em cada ativo que definem o que ele faz, qual a sua flexibilidade e qual a técnica de configuração do ativo (se ele for flexível). Essa estrutura preestabelecida de funcionamento do processo produtivo garante o ganho de tempo e confiabilidade no desenvolvimento dos produtos;
• Segmento específico de mercado: conhecido como domínio, é referente à área de conhecimento ou especialização à qual a LPS é direcionada. O domínio deve estar diretamente relacionado com as funcionalidades que os produtos da LPS devem atender. Os ativos base possuem um limite de flexibilidade. Geralmente estes limites são utilizados para delimitar o segmento de domínio. A delimitação do escopo de domínio é necessária para que a LPS não se torne muito abrangente perdendo o foco da produção e elevando os custos.

Linha de produto de software versus reuso tradicional

No reuso tradicional as organizações possuem repositórios que armazenam fragmentos e estruturas de software produzidas no desenvolvimento como bibliotecas para reuso de componentes e algoritmos. Contudo, estes repositórios não são sistematizados, estruturados e organizados para facilitar uma abordagem orientada a reuso em larga escala. Assim, os profissionais ficam procurando neles fragmentos de software para reusar e isto demanda tempo. Além disso, o reuso tradicional muitas vezes não é focado a um domínio específico, podendo ser utilizado para outros segmentos de mercado.

A LPS possui uma estratégia baseada em planejamento, automatização e sistematização. Como os repositórios são os ativos base, estes são customizados para a instanciação de produtos por meios de mecanismos de variabilidade. Uma abordagem que envolve a reutilização de software semelhante a LPS é a abordagem “clone and own”. Os produtos desenvolvidos nesta abordagem têm foco na individualidade do produto, não existe foco na família de produtos (variabilidade). Na abordagem “clone and own” o objetivo é, após um novo projeto ser iniciado, os desenvolvedores procurarem na organização por um produto que seja o mais semelhante possível com o produto que será produzido. Ao encontrá-lo, é feita uma cópia de tudo o que será aproveitado, modificando e adicionando o que é necessário para lançamento do novo produto.

Existem alguns pontos que diferenciam a abordagem “clone and own” da LPS:

• O foco de reuso na abordagem “clone and own” é o código, já a abordagem LPS faz reuso de todos os artefatos de maior custo como artefatos de requisitos e arquitetura;
• Na LPS os ativos bases são construídos orientados a reuso e variabilidade. Na abordagem “clone and own” o foco é a individualidade do produto, exigindo maior esforço de customização;
• Na abordagem “clone and own” cria-se um clone do produto independente que necessitará de manutenção individual, logo serão basicamente dois produtos tendo esforço de manutenção. Na abordagem LPS a manutenção é realizada nos ativos base, logo toda manutenção realizada nos artefatos é propagada para todos os produtos da família.

Variabilidade

A variabilidade constitui um mecanismo chave dentro da LPS. Ela está relacionada às possibilidades de mudança ou personalização da LPS. Acontece que no início do desenvolvimento do sistema o cliente possui uma grande quantidade de expectativas, o que torna ampla a quantidade de sistemas possíveis que poderão ser desenvolvidos. Em cada etapa de desenvolvimento são feitas decisões de design para restringir o número de sistemas possíveis.

Para apoiar o estudo de variabilidade, existem os artefatos de referência. Estes são estruturas que caracterizam funcionalidades dos sistemas de software de um dado domínio de aplicação. Eles são utilizados para descrever aquilo que o software deve atender dentro do escopo de domínio estabelecido. Em uma LPS existem vários artefatos de referência como requisitos de linha de produto, arquitetura de linha de produto, testes de linha de produto e etc. Cada um destes documentos servem de referência para elaboração de artefatos para novos produtos desenvolvidos na família LPS. O principal artefato de referência dentro da LPS é a arquitetura de linha de produto (ALP). A ALP é fundamental dentro da LPS porque ela é o vínculo entre as necessidades do cliente e o domínio que deve atender a LPS e o novo produto que será instanciado.

Arquiteturas de software convencionais são utilizadas para descrever a estrutura, o comportamento e a relação entre os diversos componentes do sistema. Já a ALP deve ser mapeada para um domínio específico e ser o mais flexível (genérica) possível para que ela possa atender a todo o escopo de domínio delimitado. No geral, a elaboração de artefatos de referência não é uma tarefa trivial, principalmente quando envolve a delimitação de um segmento de mercado que muitas vezes é vasto e em constante atualização.

Na LPS, as variabilidades são modeladas na ALP fazendo uso da representação dos pontos de variabilidade e variantes:

• Pontos de variabilidade: corresponde a um aspecto funcional em um elemento de software base que possui variação. Define um conjunto de possíveis variantes, o mecanismo de variabilidade para instanciar as variantes e o tempo de ativação das variantes. Os pontos de variabilidade podem ser descritos em diversos níveis de abstração (Tabela 1);
• Variantes: corresponde a uma opção do conjunto de possíveis instâncias de variação que um ponto de variabilidade poderá originar.

Gestão de variabilidade

Existem vários fatores que levam à necessidade de gerenciar a variabilidade dentro da LPS. Dentre estes fatores estão: dinamismo do mercado, impacto do software no ambiente de execução, manutenção e evolução do software para continuar sendo útil para a organização e evitar o envelhecimento do mesmo. Assim, o gerenciamento de variabilidade tem por objetivo tornar a LPS o mais dinâmica possível para atender estas exigências. A gestão de variabilidade consiste nas seguintes tarefas:

• Identificação de variabilidades: na fase inicial de desenvolvimento LPS existe um confronto de uma série de requisitos. Uma análise de requisitos é necessária para gerar uma especificação adequada para a LPS. O objetivo desta tarefa é identificar as diferenças entre os produtos e as características que existem em comum. A forma mais tradicional e conhecida para representar pontos de variabilidade são os modelos de feature;
• Introdução de variabilidade no sistema: após a identificação dos pontos de variabilidade, ocorre o projeto do sistema customizado para introdução das mesmas;
• Agrupamento de variantes: o resultado desta fase é um conjunto de variantes associadas a um ponto de variabilidade. Este conjunto de variantes pode ser representada de quatro formas: implícita, quando as variantes são baseadas no conhecimento dos desenvolvedores ou usuários; explícita, quando o sistema de forma independente decide quais variantes deseja fazer uso (está associada a sistemas inteligentes); fechada, quando nenhuma variante pode ser acrescentada; aberta, quando novas variantes podem ser introduzidas;
• Vinculação de sistemas a variantes: o resultado é a associação de um ponto de variabilidade a uma de suas variantes. Esta associação poderá ser interna ou externa. Na associação interna o sistema possui a capacidade de uma variante. Já em uma associação externa o sistema precisa de outras ferramentas para vincular a variante como, por exemplo, ferramenta para gerenciamento de configuração.

Assim como em softwares convencionais onde existe um dinamismo na utilidade e prioridade de requisitos, isso também acontece nos pontos de variabilidade. Estes podem sofrer mudanças de prioridade ao longo do tempo, podem ser removidos da LPS e outros podem ser acrescentados.

Feature Model

O principal mecanismo para modelagem de variabilidade chama-se feature model. O conceito de feature é derivado do método Feature Oriented Domain Analysis (FODA). De acordo com o método FODA, a feature corresponde a uma característica do sistema visível ao usuário final, ou seja, trata-se de um contexto do sistema que o usuário final tem contato direto. A feature também corresponde a uma unidade de comportamento utilizada para especificar conjuntos de requisitos funcionais e de qualidade. Este comportamento deve ser relevante para um ou vários stakeholders de um produto. Além disso, as features são utilizadas para agrupar um conjunto de requisitos relacionados, sendo uma forma de abstrair requisitos. A relação entre requisitos e feature ocorre de n para n.

O objetivo das features é diminuir a distância entre os usuários finais e os desenvolvedores com relação aos requisitos. Dessa forma, os usuários finais podem reportar defeitos ou novas necessidades através de features, onde os desenvolvedores podem interpretar transformando em ações que podem ser aplicadas ao ciclo de produção. Em suma, o feature model é utilizado para apresentar em alto nível as principais características comuns e variáveis em uma LPS.

A feature model é utilizada somente para modelagem dos produtos na etapa de domínio, mas não consegue representar como estes produtos serão gerados através dos artefatos presentes nos ativos base. Uma solução é o uso de configuration knowledge. Este é uma técnica utilizada para mapeamento de feature model para artefatos de implementação. Os artefatos de implementação podem ser modelados no configuration knowledge ou em um modelo a parte onde associará os artefatos de um modelo com os itens do feature model.

Notação FODA

O método FODA possui uma notação para representar graficamente uma feature model. Esta notação é utilizada para descrever o processo de análise de domínio. Nela é possível modelar features de forma explícita. O feature model representa uma hierarquia de propriedades de conceitos de domínio. Ele é um diagrama onde é possível descrever as features e itens adicionais como informações semânticas, pontos de variabilidade, prioridades e regras de dependência entre as features. Na Notação FODA, uma feature pode ser de três tipos:

• Obrigatória: este tipo de feature deve estar presente em todos os membros da LPS;
• Opcional: sua presença é opcional nos membros da LPS;
• Alternativa: composta de um conjunto de features, onde é possível escolher uma ou mais features que serão utilizadas.

A Figura 2 ilustra um feature model de um sistema eletrônico de e-shop. Os retângulos correspondem às features. As arestas com círculo preenchido em preto correspondem às features obrigatórias. As arestas com círculo vazado correspondem às features opcionais. As features alternativas são representadas por arcos. Os arcos vazados correspondem à escolha de uma feature alternativa. Os arcos preenchidos com preto correspondem a escolher mais de uma alternativa. Outro fator importante é que features podem estar relacionadas sem terem nenhum grau de parentesco. A seta direcional intitulada require indica que se uma feature A requer a feature B, a inclusão de A em um produto implica na inclusão também de B. A seta bidirecional intitulada excludes indica que a feature A exclui a feature B (ambas não podem fazer parte do mesmo produto).

A notação também permite a inserção de cardinalidade entre features e sub-features. A cardinalidade serve para remover ambiguidades e facilitar a representação da informação. As cardinalidades são definidas como:

• 0...1: pode-se escolher uma ou nenhuma feature do conjunto de sub-features;
• 1: uma feature deve ser escolhida do conjunto de sub-features;
• 0..*: nenhuma ou várias features podem ser selecionadas do conjunto de sub-features;
• 1..*: uma ou várias features podem ser selecionadas do conjunto de sub-features.

Ainda na Figura 2, pode-se observar que a primeira feature (obrigatória) é a E-shop. Esta define de uma forma geral o escopo de domínio que a LPS irá atender. Obrigatoriamente, os softwares criados pela LPS devem possuir feature de catálogos de produtos, pagamento, interface gráfica e de forma opcional as features segurança e insígnia. Na feature opcional de segurança, deve ser escolhida uma das opções: alta segurança ou média. Na feature de pagamento, ambas as features (cheque e cartão de crédito) podem ser escolhidas simultaneamente. Caso a feature cartão de crédito seja selecionada, obrigatoriamente a feature de alto nível de segurança deve ser selecionada. Na feature de interface gráfica, caso seja escolhida a opção mobile, a feature de insígnia não poderá ser selecionada para um novo produto.

Engenharia de linha de produto de software

A engenharia de LPS visa estabelecer etapas, processos, metodologias e demais recursos que facilitem o desenvolvimento de uma LPS trazendo como benefícios o tempo viável de desenvolvimento, redução de custos e produtos de qualidade. Existem três atividades essenciais e interativas que misturam práticas de negócios e tecnologia: desenvolvimento de ativos base, desenvolvimento do produto e gerenciamento da LPS. A interatividade diz respeito ao fato destas atividades, além de serem executadas de forma sequencial, podem ocorrer a qualquer momento durante o desenvolvimento da LPS.

Na atividade de desenvolvimento de ativos bases são produzidos os ativos que serão utilizados para o desenvolvimento de novos produtos. Nesta atividade ocorre a definição de aspectos comuns e variáveis da LPS para obtenção dos artefatos reutilizáveis. Os ativos base podem ser construídos com produtos existentes ou produtos do zero. Eles incluem arquitetura e sua documentação, especificações, componentes de software, ferramentas como geradores de componentes ou aplicação, modelos de desempenho, cronogramas, orçamentos, planos de teste, casos de teste, planos de trabalho e processo.

Na atividade de desenvolvimento de produtos ocorre a produção a partir dos ativos base existentes com base nos planos de produção satisfazendo exigências da LPS. O plano de produção é utilizado pelo engenheiro de software para saber como os ativos bases deverão ser utilizados para construir um novo produto. Os artefatos que são essenciais para a produção de um novo produto são a documentação de requisitos, escopo da linha de produto, ativos bases e o plano de produção.

A atividade de gerenciamento de LPS serve para fornecer e coordenar a infraestrutura necessária. Na gestão de LPS ocorre a supervisão da construção de ativos base e de desenvolvimento do produto. Em cada atividade existem grupos de desenvolvimento diferentes que devem interagir. A gestão também é responsável por planejar e gerenciar a criação de ativos bases e novos produtos. Uma informação importante é que a atividade de gestão é responsável pelo sucesso ou fracasso de uma LPS.

No geral, a implantação de uma LPS pode ser repentina ou gradual. A implantação repentina é a mais radical e economicamente viável. A empresa interrompe ou reduz drasticamente o desenvolvimento de novos produtos e os recursos são realocados para o desenvolvimento de ativos base. A implantação gradual é a mais utilizada pela indústria, onde a implantação é realizada ao longo dos projetos que vão sendo desenvolvidos. Na medida em que produtos são construídos, contribuições são realizadas à LPS. Nesta opção, apesar do custo de implementação ser maior, o risco de fracasso diminui.

Existem diversas abordagens para o desenvolvimento de LPS. Na abordagem proativa os ativos base são desenvolvidos para depois construir produtos. Na abordagem reativa, os ativos base já existem e vão sendo evoluídos com incrementos na medida que novos requisitos aparecem. Na abordagem extrativa, é feita uma análise dos produtos existentes e suas estruturas para poder extrair as características comuns e variáveis para derivar a implantação da LPS.

Ferramentas

Existem algumas ferramentas disponíveis no mercado que auxiliam na modelagem do feature model. Entre estas ferramentas estão a feature model plugin (fmp), XFeature e pure::variants.

A ferramenta fmp é um plugin gratuito utilizado na IDE Eclipse. Este plugin oferece suporte a modelagem de domínio. Os modelos gravados são do tipo XML. A modelagem de features é baseada em cardinalidade. Esta cardinalidade serve para restringir a quantidade de filhos a que uma feature pode estar relacionado. A Figura 3 ilustra a interface da ferramenta fmp.

A ferramenta XFeature (vide Figura 4) também é um plugin para o Eclipse. Ela permite acompanhar o processo de modelagem e configurar artefatos reusáveis, possui suporte a modelagem de domínio, sendo também é possível customizar meta-modelos. Os meta-modelos são estruturas que descrevem como as features estão sendo modeladas.

A ferramenta pure::variants (vide Figura 5) também é um plugin do Eclipse. A ferramenta tem suporte ao desenvolvimento e à implantação de LPS e famílias de software, dando suporte às atividades de análise, modelagem, implementação e implantação. Ela permite a modelagem de domínio de configuration knowledge permitindo o mapeamento entre features e artefatos de LPS.

Existe ainda uma ferramenta online chamada SPLOT (Software Product Line Tools), apresentada na Figura 6. Esta é formada por um conjunto de ferramentas que auxiliam no desenvolvimento de LPS. Entre as ferramentas disponíveis estão: editor de modelo de feature, análise automatizada, configuração de produto e repositório de modelo de feature.

Vantagens da LPS

A LPS traz diversos benefícios. Estes benefícios podem ser descritos de duas formas: benefícios tangíveis e benefícios intangíveis. Benefícios tangíveis são benefícios que podem ser medidos diretamente e estão relacionados a benefícios comerciais (Tabela 2). Os benefícios intangíveis são benefícios relatados pelos profissionais de TI, mas que não podem ser medidos e estão relacionados a benefícios organizacionais (Tabela 3).

Dificuldades ao adotar LPS

Por outro lado, a implantação de uma LPS não é trivial e requer muito esforço da organização. Este esforço pode ser descrito em termos de custo, reorganização de processos e mudança da mentalidade da equipe. Estes fatores podem inicialmente desmotivar a implantação e a mudança da cultura organizacional da organização. Outros fatores que podem constituir dificuldades no uso de LPS são:

• Falta de liderança comprometida: é necessário que a adoção de uma LPS para uma organização seja feita por um líder especializado em LPS que possa supervisionar, gerenciar e motivar a equipe;
• Falta de compromisso da gerência: pressões externas da organização podem levar o projeto de LPS a ficar em segundo plano e caminhar para o esquecimento;
• Abordagem inadequada: quando os produtos da LPS não possuem uma similaridade suficiente para garantir a viabilidade do modelo;
• Falta de compromisso da equipe: isto pode acontecer devido à mudança da cultura organizacional e do processo de desenvolvimento. Devido à natureza humana para resistência a mudanças, a falta de motivação pode impactar o comprometimento da equipe.

As linhas de produto de software foram desenvolvidas para apoiar diferentes atividades de um processo de desenvolvimento de software, como a LPS ágil e a LPS para teste de software. Além disso, questões associadas a requisitos não funcionais para as LPS e desafios que envolvem sua evolução também têm sido considerados.

Infelizmente, esse conceito ainda não é largamente utilizado em empresas de desenvolvimento. Contudo, é um tema que vem ganhando cada vez mais adeptos pelas suas vantagens superarem as dificuldades de seu uso, inclusive é um tema bastante recorrente em pesquisas na área de computação, o que indica que LPS ainda tem muito a evoluir.