Linhas de Produto de Software

Francisco Carlos da S. Neto, Geovanny M. de Oliveira Filho, Igor P. Silva Departamento de Sistemas e Informao Universidade Federal do Cear (UFC) Quixad, CE Brazil
{csilva547,geovannyfilho,igorpimentel}@gmail.com

Abstract. Over the last few years a new approach to software reuse has gained attention by both industry and the academy. This approach is known as Software Product Lines in which is based on the systematic reuse of software artifacts, through the exploration of commonality and manage variability among products, which are established under a single architecture. This paper presents some of the most important aspects of software product lines, such as variability, development processes and limitations in its application.. Resumo. Ao longo dos ltimos anos uma nova abordagem de reuso de software tem ganhado ateno tanto pela indstria quanto pela academia. Esta abordagem conhecida como Linhas de Produtos de Software na qual baseada na reutilizao sistemtica de artefatos de software, atravs da explorao de pontos comuns e a gesto de variabilidade entre os produtos, que so estabelecidos sob uma mesma arquitetura. Este trabalho apresenta alguns dos aspectos mais importantes sobre linhas de produtos de software, tais como variabilidade, processos de desenvolvimento e limitaes na sua aplicao.

1. Introduo
Com as iniciativas de componentizao de software e de desenvolvimento orientado a objetos, na dcada de 80, foram despertados na comunidade de software, as diferentes oportunidades e vantagens na reutilizao de cdigo. O sucesso destas atividades deu um grande passo para o incio de prticas de reuso para diversas etapas do processo de desenvolvimento de software incluindo subprodutos de trabalho como documentos, especificaes e modelos, o que aumentaria ainda mais a perspectiva de reduo de custos e ganho de produtividade. Aps o amadurecimento destas idias foi formulada a criao do modelo de Linhas de Produto de Software que apresenta um grande deslocamento no foco do paradigma tradicional de desenvolvimento de software. Dentro desse novo paradigma as organizaes que antes abordavam o desenvolvimento de software projeto a projeto, devem se concentrar na criao e manuteno de uma linha de produto de software, no qual ser a base de criao produtos de uma famlia de aplicaes. O grande objetivo do modelo ampliar ao mximo a eficincia e eficcia do processo de desenvolvimento, explorando todas as similaridades e controlando as variabilidades dos produtos da famlia de aplicao. Esse trabalho tem como objetivo apresentar o modelo de linhas de produto de software, suas vantagens tangveis e intangveis, assim como os riscos de sua

implantao nas organizaes. Isso levando em considerao os benefcios no Reuso de Software..

2. Linha de Produtos de Software Descrio e Conceito

Linha de produtos de Software o termo usado no Brasil para representar uma atividade que vem sendo internacionalmente executada e conhecida como Software Product-lines. Sem muitos esforos, pode se identificar uma relao simples e clara do termo usado para definir esse mtodo com as linhas de produo das indstrias de manufatura, as quais no final do sculo XIX introduziram uma revoluo no processo produtivo. Essas indstrias sugeriram na poca um processo de desenvolvimento seqencial de produtos, que fossem baseados em tarefas repetitivas, fazendo sempre o uso dos mesmos recursos e sendo executadas pelas mesmas pessoas. Segundo Cohen (2002), a definio de software product-line com maior aceitao na indstria de softaware a de Clements e Northrop que diz o seguinte: Uma linha de produto de software um conjunto de sistemas que usam software intensivamente, compartilhando um conjunto de caractersticas comuns e gerenciadas, que satisfazem as necessidades de um segmento particular de mercado ou misso, e que so desenvolvidos a partir de um conjunto comum de ativos principais e de uma forma preestabelecida [CLEMENTS; NORTHROP, 2002]. A definio dada por Clements e Northrop, permite o destaque de alguns termos que representam caractersticas importantes de uma linha de produto de software. Destaca-se por sustentar as principais vantagens propostas pelo modelo: conjunto comum de ativos, forma preestabelecida, e segmento particular de mercado ou misso. A anlise a seguir, descreve cada termo com suas caractersticas baseada em [CLEMENTS; NORTHROP, 2002]: Conjunto comum de ativos: Os ativos comuns so a essncia da linha de produto de software e correspondem a um conjunto de elementos customizveis, utilizados na construo dos softwares produzidos (produtos). Quando falamos em ativos, estamos citando, por exemplo: componentes de software, modelos de documentos utilizados no processo (artefatos), design-patterns utilizados pela equipe de desenvolvimento, documentao dos requisitos comuns famlia de produtos, a arquitetura da linha de produtos (que ser a base da arquitetura de cada produto gerado), cronogramas, e a arquitetura que o elemento chave nesse modelo e normalmente estudada a parte dos outros ativos. Forma preestabelecida: O processo de produo de softwares atravs de uma linha de produto realizado atravs de planos de produo. Esses planos so definidos para cada software (produto) que ser produzido pela linha. Ao definir um plano de produo, que dar origem a um novo produto, deve-se relacionar quais ativos faro parte deste produto e assim estabelecer um vnculo aos processos anexos de cada ativo utilizado. Os processos anexos so pequenos processos de utilizao contidos em cada ativo e que definem o que o ativo faz, qual a sua flexibilidade, qual a tcnica de configurao do ativo (se ele for flexvel). Essa natureza preestabelecida de

