Um Estudo sobre Ferramentas CASE para Gerenciamento do Processo de Engenharia de Domínio em Linha de Produtos de Software

UNIVERSIDADE DE PERNAMBUCO ELYDA LAISA SOARES XAVIER

UM ESTUDO SOBRE FERRAMENTAS CASE PARA GERENCIAMENTO DO PROCESSO DE ENGENHARIA DE DOMÍNIO 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 DOMÍNIO EM LINHA DE PRODUTOS DE SOFTWARE 

Monografia apresentada à Universidade de Pernambuco como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação, sob orientação do Prof. M.Sc. Humberto Rocha de Almeida Neto e co-orientação do Prof. D.Sc. Vinícius Cardoso Garcia.

CARUARU 2011

À minha família, 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 graduação bem como durante a execução deste trabalho. À minha mãe, Edna Cristina, pelo amor incondicional que dedica a mim, minha irmã, Erika Sabrinna, e meu sobrinho, Éder Vinícius; por acordar às 06h para preparar meu café da manhã após uma noite agitada de estudos, pelas broncas, conselhos, pela paciência e tanto mais. Ao meu pai, João 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 paciência 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, Diógenes Ricardo, pelos trabalhos em grupo, pela paciência (ou pela falta dela =P) durante as reuniões para execução destes trabalhos; pela confiança, pelo amor e, principalmente, pelo empenho em mostrarme a Verdade. Te amo, meu amor. À minha família, pelo amor e incentivo (e pelos inúmeros momentos hilários que passamos juntos, os quais são motivo de gargalhadas durante nossas reuniões). Sem eles eu não teria conseguido. Ao meu orientador, Humberto Rocha, pelas contribuições e pela paciência e confiança em orientar-me. Além de orientador, era preciso ser psicólogo. E ele cumpriu bem esse papel também! Ao meu co-orientador, Vinícius Garcia, pela confiança depositada em mim durante todos os trabalhos que fizemos na graduação e pela orientação deste trabalho, nunca me entregando as respostas de „mãos beijadas‟, mas sempre me

incitando a pensar. Obrigada, Vinícius. À equipe do SigConfex e ao nosso orientador, Fernando Carvalho, pelo aprendizado e pelas risadas. Aos professores da UPE Caruaru, por terem contribuído para a minha formação com seus conhecimentos e conselhos durante estes 4 anos. Ao meu pastor, Ary Queiroz Jr., pela preocupação com a minha vida espiritual, pelo auxílio nos momentos difíceis e pelos edificantes estudos bíblicos que me fazem, cada dia mais, crescer “ na graça e no conhecimento de nosso  Senhor e Salvador Jesus Cristo ” (2 Pe 3:18).

À minha igreja, I Congregacional de Caruaru, pela comunhão e pela oportunidade de trabalhar com as crianças da Escola Bíblica Mensal. Aos meus amigos: Aêda, João, Bruno, André, Warla, Marísia, Joana, Poeta, Jéssica, Walkiria e Cristianne por compartilhar tantos momentos de alegria e por me aturar nos momentos de tristeza. A Moisés Bonifácio, meu professor de espanhol durante o ensino fu ndamental e médio, por acreditar no meu potencial e por depositar sua confiança em mim. Moisés, você foi (e é) pra mim um grande amigo. Gracias por todo. Por fim, mas não menos importante, à Cardeal Distribuidora e a todos os que fazem parte desta empresa. Agradeço, 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 vocês. Deus os abençoe.

RESUMO:

Uma das abordagens sistemáticas de reuso de software  que mais tem crescido nas últimas décadas é a de Linha de Produtos de Software . Grandes empresas, como Nokia, Philips e Siemens têm-se utilizado desta abordagem a fim de reduzir o time-  to-market  de seus produtos, diminuir custos e aumentar a qualidade dos softwares  produzidos. A adoção da Linha de Produtos de Software , no entanto, não é algo simples. Para que haja sucesso na sua adoção, faz-se necessário um processo de gerenciamento sistematizado e consistente, que leve em consideração a posição importante que os artefatos reusáveis possuem. Neste contexto, as ferramentas CASE exercem um papel primordial no controle das iterações durante o desenvolvimento através da abordagem de Linha de Produtos de Software . Diante deste cenário, este trabalho visa investigar ferramentas CASE e relatos de experiência a fim de propor um conjunto de features  que apoie efetivamente o gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software.

Palavras-chave: Linha de Produtos de Software , Famílias de Produtos, Ferramentas CASE, Gerenciamento e Engenharia de Domínio.

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 - Três exemplares da série de aparelhos celulares E da Nokia, cujos sistemas compartilham diversas similaridades.......................................................... 14 Figura 3 - Vantagens da customização 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 realização da pesquisa. Autor (2011) .................................................................................................................................. 39 Figura 7 - Quantidade de trabalhos selecionados para leitura, classificados por base científica. Autor (2011) .............................................................................................. 41 Figura 8 - Trabalhos com contribuições significativas, significativas, organizados por ano de publicação. Autor (2011) ........................................................................................... 45

