VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

Linhas de Produto de Software: riscos e vantagens de sua * implantao

Roberto C. Durscki1, Mauro M. Spinola1, Robert C. Burnett2, Sheila S. Reinehr1,2
1

Departamento de Engenharia de Produo Escola Politcnica da Universidade de So Paulo (USP) - Avenida Prof. Luciano Gualberto, n 380 - So Paulo/SP Pontifcia Universidade Catlica do Paran - Rua: Imaculada Conceio, 1155 - Prado Velho - Curitiba - PR

Abstract. This paper presents the newly founded concept of Software productlines engineering. It will hold special attention to the advantages and disadvantages of the model, as well as to the risks of its implementation. Finally, some models of viability assessment will be described and considerations to the researches being made will be presented. Resumo. Esse artigo abordar o conceito do modelo de linhas de produto de software, suas vantagens e desvantagens, assim como os riscos de sua implantao. So abordados os modelos atuais para avaliao de viabilidade de implantao de linhas de produto, assim como consideraes sobre as deficincias dos modelos atuais e as conquistas obtidas neste campo de pesquisa.

1. Introduo
As iniciativas de componentizao de software e de desenvolvimento orientado a objetos na dcada de 80 despertaram a comunidade de software para as oportunidades e vantagens da reutilizao de cdigo. O sucesso destas atividades instigou iniciativas 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. A evoluo destas idias levou a formulao do modelo de Linhas de Produto de software que apresenta um deslocamento no foco do paradigma tradicional de desenvolvimento de software. Dentro desse novo paradigma as organizaes que anteriormente abordavam o desenvolvimento de software projeto a projeto, devem concentrar seus esforos na criao e manuteno de uma linha de produto de software, a qual ser a base para a produo de uma coleo de produtos pertencentes a uma famlia. O modelo tem como objetivo ampliar ao mximo a eficincia e eficcia do

Esse artigo um subproduto do projeto MILPS de pesquisa cientfica do grupo Qualidade de Processo, Projeto e Produto de Software da PUC-PR, financiado parcialmente com recursos do CNPq (PI: 55.2217/02-6).

155

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

processo de desenvolvimento, explorando as similaridades e controlando as variabilidades dos membros da famlia. 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. Apresentar-se- dois modelos de anlise de viabilidade da implantao destacando para o leitor quais os pr-requisitos e fatores facilitadores do processo. Finalmente, consideraes finais sobre os assuntos do artigo so apresentadas, com destaque para questes sobre as carncias e perspectivas das pesquisas atuais, observaes sobre os modelos de avaliaes entre outros assuntos.

2. Linha de Produto de Software: o conceito

O termo Linha de Produto de Software uma adaptao do que vm sendo utilizado internacionalmente como Software Product-lines. Esse termo uma clara referncia s linhas de produo das indstrias de manufatura, as quais, no final do sculo XIX, introduziram uma revoluo no processo produtivo, sugerindo o desenvolvimento seqencial de produtos, baseado em tarefas repetitivas, executadas sempre pelas mesmas pessoas que dispunham dos recursos materiais que necessitavam. Conforme Cohen, [COH02], a definio de software product-line com maior aceitao na indstria 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 [CLE02].

Dentro desta definio, alguns termos devem ser destacados, pois representam as caractersticas mais importantes de uma linha de produto e sustentam as principais vantagens propostas pelo modelo. Os termos so: conjunto comum de ativos, forma preestabelecida e segmento particular de mercado ou misso. A seguir, esses termos sero descritos com base em [CLE02]: Conjunto comum de ativos: Os ativos so a essncia da linha de produto e correspondem a um conjunto de elementos customizveis, utilizados na construo dos softwares produzidos (produtos). Entre os ativos esto, 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 etc. Dentre estes elementos, a arquitetura o elemento chave 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 156

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

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. Como se pode observar pela definio acima, esses conceitos foram diretamente derivados da indstria de manufatura, ou seja, derivam da filosofia de dividir para conquistar. Detalhando melhor, o processo sugere dividir o produto em pequenas partes, mais compreensveis e gerenciveis (ativos); possuir especificaes claras e sem ambigidades para produo / montagem (forma preestabelecida) e, atender a um domnio especfico (segmento particular ou misso) para que, como em uma linha de montagem da indstria tradicional, cada novo produto seja uma reutilizao de partes de produtos construdos anteriormente, pertencentes mesma famlia, e, preferencialmente, com um mnimo de esforo adicional de construo.

3. As Vantagens do Modelo de Linhas de Produto de Software