funcionamento do processo produtivo da linha de produto que garante o ganho de tempo e confiabilidade no desenvolvimento dos produtos. Segmento particular ou misso: Muitas vezes chamado de domnio, refere-se ao corpo de conhecimento ou rea de especializao em que a linha de produto atua. O domnio est diretamente relacionado com o conjunto de funcionalidades correlacionadas que os produtos da linha pretendem atender. Como a flexibilidade dos ativos (especialmente da arquitetura da linha) limitada, o modelo exige uma delimitao de um segmento de atuao. Sem essa delimitao o escopo da linha de produto poderia ser muito abrangente o que tornaria muito custoso criar e manter o conjunto comum de ativos. Pelas definies acima, pode-se observar que esses conceitos foram diretamente herdados da indstria de manufatura, que em outras palavras, quer dizer que herdaram o comportamento de dividir para conquistar.

2.1. Linha de Produtos de Software e Reuso Tradicional

Inicialmente, fcil relacionar a linha de produtos de software com o reuso tradicional, principalmente por ambos terem seu modelo baseado em reuso. Porm, existe uma pequena e talvez sutil diferena entre os modelos que impactuam diretamente nos resultados do projeto em questo. Em linha de produto de software existe uma melhor elaborao de seu modelo e mtodos de reuso do que o reuso tradicional, e torna-se a principal diferena entre ambos. A seguir, especificado as caractersticas individuais de cada modelo: Reuso tradicional: As organizaes possuem repositrios onde a sada de praticamente todo o esforo de desenvolvimento armazenado. Os repositrios contm de bibliotecas de reutilizao de componentes, mdulos e algoritmos. Os desenvolvedores (nesse caso, o pblico-alvo) so incentivados a usar dos artefatos dessa biblioteca. OBS.: Geralmente esse tipo de abordagem pode fazer com que leve-se mais tempo para encontrar e adaptar a funcionalidade desejada do que constru-la novamente. Linhas de produtos: Reuso planejado, automatizado e sistemtico. Considera-se o repositrio de reuso de uma linha de produtos como ativos de base. Os ativos de base incluem todos os artefatos mais caros para desenvolver como modelos de domnio, requisitos, arquitetura, componentes, casos de teste, Pouco ou nenhum cdigo novo para a customizao de uso no produto atual.

Dentro da reutilizao existe uma abordagem que se assemelha com o desenvolvimento de software em linhas de produto e que conhecida como clone and own. Especificao de Clone and own: Foco no produto individual. No implementa os mecanismos de variabilidade que caracterizam o desenvolvimento da famlia de produtos. A cada novo projeto a equipe busca na empresa um produto que possa ser reutilizado de outro projeto. Baseado em cpia e adaptao do produto ao novo projeto Pode representar uma boa economia
Table 1. Desvantagens do Clone and own comparados ao da linha de produtos

