UNIVERSIDADE DE PERNAMBUCO ELYDA LAISA SOARES XAVIER

UM ESTUDO SOBRE FERRAMENTAS CASE PARA GERENCIAMENTO DO PROCESSO DE ENGENHARIA DE DOMNIO EM LINHA DE PRODUTOS DE SOFTWARE

CARUARU 2011

UNIVERSIDADE DE PERNAMBUCO

ELYDA LAISA SOARES XAVIER

UM ESTUDO SOBRE FERRAMENTAS CASE PARA GERENCIAMENTO DO PROCESSO DE ENGENHARIA DE DOMNIO EM LINHA DE PRODUTOS DE SOFTWARE

Monografia apresentada Universidade de Pernambuco como requisito parcial para a obteno do ttulo de Bacharel em Sistemas de Informao, sob orientao do Prof. M.Sc. Humberto Rocha de Almeida Neto e co-orientao do Prof. D.Sc. Vincius Cardoso Garcia.

CARUARU 2011

 minha famlia, com todo amor.

AGRADECIMENTOS A Deus, nosso Pai e Criador, por ter mudado a minha vida desde o momento em que aceitei o Seu Filho, Jesus Cristo, como nico Senhor e Salvador da minha vida. E por ter me capacitado durante os meus estudos da graduao bem como durante a execuo deste trabalho. minha me, Edna Cristina, pelo amor incondicional que dedica a mim, minha irm, Erika Sabrinna, e meu sobrinho, der Vincius; por acordar s 06h para preparar meu caf da manh aps uma noite agitada de estudos, pelas broncas, conselhos, pela pacincia e tanto mais. Ao meu pai, Joo Eudes, pelo seu amor e por estar sempre presente na minha vida, mesmo quando fisicamente longe; pelo incentivo aos estudos e pelo apoio durante as dificuldades da caminhada. minha e irm e ao meu sobrinho, pela pacincia enquanto eu monopolizava o computador, PC e internet; pelo carinho nos momentos de stress e por serem a melhor irm e o melhor sobrinho que eu poderia ter. Ao meu namorado, Digenes Ricardo, pelos trabalhos em grupo, pela pacincia (ou pela falta dela =P) durante as reunies para execuo destes trabalhos; pela confiana, pelo amor e, principalmente, pelo empenho em mostrarme a Verdade. Te amo, meu amor. minha famlia, pelo amor e incentivo (e pelos inmeros momentos hilrios que passamos juntos, os quais so motivo de gargalhadas durante nossas reunies). Sem eles eu no teria conseguido. Ao meu orientador, Humberto Rocha, pelas contribuies e pela pacincia e confiana em orientar-me. Alm de orientador, era preciso ser psiclogo. E ele cumpriu bem esse papel tambm! Ao meu co-orientador, Vincius Garcia, pela confiana depositada em mim durante todos os trabalhos que fizemos na graduao e pela orientao deste trabalho, nunca me entregando as respostas de mos beijadas, mas sempre me incitando a pensar. Obrigada, Vincius. equipe do SigConfex e ao nosso orientador, Fernando Carvalho, pelo aprendizado e pelas risadas. Aos professores da UPE Caruaru, por terem contribudo para a minha formao com seus conhecimentos e conselhos durante estes 4 anos. Ao meu pastor, Ary Queiroz Jr., pela preocupao com a minha vida espiritual, pelo auxlio nos momentos difceis e pelos edificantes estudos bblicos que me fazem, cada dia mais, crescer na graa e no conhecimento de nosso Senhor e Salvador Jesus Cristo (2 Pe 3:18).

 minha igreja, I Congregacional de Caruaru, pela comunho e pela oportunidade de trabalhar com as crianas da Escola Bblica Mensal. Aos meus amigos: Ada, Joo, Bruno, Andr, Warla, Marsia, Joana, Poeta, Jssica, Walkiria e Cristianne por compartilhar tantos momentos de alegria e por me aturar nos momentos de tristeza. A Moiss Bonifcio, meu professor de espanhol durante o ensino fundamental e mdio, por acreditar no meu potencial e por depositar sua confiana em mim. Moiss, voc foi (e ) pra mim um grande amigo. Gracias por todo. Por fim, mas no menos importante, Cardeal Distribuidora e a todos os que fazem parte desta empresa. Agradeo, em especial, a Rodrigo Queiroz, Wellington Cavalcante, Igor Nascimento e Hian Cintra, meus companheiros no setor de TI, por me apoiarem e confiarem no meu potencial em todos os momentos. Eu amo cada um de vocs. Deus os abenoe.

RESUMO:

Uma das abordagens sistemticas de reuso de software que mais tem crescido nas ltimas dcadas a de Linha de Produtos de Software. Grandes empresas, como Nokia, Philips e Siemens tm-se utilizado desta abordagem a fim de reduzir o timeto-market de seus produtos, diminuir custos e aumentar a qualidade dos softwares produzidos. A adoo da Linha de Produtos de Software, no entanto, no algo simples. Para que haja sucesso na sua adoo, faz-se necessrio um processo de gerenciamento sistematizado e consistente, que leve em considerao a posio importante que os artefatos reusveis possuem. Neste contexto, as ferramentas CASE exercem um papel primordial no controle das iteraes durante o desenvolvimento atravs da abordagem de Linha de Produtos de Software. Diante deste cenrio, este trabalho visa investigar ferramentas CASE e relatos de experincia a fim de propor um conjunto de features que apoie efetivamente o gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software.

Palavras-chave: Linha de Produtos de Software, Famlias de Produtos, Ferramentas CASE, Gerenciamento e Engenharia de Domnio.

ABSTRACT:

One of systematic approaches to software reuse with higher growing over the last decades is the Software Product Line. Large companies such as Nokia, Philips and Siemens have been using this approach to reduce time-to-market of their products, reduce costs and increase quality of the produced software. Adopting Software Product Line, however, is not a simple work. To be successful in its adoption, it is necessary a systematic and consistent process of management that takes into account the important position of the reusable artifacts. In this context, CASE tools have a key role in controlling the iterations during the development using the Software Product Line approach. In this context, this paper aims to investigate CASE tools and reports of experience to propose a set of features to support effectively the management of the process of Domain Engineering in Software Product Line.

Keywords: Software Product Lines, Product Families, CASE tools, Management and Domain Engineering.

LISTA DE FIGURAS Figura 1 - Abordagens para reuso de software ......................................................... 13 Figura 2 - Trs exemplares da srie de aparelhos celulares E da Nokia, cujos sistemas compartilham diversas similaridades.......................................................... 14 Figura 3 - Vantagens da customizao em massa .................................................... 20 Figura 4 - Objetivo geral dos principais processos da Linha de Produtos de Software. Autor (2011) .............................................................................................................. 24 Figura 5 - Custos da Linha de Produtos de Software. Adaptada de (LINDEN et. al., 2007, p.4) .................................................................................................................. 25 Figura 6 - Fluxo de atividades executado para realizao da pesquisa. Autor (2011) .................................................................................................................................. 39 Figura 7 - Quantidade de trabalhos selecionados para leitura, classificados por base cientfica. Autor (2011) .............................................................................................. 41 Figura 8 - Trabalhos com contribuies significativas, organizados por ano de publicao. Autor (2011) ........................................................................................... 45

LISTA DE TABELAS Tabela 1 - Diferentes nomenclaturas envolvidas na LPS. ......................................... 22 Tabela 2 - Classificao das ferramentas segundo Furgetta (1993) ......................... 32 Tabela 3 - Classificao dos workbenches segundo Furgetta (1993) ....................... 33 Tabela 4 - Classificao dos ambientes segundo Furgetta (1993)............................ 34 Tabela 5 Ferramentas selecionadas e seus dados. Autor (2011) .......................... 43 Tabela 6 CADSEg e suas features. Autor (2011) ................................................... 43 Tabela 7 - PloneMeeting e suas features (continua). Autor (2011) ........................... 43 Tabela 8 - Features propostas para as lacunas encontradas nos relatos de experincia (continua). Autor (2011) ......................................................................... 46 Tabela 9 - Features adicionais. Autor (2011) ............................................................ 48 Tabela 10 - Features propostas que apoiam o Gerenciamento Organizacional. Autor (2011) ........................................................................................................................ 49 Tabela 11 - Features propostas que apoiam o Gerenciamento Tcnico (continua). Autor (2011) .............................................................................................................. 49

SUMRIO 1. INTRODUO ................................................................................................... 13 1.1. 1.2. 1.3. Contextualizao......................................................................................... 13 Problema de Pesquisa ................................................................................ 15 Objetivos ..................................................................................................... 15

1.3.1. Objetivo Geral ........................................................................................ 15 1.3.2. Objetivos Especficos ............................................................................ 16 1.4. 1.5. 1.6. 1.7. 2. Justificativa ................................................................................................. 16 Escopo Negativo ......................................................................................... 16 Contribuies .............................................................................................. 17 Organizao do Trabalho ............................................................................ 18

REFERENCIAL TERICO ................................................................................ 19 2.1. LINHA DE PRODUTOS DE SOFTWARE (LPS) ......................................... 19

2.1.1. Histrico ................................................................................................. 19 2.1.2. Conceito ................................................................................................ 21 2.1.3. Processos Fundamentais ...................................................................... 21 2.1.3.1. Engenharia de Domnio .................................................................. 22 2.1.3.2. Engenharia de Aplicao ................................................................ 22 2.1.3.3. Gerenciamento................................................................................ 23 2.1.4. Vantagens ............................................................................................. 24 2.1.5. Riscos .................................................................................................... 26 2.2. FERRAMENTAS CASE .............................................................................. 29 2.2.1. Histrico ................................................................................................. 29 2.2.2. Conceito ................................................................................................ 29 2.2.3. Motivao .............................................................................................. 30 2.2.4. Classificao das Ferramentas CASE ................................................... 31 2.2.5. Ferramentas CASE em Linha de Produtos de Software........................ 34 3. METODOLOGIA ................................................................................................ 37 3.1. Natureza da Pesquisa ................................................................................. 37

3.1.1. Quanto aos Fins .................................................................................... 37 3.1.2. Quanto aos Meios.................................................................................. 37 3.1.3. Quanto Forma de Abordagem ............................................................ 38 3.2. Anlise dos Dados ...................................................................................... 38

4.

UM ESTUDO SOBRE FERRAMENTAS CASE PARA GERENCIAMENTO DO

PROCESSO DE ENGENHARIA DE DOMNIO EM LINHA DE PRODUTOS DE SOFTWARE .............................................................................................................. 40 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. Realizao das Pesquisas nas Bases Cientficas ....................................... 40 Anlise das Ferramentas ............................................................................ 41 Anlise dos Relatos de Experincia ............................................................ 44 Features Adicionais..................................................................................... 47 Proposta...................................................................................................... 48 Discusso ................................................................................................... 51