LISTA DE TABELAS Tabela 1 - Diferentes nomenclaturas envolvidas na LPS. ........................... .............. .......................... ............... 22 Tabela 2 - Classificação das ferramentas segundo Furgetta (1993) ......................... ............. ............ 32 Tabela 3 - Classificação dos workbenches segundo Furgetta (1993) ....................... ............. .......... 33 Tabela 4 - Classificação dos ambientes segundo Furgetta Furgetta (1993)............ (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 experiência (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 Técnico (continua). Autor (2011) .............................................................................................................. 49

SUMÁRIO 1. INTRODUÇÃO ................................................................................................... 13  1.1. Contextualização......................................................................................... 13 1.2. Problema de Pesquisa ................................................................................ 15 1.3. Objetivos ..................................................................................................... 15 1.3.1. Objetivo Geral ........................................................................................ 15 1.3.2. Objetivos Específicos ............................................................................ 16 1.4. Justificativa ................................................................................................. 16 1.5. Escopo Negativo ......................................................................................... 16 1.6. Contribuições .............................................................................................. 17 1.7. Organização do Trabalho ......................... ............ .......................... .......................... .......................... ......................... ............ 18 2. REFERENCIAL TEÓRICO ................................................................................ 19  2.1. LINHA DE PRODUTOS DE SOFTWARE (LPS) ........................... .............. .......................... ............... 19 2.1.1. Histórico ................................................................................................. 19 2.1.2. Conceito ................................................................................................ 21 2.1.3. Processos Fundamentais Fundamentais .................................... ....................... .......................... .......................... ..................... ........ 21 2.1.3.1. Engenharia de Domínio .................................................................. 22 2.1.3.2. Engenharia de Aplicação ................................................................ 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. Histórico ................................................................................................. 29 2.2.2. Conceito ................................................................................................ 29 2.2.3. Motivação .............................................................................................. 30 2.2.4. Classificação 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. Análise dos Dados ...................................................................................... 38

4. UM ESTUDO SOBRE FERRAMENTAS CASE PARA GERENCIAMENTO DO  PROCESSO DE ENGENHARIA DE DOMÍNIO EM LINHA DE PRODUTOS DE  SOFTWARE .............................................................................................................. 40  4.1. Realização das Pesquisas nas Bases Científicas ......................... ............ .......................... ............... 40 4.2. Análise das Ferramentas ............................................................................ 41 4.3. Análise dos Relatos de Experiência ........................... ............. .......................... ......................... ..................... ........ 44 4.4. Features Adicionais......................... ............ .......................... ........................... .......................... ......................... ..................... ........ 47 4.5. Proposta ...................................................................................................... 48 4.5.1. Conjunto Proposto e Riscos da LPS ......................... ............ .......................... .......................... ................ ... 50 4.6. Discussão ................................................................................................... 51 4.6.1. Dificuldades ........................................................................................... 51 4.6.2. Limitações da Pesquisa .......................... ............. .......................... .......................... .......................... ..................... ........ 52 5. CONSIDERAÇÕES FINAIS .......................... ............. .......................... .......................... .......................... .......................... ............... 53  5.1. 5.2. 5.3.

Trabalhos Relacionados ............................................................................. 53 Trabalhos Futuros ....................................................................................... 54 Lições Aprendidas....................................................................................... 54

6. REFERÊNCIAS ................................................................................................. 55  ANEXO 1  – RESULTADO DA BUSCA NAS BASES CIENTÍFICAS ....................... ............... ........ 58 

13

1. INTRODUÇÃO 1.1.

Contextualização

Nas últimas décadas, os computadores e, por consequência, os programas, tornaram-se parte do cotidiano das pessoas e das organizações. O software  tornouse um diferencial competitivo das empresas, sendo essencial tanto para resolução 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 têm crescido sobremaneira nas últimas décadas. Diante da necessidade em atender a crescente demanda do mercado e visando agilizar a entrega do produto sem perda de sua qualidade, tanto a indústria quanto a academia têm movido esforços para a maximização da produtividade no processo de desenvolvimento. Uma das formas de se atingir este objetivo é por meio de abordagens sistemáticas 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, tradução nossa): “Linha de Produtos de Software  é um paradigma para desenvolver aplicações de software (sistemas intensivos de  software e produtos de software) usando plataformas e customização em massa ”.

14

Ou seja, a produção de software  se dá em massa, no entanto, leva em conta as necessidades específicas 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 compõem o processo de Engenharia de Domínio. Já as tarefas de desenvolvimento dos produtos finais compõem o processo de Engenharia de Aplicação. Entre as vantagens da utilização desta abordagem, podemos citar a diminuição do time-to-market  - que é o tempo que um produto demora a chegar ao mercado, aumento da qualidade dos produtos, diminuição dos custos de desenvolvimento, entre outras (POHL et. al., 2005). Os softwares  de uma determinada série de celulares, que compartilhem a maior parte de suas funcionalidades, são exemplos de sistemas que podem ser desenvolvidos numa LPS. A Figura 2 mostra parte da série 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 - Três exemplares exe mplares da série de aparelhos celulares E da Nokia, cujos sistemas compartilham diversas similaridades1

Apesar de todas as vantagens, a adoção da LPS não é algo simples. Para se obter os benefícios previstos por esta abordagem é necessário um processo de gerenciamento consistente, que leve em consideração a importância que a plataforma possui. Além disso, o gerenciamento deve ser eficaz ao lidar com os riscos inerentes à implantação da LPS (os riscos serão tratados na seção 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 Domínio. E para dar apoio à tarefa de gerenciamento, é indispensável o uso de ferramentas específicas, que forneçam suporte às particularidades desta abordagem, levando em conta as diferenças entre o desenvolvimento de um sistema único e de uma família de produtos. Conhecidas como CASE ( Computer-Aided  Software Engineering  - Engenharia de Software com Auxílio de Computador), estas ferramentas “proporcionam apoio ao processo de software pela automação de 

algumas atividades de processo e pelo fornecimento de informações sobre o  software que está sendo desenvolvido ”

(SOMMERVILLE, 2010, p.85, tradução

nossa). Dentre os diversos benefícios trazidos pelo uso deste tipo de ferramenta estão a aceleração no desenvolvimento de produtos, maior facilidade de manutenção do produto e documentação 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 são as features 2  que uma ferramenta CASE deve possuir para contribuir efetivamente com o gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software ? 1.3.

Objetivos

Para responder à pergunta de pesquisa, foram definidos os seguintes objetivos, divididos em geral e específicos: 1.3.1. Objetivo Geral Propor um conjunto de features  que apoie efetivamente o gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software .

2

O termo feature refere-se a uma característica do sistema.

16

1.3.2. Objetivos Específicos 









1.4.

Investigar os subprocessos de gerenciamento em Linha de Produtos de Software . Pesquisar ferramentas acadêmicas e industriais que forneçam suporte ao gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software . Identificar e documentar features  básicas e complementares de cada ferramenta encontrada. Pesquisar relatos de experiências no uso da abordagem de Linha de Produtos de Software. Identificar, através dos relatos encontrados, possíveis necessidades referentes a features que deem suporte ao gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software .

Justificativa

O presente trabalho poderá contribuir com estudos futuros no sentido da identificação das features  que uma ferramenta CASE deve possuir para dar apoio efetivo ao gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software . Além disso, a listagem das features  poderá servir de ponto de partida para o desenvolvimento de uma ferramenta CASE que centralize as funcionalidades necessárias ao gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software . Algumas das vantagens desta centralização estão no aumento da agilidade do processo de desenvolvimento e na execução das tarefas cotidianas de gerenciamento, mais velocidade no relacionamento com o cliente, além da padronização dos artefatos produzidos, facilitando a documentação de todo processo (CRONHOLM, 1995) e garantindo a consistência destes documentos (PRESSMAN, 2001). 1.5.

Escopo Negativo

A abordagem de Linha de Produtos de Software  envolve inúmeras áreas de interesse dentro da Engenharia de Software, tais como Gestão da Qualidade, Testes, Gestão de Configuração, entre outros. Devido à vasta extensão do tema, é

17

preciso ressaltar as questões que não serão abordadas no presente trabalho, a saber: - Frameworks : Este trabalho não aborda em detalhes nenhum framework  específico para a LPS, uma vez que o conjunto de features  a ser investigado deve ser genérico, dando suporte a abordagens variadas. Em (MATINLASSI, 2004), o autor lista, detalha e compara os principais frameworks disponíveis. - Desenvolvimento: Desenvolvimento: O desenvolvimento de uma ferramenta com as features  investigadas não faz parte do escopo deste trabalho. técnicos: Os aspectos técnicos, que auxiliem o desenvolvimento - Aspectos técnicos: das features investigadas, também não serão tratados neste trabalho. (RSL) : Uma RSL estabelece um - Revisão Sistemática de Literatura (RSL): processo formal para conduzir a investigação, evitando a introdução de vieses da revisão de literatura informal, dando maior credibilidade à pesquisa em andamento (SOUSA e RIBEIRO, 2009). Este trabalho não é uma Revisão Sistemática de Literatura; no entato, ele se utiliza de algumas atividades típicas de uma RSL (como a utilização de strings  de busca e escolha dos trabalhos a partir de critérios de inclusão e exclusão) a fim de dar mais coesão ao estudo. A realização da RSL neste trabalho foi descartada devido ao pouco tempo disponível para sua execução. 1.6.

Contribuições Entre as contribuições 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 investigação extensiva de ferramentas para gerenciamento do processo de Engenharia de Domínio em LPS, que traz uma visão geral sobre o que está sendo desenvolvido e utilizado no mercado e na academia. Uma investigação extensiva de relatos de experiência, que expõe as reais necessidades e as dificuldades do mercado e da academia no que diz respeito ao gerenciamento em Linha de Produtos Pr odutos de Software .

18

1.7.

Organização do Trabalho

Neste capítulo, foi realizada uma breve introdução aos temas deste trabalho: Linha de Produtos de Software  e ferramentas CASE. Ainda neste capítulo, o problema de pesquisa foi apresentado, bem como os objetivos gerais e específicos para responder a pergunta de pesquisa. Além disso, apresentamos a justificativa para realização deste trabalho e suas contribuições. O restante do trabalho está organizado da seguinte forma: Capítulo 2: Apresenta a revisão da literatura, que aborda de forma mais abrangente os temas Linha de Produtos de Software  e ferramentas CASE, com o apoio da literatura. Capítulo 3: Relata a metodologia a ser seguida para a realização da pesquisa e da análise de dados. Capítulo 4: Apresenta o estudo sobre ferramentas CASE para gerenciamento do processo de Engenharia de Domínio para Linha de Produtos de Software e seus resultados. Capítulo 5: Expõe as conclusões sobre os estudos e a proposta de trabalhos futuros.

19

2. REFERENCIAL TEÓRICO A seguir, serão apresentados, com apoio da literatura, os principais temas que formam a base teórica deste trabalho, a saber: Linha de Produtos de Software e Ferramentas CASE. 2.1.

LINHA DE PRODUTOS DE SOFTWARE (LPS)

Nesta seção, abordaremos o tema Linha de Produtos de Software , mostrando o histórico do surgimento da abordagem, conceito, processos fundamentais que compõem a LPS e, por fim, suas vantagens e os riscos inerentes à sua adoção. 2.1.1. Histórico Uma linha de produtos, ou família de produtos, é um grupo de sistemas que compartilham características comuns. Um dos primeiros artigos a citar uma abordagem de desenvolvimento voltada para famílias 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 famílias de produtos de software, a partir de um modelo-base. Parnas (1976, p.1, tradução nossa) citava ainda o método tradicional de desenvolvimento de uma família de produtos à época: “Um membro particular da família de produtos é desenvolvido por completo (...) e os 

outros membros da família são desenvolvidos pela modificação deste membro ”. Já o termo “ Linha de Produtos ” é uma referência clara às linhas de montagem

fordistas do século XX, que trouxeram um novo modo de fabricação dos produtos: a produção em massa (BOTELHO, 2008). Essa nova abordagem trouxe mudanças substanciais para as indústrias da época, entre as quais podemos citar a drástica redução do tempo de produção, com consequente aumento no número de produtos desenvolvidos e redução do preço dos mesmos (FUSCO et. al., 2003). Linha de Produtos de Software  é uma abordagem de desenvolvimento para famílias de produtos criada com o mesmo objetivo, o de produzir em massa - de maneira rápida e com baixo custo. A Linha de Produtos, no entanto, possui uma diferença substancial da produção fordista: investigação das necessidades particulares de cada cliente, a que chamamos de customização em massa. A customização em massa é “um processo de produção que combina  elementos da produção em massa com os de  ‘ alfaiataria alfaiataria sob medida ’ ’.  Os produtos 

20

são adaptados para atender as necessidades individuais dos clientes ” (HINDLE,

2008, p.125, tradução nossa). A respeito da necessidade de customização dos softwares Douglas McIlroy (1968, p.138, tradução nossa) pontuou: Nenhum usuário de um produto particular de uma família deve ser penalizado, com uma generalidade indesejada, pelo fato de haver sido empregado um padrão de rotina. Em outras palavras, o comprador de um componente da família irá escolhê-lo adaptado às suas exatas necessidades. :  produtor Neste cenário, o cliente se torna “ prosumidor 3 ” : 

(ao interferir no processo produtivo) e consumidor. A Figura 3, adaptada de (HEINEMANN e SCHWARZL, 2010, p.140), mostra as vantagens obtidas pela combinação da produção em massa e adaptação às necessidades dos clientes, típicos da customização em massa:

Figura 3 - Vantagens da customização em massa

Conforme mostrado na figura acima, algumas dessas vantagens são: diminuição de custos, resultante da produção massificada; aumento da vantagem competitiva, uma vez que os produtos desenvolvidos são adaptados às necessidades dos consumidores; e maior integração com os clientes, que participam de maneira ativa no processo produtivo. 3

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 características que satisfaçam as necessidades específicas de um determinado segmento de mercado ou missão, e que são desenvolvidos a partir de um conjunto comum de ativos principais de maneira pré-determinada4

Em outras palavras, Linha de Produtos de Software  é uma abordagem de desenvolvimento de software  que se aproveita das características em comum de uma família de produtos para construir, a partir de um conjunto de artefatos reusáveis, produtos que atendam às necessidades de um determinado segmento de mercado. Este conjunto de artefatos reusáveis é conhecido como plataforma. Esta deve conter os artefatos comuns a todos os produtos que serão desenvolvidos. Além disso, deve ser flexível o suficiente para suportar as especificidades de cada produto. Segundo Pohl et. al. (2005, p.20, tradução nossa) a plataforma “ consiste de 

todos os tipos de artefatos de software (requisitos, projeto, execução, testes, entre  outros)”.

A definição de LPS apresentada é a mais adequada ao contexto deste trabalho, uma vez que ressalta o uso da plataforma - mostrando sua importância na Linha de Produtos de Software  - e apresenta a necessidade de planejamento e organização do desenvolvimento.

2.1.3. Processos Fundamentais Fundamentais A Linha de Produtos de Software , em geral, é dividida três processos fundamentais: Engenharia de Domínio, Engenharia de Aplicação 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:

4

Citação 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

Família de Produtos

Núcleo de Ativos

Plataforma

Desenvolvimento do Núcleo de Ativos

Engenharia de Domínio

Desenvolvimento do Produto

Engenharia de Aplicação

2.1.3.1. Engenharia de Domínio Também conhecido como Desenvolvimento do Núcleo de Ativos, segundo Pohl et. al. (2005, p. 21, tradução 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 domínio da linha de produtos, verificando quais requisitos são comuns a todas as aplicações da linha e quais requisitos são específicos de determinadas aplicações. Uma diferença substancial do desenvolvimento em LPS para o desenvolvimento de sistemas únicos é a necessidade de planejar rigorosamente o desenvolvimento de artefatos flexíveis, que se adaptem a todos os produtos que farão uso dos mesmos. Devido a esta característica, esta fase pode, ainda, ser chamada de “desenvolvimento para reuso”

(LINDEN et. al., 2007). Por fim, os componentes são desenvolvidos e a plataforma de artefatos reusáveis é montada com os artefatos comuns a todas t odas as aplicações. 2.1.3.2. Engenharia de Aplicação Engenharia de Aplicação ou Desenvolvimento do Produto é “o processo de  engenharia de linha de produtos no qual as aplicações da linha de produtos são  construídas através do reuso de artefatos de domínio e explorando a variabilidade  da linha ” (POHL et. al., 2005, p. 21, tradução nossa).

Este processo engloba todas as atividades realizadas para o desenvolvimento desenvolvimento das aplicações a partir da plataforma criada durante o Desenvolvimento do Núcleo de Ativos. Na realidade, este processo pode ser descrito como a “montagem” de

23

cada aplicação diferente a partir dos artefatos reusáveis. Nesta fase, os esforços estão voltados para atingir uma taxa de reuso tão alta quanto possível. 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 importância para que a organização atinja resultados satisfatórios. A respeito disto, o Software  Engineering Institute  (SEI) argumenta: O conjunto de artefatos e a idealização sobre como eles são usados para criar produtos não se materializam sem planejamento e certamente não vêm gratuitamente. Eles exigem conhecimento antecipado da organização, investimento, planejamento e direção. Eles exigem o pensamento estratégico que vai além de um único produto5.

O gerenciamento é responsável por planejar e coordenar as atividades de desenvolvimento do núcleo de ativos, bem como as dos produtos gerados a partir deste núcleo. Em outras palavras, o gerenciamento direciona a execução da LPS. Em comparação ao desenvolvimento de um sistema único, o gerenciamento em LPS possui tarefas adicionais. Os gerentes da LPS devem preocupar-se com questões pontuais, as quais são exclusivas desta abordagem, como as mudanças e evolução da plataforma, entrada e saída de produtos da linha, entre outras questões. Com relação às atividades, o SEI divide o processo de gerenciamento da Linha de Produtos de Software em duas grandes áreas. São elas: 



5

Gerenciamento Organizacional: 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 Técnico: Técnico: supervisiona o desenvolvimento da plataforma e as atividades de desenvolvimento dos produtos, assegurando que aqueles que os constroem estão engajados nas

Citação retirada de http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm. Acesso: 17/03/2011. 6 A estrutura de uma organização pode ser definida como o resultado de um processo através do qual a autoridade é distribuída, as atividades desde os níveis mais baixos até a alta administração são especificadas e um sistema de comunicação é delineado (VASCONCELOS e HEMSLEY, 2008, p. 3).

24

atividades necessárias, seguindo os processos definidos para a linha de produtos. Além disso, o gerente é responsável por recolher dados para acompanhamento do progresso. De uma maneira geral, o gerenciamento deve dar subsídios para a realização das atividades da LPS. Ressaltamos que o gerenciamento das atividades do processo de Engenharia de Domínio é o foco deste trabalho. A Figura 4 mostra o objetivo geral dos principais processos envolvidos na Linha de Produtos de Software .

Engenharia de Domínio

• Atividades relacionadas ao

Engenharia de Aplicação

• Atividades relacionadas ao

Gerenciamento

desenvolvimento da plataforma

desenvolvimento dos produtos

• Planejamento da LPS e coordenação

das atividades de Engenharia de Domínio e Engenharia de Aplicação

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

2.1.4. Vantagens Diversas são as vantagens alcançadas através da utilização da abordagem de Linha de Produtos, as quais motivam sua adoção. Entre elas (POHL et. al. 2005): 

Redução dos Custos de Desenvolvimento: Desenvolvimento : Uma vez que os artefatos da plataforma são reusados por diversas aplicações 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 é necessária a codificação 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 redução 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 fração desta equipe para o desenvolvimento dos produtos da linha. Redução do time-to-market : :  Estando a plataforma pronta, os esforços para a elaboração do novo produto concentram-se concentram -se apenas na sua montagem, a partir dos artefatos da plataforma, e desenvolvimento das features  específicas do mesmo. Por consequência, o tempo de entrada do produto no mercado m ercado é reduzido. Aumento da qualidade dos produtos: produtos: Se um erro for encontrado em qualquer produto da linha, a solução para o mesmo é propagada a todos os outros produtos. Além disso, os artefatos da plataforma são

26

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

Benefícios para os clientes: clientes : a padronização dos artefatos traz benefícios de usabilidade para os clientes, que terão facilidade em manusear diferentes produtos da linha, já que a interface dos produtos (baseados na mesma plataforma) se assemelha. Já a customização garante produtos adaptados às suas necessidades. Outrossim, a redução de custos de desenvolvimento se reflete no preço final do produto, que será diminuído.

Diversos relatos de experiências mostram que grandes empresas têm-se aproveitado dos benefícios ocasionados pela adoção da Linha de Produtos de Software . Entre as quais podemos citar: Bosch, Nokia, Philips, Siemens (LINDEN et. al., 2007); Motorola (JIANG et. al., 2008); Forças Armadas Norte Americana (BERGEY et. al., 2010), entre outras. Tais exposições mostram que a LPS vem ganhando força com o passar dos anos, tornando-se estratégia de desenvolvimento de empresas renomadas em todo o mundo. 2.1.5. Riscos Adotar a estratégia de Linha de Produtos de Software , é claro, tem seus riscos associados. Este projeto pode ser considerado uma mudança tecnológica e, portanto, 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 (DURSCKI et al., 2004). Clements e Northrop apud  Cohen (2002) relatam, entre outros, os seguintes riscos associados à adoção da LPS: 

Líder não identificado: identificado : sem um líder com autoridade de gestão, a LPS não pode ter êxito. O líder é o indivíduo que comunica o projeto à gerência e aos desenvolvedores, mantém o projeto durante a adoção, conserva os desenvolvedores na direção correta diante das dificuldades e mantém a equipe motivada. Onde não há indivíduos com estas qualidades, a adoção geralmente falha.

27











Abordagem incompatível: incompatível : A Linha de Produtos de Software  deve ser uma estratégia que atenda às metas específicas da empresa. Embora as metas variem de organização para organização, os objetivos da LPS são sempre baseados na exploração do reuso sistemático entre os produtos. Se os produtos em desenvolvimento não têm similaridades suficientes para justificar uma abordagem de Linha de Produtos, qualquer esforço de empreendimento irá falhar devido à falta de resultados tangíveis. Adaptação insuficiente: insuficiente: Assim como a arquitetura ou os componentes requerem um grau de adaptação para uma Linha de Produtos, a organização também deve adaptar suas práticas em relação à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 evolução da abordagem: abordagem : se a LPS não é aperfeiçoada continuamente ao longo do tempo, as práticas provavelmente irão se tornar ineficazes e desvios de planejamento irão surgir. Divulgação ineficaz: ineficaz: O líder da Linha de Produtos deve assumir a responsabilidade de desenvolver e distribuir o tipo e níveis apropriados de documentação, treinamento, e suporte efetivo da LPS, os quais são essenciais para um lançamento bem-sucedido da linha de produtos. O lançamento não ocorrerá conforme previsto ou não produzirá os resultados desejados se houver preparação inadequada. Padronização inadequada: inadequada : As organizações comumente erram em imaginar que a adoção de normas sustentará automaticamente a LPS. Infelizmente, se a institucionalização ocorre muito rapidamente, normas inadequadas ou obsoletas poderão ser instituídas, e a inovação pode ser encerrada prematuramente. Por outro lado, se a normatização é

28

esquecida ou está obsoleta, pode haver esforços redundantes ou divergentes. Além dos já citados anteriormente, consideramos importante tratar também os seguintes riscos: 







Decisões sobre a plataforma: plataforma : Gerenciar a entrada e saída dos componentes da plataforma não é algo simples. Além de um levantamento de requisitos eficaz, é necessário estar atento às mudanças pelas quais a Linha de Produtos passa. Além do mais, se a plataforma crescer exageradamente, sua gestão pode se tornar bastante complexa. Gestão do conhecimento: conhecimento: Todo desenvolvedor deve conhecer com certa profundidade a plataforma de artefatos reusáveis. 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. Obsolescência dos componentes da plataforma: plataforma : é preciso que o gestor da Linha de Produtos esteja atento também ao momento de descartar ou reescrever certos componentes da linha. Manter artefatos obsoletos na plataforma pode resultar em perda da eficácia da mesma. Rastreabilidade dos componentes: componentes : gerenciar a rastreabilidade dos componentes (ou seja, saber qual produto da linha possui qual artefato da plataforma) é de suma importância para o sucesso da LPS. Se não houver gestão sobre isso, o responsável pela linha fica impossibilitado de administrar as diversas aplicações, pois não é possível identificar particularidades de um produto mediante outro.

Tais riscos evidenciam a necessidade de um gerenciamento efetivo da Linha de Produtos. Do contrário, estes riscos podem suplantar as vantagens de sua adoção.

29

2.2.

FERRAMENTAS CASE

Apresentamos, a seguir, um breve histórico, conceito, classificação e vantagens da utilização de ferramentas CASE nas tarefas de Engenharia de Software e, especificamente, em Linha de Produtos de Software . 2.2.1. Histórico Ferramentas de apoio ao desenvolvimento de software  são usadas desde a origem da programação, à época dos mainframes . No entanto, até a década 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, tradução nossa), “ a indústria de software não é industrializada ”. ”.

Nas décadas seguintes, novas ferramentas mais elaboradas surgiram: Ferramentas para controle de versões, ferramentas para testes de software , gerência de projetos e inúmeras 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 são utilizadas para automatização de atividades de rotina. rotina . O termo CASE faz referência a todas as ferramentas que auxiliam as tarefas de Engenharia de Software . Segundo Sommerville (2010, p.12, tradução nossa), o acrônimo CASE “abrange uma ampla gama de diferentes tipos de programas que 

são usados para apoiar as atividades de processo de software, como a análise de  requisitos, modelagem de sistemas, depuração e testes ”. ”.

No que se refere à abrangência, as ferramentas CASE podem ser usadas em diferentes atividades. Segundo Pressman (2001, p.825, tradução nossa), “ as 

ferramentas CASE automatizam CASE  automatizam atividades de gerenciamento de projeto, gerenciam  todos os trabalhos produzidos ao longo do processo, e ajudam os engenheiros em  sua análise, projeto, codificação e trabalho de teste  t este ”. ”.

30

As ferramentas CASE podem ser voltadas para uma tarefa específica de ES, ou oferecer suporte a diversas tarefas - sendo então conhecidas como ferramentas CASE Integradas. A integração de ferramentas maximiza as vantagens da Engenharia de Software  Auxiliada por Computador, permitindo que toda informação de Engenharia de Software  esteja disponível para qualquer ferramenta que necessitá-la. As motivações para utilização das ferramentas CASE (integradas ou não) serão apresentadas na seção seguinte deste trabalho. 2.2.3. Motivação A Engenharia de Software  preocupa-se não somente com os aspectos técnicos de desenvolvimento, mas também com atividades como o gerenciamento de projetos de software e o desenvolvimento de ferramentas, métodos e teorias que deem apoio à produção de software (SOMMERVILLE, 2010). E o uso destas ferramentas pode trazer benefícios para cada uma destas diversas atividades da ES. Em um estudo de caso conduzido na Suécia, Cronholm (1995) identificou duas razões principais para a utilização de ferramentas CASE: diminuição do tempo de desenvolvimento e melhoria da qualidade dos produtos. Com relação à necessidade de desenvolver softwares  mais rapidamente, as ferramentas mostraram-se úteis nos seguintes aspectos: 



Maior agilidade na execução de tarefas cotidianas  – algumas tarefas, tais como a criação e modificação de gráficos, são realizadas de maneira mais ágil. Além disso, as ferramentas CASE facilitam a documentação destas tarefas. Auxílio na padronização de métodos  – com ferramentas desenvolvidas com base nos padrões da empresa, é possível 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 usuários finais  – As reuniões com os clientes, nas quais se define o domínio do problema e o escopo do projeto são realizadas com o apoio de documentos e diagramas. Com as ferramentas CASE, estas reuniões podem ser mais rapidamente documentadas e a corretude dos diagramas mais rapidamente verificada junto ao cliente.

Com relação à melhoria dos produtos, puderam-se perceber as seguintes motivações: 



Capacidade de flexibilização dos processos  – As organizações desejam ser capazes de escolher o método de desenvolvimento apropriado - na ferramenta CASE - de acordo com uma situação específica (o domínio do problema, por exemplo). Capacidade de redigir documentações mais consistentes  – É possível, por exemplo, obter um relatório automaticamente se todos os objetos existentes em um gráfico estiverem descritos no repositório. Essa funcionalidade permite uma documentação mais livre de erros e minimiza a ambiguidade.

Além das motivações enumeradas anteriormente, Pressman (2001) cita a facilidade de transferência de informação (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 através de um melhor planejamento, monitoramento e comunicação.

2.2.4. Classificação das Ferramentas Ferramentas CASE A classificação das ferramentas CASE permite uma melhor compreensão de onde cada ferramenta pode ser aplicada nas tarefas de ES. Esta categorização, no entanto, não é 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 classificação (função, processo apoiado pela ferramenta, entre outros). Mas, apesar dos esforços, não há um padrão universalmente aceito. Uma das classificações mais citadas é a proposta por Afonso Furgetta, que relaciona as ferramentas CASE de acordo com o processo de produção. Furgetta (1993) separa as ferramentas CASE nas seguintes categorias: Ferramentas, workbenches e ambientes.

Ferramentas  – as ferramentas dão suporte apenas a tarefas específicas no processo de software  e podem ser classificadas conforme mostrado na Tabela 2, apresentada a seguir : 

Tabela 2 - Classificação das ferramentas segundo Furgetta (1993)

Classe

Descrição

Exemplos

Edição

Divididas em textuais e gráficas

Processadores de texto, ferramentas de desenho.

Programação

Usadas nas tarefas de codificação

Compiladores, depuradores.

Validação e verificação

Apoiam a validação dos requisitos do cliente e verificação do projeto.

Verificadores de sintaxe, geradores de casos de teste.

Gerência de configuração

Controlam a construção de um sistema composto de muitas partes.

Controle de versões, controle de mudanças

Métricas e medição

Coletam dados sobre os programas e sobre sua execução

Analisadores de código, monitores de execução

Gerência de projetos

Inclui suporte ao planejamento e coordenação dos projetos

Ferramentas de planejamento e estimação de custos.

33

Workbenches  –  – Os workbenches  dão suporte apenas a uma ou poucas atividades. São usualmente construídos como um conjunto de ferramentas e podem ser classificados conforme a Tabela 3, apresentada abaixo:

Tabela 3 - Classificação dos workbenches segundo workbenches segundo Furgetta (1993)

Classe

Descrição

Exemplos

Planejamento e modelagem empresarial

Auxiliam a criação de modelos de alto nível para avaliar fluxo de informações

Incluem geradores de relatório, geradores de gráficos

Análise e modelagem

Utilizados nas fases iniciais do processo de software

Inclui geradores de modelo de fluxo de dados e E-R

Desenvolvimento de interface

Auxiliam na criação, teste e integração de componentes de interface

Inclui ferramentas para criação de  janelas, testadores de interface

Programação

Fornecem interface integrada para gerenciar os itens de desenvolvimento

Inclui editor de texto, compilador e depurador

Validação e verificação

Integra ferramentas para as métricas, medições e verificação e validação

Inclui analisador de código e geradores de caso de teste

Manutenção e engenharia reversa

Geralmente composto pelas mesmas ferramentas usadas no desenvolvimento

Inclui reestruturadores de código, geradores de referência cruzada

Gerência de configuração

Provê ambiente integrado para controle de mudanças

Inclui controle de versões, de mudanças

Gerência de projetos

Integra ferramentas de apoio às atividades de gerenciamento

Inclui ferramentas para planejar e dirigir projetos

34

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

Classe

Descrição

Exemplos

Toolkits 

Agregam diferentes ferramentas e workbenches. É extensível, mas requer que o usuário integre-o explicitamente

Em geral, são estendidos de um conjunto básico do sistema operacional

Ambientes de linguagens centrados

Ambiente escrito na linguagem para a qual foi desenvolvido. Permite que os usuários personalizem e estendam-no

Geralmente concentrados no ciclo editar-compilar-depurar

Ambientes integrados

Todos os produtos deste ambiente são operados através de interface única e os dados são integrados em um repositório

Ambientes integrados de desenvolvimento

Quarta geração

Apoia o desenvolvimento de uma classe específica de programas: processamento eletrônico de dados e aplicativos de negócios

Inclui editores, compiladores e um repositório centralizado

Centrados no processo

Interpreta um processo pré-definido e apoia as atividades de desenvolvimento. Automatiza fragmentos processo.

Inclui ferramentas para modelar processos e interpretadores que executam tal modelo

2.2.5. Ferramentas CASE CASE em Linha de Produtos de Software  Como exposto nas seções anteriores deste trabalho, o emprego da abordagem de Linha de Produtos de Software  não é algo simples, uma vez que envolve mudanças significativas nos processos das empresas e possui diversos riscos associados. Diversas atividades típicas da abordagem LPS podem ser auxiliadas por ferramentas CASE. A seguir, mostraremos a importância deste apoio automatizado, apontando algumas atividades que poderiam obter benefícios por meio deste tipo de apoio, tomando por base os relatos dispostos em Bass et. al. (2000):

35













Definição 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 indispensável o uso de ferramentas CASE. Lidar com variabilidades da linha - Em um ambiente de linha de produtos, os artefatos têm de suportar a variabilidade intrínseca entre os vários produtos da linha. Para descrever um conjunto completo de alternativas ou um conjunto de critérios para determinar a adequação de um substituto, também se faz f az necessário o uso de ferramentas. Gerência de configuração multidimensional  – A abordagem de linha de produtos produz bens que são reutilizados em produtos diferentes, e cada produto tem várias versões. O processo de gerenciamento de configuração deve ser capaz de reconstruir uma determinada construção de qualquer produto, reunindo uma variedade de ativos, incluindo projetos de arquitetura, modelos de análise e exigências. Reuso dos artefatos - Técnicas de desenvolvimento permitem que uma parte de um artefato possa ser reutilizada, em oposição a uma abordagem "tudo ou nada ”. Para lidar com esta necessidade, é necessário catalogar os artefatos e, como já citado anteriormente, desenvolver para reuso. Catalogação dos artefatos reusáveis  – manter um cadastro com todas as características dos artefatos visando gerenciar a rastreabilidade dos artefatos. Geração de código  – as ferramentas podem dar suporte à geração de produtos (fase de Engenharia de Aplicação) a partir dos artefatos da plataforma.

36

Além destas, centenas de outras tarefas podem ser auxiliadas por ferramentas. Incluímos nesta gama o gerenciamento da Engenharia de Domínio em Linha de Produtos de Software , que é foco deste trabalho.

37

3. METODOLOGIA Neste capítulo será exposta a metodologia seguida para a realização deste trabalho. Segundo Kahlmeyer-Mertens Kahlmeyer-Mertens et. al. (2007, p.24), a metodologia científica “se propõe a definir regras e procedimentos que darão segurança e validade ao 

exercício de conhecer, tendo a pesquisa presente nesse processo ”. Para isso,

apresentamos, a seguir, a natureza da pesquisa e a metodologia para a análise 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 classificação desde trabalho. 3.1.1. Quanto aos Fins Quanto aos fins, a presente pesquisa pode ser classificada como exploratória e descritiva. A pesquisa exploratória visa conhecer inicialmente o tema de estudo. Segundo Pinheiro (2010, p.21), a pesquisa exploratória “ visa proporcionar maior 

familiaridade com o problema com vistas a torná-lo explícito ou a construir 

Neste trabalho, será realizada através da revisão da literatura e da análise de documentos que relatem experiências com o uso da abordagem de Linha de Produtos de Software . hipóteses ”. ”.

A pesquisa descritiva, por sua vez, visa “ descrever as características de 

determinada população ou fenômeno ou o estabelecimento de relações entre  variáveis ” (PINHEIRO, 2010, p.22). Neste trabalho, apresenta -se

através da análise

e descrição das ferramentas f erramentas encontradas.

3.1.2. Quanto aos Meios Quanto aos meios, o trabalho apresenta-se em forma de pesquisa bibliográfica. Segundo Carvalho (1989, p.100), pesquisa bibliográfica “ é a atividade 

de localização e consulta de fontes diversas de informação escrita, para coletar  dados gerais ou específicos a respeito de determinado tema ”.

38

3.1.3. Quanto à Forma de Abordagem 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 exploratória e não-estruturada que se baseia em pequenas  amostras com o objetivo de prover pr over percepções e compreensão do problema ”. ”.

3.2.

Análise dos Dados A análise dos dados será realizada cumprindo os seguintes passos: 1. Pesquisar ferramentas ferramentas CASE e relatos relatos de experiências experiências com o uso da abordagem de LPS  – As ferramentas e os relatos serão pesquisados em sites de buscas tradicionais (tais como Google 7 e Yahoo8), além das bibliotecas científicas 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 contém as strings de busca utilizadas nesta pesquisa. 2. Catalogar ferramentas e relatos de experiência experiência encontrados  – toda ferramenta para gerenciamento de Linha de Produtos de Software  será catalogada com as seguintes informações: Nome, Autores, Site , Código (disponível ou não), Tipo e Ano. Para os relatos de experiência, serão catalogados com Título, Autor e Ano apenas aqueles a partir dos quais houve inferência de features. 3. Analisar documentação das ferramentas CASE e relatos de experiência – Com relação às ferramentas, todas as features encontradas serão catalogadas; no que se refere aos relatos de experiência, a partir da análise dos mesmos, serão relacionadas features  que possam suprir

7

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/  8

39

necessidades e/ou dificuldades relatadas durante a execução 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, extraídas de outras fontes, poderão ser incluídas. 5. Proposta de features  – As features  serão classificadas de acordo com a etapa do gerenciamento ao qual apoia (Gerenciamento Organizacional ou Gerenciamento Técnico). Por fim, o conjunto de features  que apoie efetivamente o gerenciamento do processo de Engenharia de Domínio em LPS será apresentado (em tabelas) como resultado r esultado 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 experiências com o uso da abordagem de LPS

Catalogar ferramentas e relatos de experiência encontrados

Analisar documentação das ferramentas CASE e relatos de experiência

Montar tabela com features 

Proposta de features 

Figura 6 - Fluxo de atividades executado para realização da pesquisa. Autor (2011)

40

4. UM ESTUDO SOBRE FERRAMENTAS FERRAMENTAS CASE PARA GERENCIAMENTO GERENCIAMENTO DO PROCESSO DE ENGENHARIA DE DOMÍNIO EM LINHA DE PRODUTOS DE SOFTWARE  Neste capítulo, descreveremos as ações executadas para o cumprimento da pesquisa, realizada com vistas a alcançar um conjunto de features  que apoie o gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software  –  – ao qual iremos nos referir pela sigla GED. Serão descritos o passo-a-passo da busca nas bases científicas, o resultado desta busca e a proposta de solução. Por fim, uma discussão sobre o trabalho é apresentada.

4.1.

Realização das Pesquisas nas Bases Científicas

Conforme explanado na metodologia (capítulo 3), este trabalho tem início com a pesquisa das ferramentas e dos relatos de experiências em bases de dados científicas. 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 três passos: (1) exclusão realizada a partir da leitura dos títulos; (2) exclusão dos trabalhos repetidos; (3) exclusão a partir da leitura dos resumos. Desta forma, o número de artigos restantes foi 48 (quarenta e oito). Para este refinamento, foram usados os seguintes critérios: 



Critérios de Inclusão:  Trabalhos que relatem experiências na execução da LPS;  Trabalhos que relatem experiência no uso de ferramentas durante a execução da LPS. Critérios de Exclusão:  Trabalhos que tratem de processos fora da Engenharia de Domínio.  Trabalhos com conteúdo exclusivamente teórico, os quais não são resultado de aplicação da LPS em ambiente acadêmico ou profissional.

41

Ressaltamos que este refinamento foi realizado com cautela, pois, apesar de focar no GED, faz-se necessário conhecer a maneira como outras atividades da Engenharia de Domínio são executadas, a fim de compreender como as mesmas podem ser gerenciadas com o auxílio de uma ferramenta CASE. Sendo assim, artigos com foco em outras atividades da Engenharia de Domínio, mas que pudessem contribuir para esta compreensão, também foram incluídos. A Figura 7 mostra a quantidade de trabalhos selecionados para leitura completa em cada base científica.

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

Através dos resultados retornados, pudemos observar que o gerenciamento, como um todo, ainda é um tema pouco tratado dentro do domínio de Linha de Produtos. Menos citado ainda é o gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software. Trataremos destes detalhes nas seções a seguir, nas quais listamos as ferramentas e artigos considerados relevantes para a execução deste trabalho.

4.2.

Análise 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 geração automática de produtos a partir da plataforma de artefatos reusáveis, como é o caso do FeaturePlugin 14 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 descrição de cada uma delas, a partir das informações contidas em seus respectivos sites (ver Tabela 5): 



CADSEg - A CADSEg é um editor e gerador de CADSEs (Engenharia de Ambientes de Domínio Específicos Auxiliados por Computador). O objetivo principal da CADSE é auxiliar os desenvolvedores na implementação das aplicações. A CADSE se apresenta ao desenvolvedor como um workspace  inteligente de alto nível para o Eclipse 16, que "conhece" os conceitos do domínio, e sabe a melhor forma de mapeá-los para artefatos de programação. PloneMeeting  – Ferramenta em desenvolvimento para o Parlamento da Comunidade Francesa, mas disponível para download  por qualquer interessado. Permite que gerenciar sessões de discussão através de atas, agendas, opiniões 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

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

43

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

Nome

Desenvolvedor (es)

CADSEg

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

Plone Meeting

Site http://cadse.imag.fr/

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

Código

Tipo

Não disponível

Workbench

Disponível

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

O conjunto de features  que pode apoiar o gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software foi resultante da análise da documentação de cada ferramenta. O número 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  extraído de cada ferramenta CASE analisada.

Tabela 6  – CADSEg e suas features. Autor (2011)

CADSEg Problema que soluciona

Feature  Permitir visualizar a rastreabilidade dos artefatos (saber onde cada artefato foi utilizado e a relação entre eles)

Permite saber quais artefatos ou produtos uma mudança poderá afetar, auxiliando a decisão sobre mudanças na plataforma

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

PloneMeeting Feature  Agendar reuniões, enviando lembrete aos participantes

Problema que soluciona Minimiza problemas de comunicação, uma vez que a reunião agendada é comunicada e advertida a todos os envolvidos automaticamente

44

Tabela 7  – PloneMeeting e suas features (conclusão). features (conclusão). Autor (2011)

Problema que soluciona

Feature  Criação, por parte dos membros da equipe, de pontos a serem discutidos na próxima reunião. O gerente pode validar se a discussão de tal ponto entrará na reunião.

Auxilia na organização dos temas a serem discutidos nas reuniões

Criação da “agenda de reunião”, com os pontos

Auxilia na organização dos temas a serem discutidos nas reuniões

Inclusão, durante ou após a reunião, das soluções descritas para os pontos discutidos. Sendo permitido acesso posterior a todos os envolvidos Geração em vários formatos, de um documento descrevendo os pontos da reunião

Facilita validação posterior da ata de reuniões

validados pelo gerente

Facilita a geração das atas de reunião

Na seção seguinte, serão listadas as features  encontradas nos relatos de experiência bem como maiores detalhes destes trabalhos. 4.3.

Análise dos Relatos de Experiência

Os relatos de experiência são instrumentos utilizados em diferentes áreas de conhecimento, tais como medicina, administração, psicologia e diversas outras. Seu objetivo é de reportar experiências vivenciadas pelos autores, permitindo a troca de informações sobre esta experiência e evidenciando sucessos e fracassos dos experimentos. No caso deste trabalho, os relatos evidenciam experiências na utilização da abordagem de Linha de Produtos de Software . Apenas 3 (três) trabalhos retornados tratavam explicitamente explicitamente do processo 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 revisão de literatura sobre o tema, não um relato de experiência. Os trabalhos restantes relatavam experiências gerais na execução da LPS, nos quais estava incluído o gerenciamento. Com relação aos relatos de experiência, 13 (treze) trabalhos trouxeram contribuições significativas. A Figura 8 mostra estes trabalhos, seus autores e o ano de publicação.

45

Figura 8 - Trabalhos com contribuições significativas, organizados por ano de publicação. Autor (2011)

46

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

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

Trabalhos

Feature sugerida Feature  sugerida

Problema que soluciona

9, 11

Calcular custos de inserção de novos artefatos na plataforma

Verificar viabilidade financeira do investimento, a fim de que a plataforma não cresça indiscriminadamente e sem gerar o devido retorno sobre o investimento

12

Armazenar descrição das dificuldades encontradas durante o projeto e respectivas soluções Gerenciamento de aquisições de produtos e serviços Visualização de artefatos inacabados e percentual realizado Classificar artefatos de desenvolvimento (core assets ) em essenciais ou opcionais.

Manter um banco de dados de lições aprendidas a fim de facilitar o gerenciamento de novos projetos

1 7, 10, 8 10

13

8

6, 3 6

Capturar data/hora do início e fim do desenvolvimento, desenvolvedor responsável pelo artefato, quantidade de linhas de código Cronograma: Armazenar dados de atividades realizadas e a realizar, predição de quando as atividades serão finalizadas (cálculo de acordo com a complexidade cadastrada para a atividade) Minerar e extrair artefatos potencialmente reusáveis Gerar relatório de percentual de reuso da plataforma

Dá suporte ao gerenciamento financeiro da LPS Gerenciar equipe de desenvolvimento, a fim de aferir possíveis atrasos no desenvolvimento Tomar decisões de gerenciamento da equipe. Por exemplo: os desenvolvedores serão alocados para reparar um erro ou para o desenvolvimento de uma nova feature . A reparação de erro deverá ser escolhida se o artefato for classificado como essencial Geração de métricas de tempo de desenvolvimento por desenvolvedor e quantidade de linhas de código 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 eficiência da mesma e possíveis necessidades de mudança.

47

Tabela 8  – Features propostas Features propostas para as lacunas encontradas nos relatos de experiência (conclusão). Autor (2011)

Trabalhos

Feature sugerida Feature  sugerida

Problema que soluciona

2, 4, 5, 3

Permitir visualizar a rastreabilidade dos artefatos (saber onde cada artefato foi utilizado e a relação entre eles)

Permite saber quais artefatos ou produtos uma mudança poderá afetar, auxiliando a decisão sobre mudanças na plataforma

9

Classificar os artefatos de acordo com o artigo [9], a fim de seguir o modelo nele proposto para evolução da plataforma

Facilita decisões sobre evolução da plataforma. Mais uma forma de evitar que a mesma cresça indefinidamente, mantendo-a enxuta e gerenciável

O trabalho 9, “ Default Values for Improved Product Line Management ”

apresenta um framework  para gerenciar a evolução da plataforma. Descrevendo de uma maneira sintetizada, este framework  classifica os artefatos da plataforma em Proposto, Planejado, Selecionado, Excluível, Obrigatório, Obsoleto ou Removido, definindo processos-padrão para que os artefatos passem de um tipo a outro. Por exemplo, para que um artefato se torne obrigatório para a plataforma, sua classificação poderá seguir o seguinte curso: Proposto  – Planejado – Selecionável – Excluível  – Obrigatório. A utilização deste processo, empregado pela empresa Nokia, estabelece uma metodologia para evolução da plataforma, tanto impedindo que ela cresça 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

Além das features  encontradas nas ferramentas CASE e a partir da leitura dos relatos de experiência, features  adicionais, resultantes de outras fontes, foram inferidas. A Tabela 9, a seguir, mostra este levantamento:

48

Tabela 9 - Features adicionais. Features adicionais. Autor (2011)

Origem

Feature sugerida Feature  sugerida

Software  Engineering  Institute  Software  Engineering  Institute 

Software  Engineering  Institute  Software  Engineering  Institute 

Proposta pelo Autor Proposta pelo Autor Proposta pelo Autor

Proposta pelo Autor

Calcular custos de inserção 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 precisão das estimativas de custo iniciais Permitir acompanhar o andamento do projeto, aferindo se as tarefas planejadas estão sendo executadas dentro dos prazos Identificar gargalos do projeto (o desenvolvimento de quais artefatos está atrasando o projeto) Estimar prazo para finalização do projeto Estimar tempo restante para a implementação dos artefatos de desenvolvimento individualmente. Calculado a partir do nível de complexidade (que deve ser cadastrado) Contar quantas vezes cada artefato foi usado em um produto por período (mensal)

Problema que soluciona Verificar viabilidade financeira do investimento, auxiliando na tomada de decisão sobre os cursos do projeto Permite verificar se os gastos planejados estão de acordo com o esperado e constatar custos extras, que não foram planejados inicialmente Permite avaliar se o desenvolvimento Linha de Produtos está se concretizando da maneira como foi planejada Verificar se as metas planejadas estão sendo cumpridas

Facilita o gerenciamento do tempo, possibilitando que o gerente use estas informações para também gerenciar a equipe Facilita o gerenciamento de tempo do projeto Facilita o gerenciamento de tempo do projeto de uma maneira mais refinada

A fim de saber se um artefato está caindo em desuso (pois pode ser necessário retirá-lo da plataforma). Facilita a tomada de decisão sobre evolução da plataforma

Proposta pelo Autor

Distribuir tarefas para os desenvolvedores, informando-os prazos e atividades, conforme discutidos em reuniões

Agiliza a comunicação, uma vez que as informações serão enviadas automaticamente. Além disso, a informação estará centralizada sempre que o desenvolvedor necessitar

Proposta pelo Autor

Minerar projetos anteriores a fim de verificar a possibilidade de reutilização de artefatos de documentação

Agiliza a documentação do projeto atual

4.5.

Proposta

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

49

gerenciamento do processo de Engenharia de Domínio 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 Técnico (conforme explanado na seção 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 Features propostas que apoiam o Gerenciamento Organizacional. Autor (2011)

Feature 

Processo que apoia

Calcular custos de inserção de novos artefatos na plataforma

Gerenciamento Organizacional

Armazenar descrição das dificuldades encontradas durante o projeto e respectivas soluções

Gerenciamento Organizacional

Gerenciamento de aquisições de produtos e serviços

Gerenciamento Organizacional

Calcular custos de inserção de um novo produto na linha, bem como o retorno financeiro que este novo produto pode trazer

Gerenciamento Organizacional

Documentar custos esperados para todo o projeto de LPS e refiná-lo de acordo com a realidade do andamento do projeto

Gerenciamento Organizacional

Avaliar a precisão das estimativas de custo iniciais

Gerenciamento Organizacional

Permitir acompanhar o andamento do projeto, aferindo se as tarefas planejadas estão sendo executadas dentro dos prazos

Gerenciamento Organizacional

Tabela 11 - Features propostas Features propostas que apoiam o Gerenciamento Técnico (continua). Autor (2011)

Feature 

Processo que apoia

Agendar reuniões, enviando lembrete aos participantes

Gerenciamento Técnico

Criação, por parte dos membros da equipe, de pontos a serem discutidos na próxima reunião. O gerente pode validar se a discussão se tal ponto entrará na reunião.

Gerenciamento Técnico

Criação da “agenda de reunião”, com os pontos validados pelo gerente

Gerenciamento Técnico

Inclusão, durante ou após a reunião, das soluções descritas para os pontos discutidos. Sendo permitido acesso posterior a todos os envolvidos

Gerenciamento Técnico

50

Tabela 11  – Features propostas Features propostas que apoiam o Gerenciamento Técnico (conclusão). Autor (2011)

Feature 

Processo que apoia

Geração em vários formatos, de um documento descrevendo os pontos da reunião

Gerenciamento Técnico

Visualização de artefatos inacabados e percentual realizado

Gerenciamento Técnico

Classificar artefatos de desenvolvimento (core assets) em essenciais ou opcionais.

Gerenciamento Técnico

Capturar data/hora do início e fim do desenvolvimento, desenvolvedor responsável pelo artefato, quantidade de linhas de código

Gerenciamento Técnico

Cronograma: Armazenar dados de atividades realizadas e a realizar, predição de quando as atividades serão finalizadas (cálculo de acordo com a complexidade cadastrada para a atividade) Minerar e extrair artefatos potencialmente reusáveis

Gerenciamento Técnico

Gerar relatório de percentual de reuso da plataforma

Gerenciamento Técnico

Permitir visualizar a rastreabilidade dos artefatos (saber onde cada artefato foi utilizado e a relação entre eles)

Gerenciamento Técnico

Classificar os artefatos de acordo com o artigo [9], a fim de seguir o modelo nele proposto para evolução da plataforma

Gerenciamento Técnico

Identificar gargalos do projeto (o desenvolvimento de quais artefatos está atrasando o projeto)

Gerenciamento Técnico

Estimar prazo para finalização do projeto

Gerenciamento Técnico

Estimar tempo restante para a implementação dos artefatos de desenvolvimento individualmente. Calculado a partir do nível de complexidade (que deve ser cadastrado) Contar quantas vezes cada artefato foi usado em um produto por período (mensal)

Gerenciamento Técnico

Distribuir tarefas para os desenvolvedores, informando-os prazos e atividades, conforme discutidos em reuniões

Gerenciamento Técnico

Minerar projetos anteriores a fim de verificar a possibilidade de reutilização de artefatos de documentação

Gerenciamento Técnico

Gerenciamento Técnico

Gerenciamento Técnico

4.5.1. Conjunto Proposto Proposto e Riscos Riscos da LPS LPS Com relação 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 revisão r evisão sistemática 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 mitigação dos seguintes riscos: 













Documentação inadequada - uma vez há features  que apoiam a documentação do projeto; Falta de informação sobre a Linha de Produtos  – por auxiliar na geração de informações sobre o andamento da LPS; Poluição da plataforma e imutabilidade da plataforma (a plataforma não muda para atender novas necessidades)  – uma vez que auxilia na evolução da plataforma e na inserção 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. Comunicação inadequada  – já que possui features  de apoio à comunicação entre a gerência e a equipe; Custos de desenvolvimento limitados  – auxilia no planejamento de gastos; Atraso no time-to-market   – possui features  que dão auxílio ao acompanhamento do projeto, permitindo verificar possíveis atrasos com antecedência.

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

4.6.

Discussão

A seguir, é dada uma pequena discussão acerca da execução deste trabalho. 4.6.1. Dificuldades Uma das grandes dificuldades para a execução deste trabalho foi a falta de material publicado sobre o tema Gerenciamento do Processo de Engenharia de Domínio em Linha de Produtos de Software. Apesar da sua importância em qualquer

52

projeto de software , utilizando LPS ou não, este aspecto tem sido pouco mencionado na literatura. Além disso, não foi encontrada nenhuma ferramenta específica para gerenciar a LPS, o que não permitiu a utilização de n enhuma “base” para o conjunto de features , que precisou ler levantado partindo do zero. Outro problema identificado é a falta de padrão 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 prática, o gerenciamento deve estar envolvido com todos os aspectos da LPS, dando suporte à execução da mesma. O próprio modelo do SEI, que divide o gerenciamento em Organizacional e Técnico, inclui atividades dentro destas duas grandes áreas que não estão sob responsabilidade do gerente da LPS, como é o caso da Gestão de Configuração, Análise de Mercado, Marketing , e outras, as quais devem possuir uma equipe específica para sua realização. Como não é este o foco do presente trabalho, estas atividades foram ignoradas, sendo dada ênfase às tarefas de gerenciamento da Engenharia de Domínio. 4.6.2. Limitações da Pesquisa Uma das limitações do presente trabalho é a utilização de strings  de busca diferentes em cada base científica. Esta escolha, no entanto, se deu após a realização de testes nas bases científicas escolhidas para a pesquisa. Quando a quantidade de resultados retornados por uma string  de busca dificultava a execução deste trabalho (tendo em vista que a pesquisa deveria ser realizada em cinco bases científicas 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 utilização 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 títulos dos trabalhos permitiu que a mesma string  retornasse 20 (vinte) resultados.

53

5. CONSIDERAÇÕES 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 Domínio em Linha de Produtos de Software (GED). Percebe-se que a LPS tem sido uma solução bastante adotada nas empresas, havendo inúmeros relatos de experiência sobre o uso desta abordagem. Através da análise de ferramentas e leitura de relatos de experiência, percebe-se que há grande deficiência 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 publicações científicas. Após a realização dos estudos, concluímos, portanto, que os objetivos da pesquisa foram alcançados e a pergunta de pesquisa (Quais são as features  que uma CASE deve possuir para contribuir efetivamente com o gerenciamento do processo de Engenharia de Domínio em Linha de Produtos de Software ?) ?) foi respondida após a análise das ferramentas e dos relatos de experiência, que resultou na proposta de um conjunto de features. Apresentamos, a seguir, os trabalhos relacionados a este, as propostas de trabalhos futuros e lições aprendidas durante a execução deste estudo. 5.1.

Trabalhos Relacionados

Durante as pesquisas para realização deste estudo, diversos trabalhos que relacionam Linha de Produtos de Software  e ferramentas CASE foram encontrados. O capitulo 4 apresentou alguns deles. Além destes, podemos citar como trabalho t rabalho relacionado a dissertação de Liana Lisboa, ToolDAy  – A Tool for Domain Analysis , a qual serviu de inspiração para a realização do presente estudo. Lisboa realizou um estudo extensivo sobre ferramentas CASE para Análise de Domínio em LPS a fim de levantar requisitos e desenvolver uma ferramenta que dê suporte a este processo. As duas principais diferenças deste trabalho para os listados acima são o foco e os relatos de experiência. O presente trabalho tem foco no GED, que não foi tratado especificamente em nenhum trabalho encontrado. Além disto, neste trabalho, foram utilizados relatos de experiência e ferramentas CASE a fim de inferir o

54

conjunto de features. Em oposição, o trabalho de Lisboa utilizou como base apenas ferramentas já existentes. 5.2. Trabalhos Trabalhos Futuros Como trabalhos futuros, decorrentes desta pesquisa, sugerimos o desenvolvimento de uma ferramenta, a qual possua o conjunto de features proposto. Adicionalmente, a realização de um estudo de caso em projetos de Linha de Produtos fazendo uso desta ferramenta poderia aferir a eficácia da mesma, além de permitir a implementação de melhorias e refinamentos, percebidos após uso diário 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.

Lições Aprendidas Aprendidas

Durante a execução deste estudo, diversas lições foram aprendidas. Compartilharemos algumas delas a seguir. Após inferir algumas features  que não faziam parte do GED, as quais foram excluídas após exame dos orientadores, foi necessária uma pesquisa extensiva dos processos de gerenciamento em LPS. A intenção desta era estabelecer um padrão a ser utilizado por este trabalho, uma vez que, conforme explicado anteriormente, a literatura não provê este padrão. Sendo assim, mesmo não havendo um padrão para o processo o qual se deseja pesquisar, faz-se necessário estabelecê-lo. Além disso, devido à falta de trabalhos focados no Gerenciamento do Processo de Engenharia de Domínio, foi preciso usar de perspicácia para inferir features  em trabalhos sequer citavam o gerenciamento. Era preciso ler os artigos atentamente, buscando a descrição de qualquer lacuna que pudesse ser apoiada por uma ferramenta. Por fim, todo o processo de pesquisa serviu de aprendizado para a execução dos trabalhos posteriores a este.

55

6. REFERÊNCIAS 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. Disponível em: http://www.sei.cmu.edu/reports/00tr002.pdf. http://www.sei.cmu.edu/reports/00tr002 .pdf. Acesso: 08/05/2011. BERGEY, John K.; CHASTEK, Gary; COHEN, Sholom; DONOHOE, Patrick; JONES, Lines : Report of the 2010 U.S. Lawrence G.; NORTHROP, Linda. Software Product Lines: Army Software Product Line Workshop. Carnegie Mellon University: June, 2010. Disponível em: . TRDoc.pdf&AD=ADA528683>. Acesso: 08/03/2011. BOTELHO, Adriano. Do Fordismo à Produção Flexível: O espaço da indústria num contexto de mudanças das estratégias de acumulação do capital. São Paulo: Annablume Editora, 2008. CARVALHO, Maria. Cecília Maringoni de (org.). Construindo o saber Metodologia Científica: Científica: Fundamentos e técnicas. 2ª edição. Campinas: Papirus, 1989. COHEN, Sholom. Product Line State of the Practice Report. Report . Technical Note CMU/SEI-2002-TN-017. Pittsburgh: September, 2002. Disponível em < http://www.sei.cmu.edu/library/abstracts/reports/02tn017.cfm>. 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, Software : riscos e vantagens de sua implantação. Sheila S.. Linhas de Produto de Software: In: VI Simpósio Internacional de Melhoria de Processos de Software São Paulo, 2004.

56

FUGGETTA, Alfonso. A Classification of CASE Technology. 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. companies. Tese (doutorado)  – Universidade Federal de Pernambuco. Recife, 2010. FUSCO, José Paulo Alves; SACOMANO, José Benedito; BARBOSA, Fábio Alves; operações : da formulação estratégica AZZOLINI, Walther Júnior. Administração de operações: ao controle operacional. São Paulo: Arte & Ciência, 2003. HEINEMANN, Gerrit; SCHWARZL, Christoph. New Online Retailing Innovation and Transformation. Transformation. Gabler, 2010. (Economist) . 3rd edition. HINDLE, Tim. Guide to Management Ideas and Gurus (Economist). 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.; pesquisa : Linguagem e método. Rio SIQUEIRA, Fabio. Como elaborar projetos de pesquisa: 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. marketing: uma orientação aplicada. 4ª MALHOTRA, Naresh K.. Pesquisa de marketing: edição. Bookman, 2006. MATINLASSI, Mari. Comparison of Software Product Line Architecture Design Methods: 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. Automation. Prentice Hall. 1989. Components . In: Report on MCILROY, Malcom Douglas. Mass Produced Software Components. a conference sponsored by the NATO SCIENCE COMMITTEE. COMMITTEE . Garmisch, Germany, 7th to 11th October 1968. NORTHROP, Linda. Software Product Lines Essentials. Essentials . Software Engineering Institute, Carnegie Mellon University. Pittsburgh, PA 15213-2612, 2008. Disponível em: . Acesso: 31/03/2011. Families . In: PARNAS, David L.; On the Design and Development of Program Families. IEEE Transactions on Software Engineering. Vol. SE-2, Nº 1. March 1976. Disponível em: < http://web.cecs.pdx.edu/~omse http://web.cecs.pdx.edu/~omse532/Parnas_Families 532/Parnas_Families.pdf .pdf >. Acesso: 08/03/2011. TCC: Uma PINHEIRO, José Maurício dos Santos. Da Iniciação Científica ao TCC: Abordagem para os Cursos de Tecnologia.1ª edição. Ciência Moderna, 2010. POHL, Klaus; BÖCKLE, Günter; LINDEN, Frank van der. Software Product Line Engineering: Engineering: Foundations, Principles, and Techniques. Springer, 2005. Engineering: A Practitioner's Approach. 5th PRESSMAN, Roger S. Software Engineering: edition. McGraw-Hill, 2001. Engineering. 9th edition. Addison Wesley, 2010. SOMMERVILLE, Ian. Software Engineering. 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. organizações : VASCONCELOS, Eduardo; HEMSLEY, James R. Estrutura das organizações: Estruturas tradicionais, estruturas para inovação, estrutura matricial.. 4ª edição. São Paulo, Editora Thompson, 2003.

58

ANEXO 1  – RESULTADO DA BUSCA NAS BASES CIENTÍFICAS A seguir, são relatados os detalhes das pesquisas realizadas em cada base científica, a saber: Scopus, SciELO, IEEE Xplore, Science Direct e ACM.

Tabela 1 - Detalhamento Detalhamento da pesquisa. Autor Autor (2011)

Data da pesquisa

Strings utilizadas Strings utilizadas

Resultado

Scopus

18/04/2011

(TITLE("software product line") OR TITLE("product family") f amily") OR TITLE("product families") AND TITLE("tool") OR TITLE("report"))

20

SciELO

18/04/2011

("software product line" OR "product families") f amilies") AND ("report" OR "tool")

0

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

9

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

47

(TITLE"software product line" OR TITLE"product families") AND (TITLE"tool" OR TITLE"report") AND (TITLE"management") Realizada com a opção “em todas as áreas de assunto”

92

("software product line" OR "product families") f amilies") AND ("management") AND ("report")

87

("software product line" OR "product families") f amilies") AND ("management") AND ("tool" OR "system")

90

IEEE Xplore

Science Direct

ACM

18/04/2011

18/04/2011

21/04/2011

Total: 345 trabalhos