Vantagens de Linhas de produtos Todos os artefatos caros so reutilizados. Ativos desenvolvidos pensando

Desvantagens de Clone and own Apenas cdigo.

na Foco no produto individual.

reutilizao. Menor esforo em adaptar. Manuteno de ativos base na famlia. Maior esforo em adaptar. Manuteno de ativos base individual.

2.2. As Vantagens do Modelo de Linhas de Produtos de Software

Cohen (2003) prope um mapeamento das vantagens propostas pelo modelo e classificou os benefcios de uma linha de produto de duas formas: Tangveis: benefcios que podem ser medidos diretamente, como reduo do time-to-market ou reduo de defeitos. Intangveis: benefcios que os desenvolvedores relatam, mas que no podem ser medidos em termos de mtricas. Esses benefcios podem incluir satisfao do cliente, animo dos recursos, etc. Cohen em seu estudo explora essa classificao especificando uma lista de benefcios pertencentes as duas categorias, conforme pode ser visualizado abaixo.
Table 2. Benefcios tangveis de uma linha de produto de software

Benefcios Tangveis Lucratividade O repositrio de ativos permite que a organizao produza produtos voltados para um segmento especfico de mercado. O

benefcio dessa focalizao observado no aumento da participao de mercado e aumento da lucratividade Qualidade Uma reduo no nmero de defeitos relatados, comum em sistemas desenvolvidos em linhas de produto. A qualidade tambm pode ser medida em termos de reduo do tempo de correes e da reduo do efeito ripple (gerao de novos defeitos a partir de correes executadas) Performance dos produtos de software A utilizao de ativos aumenta a performance em relao ao desenvolvimento tradicional, especialmente com o aumento da maturidade da linha, o que faz com que os ativos estejam cada vez mais otimizados. Tempo de integrao Produtividade A equipe de desenvolvimento pode ser reduzida; O custo total de desenvolvimento cortado consideravelmente; O cronograma reduzido (maior velocidade de lanamento); O sistema possui uma flexibilidade documentada, o que facilita o atendimento das solicitaes de modificaes do cliente.
Table 3. Benefcios intangveis de uma linha de produto de software

O tempo de integrao no desenvolvimento incremental facilitado

Benefcios Intangveis Desgaste de profissionais Aceitabilidade dos desenvolvedores Menor desgaste dos profissionais, o que resulta em uma reduo do turnover de membros da equipe.

Aps um treinamento inicial, os desenvolvedores relatam satisfao em trabalhar com a abordagem baseada em ativos e arquitetura comuns.

Satisfao profissional

Os desenvolvedores relatam que o trabalho braal j foi realizado (desenvolvimento dos ativos de software), assim eles podem se concentrar em atividades mais interessantes, como o aperfeioamento e / ou inovao de elementos especficos

Satisfao do Cliente

Os ativos reduzem os riscos, aumentando a previsibilidade da entrega e diminuindo a taxa de defeitos. Esses fatores afetam positivamente o cliente (induzindo-o a preferir produtos derivados de linhas de produto).

3. Limitaes e Riscos na Implantao Um projeto de implantao de uma linha de produto de software pode ser considerado um projeto de inovao tecnolgica, j que modificado o paradigma que est implantado na organizao. A implantao tambm pode ser tratada como um projeto de adaptao a uma nova tecnologia, ou, a uma nova maneira de fazer negcio. Como toda mudana tecnolgica, esse tipo de projeto deve envolver uma avaliao da situao atual da empresa, uma definio do estado desejado e a elaborao de um plano para atingi-lo. Principalmente no caso de linhas de produto, por ser um modelo que interfere diretamente na maneira de como a empresa trabalho, fatores extratecnolgicos devem ser considerados, como por exemplo: a adaptabilidade das pessoas, o tipo de treinamento necessrio e a preparao do cliente para a nova maneira de trabalhar. Tradicionalmente, o projeto de implantao de uma linha pode ser abordado de duas maneiras: Repentino (completo): Essa abordagem radical e muitas vezes invivel economicamente. Nesse caso a empresa interrompe, ou reduz drasticamente, o desenvolvimento de novos produtos, re-alocando seus recursos para o desenvolvimento do repositrio de ativos (componentes de software, arquitetura da linha, definio de processo, definio do escopo e requisitos, entre outros).

