Linhas de Produto de Software: riscos e vantagens de sua implantação *

Transcrição

1 Linhas de Produto de Software: riscos e vantagens de sua implantação * Roberto C. Durscki 1, Mauro M. Spinola 1, Robert C. Burnett 2, Sheila S. Reinehr 1,2 1 Departamento de Engenharia de Produção Escola Politécnica da Universidade de São Paulo (USP) - Avenida Prof. Luciano Gualberto, nº São Paulo/SP 2 Pontifícia Universidade Católica do Paraná - Rua: Imaculada Conceição, 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 implantação. São abordados os modelos atuais para avaliação de viabilidade de implantação de linhas de produto, assim como considerações sobre as deficiências dos modelos atuais e as conquistas obtidas neste campo de pesquisa. 1. Introdução As iniciativas de componentização de software e de desenvolvimento orientado a objetos na década de 80 despertaram a comunidade de software para as oportunidades e vantagens da reutilização de código. O sucesso destas atividades instigou iniciativas de reuso para diversas etapas do processo de desenvolvimento de software incluindo subprodutos de trabalho como documentos, especificações e modelos, o que aumentaria ainda mais a perspectiva de redução de custos e ganho de produtividade. A evolução destas idéias levou a formulação 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 organizações que anteriormente abordavam o desenvolvimento de software projeto a projeto, devem concentrar seus esforços na criação e manutenção de uma linha de produto de software, a qual será a base para a produção de uma coleção de produtos pertencentes a uma família. O modelo tem como objetivo ampliar ao máximo a eficiência e eficácia do * Esse artigo é um subproduto do projeto MILPS de pesquisa científica do grupo Qualidade de Processo, Projeto e Produto de Software da PUC-PR, financiado parcialmente com recursos do CNPq (PI: /02-6). 155

2 processo de desenvolvimento, explorando as similaridades e controlando as variabilidades dos membros da família. Esse trabalho tem como objetivo apresentar o modelo de linhas de produto de software, suas vantagens tangíveis e intangíveis, assim como os riscos de sua implantação nas organizações. Apresentar-se-á dois modelos de análise de viabilidade da implantação destacando para o leitor quais os pré-requisitos e fatores facilitadores do processo. Finalmente, considerações finais sobre os assuntos do artigo são apresentadas, com destaque para questões sobre as carências e perspectivas das pesquisas atuais, observações sobre os modelos de avaliações entre outros assuntos. 2. Linha de Produto de Software: o conceito O termo Linha de Produto de Software é uma adaptação do que vêm sendo utilizado internacionalmente como Software Product-lines. Esse termo é uma clara referência às linhas de produção das indústrias de manufatura, as quais, no final do século XIX, introduziram uma revolução no processo produtivo, sugerindo o desenvolvimento seqüencial de produtos, baseado em tarefas repetitivas, executadas sempre pelas mesmas pessoas que dispunham dos recursos materiais que necessitavam. Conforme Cohen, [COH02], a definição de software product-line com maior aceitação na indústria é 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 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 [CLE02]. Dentro desta definição, alguns termos devem ser destacados, pois representam as características mais importantes de uma linha de produto e sustentam as principais vantagens propostas pelo modelo. Os termos são: conjunto comum de ativos, forma preestabelecida e segmento particular de mercado ou missão. A seguir, esses termos serão descritos com base em [CLE02]: Conjunto comum de ativos: Os ativos são a essência da linha de produto e correspondem a um conjunto de elementos customizáveis, utilizados na construção dos softwares produzidos (produtos). Entre os ativos estão, por exemplo: componentes de software, modelos de documentos utilizados no processo (artefatos), design-patterns utilizados pela equipe de desenvolvimento, documentação dos requisitos comuns à família 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 produção de softwares através de uma linha de produto é realizado através de planos de produção. Esses planos são definidos para cada software (produto) que será produzido pela linha. Ao definir um plano de produção, que dará origem a um novo produto, deve-se relacionar quais ativos farão parte deste produto e assim estabelecer um vínculo aos processos anexos de cada ativo utilizado. Os processos anexos são pequenos processos de utilização contidos em cada ativo e que definem o que o ativo faz, qual a sua flexibilidade, qual a técnica de configuração do 156