Muitas vantagens so atribudas ao modelo de linhas de produto, especialmente na esfera terico-acadmica. No entanto, antes de discutir conceitualmente as vantagens apresentar-se- resumidamente as vantagens relatadas em um estudo de caso, [CLE96], onde apresentado com detalhes o processo de implantao de linhas de produto na CelsiusTech (empresa sub-contratada da marinha sueca para o desenvolvimento de sistemas para embarcaes militares). Ao fim da implantao a empresa constatou que: A participao do software no custo total dos sistemas caiu de 65% para 20%; Reduo da mo de obra de desenvolvimento de software (dos projetos de uma famlia) de 200 pessoas para menos de 50; O tempo de entrega (time-to-market) passou de poucos anos para meses; 70% a 80% dos sistemas de software eram compostos de componentes do repositrio de ativos; Houve um aumento na qualidade dos sistemas desenvolvidos e na satisfao dos clientes.

Esse exemplo deixa claro as diversas vantagens que o modelo pode trazer para uma organizao que desenvolve intensamente software, e este no um caso exclusivo. Ganhos semelhantes foram relatados em outras grandes empresas como Nokia, Philips e Avaya Telecom. Para mapear melhor as vantagens propostas pelo modelo, Cohen, em [COHEN 2003], classificou os benefcios de uma linha de produto de duas maneiras:

157

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

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.

Em seu estudo, Cohen explora ainda mais essa classificao, apresentando uma lista de benefcios das duas categorias. Uma adaptao destas tabelas pode ser visto na Tabela 1 e na Tabela 2.
Tabela 1. Benefcios tangveis de uma linha de produto de software. Lucratividade Benefcios Tangveis 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. 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). 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. O tempo de integrao no desenvolvimento incremental facilitado. 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.

Qualidade

Performance dos produtos de software Tempo de integrao Produtividade

Tabela 2. Benefcios intangveis de uma linha de produto de software. Desgaste de profissionais Aceitabilidade dos desenvolvedores Satisfao profissional Benefcios Intangveis 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. 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. 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).

Satisfao do Cliente

Como era de se esperar, esses benefcios no vm de graa, por sinal, muito longe disto. A implantao e institucionalizao de uma linha de produto de software muito custosa e, em conseqncia disto, demanda muito cuidado e planejamento. Na prxima seo sero discutidas as dificuldades de implantao e os principais riscos dessa empreitada.

158

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

4. Dificuldades e Riscos da Implantao

Segundo [CLE02] um projeto de implantao de uma linha de produto de software pode ser considerado um projeto de inovao tecnolgica, ou seja, um projeto de adaptao uma nova tecnologia, ou, uma nova maneira de fazer negcio. Especificamente no caso de linhas de produto, ambas as definies se aplicam tornando o projeto ainda mais delicado. Como toda mudana tecnolgica, esse tipo de projeto deve envolver uma avaliao da situao atual da empresa, uma articulao do estado desejado e a elaborao de um plano para atingir este estado. Especificamente no caso de linhas de produto, por ser um modelo que interfere diretamente na maneira de trabalhar da empresa, fatores extratecnolgicos devem ser considerados, como 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 a mais radical e muitas vezes economicamente invivel. 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, normalmente preferida pela indstria (ver [COH02]), 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, nesta abordagem a empresa continua desenvolvendo seus produtos, no entanto, durante algumas fases de cada projeto so feitas contribuies para a estrutura da linha de produto. 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.

As dificuldades de implantao de uma linha so diversas e podem vir de vrias fontes. Conforme mencionado, o processo envolve tanto pessoas como tecnologias e pode sofrer muita resistncia dentro da organizao. Os principais problemas levantados por [COH02] so: Falta de um lder comprometido: para o processo de adoo sugere-se a alocao de um lder, uma pessoa que acredita nos princpios do modelo e que estar supervisionando o processo e motivando as pessoas. O lder estar comunicando e motivando os acontecimentos para a gerncia alm de apoiar os desenvolvedores em momentos de dificuldade evitando que eles desviem do modelo. Caso esta pessoa no receba a autoridade necessria, no acredite no modelo, ou simplesmente no exista, muito difcil manter o foco e a confiana durante o processo e h um grande risco de desistncia. Falta de compromisso da gerncia: a gerncia deve estar convencida da 159

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