4.5.1. Conjunto Proposto e Riscos da LPS...................................................... 50 4.6.1. Dificuldades ........................................................................................... 51 4.6.2. Limitaes da Pesquisa ......................................................................... 52 5. CONSIDERAES FINAIS ............................................................................... 53 5.1. 5.2. 5.3. 6. Trabalhos Relacionados ............................................................................. 53 Trabalhos Futuros ....................................................................................... 54 Lies Aprendidas....................................................................................... 54

REFERNCIAS ................................................................................................. 55

ANEXO 1 RESULTADO DA BUSCA NAS BASES CIENTFICAS ....................... 58

13

1. INTRODUO 1.1. Contextualizao Nas ltimas dcadas, os computadores e, por consequncia, os programas, tornaram-se parte do cotidiano das pessoas e das organizaes. O software tornouse um diferencial competitivo das empresas, sendo essencial tanto para resoluo de problemas simples - como manter um cadastro de clientes - quanto para tarefas complexas como o controle de aeronaves. Sendo assim, a demanda e a complexidade dos sistemas tm crescido sobremaneira nas ltimas dcadas. Diante da necessidade em atender a crescente demanda do mercado e visando agilizar a entrega do produto sem perda de sua qualidade, tanto a indstria quanto a academia tm movido esforos para a maximizao da produtividade no processo de desenvolvimento. Uma das formas de se atingir este objetivo por meio de abordagens sistemticas de reuso de software. A Figura 1, adaptada de Garcia (2010), apresenta diferentes abordagens de reuso existentes:

Figura 1 - Abordagens para reuso de software

Entre estas abordagens est a de Linha de Produtos de Software (LPS). Segundo Pohl et. al. (2005, p.14, traduo nossa): Linha de Produtos de Software um paradigma para desenvolver aplicaes de software (sistemas intensivos de software e produtos de software) usando plataformas e customizao em massa.

14

Ou seja, a produo de software se d em massa, no entanto, leva em conta as necessidades especficas dos clientes. Para atingir tal objetivo, uma plataforma, composta por um conjunto comum de funcionalidades, reutilizada por todos os produtos da linha. As tarefas envolvidas no desenvolvimento da plataforma compem o processo de Engenharia de Domnio. J as tarefas de desenvolvimento dos produtos finais compem o processo de Engenharia de Aplicao. Entre as vantagens da utilizao desta abordagem, podemos citar a diminuio do time-to-market - que o tempo que um produto demora a chegar ao mercado, aumento da qualidade dos produtos, diminuio dos custos de desenvolvimento, entre outras (POHL et. al., 2005). Os softwares de uma determinada srie de celulares, que compartilhem a maior parte de suas funcionalidades, so exemplos de sistemas que podem ser desenvolvidos numa LPS. A Figura 2 mostra parte da srie de celulares E da Nokia, cujos sistemas compartilham diversas similaridades, o que indica que o desenvolvimento de tais sistemas pode beneficiar-se das vantagens da Linha de Produtos de Software.

Figura 2 - Trs exemplares da srie de aparelhos celulares E da Nokia, cujos sistemas compartilham 1 diversas similaridades

Apesar de todas as vantagens, a adoo da LPS no algo simples. Para se obter os benefcios previstos por esta abordagem necessrio um processo de gerenciamento consistente, que leve em considerao a importncia que a plataforma possui. Alm disso, o gerenciamento deve ser eficaz ao lidar com os riscos inerentes implantao da LPS (os riscos sero tratados na seo 2.1.5
1

Imagens retiradas de http://www.nokia.com.br e http://www.nokia.co.uk/. Acesso: 16/03/2011.

15

deste trabalho). O planejamento de toda a Linha de Produtos e as tarefas envolvidas no desenvolvimento da plataforma fazem parte do processo de Engenharia de Domnio. E para dar apoio tarefa de gerenciamento, indispensvel o uso de ferramentas especficas, que forneam suporte s particularidades desta

abordagem, levando em conta as diferenas entre o desenvolvimento de um sistema nico e de uma famlia de produtos. Conhecidas como CASE (Computer-Aided Software Engineering - Engenharia de Software com Auxlio de Computador), estas ferramentas proporcionam apoio ao processo de software pela automao de algumas atividades de processo e pelo fornecimento de informaes sobre o software que est sendo desenvolvido (SOMMERVILLE, 2010, p.85, traduo nossa). Dentre os diversos benefcios trazidos pelo uso deste tipo de ferramenta esto a acelerao no desenvolvimento de produtos, maior facilidade de manuteno do produto e documentao dos processos, entre outros.

1.2.

Problema de Pesquisa Diante desta necessidade de apoio automatizado para o gerenciamento da

LPS, a pergunta definida para a pesquisa foi: Quais so as features2 que uma ferramenta CASE deve possuir para contribuir efetivamente com o gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software?

1.3.

Objetivos Para responder pergunta de pesquisa, foram definidos os seguintes

objetivos, divididos em geral e especficos: 1.3.1. Objetivo Geral Propor um conjunto de features que apoie efetivamente o gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software.

O termo feature refere-se a uma caracterstica do sistema.

16

1.3.2. Objetivos Especficos Investigar os subprocessos de gerenciamento em Linha de Produtos de Software. Pesquisar ferramentas acadmicas e industriais que forneam suporte ao gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software. Identificar e documentar features bsicas e complementares de cada ferramenta encontrada. Pesquisar relatos de experincias no uso da abordagem de Linha de Produtos de Software. Identificar, atravs dos relatos encontrados, possveis necessidades referentes a features que deem suporte ao gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software.

1.4.

Justificativa O presente trabalho poder contribuir com estudos futuros no sentido da

identificao das features que uma ferramenta CASE deve possuir para dar apoio efetivo ao gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software. Alm disso, a listagem das features poder servir de ponto de partida para o desenvolvimento de uma ferramenta CASE que centralize as funcionalidades necessrias ao gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software. Algumas das vantagens desta centralizao esto no aumento da agilidade do processo de desenvolvimento e na execuo das tarefas cotidianas de gerenciamento, mais velocidade no relacionamento com o cliente, alm da padronizao dos artefatos produzidos, facilitando a documentao de todo processo (CRONHOLM, 1995) e garantindo a consistncia destes documentos (PRESSMAN, 2001). 1.5. Escopo Negativo A abordagem de Linha de Produtos de Software envolve inmeras reas de interesse dentro da Engenharia de Software, tais como Gesto da Qualidade, Testes, Gesto de Configurao, entre outros. Devido vasta extenso do tema,

17

preciso ressaltar as questes que no sero abordadas no presente trabalho, a saber: - Frameworks: Este trabalho no aborda em detalhes nenhum framework especfico para a LPS, uma vez que o conjunto de features a ser investigado deve ser genrico, dando suporte a abordagens variadas. Em (MATINLASSI, 2004), o autor lista, detalha e compara os principais frameworks disponveis. - Desenvolvimento: O desenvolvimento de uma ferramenta com as features investigadas no faz parte do escopo deste trabalho. - Aspectos tcnicos: Os aspectos tcnicos, que auxiliem o desenvolvimento das features investigadas, tambm no sero tratados neste trabalho. - Reviso Sistemtica de Literatura (RSL): Uma RSL estabelece um processo formal para conduzir a investigao, evitando a introduo de vieses da reviso de literatura informal, dando maior credibilidade pesquisa em andamento (SOUSA e RIBEIRO, 2009). Este trabalho no uma Reviso Sistemtica de Literatura; no entato, ele se utiliza de algumas atividades tpicas de uma RSL (como a utilizao de strings de busca e escolha dos trabalhos a partir de critrios de incluso e excluso) a fim de dar mais coeso ao estudo. A realizao da RSL neste trabalho foi descartada devido ao pouco tempo disponvel para sua execuo. 1.6. Contribuies Entre as contribuies efetivas deste trabalho, podemos citar: Um estudo investigativo sobre Linha de Produtos de Software e ferramentas CASE, que podem servir de ponto de partida para aqueles que desejam aprender sobre os temas. Uma investigao extensiva de ferramentas para gerenciamento do processo de Engenharia de Domnio em LPS, que traz uma viso geral sobre o que est sendo desenvolvido e utilizado no mercado e na academia. Uma investigao extensiva de relatos de experincia, que expe as reais necessidades e as dificuldades do mercado e da academia no que diz respeito ao gerenciamento em Linha de Produtos de Software.

18

1.7.

Organizao do Trabalho Neste captulo, foi realizada uma breve introduo aos temas deste trabalho:

Linha de Produtos de Software e ferramentas CASE. Ainda neste captulo, o problema de pesquisa foi apresentado, bem como os objetivos gerais e especficos para responder a pergunta de pesquisa. Alm disso, apresentamos a justificativa para realizao deste trabalho e suas contribuies. O restante do trabalho est organizado da seguinte forma: Captulo 2: Apresenta a reviso da literatura, que aborda de forma mais abrangente os temas Linha de Produtos de Software e ferramentas CASE, com o apoio da literatura. Captulo 3: Relata a metodologia a ser seguida para a realizao da pesquisa e da anlise de dados. Captulo 4: Apresenta o estudo sobre ferramentas CASE para gerenciamento do processo de Engenharia de Domnio para Linha de Produtos de Software e seus resultados. Captulo 5: Expe as concluses sobre os estudos e a proposta de trabalhos futuros.

19

2. REFERENCIAL TERICO A seguir, sero apresentados, com apoio da literatura, os principais temas que formam a base terica deste trabalho, a saber: Linha de Produtos de Software e Ferramentas CASE. 2.1. LINHA DE PRODUTOS DE SOFTWARE (LPS) Nesta seo, abordaremos o tema Linha de Produtos de Software, mostrando o histrico do surgimento da abordagem, conceito, processos fundamentais que compem a LPS e, por fim, suas vantagens e os riscos inerentes sua adoo. 2.1.1. Histrico Uma linha de produtos, ou famlia de produtos, um grupo de sistemas que compartilham caractersticas comuns. Um dos primeiros artigos a citar uma abordagem de desenvolvimento voltada para famlias de produtos foi publicado em 1976. Em seu artigo On the Design and Development of Program Families, David Parnas propunha um novo processo para desenvolver famlias de produtos de software, a partir de um modelo-base. Parnas (1976, p.1, traduo nossa) citava ainda o mtodo tradicional de desenvolvimento de uma famlia de produtos poca: Um membro particular da famlia de produtos desenvolvido por completo (...) e os outros membros da famlia so desenvolvidos pela modificao deste membro. J o termo Linha de Produtos uma referncia clara s linhas de montagem fordistas do sculo XX, que trouxeram um novo modo de fabricao dos produtos: a produo em massa (BOTELHO, 2008). Essa nova abordagem trouxe mudanas substanciais para as indstrias da poca, entre as quais podemos citar a drstica reduo do tempo de produo, com consequente aumento no nmero de produtos desenvolvidos e reduo do preo dos mesmos (FUSCO et. al., 2003). Linha de Produtos de Software uma abordagem de desenvolvimento para famlias de produtos criada com o mesmo objetivo, o de produzir em massa - de maneira rpida e com baixo custo. A Linha de Produtos, no entanto, possui uma diferena substancial da produo fordista: investigao das necessidades particulares de cada cliente, a que chamamos de customizao em massa. A customizao em massa um processo de produo que combina elementos da produo em massa com os de alfaiataria sob medida. Os produtos