3 ativo (se ele for flexível). 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 missão: Muitas vezes chamado de domínio, refere-se ao corpo de conhecimento ou à área de especialização em que a linha de produto atua. O domínio 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 delimitação de um segmento de atuação. Sem essa delimitação 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 definição acima, esses conceitos foram diretamente derivados da indústria de manufatura, ou seja, derivam da filosofia de dividir para conquistar. Detalhando melhor, o processo sugere dividir o produto em pequenas partes, mais compreensíveis e gerenciáveis (ativos); possuir especificações claras e sem ambigüidades para produção / montagem (forma preestabelecida) e, atender a um domínio específico (segmento particular ou missão) para que, como em uma linha de montagem da indústria tradicional, cada novo produto seja uma reutilização de partes de produtos construídos anteriormente, pertencentes à mesma família, e, preferencialmente, com um mínimo de esforço adicional de construção. 3. As Vantagens do Modelo de Linhas de Produto de Software Muitas vantagens são atribuídas ao modelo de linhas de produto, especialmente na esfera teórico-acadêmica. 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 implantação de linhas de produto na CelsiusTech (empresa sub-contratada da marinha sueca para o desenvolvimento de sistemas para embarcações militares). Ao fim da implantação a empresa constatou que: A participação do software no custo total dos sistemas caiu de 65% para 20%; Redução da mão de obra de desenvolvimento de software (dos projetos de uma família) 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 repositório de ativos; Houve um aumento na qualidade dos sistemas desenvolvidos e na satisfação dos clientes. Esse exemplo deixa claro as diversas vantagens que o modelo pode trazer para uma organização que desenvolve intensamente software, e este não é 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 benefícios de uma linha de produto de duas maneiras: 157

4 Tangíveis: benefícios que podem ser medidos diretamente, como redução do time-to-market ou redução de defeitos. Intangíveis: benefícios que os desenvolvedores relatam, mas que não podem ser medidos em termos de métricas. Esses benefícios podem incluir satisfação do cliente, animo dos recursos, etc. Em seu estudo, Cohen explora ainda mais essa classificação, apresentando uma lista de benefícios das duas categorias. Uma adaptação destas tabelas pode ser visto na Tabela 1 e na Tabela 2. Lucratividade Qualidade Performance dos produtos de software Tempo de integração Produtividade Desgaste de profissionais Aceitabilidade dos desenvolvedores Satisfação profissional Satisfação do Cliente Tabela 1. Benefícios tangíveis de uma linha de produto de software. Benefícios Tangíveis O repositório de ativos permite que a organização produza produtos voltados para um segmento específico de mercado. O benefício dessa focalização é observado no aumento da participação de mercado e aumento da lucratividade. Uma redução no número de defeitos relatados, é comum em sistemas desenvolvidos em linhas de produto. A qualidade também pode ser medida em termos de redução do tempo de correções e da redução do efeito ripple (geração de novos defeitos a partir de correções executadas). A utilização de ativos aumenta a performance em relação 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 integração no desenvolvimento incremental é facilitado. A equipe de desenvolvimento pode ser reduzida; O custo total de desenvolvimento é cortado consideravelmente; O cronograma é reduzido (maior velocidade de lançamento); O sistema possui uma flexibilidade documentada, o que facilita o atendimento das solicitações de modificações do cliente. Tabela 2. Benefícios intangíveis de uma linha de produto de software. Benefícios Intangíveis Menor desgaste dos profissionais, o que resulta em uma redução do turnover de membros da equipe. Após um treinamento inicial, os desenvolvedores relatam satisfação em trabalhar com a abordagem baseada em ativos e arquitetura comuns. Os desenvolvedores relatam que o trabalho braçal já foi realizado (desenvolvimento dos ativos de software), assim eles podem se concentrar em atividades mais interessantes, como o aperfeiçoamento e / ou inovação de elementos específicos. 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). Como era de se esperar, esses benefícios não vêm de graça, por sinal, muito longe disto. A implantação e institucionalização de uma linha de produto de software é muito custosa e, em conseqüência disto, demanda muito cuidado e planejamento. Na próxima seção serão discutidas as dificuldades de implantação e os principais riscos dessa empreitada. 158