viabilidade e das vantagens que o projeto vai trazer para a organizao. comum que projetos de implantao de linhas de produto comecem com fora total, mas ao longo do tempo, por presso do mercado e por falta de foco, tornem-se projetos coadjuvantes e logo caminhem para o esquecimento. Esse tipo de situao muito ruim para a organizao, pois desmoraliza os idealizadores alm de desperdiar muito recurso. Abordagem inadequada: a linha de produto deve ser um projeto estratgico para atingir objetivos corporativos. Apesar de seus objetivos variarem de empresa para empresa, eles esto sempre baseados no ganho de produtividade, custo e qualidade baseados na explorao das similaridades de produtos de uma famlia. 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 e tornar-se um fim em si mesma. Falta de compromisso da equipe: Assim como o problema relatado com a gerncia, o lder da linha deve obter o compromisso da equipe desenvolvedora com os princpios e com o processo de desenvolvimento da linha. Uma equipe que desacredita o modelo impossibilita o processo. Uma maneira de evitar esse tipo de problema envolver membros da equipe nas atividades de elaborao da linha fazendo-os sentir-se parte do projeto. Interao insuficiente entre as equipes: A iniciativa de uma linha de produto transcende os limites tradicionais da organizao. O processo acaba, inevitavelmente, envolvendo diversas equipes como gerncia, marketing e engenharia. Uma falta de interao e colaborao entre essas equipes pode impedir a obteno dos objetivos planejados. Em seu trabalho, [EBE03] detalham que o envolvimento de marketing na definio do escopo e dos requisitos de uma linha de produto fundamental para o sucesso do projeto, caso contrrio, o pessoal de marketing pode vender produtos que a linha de produto no suporta, ou, em contrapartida, o pessoal de engenharia pode permitir variabilidades na linha de produto que no so demandadas pelo mercado. Padronizaes desapropriadas: H uma tendncia nas organizaes de assumir que a adoo de padres ir guiar automaticamente para a implantao de uma linha de produto. A institucionalizao prematura e impensada de padres, muitas vezes obsoletos, pode limitar as opes de tecnologia da linha, prejudicando o escopo da mesma. Os padres devem ser estudados caso a caso e, apesar de serem importantes para a linha, devem ser discutidos antes de sua implementao. Adaptao insuficiente: Assim como a arquitetura e os componentes que devem permitir um certo grau de adaptabilidade dentro da linha de produto, as prticas organizacionais (padronizadas ou no) devem permitir um grau de adaptao, ou melhor, personalizao voltadas para as caractersticas da linha. A falta de adaptabilidade ou uma adaptao mal pensada pode sub-otimizar a performance das equipes ou gerar desvios imprevistos das atividades envolvidas no processo da linha de produto. Evoluo da abordagem: Esse fator tambm poderia ser chamado de melhoria 160

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

contnua, ou seja, caso o processo da linha de produto no seja revisado e atualizado periodicamente, suas prticas iro tornar-se obsoletas e inapropriadas s novas necessidades que surgiro. Neste caso, novas prticas no-previstas iro surgir informalmente devido s 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 ou processo de iniciao da linha, e caso falhem, podem prejudicar tanto o cronograma como os objetivos da linha.

Evidentemente, nenhuma organizao ir enfrentar todos as dificuldades e desafios citados acima, no entanto, a pesquisa realizada em [COH02] revelou que pelo menos trs ou quatro destes elementos estiveram ou esto presentes nas organizaes entrevistadas conforme a Tabela 3.
Tabela 3 - Problemas identificados pelas empresas entrevistadas em [COH02]. Problema: Resistncia Organizacional Resistncia Gerencial Resistncia dos Desenvolvedores Preocupaes e desconfianas com o tamanho do investimento Falta de recursos devidamente treinados e capacitados Incapacidade de analisar e prever o impacto da implantao Preocupao sobre o longo tempo para retorno do investimento Percentual identificado: 52% 36% 32% 45% 29% 19% 18%

Alguns riscos identificados em [COH02] foram os seguintes: Clientes desinformados ou cticos com relao s mudanas; Tendncias da organizao de retornar ao modelo antigo de desenvolvimento, e Momento inoportuno para implantao (empresas que resolveram iniciar o projeto de implantao do modelo no meio do desenvolvimento de projetos crticos para a empresa).

5. Avaliando a Viabilidades e Justificando a Iniciativa