20

so adaptados para atender as necessidades individuais dos clientes (HINDLE, 2008, p.125, traduo nossa). A respeito da necessidade de customizao dos softwares Douglas McIlroy (1968, p.138, traduo nossa) pontuou:
Nenhum usurio de um produto particular de uma famlia deve ser penalizado, com uma generalidade indesejada, pelo fato de haver sido empregado um padro de rotina. Em outras palavras, o comprador de um componente da famlia ir escolh-lo adaptado s suas exatas necessidades.

Neste cenrio, o cliente se torna prosumidor3: produtor (ao interferir no processo produtivo) e consumidor. A Figura 3, adaptada de (HEINEMANN e SCHWARZL, 2010, p.140), mostra as vantagens obtidas pela combinao da produo em massa e adaptao s necessidades dos clientes, tpicos da customizao em massa:

Figura 3 - Vantagens da customizao em massa

Conforme mostrado na figura acima, algumas dessas vantagens so: diminuio de custos, resultante da produo massificada; aumento da vantagem competitiva, uma vez que os produtos desenvolvidos so adaptados s necessidades dos consumidores; e maior integrao com os clientes, que participam de maneira ativa no processo produtivo.

Este conceito foi estabelecido por Alvin Toffler em seu livro The Third Wave, de 1980.

21

2.1.2. Conceito A seguir, dado o conceito do Software Engineering Institute (SEI) para uma Linha de Produtos de Software.
Linha de Produtos de Software constitui um conjunto de sistemas de software intensivo que compartilham um comum, conjunto de caractersticas que satisfaam as necessidades especficas de um determinado segmento de mercado ou misso, e que so desenvolvidos a partir de um conjunto comum 4 de ativos principais de maneira pr-determinada

Em outras palavras, Linha de Produtos de Software uma abordagem de desenvolvimento de software que se aproveita das caractersticas em comum de uma famlia de produtos para construir, a partir de um conjunto de artefatos reusveis, produtos que atendam s necessidades de um determinado segmento de mercado. Este conjunto de artefatos reusveis conhecido como plataforma. Esta deve conter os artefatos comuns a todos os produtos que sero desenvolvidos. Alm disso, deve ser flexvel o suficiente para suportar as especificidades de cada produto. Segundo Pohl et. al. (2005, p.20, traduo nossa) a plataforma consiste de todos os tipos de artefatos de software (requisitos, projeto, execuo, testes, entre outros). A definio de LPS apresentada a mais adequada ao contexto deste trabalho, uma vez que ressalta o uso da plataforma - mostrando sua importncia na Linha de Produtos de Software - e apresenta a necessidade de planejamento e organizao do desenvolvimento.

2.1.3. Processos Fundamentais A Linha de Produtos de Software, em geral, dividida trs processos fundamentais: Engenharia de Domnio, Engenharia de Aplicao e Gerenciamento. A nomenclatura destes processos, no entanto, pode variar. A Tabela 1, adaptada de (NORTHROP, 2008), mostra duas diferentes terminologias para os processos envolvidos em LPS:

Citao retirada de http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm. Acesso: 09/05/2011

22

Tabela 1 - Diferentes nomenclaturas envolvidas na LPS.

Nomenclaturas Linha de Produtos Ncleo de Ativos Desenvolvimento do Ncleo de Ativos Desenvolvimento do Produto Famlia de Produtos Plataforma Engenharia de Domnio Engenharia de Aplicao

2.1.3.1.

Engenharia de Domnio

Tambm conhecido como Desenvolvimento do Ncleo de Ativos, segundo Pohl et. al. (2005, p. 21, traduo nossa), o processo de engenharia de produto de software no qual a similaridade e a variabilidade da linha de produtos definida e executada. Este processo objetiva conhecer o domnio da linha de produtos, verificando quais requisitos so comuns a todas as aplicaes da linha e quais requisitos so especficos de determinadas aplicaes. Uma diferena substancial do

desenvolvimento em LPS para o desenvolvimento de sistemas nicos a necessidade de planejar rigorosamente o desenvolvimento de artefatos flexveis, que se adaptem a todos os produtos que faro uso dos mesmos. Devido a esta caracterstica, esta fase pode, ainda, ser chamada de desenvolvimento para reuso (LINDEN et. al., 2007). Por fim, os componentes so desenvolvidos e a plataforma de artefatos reusveis montada com os artefatos comuns a todas as aplicaes. 2.1.3.2. Engenharia de Aplicao

Engenharia de Aplicao ou Desenvolvimento do Produto o processo de engenharia de linha de produtos no qual as aplicaes da linha de produtos so construdas atravs do reuso de artefatos de domnio e explorando a variabilidade da linha (POHL et. al., 2005, p. 21, traduo nossa). Este processo engloba todas as atividades realizadas para o desenvolvimento das aplicaes a partir da plataforma criada durante o Desenvolvimento do Ncleo de Ativos. Na realidade, este processo pode ser descrito como a montagem de

23

cada aplicao diferente a partir dos artefatos reusveis. Nesta fase, os esforos esto voltados para atingir uma taxa de reuso to alta quanto possvel. 2.1.3.3. Gerenciamento

O processo de gerenciamento em Linha de Produtos de Software, bem como em qualquer projeto de software, um procedimento de extrema importncia para que a organizao atinja resultados satisfatrios. A respeito disto, o Software Engineering Institute (SEI) argumenta:
O conjunto de artefatos e a idealizao sobre como eles so usados para criar produtos no se materializam sem planejamento e certamente no vm gratuitamente. Eles exigem conhecimento antecipado da organizao, investimento, planejamento e direo. Eles exigem o pensamento estratgico 5 que vai alm de um nico produto .

O gerenciamento responsvel por planejar e coordenar as atividades de desenvolvimento do ncleo de ativos, bem como as dos produtos gerados a partir deste ncleo. Em outras palavras, o gerenciamento direciona a execuo da LPS. Em comparao ao desenvolvimento de um sistema nico, o gerenciamento em LPS possui tarefas adicionais. Os gerentes da LPS devem preocupar-se com questes pontuais, as quais so exclusivas desta abordagem, como as mudanas e evoluo da plataforma, entrada e sada de produtos da linha, entre outras questes. Com relao s atividades, o SEI divide o processo de gerenciamento da Linha de Produtos de Software em duas grandes reas. So elas:

Gerenciamento

Organizacional:

deve

criar

uma

estrutura

organizacional6 adequada para a empresa e certificar-se de que as unidades organizacionais recebem os recursos adequados (por exemplo, pessoal bem treinado) em quantidades suficientes.

Gerenciamento

Tcnico:

supervisiona

desenvolvimento

da

plataforma e as atividades de desenvolvimento dos produtos, assegurando que aqueles que os constroem esto engajados nas
5

Citao retirada de http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm. Acesso: 17/03/2011. 6 A estrutura de uma organizao pode ser definida como o resultado de um processo atravs do qual a autoridade distribuda, as atividades desde os nveis mais baixos at a alta administrao so especificadas e um sistema de comunicao delineado (VASCONCELOS e HEMSLEY, 2008, p. 3).

24

atividades necessrias, seguindo os processos definidos para a linha de produtos. Alm disso, o gerente responsvel por recolher dados para acompanhamento do progresso.

De uma maneira geral, o gerenciamento deve dar subsdios para a realizao das atividades da LPS. Ressaltamos que o gerenciamento das atividades do processo de Engenharia de Domnio o foco deste trabalho. A Figura 4 mostra o objetivo geral dos principais processos envolvidos na Linha de Produtos de Software.

Engenharia de Domnio

Atividades relacionadas ao desenvolvimento da plataforma

Engenharia de Aplicao

Atividades relacionadas ao desenvolvimento dos produtos

Gerenciamento

Planejamento da LPS e coordenao das atividades de Engenharia de Domnio e Engenharia de Aplicao

Figura 4 - Objetivo geral dos principais processos da Linha de Produtos de Software. Autor (2011)

2.1.4. Vantagens Diversas so as vantagens alcanadas atravs da utilizao da abordagem de Linha de Produtos, as quais motivam sua adoo. Entre elas (POHL et. al. 2005):

Reduo dos Custos de Desenvolvimento: Uma vez que os artefatos da plataforma so reusados por diversas aplicaes diferentes, os custos de desenvolvimento caem significativamente a cada software desenvolvido. preciso ressaltar, no entanto, que para um investimento inicial em LPS, o custo alto (uma vez que necessria a codificao de cada artefato da plataforma). O ponto de quebra, a partir do qual passa a valer a pena o investimento em Linha de Produtos, o desenvolvimento de 3 sistemas, aproximadamente (LINDEN et. al., 2007).

25

A Figura 5, mostrada abaixo, evidencia a reduo dos custos de desenvolvimento a cada software desenvolvido com o uso da abordagem de LPS. Em contraste, os custos de desenvolvimento de sistemas nicos crescem na medida em que aumenta a quantidade de softwares desenvolvidos.

Figura 5 - Custos da Linha de Produtos de Software. Adaptada de (LINDEN et. al., 2007, p.4)

Melhor aproveitamento dos recursos humanos: Visto que a maior parte do trabalho est concentrada no desenvolvimento da plataforma, ao fim desta fase grande parte da equipe de desenvolvimento j pode ser alocada para outros projetos. preciso somente uma frao desta equipe para o desenvolvimento dos produtos da linha.

Reduo do time-to-market: Estando a plataforma pronta, os esforos para a elaborao do novo produto concentram-se apenas na sua montagem, a das partir dos artefatos especficas da do plataforma, mesmo. e Por

desenvolvimento

features

consequncia, o tempo de entrada do produto no mercado reduzido.

Aumento da qualidade dos produtos: Se um erro for encontrado em qualquer produto da linha, a soluo para o mesmo propagada a todos os outros produtos. Alm disso, os artefatos da plataforma so

26

testados em diversos produtos, o que implica em aumento da qualidade.

Benefcios para os clientes: a padronizao dos artefatos traz benefcios de usabilidade para os clientes, que tero facilidade em manusear diferentes produtos da linha, j que a interface dos produtos (baseados na mesma plataforma) se assemelha. J a customizao garante produtos adaptados s suas necessidades. Outrossim, a reduo de custos de desenvolvimento se reflete no preo final do produto, que ser diminudo.