5 4. Dificuldades e Riscos da Implantação Segundo [CLE02] um projeto de implantação de uma linha de produto de software pode ser considerado um projeto de inovação tecnológica, ou seja, um projeto de adaptação à uma nova tecnologia, ou, à uma nova maneira de fazer negócio. Especificamente no caso de linhas de produto, ambas as definições se aplicam tornando o projeto ainda mais delicado. Como toda mudança tecnológica, esse tipo de projeto deve envolver uma avaliação da situação atual da empresa, uma articulação do estado desejado e a elaboração 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 extratecnológicos devem ser considerados, como a adaptabilidade das pessoas, o tipo de treinamento necessário e a preparação do cliente para a nova maneira de trabalhar. Tradicionalmente, o projeto de implantação de uma linha pode ser abordado de duas maneiras: Repentino (completo): Essa abordagem é a mais radical e muitas vezes economicamente inviável. Nesse caso a empresa interrompe, ou reduz drasticamente, o desenvolvimento de novos produtos, re-alocando seus recursos para o desenvolvimento do repositório de ativos (componentes de software, arquitetura da linha, definição de processo, definição do escopo e requisitos, entre outros). Gradual (incremental): Essa abordagem, normalmente preferida pela indústria (ver [COH02]), suaviza os principais riscos da abordagem repentina e faz isto distribuindo o processo de implantação ao longo de vários projetos de produtos. Como a interrupção da produção pode ser algo fatal para muitas empresas, nesta abordagem a empresa continua desenvolvendo seus produtos, no entanto, durante algumas fases de cada projeto são feitas contribuições para a estrutura da linha de produto. Essas contribuições consistem no desenvolvimento de ativos para o repositório da linha, ou seja, algum componente que seja útil não só para o produto em questão, mas também para os outros membros da família. Nesta abordagem o custo total de implementação é maior, no entanto, está diluído ao longo de projetos, diminuindo os riscos e facilitando a adaptação da organização. As dificuldades de implantação de uma linha são diversas e podem vir de várias fontes. Conforme mencionado, o processo envolve tanto pessoas como tecnologias e pode sofrer muita resistência dentro da organização. Os principais problemas levantados por [COH02] são: Falta de um líder comprometido: para o processo de adoção sugere-se a alocação de um líder, uma pessoa que acredita nos princípios do modelo e que estará supervisionando o processo e motivando as pessoas. O líder estará comunicando e motivando os acontecimentos para a gerência além de apoiar os desenvolvedores em momentos de dificuldade evitando que eles desviem do modelo. Caso esta pessoa não receba a autoridade necessária, não acredite no modelo, ou simplesmente não exista, é muito difícil manter o foco e a confiança durante o processo e há um grande risco de desistência. Falta de compromisso da gerência: a gerência deve estar convencida da 159

6 viabilidade e das vantagens que o projeto vai trazer para a organização. É comum que projetos de implantação de linhas de produto comecem com força total, mas ao longo do tempo, por pressão do mercado e por falta de foco, tornem-se projetos coadjuvantes e logo caminhem para o esquecimento. Esse tipo de situação é muito ruim para a organização, pois desmoraliza os idealizadores além de desperdiçar muito recurso. Abordagem inadequada: a linha de produto deve ser um projeto estratégico para atingir objetivos corporativos. Apesar de seus objetivos variarem de empresa para empresa, eles estão sempre baseados no ganho de produtividade, custo e qualidade baseados na exploração das similaridades de produtos de uma família. Caso os produtos planejados para a linha não 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 gerência, o líder da linha deve obter o compromisso da equipe desenvolvedora com os princípios 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 elaboração da linha fazendo-os sentir-se parte do projeto. Interação insuficiente entre as equipes: A iniciativa de uma linha de produto transcende os limites tradicionais da organização. O processo acaba, inevitavelmente, envolvendo diversas equipes como gerência, marketing e engenharia. Uma falta de interação e colaboração entre essas equipes pode impedir a obtenção dos objetivos planejados. Em seu trabalho, [EBE03] detalham que o envolvimento de marketing na definição do escopo e dos requisitos de uma linha de produto é fundamental para o sucesso do projeto, caso contrário, o pessoal de marketing pode vender produtos que a linha de produto não suporta, ou, em contrapartida, o pessoal de engenharia pode permitir variabilidades na linha de produto que não são demandadas pelo mercado. Padronizações desapropriadas: Há uma tendência nas organizações de assumir que a adoção de padrões irá guiar automaticamente para a implantação de uma linha de produto. A institucionalização prematura e impensada de padrões, muitas vezes obsoletos, pode limitar as opções de tecnologia da linha, prejudicando o escopo da mesma. Os padrões devem ser estudados caso a caso e, apesar de serem importantes para a linha, devem ser discutidos antes de sua implementação. Adaptação insuficiente: Assim como a arquitetura e os componentes que devem permitir um certo grau de adaptabilidade dentro da linha de produto, as práticas organizacionais (padronizadas ou não) devem permitir um grau de adaptação, ou melhor, personalização voltadas para as características da linha. A falta de adaptabilidade ou uma adaptação mal pensada pode sub-otimizar a performance das equipes ou gerar desvios imprevistos das atividades envolvidas no processo da linha de produto. Evolução da abordagem: Esse fator também poderia ser chamado de melhoria 160