Conforme exposto nos tpicos anteriores, o modelo apresenta muitas perspectivas de melhorias, assim como, de dificuldades e riscos. Essa dicotomia, tradicional nos projetos de mudana/inovao tecnolgica, demanda muito cuidado da organizao e, acima de tudo, um estudo criterioso para avaliar a viabilidades e o custo x benefcio da aplicao da nova tecnologia na empresa. Diversos estudos esto sendo desenvolvidos, desde a anlise do escopo e requisito da linha at sistemas automatizados de montagem dos produtos, para facilitar a implantao e utilizao de linhas de produto de software. Dentre estes estudos destacase, no tema de anlise de viabilidades, as abordagens ABC para linhas de produto e o Modelo de Avaliao Orientado a Objetivos para Domnios de Linhas de Produto. A seguir, sero explorados com maior profundidade esses modelos, assim como, alguns 161

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

conceitos fundamentais para a compreenso dos mesmos. 5.1 Modelo de Avaliao Orientado a Objetivos para Domnios de Linhas de Produto Antes de introduzir o modelo importante compreender o significado do termo domnio para o contexto de linhas de produto de software. O termo Domnio A literatura no apresenta um consenso na definio deste termo, no entanto, muitos autores concordam com o conceito de Clements e Northrop, [CLE02], que dizem o seguinte:
Domnio corresponde a uma rea de conhecimento ou atividade caracterizado por uma coleo de conceitos e terminologias compreendidos e aceitos pelos profissionais da rea.

Essa definio, no entanto, muito vaga o que acaba gerando interpretaes distintas. Em um sentido mais amplo, domnio pode ser considerado como uma rea de atuao de mercado, a qual poder ser o objetivo dos produtos de uma linha de produto de software. Esse o caso da empresa MarketMaker, citada em [GAC01], que ao iniciar seu plano de implantao de linha de produto definiu seu domnio como sendo gesto de fundo monetrios e bancrios, ou seja, seu foco de mercado. Uma outra definio, mais restrita que a anterior, a de que domnios so grupos de aplicativos de softwares voltados para um determinado nicho de mercado, como sistemas gestores de bancos de dados, sistemas de intranet, sistemas de CRM, etc. Nestes casos a definio de domnio est mais voltada para os produtos do que para o mercado. Finalmente, domnio pode ser considerado uma sub-rea dos conhecimentos envolvidos no desenvolvimento dos produtos de softwares em uma linha de produto. Assim, uma linha de produto que desenvolve sistemas bancrios, vai possuir ativos (componentes e artefatos) dos domnios de interface com usurio, comunicao, segurana, algoritmos financeiros, etc. O Modelo O Modelo de Avaliao Orientado a Objetivos para Domnios de Linhas de Produto tem como objetivo priorizar os domnios que sero inseridos em uma linha de produto considerando que esta ser implantada gradativamente, de forma incremental. O modelo foi desenvolvido para a empresa Avaya Telecom. com o intuito de identificar quais mdulos de uma famlia de sistemas so prioritrios para desenvolvimento no paradigma de linhas de produto. Na descrio do modelo, [WEI03], fica claro que a interpretao dos autores por domnio alinhada terceira definio apresentada na seo 5.1.1, ou seja, que domnios so sub-reas de conhecimento envolvidas no desenvolvimento de uma famlia de sistemas. Para avaliar a probabilidade de sucesso de um domnio no modelo de linha de produto, os autores decompem os domnios em mdulos para poder avali-los com mais 162

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

clareza. Esse mdulos so os componentes fsicos das sub-reas de conhecimento, conforme pode ser observado na Figura 1.

Figura 1 - Viso geral de uma linha de produto com destaque para os domnios e mdulos.

O modelo sugere entrevistas com os especialistas de cada domnio para obter uma pontuao de cada mdulo em diversos critrios utilizados na anlise dos domnios. Esses critrios so separados em quatro grupos: Atividade: avalia o quo ativo so os mdulos de um domnio, ou seja, a freqncia com que so modificados e a quantidade de manuteno que requerem. Retorno: avalia a importncia do domnio para os objetivos de mercado da empresa, a importncia do domnio para o cliente, seu potencial de gerar produtos diferenciados, etc. Independncia: quanto mais dependente um domnio for de outros o mais difcil ser para desenvolv-lo independentemente em uma linha de produto. Esse critrio avalia o grau de dependncia de um mdulo com seus mdulos adjacentes. Viabilidade: avalia questes como complexidade de cdigo, maturidade dos mdulos e restries de recursos (capital e humano).

Cada um dos grupos acima composto por diversos critrios, e sua graduao conseqncia da aplicao de formulas que relacionam de forma ponderada os critrios constituintes. Com o resultado da graduao de cada grupo o modelo utiliza duas novas frmulas para obter uma graduao normalizada de dois parmetros: impacto coorporativo e probabilidade de sucesso. Mapeando os diversos mdulos numa matriz que confronta 163

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