Diversos relatos de experincias mostram que grandes empresas tm-se aproveitado dos benefcios ocasionados pela adoo da Linha de Produtos de Software. Entre as quais podemos citar: Bosch, Nokia, Philips, Siemens (LINDEN et. al., 2007); Motorola (JIANG et. al., 2008); Foras Armadas Norte Americana (BERGEY et. al., 2010), entre outras. Tais exposies mostram que a LPS vem ganhando fora com o passar dos anos, tornando-se estratgia de desenvolvimento de empresas renomadas em todo o mundo. 2.1.5. Riscos Adotar a estratgia de Linha de Produtos de Software, claro, tem seus riscos associados. Este projeto pode ser considerado uma mudana tecnolgica e, portanto, deve envolver uma avaliao da situao atual da empresa, uma articulao do estado desejado e a elaborao de um plano para atingir este estado (DURSCKI et al., 2004). Clements e Northrop apud Cohen (2002) relatam, entre outros, os seguintes riscos associados adoo da LPS:

Lder no identificado: sem um lder com autoridade de gesto, a LPS no pode ter xito. O lder o indivduo que comunica o projeto gerncia e aos desenvolvedores, mantm o projeto durante a adoo, conserva os desenvolvedores na direo correta diante das

dificuldades e mantm a equipe motivada. Onde no h indivduos com estas qualidades, a adoo geralmente falha.

27

Abordagem incompatvel: A Linha de Produtos de Software deve ser uma estratgia que atenda s metas especficas da empresa. Embora as metas variem de organizao para organizao, os objetivos da LPS so sempre baseados na explorao do reuso sistemtico entre os produtos. Se os produtos em desenvolvimento no tm

similaridades suficientes para justificar uma abordagem de Linha de Produtos, qualquer esforo de empreendimento ir falhar devido falta de resultados tangveis.

Adaptao

insuficiente:

Assim

como

arquitetura

ou

os

componentes requerem um grau de adaptao para uma Linha de Produtos, a organizao tambm deve adaptar suas prticas em relao s equipes de desenvolvimento ou produtos. A falta de adaptabilidade pode resultar em desempenho abaixo do ideal ou desvios de planejamento, os quais inviabilizam a LPS.

Falha na evoluo da abordagem: se a LPS no aperfeioada continuamente ao longo do tempo, as prticas provavelmente iro se tornar ineficazes e desvios de planejamento iro surgir.

Divulgao ineficaz: O lder da Linha de Produtos deve assumir a responsabilidade de desenvolver e distribuir o tipo e nveis apropriados de documentao, treinamento, e suporte efetivo da LPS, os quais so essenciais para um lanamento bem-sucedido da linha de produtos. O lanamento no ocorrer conforme previsto ou no produzir os resultados desejados se houver preparao inadequada.

Padronizao inadequada: As organizaes comumente erram em imaginar que a adoo de normas sustentar automaticamente a LPS. Infelizmente, se a institucionalizao ocorre muito rapidamente, normas inadequadas ou obsoletas podero ser institudas, e a inovao pode ser encerrada prematuramente. Por outro lado, se a normatizao

28

esquecida ou est obsoleta, pode haver esforos redundantes ou divergentes.

Alm dos j citados anteriormente, consideramos importante tratar tambm os seguintes riscos:

Decises sobre a plataforma: Gerenciar a entrada e sada dos componentes da plataforma no algo simples. Alm de um levantamento de requisitos eficaz, necessrio estar atento s mudanas pelas quais a Linha de Produtos passa. Alm do mais, se a plataforma crescer exageradamente, sua gesto pode se tornar bastante complexa.

Gesto do conhecimento: Todo desenvolvedor deve conhecer com certa profundidade a plataforma de artefatos reusveis. No entanto, se a plataforma crescer demasiadamente em tamanho e complexidade (sem o devido gerenciamento) isso pode se tornar-se uma complicada tarefa para cada novo desenvolvedor contratado.

Obsolescncia dos componentes da plataforma: preciso que o gestor da Linha de Produtos esteja atento tambm ao momento de descartar ou reescrever certos componentes da linha. Manter artefatos obsoletos na plataforma pode resultar em perda da eficcia da mesma.

Rastreabilidade dos componentes: gerenciar a rastreabilidade dos componentes (ou seja, saber qual produto da linha possui qual artefato da plataforma) de suma importncia para o sucesso da LPS. Se no houver gesto sobre isso, o responsvel pela linha fica impossibilitado de administrar as diversas aplicaes, pois no possvel identificar particularidades de um produto mediante outro.

Tais riscos evidenciam a necessidade de um gerenciamento efetivo da Linha de Produtos. Do contrrio, estes riscos podem suplantar as vantagens de sua adoo.

29

2.2.

FERRAMENTAS CASE Apresentamos, a seguir, um breve histrico, conceito, classificao e

vantagens da utilizao de ferramentas CASE nas tarefas de Engenharia de Software e, especificamente, em Linha de Produtos de Software. 2.2.1. Histrico Ferramentas de apoio ao desenvolvimento de software so usadas desde a origem da programao, poca dos mainframes. No entanto, at a dcada de 1970, a Engenharia de Software (ES) fazia uso principalmente de softwares simples e fundamentais para o desenvolvimento, como editores de texto e compiladores. Apesar de desenvolver softwares para automatizar os processos de outras reas de conhecimento, as ferramentas eram insuficientes na ES. Como definiu McIlroy (1968, p.138, traduo nossa), a indstria de software no industrializada. Nas dcadas seguintes, novas ferramentas mais elaboradas surgiram: Ferramentas para controle de verses, ferramentas para testes de software, gerncia de projetos e inmeras outras. A estas ferramentas, simples ou elaboradas, damos o nome de Computer-Aided Software Engineering (Engenharia de Software Auxiliada por Computador - CASE). O termo CASE refere-se ao uso de ferramentas para auxiliar as tarefas de Engenharia de Software. 2.2.2. Conceito Ferramentas CASE so utilizadas para automatizao de atividades de rotina. O termo CASE faz referncia a todas as ferramentas que auxiliam as tarefas de Engenharia de Software. Segundo Sommerville (2010, p.12, traduo nossa), o acrnimo CASE abrange uma ampla gama de diferentes tipos de programas que so usados para apoiar as atividades de processo de software, como a anlise de requisitos, modelagem de sistemas, depurao e testes. No que se refere abrangncia, as ferramentas CASE podem ser usadas em diferentes atividades. Segundo Pressman (2001, p.825, traduo nossa), as ferramentas CASE automatizam atividades de gerenciamento de projeto, gerenciam todos os trabalhos produzidos ao longo do processo, e ajudam os engenheiros em sua anlise, projeto, codificao e trabalho de teste.

30

As ferramentas CASE podem ser voltadas para uma tarefa especfica de ES, ou oferecer suporte a diversas tarefas - sendo ento conhecidas como ferramentas CASE Integradas. A integrao de ferramentas maximiza as vantagens da Engenharia de Software Auxiliada por Computador, permitindo que toda informao de Engenharia de Software esteja disponvel para qualquer ferramenta que necessit-la. As motivaes para utilizao das ferramentas CASE (integradas ou no) sero apresentadas na seo seguinte deste trabalho. 2.2.3. Motivao A Engenharia de Software preocupa-se no somente com os aspectos tcnicos de desenvolvimento, mas tambm com atividades como o gerenciamento de projetos de software e o desenvolvimento de ferramentas, mtodos e teorias que deem apoio produo de software (SOMMERVILLE, 2010). E o uso destas ferramentas pode trazer benefcios para cada uma destas diversas atividades da ES. Em um estudo de caso conduzido na Sucia, Cronholm (1995) identificou duas razes principais para a utilizao de ferramentas CASE: diminuio do tempo de desenvolvimento e melhoria da qualidade dos produtos. Com relao necessidade de desenvolver softwares mais rapidamente, as ferramentas mostraram-se teis nos seguintes aspectos: Maior agilidade na execuo de tarefas cotidianas algumas tarefas, tais como a criao e modificao de grficos, so realizadas de maneira mais gil. Alm disso, as ferramentas CASE facilitam a documentao destas tarefas.

Auxlio

na

padronizao

de

mtodos

com

ferramentas

desenvolvidas com base nos padres da empresa, possvel padronizar as tarefas de desenvolvimento (e os artefatos gerados por estas tarefas). A estas ferramentas, cujo foco est no processo, damos o nome de Process-Centered Software Engineering Environments (Ambientes de Engenharia de Software Centrados no Processo).

31

Maior agilidade no relacionamento com os usurios finais As reunies com os clientes, nas quais se define o domnio do problema e o escopo do projeto so realizadas com o apoio de documentos e diagramas. Com as ferramentas CASE, estas reunies podem ser mais rapidamente documentadas e a corretude dos diagramas mais rapidamente verificada junto ao cliente.

Com relao melhoria dos produtos, puderam-se perceber as seguintes motivaes: Capacidade de flexibilizao dos processos As organizaes desejam ser capazes de escolher o mtodo de desenvolvimento apropriado - na ferramenta CASE - de acordo com uma situao especfica (o domnio do problema, por exemplo). Capacidade de redigir documentaes mais consistentes possvel, por exemplo, obter um relatrio automaticamente se todos os objetos existentes em um grfico estiverem descritos no repositrio. Essa funcionalidade permite uma documentao mais livre de erros e minimiza a ambiguidade.

Alm das motivaes enumeradas anteriormente, Pressman (2001) cita a facilidade de transferncia de informao (modelos, programas, documentos, dados) de uma ferramenta para outra e de uma etapa de Engenharia de Software para a seguinte; e o aumento do controle do projeto, que conseguido atravs de um melhor planejamento, monitoramento e comunicao.

2.2.4. Classificao das Ferramentas CASE A classificao das ferramentas CASE permite uma melhor compreenso de onde cada ferramenta pode ser aplicada nas tarefas de ES. Esta categorizao, no entanto, no uma tarefa trivial.

32

Diversas taxonomias j foram propostas na literatura, tais como (MCCLURE, 1989; FURGETTA, 1993; PRESSMAN, 2001), cada uma levando em conta aspectos diferentes para realizar a classificao (funo, processo apoiado pela ferramenta, entre outros). Mas, apesar dos esforos, no h um padro universalmente aceito. Uma das classificaes mais citadas a proposta por Afonso Furgetta, que relaciona as ferramentas CASE de acordo com o processo de produo. Furgetta (1993) separa as ferramentas CASE nas seguintes categorias: Ferramentas, workbenches e ambientes.

Ferramentas as ferramentas do suporte apenas a tarefas especficas no processo de software e podem ser classificadas conforme mostrado na Tabela 2, apresentada a seguir:

Tabela 2 - Classificao das ferramentas segundo Furgetta (1993)

Classe

Descrio

Exemplos Processadores de texto,

Edio

Divididas em textuais e grficas