7 contínua, ou seja, caso o processo da linha de produto não seja revisado e atualizado periodicamente, suas práticas irão tornar-se obsoletas e inapropriadas às novas necessidades que surgirão. Neste caso, novas práticas não-previstas irão surgir informalmente devido às necessidades e poderão comprometer todo o modelo. Falha de disseminação: O líder da linha deve tomar a responsabilidade de desenvolver e distribuir as documentações em nível e tipo apropriados para a organização, treinar os envolvidos, e apoiar o processo no que for necessário. Esses produtos são essenciais ou processo de iniciação da linha, e caso falhem, podem prejudicar tanto o cronograma como os objetivos da linha. Evidentemente, nenhuma organização irá enfrentar todos as dificuldades e desafios citados acima, no entanto, a pesquisa realizada em [COH02] revelou que pelo menos três ou quatro destes elementos estiveram ou estão presentes nas organizações entrevistadas conforme a Tabela 3. Tabela 3 - Problemas identificados pelas empresas entrevistadas em [COH02]. Problema: Percentual identificado: Resistência Organizacional 52% Resistência Gerencial 36% Resistência dos Desenvolvedores 32% Preocupações e desconfianças com o tamanho do investimento 45% Falta de recursos devidamente treinados e capacitados 29% Incapacidade de analisar e prever o impacto da implantação 19% Preocupação sobre o longo tempo para retorno do investimento 18% Alguns riscos identificados em [COH02] foram os seguintes: Clientes desinformados ou céticos com relação às mudanças; Tendências da organização de retornar ao modelo antigo de desenvolvimento, e Momento inoportuno para implantação (empresas que resolveram iniciar o projeto de implantação do modelo no meio do desenvolvimento de projetos críticos para a empresa). 5. Avaliando a Viabilidades e Justificando a Iniciativa Conforme exposto nos tópicos anteriores, o modelo apresenta muitas perspectivas de melhorias, assim como, de dificuldades e riscos. Essa dicotomia, tradicional nos projetos de mudança/inovação tecnológica, demanda muito cuidado da organização e, acima de tudo, um estudo criterioso para avaliar a viabilidades e o custo x benefício da aplicação da nova tecnologia na empresa. Diversos estudos estão sendo desenvolvidos, desde a análise do escopo e requisito da linha até sistemas automatizados de montagem dos produtos, para facilitar a implantação e utilização de linhas de produto de software. Dentre estes estudos destacase, no tema de análise de viabilidades, as abordagens ABC para linhas de produto e o Modelo de Avaliação Orientado a Objetivos para Domínios de Linhas de Produto. A seguir, serão explorados com maior profundidade esses modelos, assim como, alguns 161

8 conceitos fundamentais para a compreensão dos mesmos. 5.1 Modelo de Avaliação Orientado a Objetivos para Domínios de Linhas de Produto Antes de introduzir o modelo é importante compreender o significado do termo domínio para o contexto de linhas de produto de software. O termo Domínio A literatura não apresenta um consenso na definição deste termo, no entanto, muitos autores concordam com o conceito de Clements e Northrop, [CLE02], que dizem o seguinte: Domínio corresponde a uma área de conhecimento ou atividade caracterizado por uma coleção de conceitos e terminologias compreendidos e aceitos pelos profissionais da área. Essa definição, no entanto, é muito vaga o que acaba gerando interpretações distintas. Em um sentido mais amplo, domínio pode ser considerado como uma área de atuação 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 implantação de linha de produto definiu seu domínio como sendo gestão de fundo monetários e bancários, ou seja, seu foco de mercado. Uma outra definição, mais restrita que a anterior, é a de que domínios são 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 definição de domínio está mais voltada para os produtos do que para o mercado. Finalmente, domínio 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 bancários, vai possuir ativos (componentes e artefatos) dos domínios de interface com usuário, comunicação, segurança, algoritmos financeiros, etc. O Modelo O Modelo de Avaliação Orientado a Objetivos para Domínios de Linhas de Produto tem como objetivo priorizar os domínios que serão 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 módulos de uma família de sistemas são prioritários para desenvolvimento no paradigma de linhas de produto. Na descrição do modelo, [WEI03], fica claro que a interpretação dos autores por domínio é alinhada à terceira definição apresentada na seção 5.1.1, ou seja, que domínios são sub-áreas de conhecimento envolvidas no desenvolvimento de uma família de sistemas. Para avaliar a probabilidade de sucesso de um domínio no modelo de linha de produto, os autores decompõem os domínios em módulos para poder avaliá-los com mais 162