essas variveis, possvel selecionar os domnios mais promissores para ingressarem no paradigma de linhas de produto, ou seja, aqueles com alta probabilidade de sucesso e alto impacto coorporativo (considerando que impacto visto como o grau de influencia positiva no negcio). 5.2 A Abordagem ABC para Linhas de Produto de Software Essa abordagem utiliza o ABC de estudos de casos de negcio para a realidade das linhas de produto. Nessa abordagem, detalhada em [COH03], utilize-se trs variveis para avaliar a viabilidade da implantao do modelo: Aplicaes: quantos sistemas a organizao planeja entregar (produzir) usando os ativos da linha de produto durante o perodo do caso de negcio estudado; quanto esses produtos iro variar ao longo do tempo? Benefcios: as projees de economia, ou outros retornos, provenientes da utilizao dos ativos da linha de produto; Como o investimento contnuo no desenvolvimento dos ativos ir ajudar essas projees? Custos: os custos de re-uso, ou seja, gastos que a organizao vai enfrentar ao desenvolver utilizando os ativos da linha de produto.

Em [COH03] este modelo utilizado para guiar a implantao de uma linha de produto de software, de forma incremental, no NRO (Escritrio de Reconhecimento de Territrios) das foras armadas do EUA. Para compreender melhor como o modelo funciona h trs termos que devem ser esclarecidos: Cost of Reuse (COR): o custo do reuso, ou seja, o quanto prtica do reuso est acrescentando de trabalho aos desenvolvedores e, conseqentemente, custos organizao. Esse fator pode ser diminudo com treinamento, ferramentas automatizadas, etc. Degree of Reuse (DOR): o grau de reuso, esse termo referencia o grau de reuso pretendido em um projeto, ou seja, qual o percentual do produto que composto de ativos reutilizveis da base de ativos da linha de produto. O objetivo aumentar esse valor conforme a linha evolui para desfrutar, cada vez mais, das vantagens do modelo. Refresh rate: taxa de atualizao (renovao), essa medio serve para determinar a freqncia com que um domnio sofre uma desatualizao a ponto de necessitar uma renovao dos seus ativos. Normalmente, conforme o tempo vai passando e as tecnologias do domnio evoluindo, o COR vai aumentando e o DOR diminuindo. Chega um momento onde a aplicao dos ativos do repositrio da linha no mais vantajosa ou, at mesmo, impraticvel (como no caso de uma mudana de plataforma) e a empresa deve re-popular o repositrio a um custo elevado. Um domnio que tem uma taxa de atualizao muito alta no um bom candidato para linhas de produto, pois dificilmente vai desfrutar de vantagem econmica na abordagem.

Para o desenvolvimento do caso de negcio aplicando o modelo ABC, a empresa deve antes de tudo, planejar quantas iteraes planeja realizar, ou seja, em quantas etapas ser estabelecida sua linha de produto. Para cada iterao deve-se planejar quais aplicaes 164

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

sero desenvolvidas (mesmo que parcialmente), qual o COR e o DOR planejados e qual o retorno esperado ao fim de cada iterao. No que toca as aplicaes, a organizao deve ver qual sua perspectiva de lanamento de novos produtos no perodo de implantao, pois, sem produtos, no h retorno. Ainda com relao aos produtos, deve-se avaliar qual ser o COR e o DOR de cada deles por iterao. Esses valores iro auxiliar no levantamento dos custos e retornos. Quanto aos benefcios, a organizao deve estabelecer metas claras quanto aos objetivos de reduo de custo, aumento de lucratividades, diminuio de time-to-market ou qualquer outro objetivo plausvel e perceptvel que espere ter com a iniciativa. Deve-se considerar que esses benefcios esto diretamente ligados quantidade de produtos desenvolvidos e maturidade dos processos da linha conforme a evoluo das iteraes. Finalmente quanto aos custos, seo de maior trabalho, a empresa deve utilizar dados, mtricas e projees para ilustrar os benefcios financeiros da adoo do modelo e determinar sua viabilidade ou no. Os principais elementos desta seo so: Custos histricos: levantar os custos de desenvolvimento dos sistemas no paradigma anterior, projeto a projeto. Custos de desenvolvimento dos ativos: os custos do desenvolvimento e manuteno dos ativos durante o perodo coberto pelo caso de negcio. Custo incremental e economias: o custo de implementao de cada iterao do processo e as economias projetadas para cada iterao.