ferramentas de desenho. Compiladores, depuradores. Verificadores de sintaxe, geradores de casos de teste. Controle de verses, controle de mudanas Analisadores de cdigo, monitores de execuo Ferramentas de planejamento e estimao de custos.

Programao Validao e verificao Gerncia de configurao Mtricas e medio Gerncia de projetos

Usadas nas tarefas de codificao Apoiam a validao dos requisitos do cliente e verificao do projeto. Controlam a construo de um sistema composto de muitas partes. Coletam dados sobre os programas e sobre sua execuo Inclui suporte ao planejamento e coordenao dos projetos

33

Workbenches Os workbenches do suporte apenas a uma ou poucas atividades. So usualmente construdos como um conjunto de ferramentas e podem ser classificados conforme a Tabela 3, apresentada abaixo:

Tabela 3 - Classificao dos workbenches segundo Furgetta (1993)

Classe Planejamento e modelagem empresarial Anlise e modelagem Desenvolvimento de interface Programao

Descrio Auxiliam a criao de modelos de alto nvel para avaliar fluxo de informaes Utilizados nas fases iniciais do processo de software Auxiliam na criao, teste e integrao de componentes de interface Fornecem interface integrada para gerenciar os itens de desenvolvimento Integra ferramentas para as mtricas, medies e verificao e validao Geralmente composto pelas mesmas ferramentas usadas no desenvolvimento Prov ambiente integrado para controle de mudanas Integra ferramentas de apoio s atividades de gerenciamento

Exemplos Incluem geradores de relatrio, geradores de grficos Inclui geradores de modelo de fluxo de dados e E-R Inclui ferramentas para criao de janelas, testadores de interface Inclui editor de texto, compilador e depurador Inclui analisador de cdigo e geradores de caso de teste Inclui reestruturadores de cdigo, geradores de referncia cruzada Inclui controle de verses, de mudanas Inclui ferramentas para planejar e dirigir projetos

Validao e verificao Manuteno e engenharia reversa Gerncia de configurao Gerncia de projetos

34

Ambientes Os ambientes do suporte a uma grande parte do processo de software. Podem ser classificados de acordo com a Tabela 4, apresentada abaixo:
Tabela 4 - Classificao dos ambientes segundo Furgetta (1993)

Classe

Descrio Agregam diferentes ferramentas e workbenches.

Exemplos Em geral, so estendidos de um conjunto bsico do sistema operacional

Toolkits

extensvel, mas requer que o usurio integre-o explicitamente

Ambientes de linguagens centrados Ambientes integrados

Ambiente escrito na linguagem para a qual foi desenvolvido. Permite que os usurios personalizem e estendam-no Todos os produtos deste ambiente so operados atravs de interface nica e os dados so integrados em um repositrio Apoia o desenvolvimento de uma classe especfica de programas: processamento eletrnico de dados e aplicativos de negcios Interpreta um processo pr-definido e apoia as atividades de desenvolvimento. Automatiza fragmentos processo.

Geralmente concentrados no ciclo editar-compilar-depurar

Ambientes integrados de desenvolvimento

Quarta gerao

Inclui editores, compiladores e um repositrio centralizado Inclui ferramentas para modelar processos e interpretadores que executam tal modelo

Centrados no processo

2.2.5. Ferramentas CASE em Linha de Produtos de Software Como exposto nas sees anteriores deste trabalho, o emprego da abordagem de Linha de Produtos de Software no algo simples, uma vez que envolve mudanas significativas nos processos das empresas e possui diversos riscos associados. Diversas atividades tpicas da abordagem LPS podem ser auxiliadas por ferramentas CASE. A seguir, mostraremos a importncia deste apoio automatizado, apontando algumas atividades que poderiam obter benefcios por meio deste tipo de apoio, tomando por base os relatos dispostos em Bass et. al. (2000):

35

Definio da arquitetura A arquitetura da Linha de Produtos mais complexa que a de sistemas nicos, uma vez que ela planejada para um conjunto menor (a linha de produto como um todo) e estendida, de maneira adaptada, a um conjunto maior (cada produto desenvolvido). Para solucionar este problema, torna-se indispensvel o uso de ferramentas CASE.

Lidar com variabilidades da linha - Em um ambiente de linha de produtos, os artefatos tm de suportar a variabilidade intrnseca entre os vrios produtos da linha. Para descrever um conjunto completo de alternativas ou um conjunto de critrios para determinar a adequao de um substituto, tambm se faz necessrio o uso de ferramentas.

Gerncia de configurao multidimensional A abordagem de linha de produtos produz bens que so reutilizados em produtos diferentes, e cada produto tem vrias verses. O processo de gerenciamento de configurao deve ser capaz de reconstruir uma determinada construo de qualquer produto, reunindo uma variedade de ativos, incluindo projetos de arquitetura, modelos de anlise e exigncias.

Reuso dos artefatos - Tcnicas de desenvolvimento permitem que uma parte de um artefato possa ser reutilizada, em oposio a uma abordagem "tudo ou nada. Para lidar com esta necessidade, necessrio catalogar os artefatos e, como j citado anteriormente, desenvolver para reuso.

Catalogao dos artefatos reusveis manter um cadastro com todas as caractersticas dos artefatos visando gerenciar a

rastreabilidade dos artefatos. Gerao de cdigo as ferramentas podem dar suporte gerao de produtos (fase de Engenharia de Aplicao) a partir dos artefatos da plataforma.

36

Alm destas, centenas de outras tarefas podem ser auxiliadas por ferramentas. Inclumos nesta gama o gerenciamento da Engenharia de Domnio em Linha de Produtos de Software, que foco deste trabalho.

37

3. METODOLOGIA Neste captulo ser exposta a metodologia seguida para a realizao deste trabalho. Segundo Kahlmeyer-Mertens et. al. (2007, p.24), a metodologia cientfica se prope a definir regras e procedimentos que daro segurana e validade ao exerccio de conhecer, tendo a pesquisa presente nesse processo. Para isso, apresentamos, a seguir, a natureza da pesquisa e a metodologia para a anlise dos dados.

3.1.

Natureza da Pesquisa A natureza da pesquisa pode ser classificada: quanto aos fins, quanto aos

meios e quanto forma de abordagem. Apresentamos, em seguida, a classificao desde trabalho. 3.1.1. Quanto aos Fins Quanto aos fins, a presente pesquisa pode ser classificada como exploratria e descritiva. A pesquisa exploratria visa conhecer inicialmente o tema de estudo. Segundo Pinheiro (2010, p.21), a pesquisa exploratria visa proporcionar maior familiaridade com o problema com vistas a torn-lo explcito ou a construir hipteses. Neste trabalho, ser realizada atravs da reviso da literatura e da anlise de documentos que relatem experincias com o uso da abordagem de Linha de Produtos de Software. A pesquisa descritiva, por sua vez, visa descrever as caractersticas de determinada populao ou fenmeno ou o estabelecimento de relaes entre variveis (PINHEIRO, 2010, p.22). Neste trabalho, apresenta-se atravs da anlise e descrio das ferramentas encontradas.

3.1.2. Quanto aos Meios Quanto aos meios, o trabalho apresenta-se em forma de pesquisa bibliogrfica. Segundo Carvalho (1989, p.100), pesquisa bibliogrfica a atividade de localizao e consulta de fontes diversas de informao escrita, para coletar dados gerais ou especficos a respeito de determinado tema.

38

3.1.3. Quanto Forma de Abordagem Por fim, quanto forma de abordagem, a pesquisa classifica-se como qualitativa. Segundo Malhotra (2006, p.66), a pesquisa qualitativa uma metodologia de pesquisa exploratria e no-estruturada que se baseia em pequenas amostras com o objetivo de prover percepes e compreenso do problema.

3.2.

Anlise dos Dados A anlise dos dados ser realizada cumprindo os seguintes passos:

1. Pesquisar ferramentas CASE e relatos de experincias com o uso da abordagem de LPS As ferramentas e os relatos sero pesquisados em sites de buscas tradicionais (tais como Google7 e Yahoo8), alm das bibliotecas cientficas Association for Computing Machinery (ACM)9, Scientific Eletronic Library Online (SciELO)10, Institute of Electrical and Electronic Engineers (IEEE Xplore)11, ScienceDirect12 e Scopus13. O Anexo 1 contm as strings de busca utilizadas nesta pesquisa. 2. Catalogar ferramentas e relatos de experincia encontrados toda ferramenta para gerenciamento de Linha de Produtos de Software ser catalogada com as seguintes informaes: Nome, Autores, Site, Cdigo (disponvel ou no), Tipo e Ano. Para os relatos de experincia, sero catalogados com Ttulo, Autor e Ano apenas aqueles a partir dos quais houve inferncia de features.

3. Analisar

documentao

das

ferramentas

CASE

relatos

de

experincia Com relao s ferramentas, todas as features encontradas sero catalogadas; no que se refere aos relatos de experincia, a partir da anlise dos mesmos, sero relacionadas features que possam suprir
7 8

http://www.google.com.br/ http://br.search.yahoo.com/ 9 http://portal.acm.org/ 10 http://www.scielo.org/php/index.php 11 http://ieeexplore.ieee.org/ 12 http://www.sciencedirect.com/ 13 http://www.scopus.com/

39

necessidades e/ou dificuldades relatadas durante a execuo da abordagem de LPS. 4. Montar tabela com features A fim de dar maior visibilidade, ser montada uma tabela contendo todas as features encontradas e o problema-alvo a ser solucionado. Features adicionais, extradas de outras fontes, podero ser includas. 5. Proposta de features As features sero classificadas de acordo com a etapa do gerenciamento ao qual apoia (Gerenciamento Organizacional ou Gerenciamento Tcnico). Por fim, o conjunto de features que apoie efetivamente o gerenciamento do processo de Engenharia de Domnio em LPS ser apresentado (em tabelas) como resultado final deste trabalho.

O fluxo de atividades descrito pode ser resumido de acordo com a Figura 6, mostrada abaixo:

Pesquisar ferramentas CASE e relatos de experincias com o uso da abordagem de LPS

Catalogar ferramentas e relatos de experincia encontrados

Analisar documentao das ferramentas CASE e relatos de experincia

Montar tabela com features

Proposta de features

Figura 6 - Fluxo de atividades executado para realizao da pesquisa. Autor (2011)

40

4. UM ESTUDO SOBRE FERRAMENTAS CASE PARA GERENCIAMENTO DO PROCESSO DE ENGENHARIA DE DOMNIO EM LINHA DE PRODUTOS DE SOFTWARE Neste captulo, descreveremos as aes executadas para o cumprimento da pesquisa, realizada com vistas a alcanar um conjunto de features que apoie o gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software ao qual iremos nos referir pela sigla GED. Sero descritos o passo-a-passo da busca nas bases cientficas, o resultado desta busca e a proposta de soluo. Por fim, uma discusso sobre o trabalho apresentada.