9 clareza. Esse módulos são os componentes físicos das sub-áreas de conhecimento, conforme pode ser observado na Figura 1. Figura 1 - Visão geral de uma linha de produto com destaque para os domínios e módulos. O modelo sugere entrevistas com os especialistas de cada domínio para obter uma pontuação de cada módulo em diversos critérios utilizados na análise dos domínios. Esses critérios são separados em quatro grupos: Atividade: avalia o quão ativo são os módulos de um domínio, ou seja, a freqüência com que são modificados e a quantidade de manutenção que requerem. Retorno: avalia a importância do domínio para os objetivos de mercado da empresa, a importância do domínio para o cliente, seu potencial de gerar produtos diferenciados, etc. Independência: quanto mais dependente um domínio for de outros o mais difícil será para desenvolvê-lo independentemente em uma linha de produto. Esse critério avalia o grau de dependência de um módulo com seus módulos adjacentes. Viabilidade: avalia questões como complexidade de código, maturidade dos módulos e restrições de recursos (capital e humano). Cada um dos grupos acima é composto por diversos critérios, e sua graduação é conseqüência da aplicação de formulas que relacionam de forma ponderada os critérios constituintes. Com o resultado da graduação de cada grupo o modelo utiliza duas novas fórmulas para obter uma graduação normalizada de dois parâmetros: impacto coorporativo e probabilidade de sucesso. Mapeando os diversos módulos numa matriz que confronta 163

10 essas variáveis, é possível selecionar os domínios 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 negócio). 5.2 A Abordagem ABC para Linhas de Produto de Software Essa abordagem utiliza o ABC de estudos de casos de negócio para a realidade das linhas de produto. Nessa abordagem, detalhada em [COH03], utilize-se três variáveis para avaliar a viabilidade da implantação do modelo: Aplicações: quantos sistemas a organização planeja entregar (produzir) usando os ativos da linha de produto durante o período do caso de negócio estudado; quanto esses produtos irão variar ao longo do tempo? Benefícios: as projeções de economia, ou outros retornos, provenientes da utilização dos ativos da linha de produto; Como o investimento contínuo no desenvolvimento dos ativos irá ajudar essas projeções? Custos: os custos de re-uso, ou seja, gastos que a organização vai enfrentar ao desenvolver utilizando os ativos da linha de produto. Em [COH03] este modelo é utilizado para guiar a implantação de uma linha de produto de software, de forma incremental, no NRO (Escritório de Reconhecimento de Territórios) das forças armadas do EUA. Para compreender melhor como o modelo funciona há três termos que devem ser esclarecidos: Cost of Reuse (COR): o custo do reuso, ou seja, o quanto à prática do reuso está acrescentando de trabalho aos desenvolvedores e, conseqüentemente, custos à organização. Esse fator pode ser diminuído 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 reutilizáveis 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 atualização (renovação), essa medição serve para determinar a freqüência com que um domínio sofre uma desatualização a ponto de necessitar uma renovação dos seus ativos. Normalmente, conforme o tempo vai passando e as tecnologias do domínio evoluindo, o COR vai aumentando e o DOR diminuindo. Chega um momento onde a aplicação dos ativos do repositório da linha não é mais vantajosa ou, até mesmo, impraticável (como no caso de uma mudança de plataforma) e a empresa deve re-popular o repositório a um custo elevado. Um domínio que tem uma taxa de atualização muito alta não é um bom candidato para linhas de produto, pois dificilmente vai desfrutar de vantagem econômica na abordagem. Para o desenvolvimento do caso de negócio aplicando o modelo ABC, a empresa deve antes de tudo, planejar quantas iterações planeja realizar, ou seja, em quantas etapas será estabelecida sua linha de produto. Para cada iteração deve-se planejar quais aplicações 164