Gradual (incremental): Essa abordagem geralmente a preferida pela indstria de software, ela suaviza os principais riscos da abordagem repentina e faz isto distribuindo o processo de implantao ao longo de vrios projetos de produtos. Como a interrupo da produo pode ser algo fatal para muitas empresas, j que elas dependem dos seus produtos, nesta abordagem a empresa continua desenvolvendo eles, no entanto, durante algumas fases de cada projeto so feitas contribuies para a

estrutura da linha de produto de forma gradual. Essas contribuies consistem no desenvolvimento de ativos para o repositrio da linha, ou seja, algum componente que seja til no s para o produto em questo, mas tambm para os outros membros da famlia. Nesta abordagem o custo total de implementao maior, no entanto, est diludo ao longo de projetos, diminuindo os riscos e facilitando a adaptao da organizao. Existem diversas dificuldades na implantao de uma linha de produto, e elas tm origem de diversas fontes. O processo de implantao envolve tanto pessoas como tecnologia, isso pode gerar muita resistncia dentro da organizao. Os principais problemas levantados por [COHEN, 2002] so:

Falta de um lder comprometido: no processo de implantao sugerida a alocao de um lder, uma pessoa que deve acreditar nos princpios do modelo e que estar supervisionando todo o processo e motivando as pessoas. O lder dever comunicar e motivar os acontecimentos para a gerncia alm de apoiar os desenvolvedores em momentos de dificuldade evitando que eles se desviem do modelo. Caso esta pessoa no receba a autoridade necessria, ou no acredite no modelo, ou simplesmente no exista, ser muito difcil manter o foco e a confiana durante o processo e alm de haver um grande risco de desistncia. Falta de compromisso da gerncia: a gerncia deve estar convencida sobre a viabilidade e sobre as vantagens que o projeto ir trazer pra dentro da organizao. comum que projetos de implantao de linhas de produto comecem com fora total, mas depois de um tempo, por presso do mercado e por falta de foco, tornem-se projetos coadjuvantes e logo caminhem para o esquecimento. Esse tipo de situao prejudicial para a organizao, pois desmoraliza os idealizadores alm de desperdiar muito recurso. Abordagem inadequada: o modelo de linha de produto deve ser tratado como um projeto estratgico para atingir objetivos corporativos. Mesmo seus objetivos variarem de organizao para organizao, eles esto sempre baseados no ganho de produtividade, custo e qualidade. So

baseados tambm na explorao das similaridades de produtos de uma famlia de aplicativos. Caso os produtos planejados para a linha no possuam similaridades suficientes para garantir a viabilidade do modelo, a linha poder nunca trazer o retorno planejado.

Falta de compromisso da equipe: O lder da linha deve obter o compromisso de toda equipe desenvolvedora com o processo de desenvolvimento da linha. Uma equipe que no acredita no modelo impossibilita o processo. Existe uma maneira de evitar esse tipo de problema, que envolver membros da equipe nas atividades de elaborao da linha fazendo eles se sentirem como parte do projeto. Interao insuficiente entre as equipes: A iniciativa de uma linha de produto ultrapassa os limites tradicionais da organizao. Inevitavelmente, o processo acaba envolvendo outras equipes da empresa como, por exemplo: a equipe de gerncia, a equipe de marketing e a equipe de engenharia. Uma falta de interao e colaborao entre essas elas pode impedir a obteno dos objetivos planejados. Um cenrio que ilustra a situao de uma falta de interao de equipes que, o pessoal de marketing pode vender produtos que a linha no suporta, ou o pessoal da engenharia produzir variabilidades da linha em que o mercado no demanda. Com a interao e colaborao esse problema resolvido. Evoluo da abordagem: Para manter uma linha de produto preciso uma melhoria contnua, ou seja, o processo da linha de produto deve ser revisado e atualizado periodicamente, caso isso no acontea, suas prticas iro tornar-se obsoletas e inapropriadas s novas necessidades vo surgindo. Com isso, novas prticas no previstas iro surgir informalmente devido as necessidades e podero comprometer todo o modelo. Falha de disseminao: O lder da linha deve tomar a responsabilidade de desenvolver e distribuir as documentaes em nvel e tipo apropriados para a organizao, treinar os envolvidos, e apoiar o processo no que for necessrio. Esses produtos so essenciais no processo de iniciao da