4.1.

Realizao das Pesquisas nas Bases Cientficas Conforme explanado na metodologia (captulo 3), este trabalho tem incio com

a pesquisa das ferramentas e dos relatos de experincias em bases de dados cientficas. A partir desta pesquisa (detalhes no Anexo 1), foram retornados 345 (trezentos e quarenta e cinco) trabalhos. Um refinamento, a fim de obter somente artigos relevantes para a rea da pesquisa, foi realizado em trs passos: (1) excluso realizada a partir da leitura dos ttulos; (2) excluso dos trabalhos repetidos; (3) excluso a partir da leitura dos resumos. Desta forma, o nmero de artigos restantes foi 48 (quarenta e oito). Para este refinamento, foram usados os seguintes critrios:

Critrios de Incluso: Trabalhos que relatem experincias na execuo da LPS; Trabalhos que relatem experincia no uso de ferramentas durante a execuo da LPS.

Critrios de Excluso: Trabalhos que tratem de processos fora da Engenharia de Domnio. Trabalhos com contedo exclusivamente terico, os quais no so resultado de aplicao da LPS em ambiente acadmico ou profissional.

41

Ressaltamos que este refinamento foi realizado com cautela, pois, apesar de focar no GED, faz-se necessrio conhecer a maneira como outras atividades da Engenharia de Domnio so executadas, a fim de compreender como as mesmas podem ser gerenciadas com o auxlio de uma ferramenta CASE. Sendo assim, artigos com foco em outras atividades da Engenharia de Domnio, mas que pudessem contribuir para esta compreenso, tambm foram includos. A Figura 7 mostra a quantidade de trabalhos selecionados para leitura completa em cada base cientfica.

Figura 7 - Quantidade de trabalhos selecionados para leitura, classificados por base cientfica. Autor (2011)

Atravs dos resultados retornados, pudemos observar que o gerenciamento, como um todo, ainda um tema pouco tratado dentro do domnio de Linha de Produtos. Menos citado ainda o gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software. Trataremos destes detalhes nas sees a seguir, nas quais listamos as ferramentas e artigos considerados relevantes para a execuo deste trabalho.

4.2.

Anlise das Ferramentas

Durante as pesquisas, foram encontradas apenas 2 (duas) ferramentas com features que podem dar suporte ao GED. No entanto, nenhuma das ferramentas encontradas foi desenvolvida com foco no suporte ao gerenciamento em LPS.

42

A maioria das ferramentas encontradas nesta pesquisa est focada nas tarefas de gerenciamento da variabilidade ou na gerao automtica de produtos a partir da plataforma de artefatos reusveis, como o caso do FeaturePlugin14 e da pure::variants15, respectivamente. No entanto, algumas features de tais ferramentas foram consideradas teis para o GED e, portanto, 2 (duas) ferramentas foram selecionadas. Segue, abaixo, uma breve descrio de cada uma delas, a partir das informaes contidas em seus respectivos sites (ver Tabela 5):

CADSEg - A CADSEg um editor e gerador de CADSEs (Engenharia de Ambientes de Domnio Especficos Auxiliados por Computador). O objetivo principal da CADSE auxiliar os desenvolvedores na implementao das aplicaes. A CADSE se apresenta ao desenvolvedor como um workspace inteligente de alto nvel para o Eclipse16, que "conhece" os conceitos do domnio, e sabe a melhor forma de mape-los para artefatos de programao.

PloneMeeting Ferramenta em desenvolvimento para o Parlamento da Comunidade Francesa, mas disponvel para download por qualquer interessado. Permite que gerenciar sesses de discusso atravs de atas, agendas, opinies sobre os pontos discutidos, entre outros.

A Tabela 5 mostra as ferramentas selecionadas e seus dados. A coluna artigo refere-se ao artigo selecionado para leitura completa no qual a ferramenta citada. Quanto ao tipo, as ferramentas foram classificadas de acordo com Furgetta (1993).

14 15

http://gsd.uwaterloo.ca/fmp http://www.pure-systems.com/pure_variants.49.0.html 16 http://eclipse.org/

43

Tabela 5 Ferramentas selecionadas e seus dados. Autor (2011)

Nome CADSEg

Desenvolvedor (es)

Site http://cadse.imag.fr/

Cdigo No disponvel

Tipo Workbench

Artigo Software Product Line Evolution: The Selecta System, Estublier et. al., 2010. Taking Care of Cooperation when Evolving Socially Embedded Systems: The PloneMeeting Case. Unphon et. al., 2009

Plone Meeting

Jacky Estublier, German Vega, Philippe Lalanda, Thomas Leveque Hataichanok Unphon, Yvonne Dittrich e Arnaud Hubaux

http://www.commune splone.org/lesoutils/applicationsmetier/gestion-desdeliberations

Disponvel

Workbench

O conjunto de features que pode apoiar o gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software foi resultante da anlise da documentao de cada ferramenta. O nmero de features encontradas, no entanto, foi bastante restrito, uma vez que nenhuma das ferramentas tem foco no GED. As Tabelas 6 e 7, mostradas abaixo, mostram este conjunto de features extrado de cada ferramenta CASE analisada.

Tabela 6 CADSEg e suas features. Autor (2011)

CADSEg Feature Permitir visualizar a rastreabilidade dos artefatos (saber onde cada artefato foi utilizado e a relao entre eles) Problema que soluciona Permite saber quais artefatos ou produtos uma mudana poder afetar, auxiliando a deciso sobre mudanas na plataforma

Tabela 7 - PloneMeeting e suas features (continua). Autor (2011)

PloneMeeting Feature Problema que soluciona Minimiza problemas de comunicao, uma vez que a reunio agendada comunicada e advertida a todos os envolvidos automaticamente

Agendar reunies, enviando lembrete aos participantes

44

Tabela 7 PloneMeeting e suas features (concluso). Autor (2011)

Feature Criao, por parte dos membros da equipe, de pontos a serem discutidos na prxima reunio. O gerente pode validar se a discusso de tal ponto entrar na reunio. Criao da agenda de reunio, com os pontos validados pelo gerente Incluso, durante ou aps a reunio, das solues descritas para os pontos discutidos. Sendo permitido acesso posterior a todos os envolvidos Gerao em vrios formatos, de um documento descrevendo os pontos da reunio

Problema que soluciona Auxilia na organizao dos temas a serem discutidos nas reunies

Auxilia na organizao dos temas a serem discutidos nas reunies Facilita validao posterior da ata de reunies

Facilita a gerao das atas de reunio

Na seo seguinte, sero listadas as features encontradas nos relatos de experincia bem como maiores detalhes destes trabalhos. 4.3. Anlise dos Relatos de Experincia

Os relatos de experincia so instrumentos utilizados em diferentes reas de conhecimento, tais como medicina, administrao, psicologia e diversas outras. Seu objetivo de reportar experincias vivenciadas pelos autores, permitindo a troca de informaes sobre esta experincia e evidenciando sucessos e fracassos dos experimentos. No caso deste trabalho, os relatos evidenciam experincias na utilizao da abordagem de Linha de Produtos de Software. Apenas 3 (trs) trabalhos retornados tratavam explicitamente do processo de gerenciamento da LPS: Default Values for Improved Product Line Management, The Importance of Documentation, Design and Reuse in Risk Management for SPL e Standards Initiatives for Software Product Line Engineering and Management, sendo este ltimo uma reviso de literatura sobre o tema, no um relato de experincia. Os trabalhos restantes relatavam experincias gerais na execuo da LPS, nos quais estava includo o gerenciamento. Com relao aos relatos de experincia, 13 (treze) trabalhos trouxeram contribuies significativas. A Figura 8 mostra estes trabalhos, seus autores e o ano de publicao.

45

Figura 8 - Trabalhos com contribuies significativas, organizados por ano de publicao. Autor (2011)

46

A leitura completa dos relatos de experincia resultou em um conjunto de 11 (onze) features. A Tabela 8, a seguir, mostra um resumo dos problemas descritos nos relatos de experincia selecionados e suas respectivas propostas de soluo. A coluna Trabalhos refere-se ao identificador do trabalho (ver Figura 8) a partir do qual foram inferidas as features.

Tabela 8 - Features propostas para as lacunas encontradas nos relatos de experincia (continua). Autor (2011)

Trabalhos 9, 11

Feature sugerida Calcular custos de insero de novos artefatos na plataforma

Problema que soluciona Verificar viabilidade financeira do investimento, a fim de que a plataforma no cresa indiscriminadamente e sem gerar o devido retorno sobre o investimento Manter um banco de dados de lies aprendidas a fim de facilitar o gerenciamento de novos projetos

12

1 7, 10, 8

10

Armazenar descrio das dificuldades encontradas durante o projeto e respectivas solues Gerenciamento de aquisies de produtos e servios Visualizao de artefatos inacabados e percentual realizado Classificar artefatos de desenvolvimento (core assets) em essenciais ou opcionais.

D suporte ao gerenciamento financeiro da LPS Gerenciar equipe de desenvolvimento, a fim de aferir possveis atrasos no desenvolvimento Tomar decises de gerenciamento da equipe. Por exemplo: os desenvolvedores sero alocados para reparar um erro ou para o desenvolvimento de uma nova feature. A reparao de erro dever ser escolhida se o artefato for classificado como essencial Gerao de mtricas de tempo de desenvolvimento por desenvolvedor e quantidade de linhas de cdigo

13

6, 3 6

Capturar data/hora do incio e fim do desenvolvimento, desenvolvedor responsvel pelo artefato, quantidade de linhas de cdigo Cronograma: Armazenar dados de atividades realizadas e a realizar, predio de quando as atividades sero finalizadas (clculo de acordo com a complexidade cadastrada para a atividade) Minerar e extrair artefatos potencialmente reusveis Gerar relatrio de percentual de reuso da plataforma

Facilitar gerenciamento do tempo do projeto

Facilita o planejamento de tempo e custo de uma nova linha de produtos Auxilia o gerenciamento da plataforma, permitindo visualizar eficincia da mesma e possveis necessidades de mudana.

47

Tabela 8 Features propostas para as lacunas encontradas nos relatos de experincia (concluso). Autor (2011)

Trabalhos 2, 4, 5, 3

Feature sugerida Permitir visualizar a rastreabilidade dos artefatos (saber onde cada artefato foi utilizado e a relao entre eles) Classificar os artefatos de acordo com o artigo [9], a fim de seguir o modelo nele proposto para evoluo da plataforma

Problema que soluciona Permite saber quais artefatos ou produtos uma mudana poder afetar, auxiliando a deciso sobre mudanas na plataforma

Facilita decises sobre evoluo da plataforma. Mais uma forma de evitar que a mesma cresa indefinidamente, mantendo-a enxuta e gerencivel