11 serão desenvolvidas (mesmo que parcialmente), qual o COR e o DOR planejados e qual o retorno esperado ao fim de cada iteração. No que toca as aplicações, a organização deve ver qual sua perspectiva de lançamento de novos produtos no período de implantação, pois, sem produtos, não há retorno. Ainda com relação aos produtos, deve-se avaliar qual será o COR e o DOR de cada deles por iteração. Esses valores irão auxiliar no levantamento dos custos e retornos. Quanto aos benefícios, a organização deve estabelecer metas claras quanto aos objetivos de redução de custo, aumento de lucratividades, diminuição de time-to-market ou qualquer outro objetivo plausível e perceptível que espere ter com a iniciativa. Deve-se considerar que esses benefícios estão diretamente ligados à quantidade de produtos desenvolvidos e à maturidade dos processos da linha conforme a evolução das iterações. Finalmente quanto aos custos, seção de maior trabalho, a empresa deve utilizar dados, métricas e projeções para ilustrar os benefícios financeiros da adoção do modelo e determinar sua viabilidade ou não. Os principais elementos desta seção são: Custos históricos: levantar os custos de desenvolvimento dos sistemas no paradigma anterior, projeto a projeto. Custos de desenvolvimento dos ativos: os custos do desenvolvimento e manutenção dos ativos durante o período coberto pelo caso de negócio. Custo incremental e economias: o custo de implementação de cada iteração do processo e as economias projetadas para cada iteração. Planificando esses dados, é possível analisar a projeção de custo para cada sistema, tanto no caso da utilização do reuso como no caso negativo. Vale ressaltar que se os produtos forem desenvolvidos em seqüência eles serão criados em momentos diferentes da linha de produto, ou seja, iterações diferentes do plano de implantação, isso faz com que o COR e o DOR mudem e conseqüentemente as projeções de custo e economia para cada sistema. Com estas projeções de custos e economia, o modelo se propõe a tornar mais clara a visibilidade para determinar se a implantação de uma linha de produto de software para um domínio é viável ou não e, além disso, servir como um instrumento para apoiar a negociação gerencial para aprovação e captação de fundos para o projeto. 6. Comentários Finais Neste trabalho, foi apresentado ao leitor o conceito de Linhas de Produto de Software e seus principais elementos constituintes, foram apresentadas também, as principais vantagens previstas pelo modelo e constatadas pela indústria, assim como, as dificuldades e riscos do processo de implantação. Finalmente, dois modelos de avaliação de viabilidade dirigidos para linhas de produto de software em empresas são expostos, juntamente com a definição de alguns termos essenciais para a correta compreensão dos modelos. Ao fim deste trabalho é possível fazer as seguintes observações sobre os tópicos expostos: 165

12 O estudo de linhas de produto de software está em plena ascensão e migrando, gradativamente, do ambiente acadêmico e de pesquisa, para as indústrias, conforme pode ser observado em [COH02]. Os institutos e grupos que dominam o assunto de linhas de produto de software e que estão aplicando esse modelo nas indústrias ainda são muito poucos. Isso serve de motivação para que as pesquisas sobre este assunto migrem para outras nações, 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 são muitos os pontos que podem interferir no sucesso da implantação do modelo nas indústrias, no entanto, os problemas não são novos e, em sua maioria, são os mesmo observados em outros projetos de melhoria de processos. Assim, a adaptação de práticas existentes pode ser uma boa solução para os novos problemas. No que toca o tema principal do artigo, os modelos de avaliação de viabilidade, ainda há um longo caminho pela frente. As iniciativas, ainda pouco abrangentes e demasiadamente subjetivas, não garantem a segurança que as empresas esperam. Além disso, os estudos de caso de aplicação dos modelos ([COH03], [WEI03]) ainda são muito recentes e não apresentam resultados concretos da iniciativa. Espera-se que a pesquisa em métodos e modelos de avaliação de viabilidade continue, pois estes são essenciais para convencer as indústrias a considerar a implantação, e conseqüente disseminação, do modelo. Referências Bibliográficas [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. Disponível em 08/07/04. [CLE96] CLEMENTS, Paul; BROWNSWORD, Lisa. A Case Study in Successful Product Line Development. Disponível em 04/07/04. [COH03] COHEN, Sholom; Predicting when Software Product Lines Pays. Disponível em: 21/05/04. [GAC01] GACEK, Cristina; et. al. Successful Software Product Line Development in a Small Organization. Universidade Kaiserslautern, disponível em: 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 IEEE Comp. Soc. Press. Los Alamitos, EUA, [WEI03] WEISS, David M.; GEPPERT, Birgit. Goal-Oriented Assessment of Product- Line Domains. Anais do IEEE Ninth International Software Metrics Symposium 2003, pp IEEE Comp. Soc. Press. Los Alamitos, EUA,