linha, e caso falhem, podem prejudicar tanto o cronograma como os objetivos da linha. Evidentemente, nenhuma organizao ir enfrentar todas as dificuldades e desafios citados acima, no entanto, a pesquisa realizada em [COHEN, 2002] revelou que pelo menos trs ou quatro destes elementos estiveram ou esto presentes nas organizaes entrevistadas conforme a Tabela 4.
Table 4. Problemas identificados pelas empresas entrevistas por [COHEN,

2002]

4. Concluso
Linhas de produtos de software vem a possibilitar uma melhor prtica de reuso em grandes organizaes, e permitir adaptao de boas prticas em pequenas empresas que desejam maximizar o uso de seu tempo, diminuir gastos, e melhorar o desempenho de seus projetos. Linhas de produtos vai alm de apenas reusar, seu objetivo o reuso consciente, planejado e sempre com trs focos principais: Aumentar seus ganhos; diminuir seus gastos e melhorar seu produtos. Com essa perspectiva, pode-se esperar que grandes projetos futuros possam ser mais baratos, de melhor qualidade, e ainda permitir um maior ganho de lucros da empresa desenvolvedora, devido as suas prticas de linhas de produto.

Referncias
[BOSH, 2000] J. BOSCH. Design and use of Software Architectures: Adopting and evolving a product-line approach. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 2000. [CLEMENTS; BROWNSWORD, 2004] P. CLEMENTS; L. BROWNSWORD. A Case Study in Successful Product Line Development, 2004. [COHEN, 2002] S. COHEN. Product Line State of the Practice Report, 2002. [COHEN, 2003] S. COHEN. Predicting when Software Product Lines Pays, 2003. [CLEMENTS; NORTHROP, 2002] P. CLEMENTS; L. NORTHROP. Software Product Lines: Practices and patterns. Boston: Addison-Wesley, 2002, 563 p.

[DA SILVA ET AL, 2011] F. A. P. DA SILVA; P. A. DA M. S. NETO; V. C. GARCIA; P. F. MUNIZ. Linhas de Produtos de Software: Uma tendncia da indstria, 2011. [DURSCKI ET AL, 2004] R. C. Durscki; M. M. Spinola; R. C. Burnett; S. S. Reinehr. Linhas de Produto de Software: Riscos e vantagens de sua implantao, 2004. [KANG, 1990] K. KANG. Feature-Oriented Domain Analysis Feasibility Study. Technical report, SEI Technical Report, 1990. [LINDEN, 2007] S. K. LINDEN, E. ROMMES. Software Product Lines in Action:The Best Industrial Practice in Product Line Engineering. Springer-Verlag, 2007. [LOBO; RUBIRA, 2009] A. E. C. LOBO; C. M. F. RUBIRA. Um Estudo para Impantao de Linha de Produto de Software Baseada em Componentes, 2009. [LONG, 2002] C. A. LONG. Software Product Lines: Practices And Patterns [book review]. Software, IEEE, 19(4):131 132, jul/aug 2002. [MUHAMMAD ET AL, 2010] M. A. BABAR; L. CHEN; F. SHULL. Managing Variability in Software Product Lines.IEEE Software, 27:8991, 94, 2010. [POHL ET AL, 2005] K. POHL; G. BCKLE; F. J. VAN DER LINDEN. Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2005.