O trabalho 9, Default Values for Improved Product Line Management apresenta um framework para gerenciar a evoluo da plataforma. Descrevendo de uma maneira sintetizada, este framework classifica os artefatos da plataforma em Proposto, Planejado, Selecionado, Excluvel, Obrigatrio, Obsoleto ou Removido, definindo processos-padro para que os artefatos passem de um tipo a outro. Por exemplo, para que um artefato se torne obrigatrio para a plataforma, sua classificao poder seguir o seguinte curso: Proposto Planejado Selecionvel Excluvel Obrigatrio. A utilizao deste processo, empregado pela empresa Nokia, estabelece uma metodologia para evoluo da plataforma, tanto impedindo que ela cresa indefinidamente quanto minimizando o impacto que a retirada de um artefato pode causar na mesma, uma vez que essa retirada planejada e acompanhada.

4.4.

Features Adicionais

Alm das features encontradas nas ferramentas CASE e a partir da leitura dos relatos de experincia, features adicionais, resultantes de outras fontes, foram inferidas. A Tabela 9, a seguir, mostra este levantamento:

48

Tabela 9 - Features adicionais. Autor (2011)

Origem Software Engineering Institute Software Engineering Institute

Feature sugerida Calcular custos de insero de um novo produto na linha, bem como o retorno financeiro que este novo produto pode trazer Documentar custos esperados para todo o projeto de LPS e refin-lo de acordo com a realidade do andamento do projeto Avaliar a preciso das estimativas de custo iniciais Permitir acompanhar o andamento do projeto, aferindo se as tarefas planejadas esto sendo executadas dentro dos prazos Identificar gargalos do projeto (o desenvolvimento de quais artefatos est atrasando o projeto) Estimar prazo para finalizao do projeto Estimar tempo restante para a implementao dos artefatos de desenvolvimento individualmente. Calculado a partir do nvel de complexidade (que deve ser cadastrado) Contar quantas vezes cada artefato foi usado em um produto por perodo (mensal) Distribuir tarefas para os desenvolvedores, informando-os prazos e atividades, conforme discutidos em reunies Minerar projetos anteriores a fim de verificar a possibilidade de reutilizao de artefatos de documentao

Problema que soluciona Verificar viabilidade financeira do investimento, auxiliando na tomada de deciso sobre os cursos do projeto Permite verificar se os gastos planejados esto de acordo com o esperado e constatar custos extras, que no foram planejados inicialmente

Software Engineering Institute Software Engineering Institute

Permite avaliar se o desenvolvimento Linha de Produtos est se concretizando da maneira como foi planejada Verificar se as metas planejadas esto sendo cumpridas

Proposta pelo Autor

Facilita o gerenciamento do tempo, possibilitando que o gerente use estas informaes para tambm gerenciar a equipe Facilita o gerenciamento de tempo do projeto Facilita o gerenciamento de tempo do projeto de uma maneira mais refinada

Proposta pelo Autor Proposta pelo Autor

Proposta pelo Autor Proposta pelo Autor

A fim de saber se um artefato est caindo em desuso (pois pode ser necessrio retir-lo da plataforma). Facilita a tomada de deciso sobre evoluo da plataforma Agiliza a comunicao, uma vez que as informaes sero enviadas automaticamente. Alm disso, a informao estar centralizada sempre que o desenvolvedor necessitar Agiliza a documentao do projeto atual

Proposta pelo Autor

4.5.

Proposta

Apresentamos, a seguir, a listagem das features que constituem a razo deste trabalho: a proposta de um conjunto de features que apoie efetivamente o

49

gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software. O conjunto final de features foi classificado de acordo com a fase do gerenciamento que apoia: Gerenciamento Organizacional ou Tcnico (conforme explanado na seo 2.1.3.3 deste trabalho). O resultado desta pesquisa est sintetizado nas Tabelas 10 e 11, que apresentam as features propostas, classificadas de acordo a etapa do gerenciamento a qual ela d suporte.

Tabela 10 - Features propostas que apoiam o Gerenciamento Organizacional. Autor (2011)

Feature Calcular custos de insero de novos artefatos na plataforma Armazenar descrio das dificuldades encontradas durante o projeto e respectivas solues Gerenciamento de aquisies de produtos e servios Calcular custos de insero de um novo produto na linha, bem como o retorno financeiro que este novo produto pode trazer Documentar custos esperados para todo o projeto de LPS e refin-lo de acordo com a realidade do andamento do projeto Avaliar a preciso das estimativas de custo iniciais Permitir acompanhar o andamento do projeto, aferindo se as tarefas planejadas esto sendo executadas dentro dos prazos

Processo que apoia Gerenciamento Organizacional Gerenciamento Organizacional Gerenciamento Organizacional Gerenciamento Organizacional Gerenciamento Organizacional Gerenciamento Organizacional Gerenciamento Organizacional

Tabela 11 - Features propostas que apoiam o Gerenciamento Tcnico (continua). Autor (2011)

Feature Agendar reunies, enviando lembrete aos participantes Criao, por parte dos membros da equipe, de pontos a serem discutidos na prxima reunio. O gerente pode validar se a discusso se tal ponto entrar na reunio. Criao da agenda de reunio, com os pontos validados pelo gerente Incluso, durante ou aps a reunio, das solues descritas para os pontos discutidos. Sendo permitido acesso posterior a todos os envolvidos

Processo que apoia Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico

50

Tabela 11 Features propostas que apoiam o Gerenciamento Tcnico (concluso). Autor (2011)

Feature Gerao em vrios formatos, de um documento descrevendo os pontos da reunio Visualizao de artefatos inacabados e percentual realizado Classificar artefatos de desenvolvimento (core assets) em essenciais ou opcionais. Capturar data/hora do incio e fim do desenvolvimento, desenvolvedor responsvel pelo artefato, quantidade de linhas de cdigo Cronograma: Armazenar dados de atividades realizadas e a realizar, predio de quando as atividades sero finalizadas (clculo de acordo com a complexidade cadastrada para a atividade) Minerar e extrair artefatos potencialmente reusveis Gerar relatrio de percentual de reuso da plataforma Permitir visualizar a rastreabilidade dos artefatos (saber onde cada artefato foi utilizado e a relao entre eles) Classificar os artefatos de acordo com o artigo [9], a fim de seguir o modelo nele proposto para evoluo da plataforma Identificar gargalos do projeto (o desenvolvimento de quais artefatos est atrasando o projeto) Estimar prazo para finalizao do projeto Estimar tempo restante para a implementao dos artefatos de desenvolvimento individualmente. Calculado a partir do nvel de complexidade (que deve ser cadastrado) Contar quantas vezes cada artefato foi usado em um produto por perodo (mensal) Distribuir tarefas para os desenvolvedores, informando-os prazos e atividades, conforme discutidos em reunies Minerar projetos anteriores a fim de verificar a possibilidade de reutilizao de artefatos de documentao

Processo que apoia Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico Gerenciamento Tcnico

4.5.1. Conjunto Proposto e Riscos da LPS Com relao aos riscos que podem afetar o andamento da Linha de Produtos de Software, o trabalho 12, The Importance of Documentation, Design and Reuse in Risk Management for SPL, traz um conjunto bastante completo de riscos inerentes LPS, resultantes de uma reviso sistemtica da literatura e de estudos de caso.

51

Alguns desses riscos podem ser gerenciados com apoio de ferramentas CASE. Tomando por base estes riscos, podemos observar que o conjunto de features proposto por este trabalho d suporte na mitigao dos seguintes riscos:

Documentao inadequada - uma vez h features que apoiam a documentao do projeto; Falta de informao sobre a Linha de Produtos por auxiliar na gerao de informaes sobre o andamento da LPS; Poluio da plataforma e imutabilidade da plataforma (a plataforma no muda para atender novas necessidades) uma vez que auxilia na evoluo da plataforma e na insero de novos componentes;

Falta de ferramenta de suporte uma vez que o conjunto de features pode ser transformado em ferramenta, a qual ir apoiar a LPS. Comunicao inadequada j que possui features de apoio comunicao entre a gerncia e a equipe; Custos de desenvolvimento limitados auxilia no planejamento de gastos; Atraso no time-to-market possui features que do auxlio ao acompanhamento do projeto, permitindo verificar possveis atrasos com antecedncia.

A partir desta perspectiva, podemos observar que o conjunto de features proposto d grande suporte ao gerenciamento de riscos, alm de apoiar atividades cotidianas de gerenciamento do GED.

4.6.

Discusso

A seguir, dada uma pequena discusso acerca da execuo deste trabalho. 4.6.1. Dificuldades Uma das grandes dificuldades para a execuo deste trabalho foi a falta de material publicado sobre o tema Gerenciamento do Processo de Engenharia de Domnio em Linha de Produtos de Software. Apesar da sua importncia em qualquer

52

projeto de software, utilizando LPS ou no, este aspecto tem sido pouco mencionado na literatura. Alm disso, no foi encontrada nenhuma ferramenta especfica para gerenciar a LPS, o que no permitiu a utilizao de nenhuma base para o conjunto de features, que precisou ler levantado partindo do zero. Outro problema identificado a falta de padro na tarefa de Gerenciamento. Um exemplo disto o framework proposto por Pohl et. al. (2005), que mostra o gerenciamento como uma fase isolada, que se preocupa basicamente com os aspectos financeiros da LPS. Na prtica, o gerenciamento deve estar envolvido com todos os aspectos da LPS, dando suporte execuo da mesma. O prprio modelo do SEI, que divide o gerenciamento em Organizacional e Tcnico, inclui atividades dentro destas duas grandes reas que no esto sob responsabilidade do gerente da LPS, como o caso da Gesto de Configurao, Anlise de Mercado, Marketing, e outras, as quais devem possuir uma equipe especfica para sua realizao. Como no este o foco do presente trabalho, estas atividades foram ignoradas, sendo dada nfase s tarefas de gerenciamento da Engenharia de Domnio. 4.6.2. Limitaes da Pesquisa Uma das limitaes do presente trabalho a utilizao de strings de busca diferentes em cada base cientfica. Esta escolha, no entanto, se deu aps a realizao de testes nas bases cientficas escolhidas para a pesquisa. Quando a quantidade de resultados retornados por uma string de busca dificultava a execuo deste trabalho (tendo em vista que a pesquisa deveria ser realizada em cinco bases cientficas diferentes) a string era refinada. A pesquisa, no entanto, deveria conter obrigatoriamente as palavras-chave Software Product Line (ou product families) e Tool (ou report). Um exemplo deste problema ocorreu com a utilizao da string ("software product line" OR "product families") AND ("management") AND ("tool" OR "report") na base Scopus, que retornou 1.965 (mil novecentos e sessenta e cinco) resultados. Um refinamento, utilizando s os ttulos dos trabalhos permitiu que a mesma string retornasse 20 (vinte) resultados.

53