Planificando esses dados, possvel analisar a projeo de custo para cada sistema, tanto no caso da utilizao do reuso como no caso negativo. Vale ressaltar que se os produtos forem desenvolvidos em seqncia eles sero criados em momentos diferentes da linha de produto, ou seja, iteraes diferentes do plano de implantao, isso faz com que o COR e o DOR mudem e conseqentemente as projees de custo e economia para cada sistema. Com estas projees de custos e economia, o modelo se prope a tornar mais clara a visibilidade para determinar se a implantao de uma linha de produto de software para um domnio vivel ou no e, alm disso, servir como um instrumento para apoiar a negociao gerencial para aprovao e captao de fundos para o projeto.

6. Comentrios Finais
Neste trabalho, foi apresentado ao leitor o conceito de Linhas de Produto de Software e seus principais elementos constituintes, foram apresentadas tambm, as principais vantagens previstas pelo modelo e constatadas pela indstria, assim como, as dificuldades e riscos do processo de implantao. Finalmente, dois modelos de avaliao de viabilidade dirigidos para linhas de produto de software em empresas so expostos, juntamente com a definio de alguns termos essenciais para a correta compreenso dos modelos. Ao fim deste trabalho possvel fazer as seguintes observaes sobre os tpicos expostos:

165

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

O estudo de linhas de produto de software est em plena ascenso e migrando, gradativamente, do ambiente acadmico e de pesquisa, para as indstrias, conforme pode ser observado em [COH02]. Os institutos e grupos que dominam o assunto de linhas de produto de software e que esto aplicando esse modelo nas indstrias ainda so muito poucos. Isso serve de motivao para que as pesquisas sobre este assunto migrem para outras naes, incluindo o Brasil, acelerando as pesquisas e evitando que o setor industrial necessite importar pessoas e consultorias para desfrutar do modelo. Quanto aos riscos, fica evidente que so muitos os pontos que podem interferir no sucesso da implantao do modelo nas indstrias, no entanto, os problemas no so novos e, em sua maioria, so os mesmo observados em outros projetos de melhoria de processos. Assim, a adaptao de prticas existentes pode ser uma boa soluo para os novos problemas. No que toca o tema principal do artigo, os modelos de avaliao de viabilidade, ainda h um longo caminho pela frente. As iniciativas, ainda pouco abrangentes e demasiadamente subjetivas, no garantem a segurana que as empresas esperam. Alm disso, os estudos de caso de aplicao dos modelos ([COH03], [WEI03]) ainda so muito recentes e no apresentam resultados concretos da iniciativa. Espera-se que a pesquisa em mtodos e modelos de avaliao de viabilidade continue, pois estes so essenciais para convencer as indstrias a considerar a implantao, e conseqente disseminao, do modelo.

Referncias Bibliogrficas
[CLE02] CLEMENTS, Paul; NORTHROP, Linda. Software Product Lines: Practices and Patterns. Boston: Addison-Wesley, 2002, 563 p. [COH02] COHEN, Sholom. Product Line State of the Practice Report. Disponvel em http://www.sei.cmu.edu/publications/documents/02.reports/02tn017.html, 08/07/04. [CLE96] CLEMENTS, Paul; BROWNSWORD, Lisa. A Case Study in Successful Product Line Development. Disponvel em http://www.sei.cmu.edu/publications/documents/96.reports/96tr016.html, 04/07/04. [COH03] COHEN, Sholom; Predicting when Software Product Lines Pays. Disponvel em: http://www.sei.cmu.edu/pub/documents/03.reports/pdf/03tn017.pdf, 21/05/04. [GAC01] GACEK, Cristina; et. al. Successful Software Product Line Development in a Small Organization. Universidade Kaiserslautern, disponvel em: http://docserver.fhg.de/iese/2001/reports/013.pdf, 04/07/04. [EBE03] EBERT, Christof; SMOUTS, Michel. Tricks and Traps of Initiating a Product Line Concept in Existing Products. Anais do IEEE International Conference on Software Engineering 2003, pp. 520-525. IEEE Comp. Soc. Press. Los Alamitos, EUA, 2003. [WEI03] WEISS, David M.; GEPPERT, Birgit. Goal-Oriented Assessment of ProductLine Domains. Anais do IEEE Ninth International Software Metrics Symposium 2003, pp. 180-189. IEEE Comp. Soc. Press. Los Alamitos, EUA, 2003.

166