5. CONSIDERAES FINAIS Este trabalho apresentou a proposta de um conjunto features que uma ferramenta deve possuir para dar suporte ao Gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software (GED). Percebe-se que a LPS tem sido uma soluo bastante adotada nas empresas, havendo inmeros relatos de experincia sobre o uso desta abordagem. Atravs da anlise de ferramentas e leitura de relatos de experincia, percebe-se que h grande deficincia de ferramentas que possam apoiar o GED: nenhuma ferramenta que apoie esta tarefa foi encontrada. Adicionalmente, o gerenciamento da LPS, como um todo, tem sido um assunto pouco tratado nas publicaes cientficas. Aps a realizao dos estudos, conclumos, portanto, que os objetivos da pesquisa foram alcanados e a pergunta de pesquisa (Quais so as features que uma CASE deve possuir para contribuir efetivamente com o gerenciamento do processo de Engenharia de Domnio em Linha de Produtos de Software?) foi respondida aps a anlise das ferramentas e dos relatos de experincia, que resultou na proposta de um conjunto de features. Apresentamos, a seguir, os trabalhos relacionados a este, as propostas de trabalhos futuros e lies aprendidas durante a execuo deste estudo. 5.1. Trabalhos Relacionados Durante as pesquisas para realizao deste estudo, diversos trabalhos que relacionam Linha de Produtos de Software e ferramentas CASE foram encontrados. O capitulo 4 apresentou alguns deles. Alm destes, podemos citar como trabalho relacionado a dissertao de Liana Lisboa, ToolDAy A Tool for Domain Analysis, a qual serviu de inspirao para a realizao do presente estudo. Lisboa realizou um estudo extensivo sobre ferramentas CASE para Anlise de Domnio em LPS a fim de levantar requisitos e desenvolver uma ferramenta que d suporte a este processo. As duas principais diferenas deste trabalho para os listados acima so o foco e os relatos de experincia. O presente trabalho tem foco no GED, que no foi tratado especificamente em nenhum trabalho encontrado. Alm disto, neste trabalho, foram utilizados relatos de experincia e ferramentas CASE a fim de inferir o

54

conjunto de features. Em oposio, o trabalho de Lisboa utilizou como base apenas ferramentas j existentes. 5.2. Trabalhos Futuros Como trabalhos futuros, decorrentes desta pesquisa, sugerimos o

desenvolvimento de uma ferramenta, a qual possua o conjunto de features proposto. Adicionalmente, a realizao de um estudo de caso em projetos de Linha de Produtos fazendo uso desta ferramenta poderia aferir a eficcia da mesma, alm de permitir a implementao de melhorias e refinamentos, percebidos aps uso dirio da ferramenta. Por fim, sugerimos ainda expandir a pesquisa para outras reas da LPS, que possam oferecer ferramentas CASE de suporte equipe de desenvolvimento.

5.3.

Lies Aprendidas Durante a execuo deste estudo, diversas lies foram aprendidas.

Compartilharemos algumas delas a seguir. Aps inferir algumas features que no faziam parte do GED, as quais foram excludas aps exame dos orientadores, foi necessria uma pesquisa extensiva dos processos de gerenciamento em LPS. A inteno desta era estabelecer um padro a ser utilizado por este trabalho, uma vez que, conforme explicado anteriormente, a literatura no prov este padro. Sendo assim, mesmo no havendo um padro para o processo o qual se deseja pesquisar, faz-se necessrio estabelec-lo. Alm disso, devido falta de trabalhos focados no Gerenciamento do Processo de Engenharia de Domnio, foi preciso usar de perspiccia para inferir features em trabalhos sequer citavam o gerenciamento. Era preciso ler os artigos atentamente, buscando a descrio de qualquer lacuna que pudesse ser apoiada por uma ferramenta. Por fim, todo o processo de pesquisa serviu de aprendizado para a execuo dos trabalhos posteriores a este.

55

6. REFERNCIAS BASS, Len; CLEMENTS, Paul; DONOHOE, Patrick; MCGREGOR, John;

NORTHROP, Linda. Fourth Product Line Practice Workshop Report. Technical report CMU/SEI-2000-TR-002 ESC-TR-2000-002. February, 2000. Disponvel em: http://www.sei.cmu.edu/reports/00tr002.pdf. Acesso: 08/05/2011.

BERGEY, John K.; CHASTEK, Gary; COHEN, Sholom; DONOHOE, Patrick; JONES, Lawrence G.; NORTHROP, Linda. Software Product Lines: Report of the 2010 U.S. Army Software Product Line Workshop. Carnegie Mellon University: June, 2010. Disponvel em: <http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=Get

TRDoc.pdf&AD=ADA528683>. Acesso: 08/03/2011.

BOTELHO, Adriano. Do Fordismo Produo Flexvel: O espao da indstria num contexto de mudanas das estratgias de acumulao do capital. So Paulo: Annablume Editora, 2008.

CARVALHO, Maria. Ceclia Maringoni de (org.). Construindo o saber Metodologia Cientfica: Fundamentos e tcnicas. 2 edio. Campinas: Papirus, 1989.

COHEN, Sholom. Product Line State of the Practice Report. Technical Note CMU/SEI-2002-TN-017. Pittsburgh: September, 2002. Disponvel em <

http://www.sei.cmu.edu/library/abstracts/reports/02tn017.cfm>. Acesso: 09/03/20011.

CRONHOLM, S.. Why CASE tools in information systems development? - an empirical study concerning motives for investing in case tools. In: 18th Information Systems research In Scandinavia (IRIS 18), Gjern, Denmark, 1995.

DURSCKI, Roberto C.; SPINOLA, Mauro M.; BURNETT, Robert C.; REINEHR, Sheila S.. Linhas de Produto de Software: riscos e vantagens de sua implantao. In: VI Simpsio Internacional de Melhoria de Processos de Software So Paulo, 2004.

56

FUGGETTA, Alfonso. A Classification of CASE Technology. In: IEEE Computer Society Press Los Alamitos, CA, USA. Volume 26 p. 25 - 38. 12, December 1993.

GARCIA, Vinicius Cardoso. RiSE reference model for software reuse adoption in brazilian companies. Tese (doutorado) Universidade Federal de Pernambuco. Recife, 2010.

FUSCO, Jos Paulo Alves; SACOMANO, Jos Benedito; BARBOSA, Fbio Alves; AZZOLINI, Walther Jnior. Administrao de operaes: da formulao estratgica ao controle operacional. So Paulo: Arte & Cincia, 2003.

HEINEMANN, Gerrit; SCHWARZL, Christoph. New Online Retailing Innovation and Transformation. Gabler, 2010.

HINDLE, Tim. Guide to Management Ideas and Gurus (Economist). 3rd edition. London: Economist Books, 2008.

JIANG, Michael; ZHANG, Jing; ZHAO, Hong; ZHOU, Yuanyuan. Maintaining Software Product Lines - An Industrial Practice. In: 24th IEEE International Conference on Software Maintenance. Beijing, 2008.

KAHLMEYER-MERTENS, Roberto S.; FUMANGA, Mario; TOFFANO, Claudia B.; SIQUEIRA, Fabio. Como elaborar projetos de pesquisa: Linguagem e mtodo. Rio de Janeiro, Editora FGV, 2007.

LINDEN, Frank van der; SCHMID, Klaus; ROMMES, Eelco. Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering.Springer, 2007. MALHOTRA, Naresh K.. Pesquisa de marketing: uma orientao aplicada. 4 edio. Bookman, 2006.

MATINLASSI, Mari. Comparison of Software Product Line Architecture Design Methods: COPA, FAST, FORM, KobrA and QADA. In: ICSE '04 Proceedings of the 26th International Conference on Software Engineering. Edinburgh, 2004.

57

MCCLURE , Carma. CASE is Software Automation. Prentice Hall. 1989.

MCILROY, Malcom Douglas. Mass Produced Software Components. In: Report on a conference sponsored by the NATO SCIENCE COMMITTEE. Garmisch, Germany, 7th to 11th October 1968.

NORTHROP, Linda. Software Product Lines Essentials. Software Engineering Institute, Carnegie Mellon University. Pittsburgh, PA 15213-2612, 2008. Disponvel em: <http://www.sei.cmu.edu/library/assets/spl-essentials.pdf>. Acesso: 31/03/2011.

PARNAS, David L.; On the Design and Development of Program Families. In: IEEE Transactions on Software Engineering. Vol. SE-2, N 1. March 1976. Disponvel em: < http://web.cecs.pdx.edu/~omse532/Parnas_Families.pdf >. Acesso: 08/03/2011.

PINHEIRO, Jos Maurcio dos Santos. Da Iniciao Cientfica ao TCC: Uma Abordagem para os Cursos de Tecnologia.1 edio. Cincia Moderna, 2010.

POHL, Klaus; BCKLE, Gnter; LINDEN, Frank van der. Software Product Line Engineering: Foundations, Principles, and Techniques. Springer, 2005.

PRESSMAN, Roger S. Software Engineering: A Practitioner's Approach. 5th edition. McGraw-Hill, 2001.

SOMMERVILLE, Ian. Software Engineering. 9th edition. Addison Wesley, 2010.

SOUSA, M. R.; RIBEIRO, A. L. P. Systematic Review And Meta-Analysis Of Diagnostic And Prognostic Studies: A Tutorial. Arquivo Brasileiro de Cardiologia, V. 92, N. 3, P. 241-251, 2009.

VASCONCELOS, Eduardo; HEMSLEY, James R. Estrutura das organizaes: Estruturas tradicionais, estruturas para inovao, estrutura matricial.. 4 edio. So Paulo, Editora Thompson, 2003.

58

ANEXO 1 RESULTADO DA BUSCA NAS BASES CIENTFICAS A seguir, so relatados os detalhes das pesquisas realizadas em cada base cientfica, a saber: Scopus, SciELO, IEEE Xplore, Science Direct e ACM.

Tabela 1 - Detalhamento da pesquisa. Autor (2011)

Data da pesquisa

ResulStrings utilizadas (TITLE("software product line") OR TITLE("product family") tado

Scopus

18/04/2011

OR TITLE("product families") AND TITLE("tool") OR TITLE("report"))

20

SciELO

18/04/2011

("software product line" OR "product families") AND ("report" OR "tool") (((Abstract:"software product line") OR Abstract:"product

IEEE Xplore

18/04/2011

families") AND Abstract:"report") (((Abstract:"software product line") OR Abstract:"product families") AND Abstract:"tool") (TITLE"software product line" OR TITLE"product families") 47

Science Direct

18/04/2011

AND (TITLE"tool" OR TITLE"report") AND (TITLE"management") Realizada com a opo em todas as reas de assunto ("software product line" OR "product families") AND

92

87

ACM

21/04/2011

("management") AND ("report") ("software product line" OR "product families") AND ("management") AND ("tool" OR "system") Total: 345 trabalhos 90