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

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


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 mostrar-

me 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 fundamental

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, 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 (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 ...................................................................... 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


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. Trabalhos Relacionados ............................................................................. 53

5.2. Trabalhos Futuros ....................................................................................... 54

5.3. 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 tornou-

se 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 da série de aparelhos celulares E da Nokia, cujos sistemas compartilham diversas similaridades

1

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 features2 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

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


Identificar e documentar features básicas e complementares de cada

ferramenta encontrada.

Pesquisar relatos de experiências no uso da abordagem de Linha de


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.

1.4. 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


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: O desenvolvimento de uma ferramenta com as features

investigadas não faz parte do escopo deste trabalho.

- Aspectos técnicos: Os aspectos técnicos, que auxiliem o desenvolvimento

das features investigadas, também não serão tratados neste trabalho.

- Revisão Sistemática de Literatura (RSL): Uma RSL estabelece um

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 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 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.

Neste cenário, o cliente se torna “prosumidor3”: produtor (ao interferir no

processo produtivo) e consumidor. A Figura 3, adaptada de (HEINEMANN e

SCHWARZL, 2010, p.140), mostra as vantagens obtidas pela 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

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

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 produto

5.

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:

Gerenciamento Organizacional: deve criar uma estrutura

organizacional6 adequada para a empresa e certificar-se de que as

unidades organizacionais recebem os recursos adequados (por

exemplo, pessoal bem treinado) em quantidades suficientes.

Gerenciamento Técnico: supervisiona o desenvolvimento da

plataforma e as atividades de desenvolvimento dos produtos,

assegurando que aqueles que os constroem estão engajados nas

5 Citação retirada de http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm. Acesso:

17/03/2011. 6A 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.

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: 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).

•Atividades relacionadas ao desenvolvimento da plataforma

Engenharia de Domínio

•Atividades relacionadas ao desenvolvimento dos produtos

Engenharia de Aplicação

•Planejamento da LPS e coordenação das atividades de Engenharia de Domínio e Engenharia de Aplicação

Gerenciamento

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 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 é reduzido.

Aumento da qualidade dos 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: é 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: 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.

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 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”.

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 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 Furgetta (1993)


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

Desenvolvi-

mento 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)


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

hipóteses”. 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.

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

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 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 CASE e relatos de experiências com o uso da

abordagem de LPS – As ferramentas e os relatos serão pesquisados em

sites de buscas tradicionais (tais como Google7 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 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/

8 http://br.search.yahoo.com/

9 http://portal.acm.org/

10 http://www.scielo.org/php/index.php

11 http://ieeexplore.ieee.org/

12 http://www.sciencedirect.com/

13 http://www.scopus.com/

39

necessidades e/ou dificuldades relatadas durante a 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 final deste trabalho.

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

mostrada abaixo:

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

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

40

4. UM ESTUDO SOBRE FERRAMENTAS CASE PARA GERENCIAMENTO DO


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 FeaturePlugin14 e da

pure::variants15, respectivamente. No entanto, algumas features de tais ferramentas

foram consideradas úteis para o GED e, portanto, 2 (duas) ferramentas foram

selecionadas.

Segue, abaixo, uma breve 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 Eclipse16, 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 15

http://www.pure-systems.com/pure_variants.49.0.html 16

http://eclipse.org/

43

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

Nome Desenvolvedor (es)

Site Código Tipo Artigo

CADSEg Jacky Estublier, German Vega, Philippe Lalanda, Thomas Leveque

http://cadse.imag.fr/ Não disponí-vel

Workbench Software Product Line Evolution: The Selecta System, Estublier et. al., 2010.

Plone Meeting

Hataichanok Unphon, Yvonne Dittrich e Arnaud Hubaux

http://www.communesplone.org/les-outils/applications-metier/gestion-des-deliberations

Disponí-vel

Workbench 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

Feature Problema que soluciona

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). Autor (2011)

PloneMeeting


Agendar reuniões, enviando lembrete aos participantes

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). Autor (2011)


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 validados pelo gerente

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

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

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

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 do processo de

gerenciamento da LPS: “Default Values for Improved Product Line Management”,

“The Importance of Documentation, Design and Reuse in Risk Management for SPL”

e “Standards Initiatives for Software Product Line Engineering and Management”,

sendo este último uma 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 para as lacunas encontradas nos relatos de experiência (continua). Autor

(2011)

Trabalhos 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

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

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

Dá suporte ao gerenciamento financeiro da LPS

7, 10, 8 Visualização de artefatos inacabados e percentual realizado

Gerenciar equipe de desenvolvimento, a fim de aferir possíveis atrasos no desenvolvimento

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

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

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

Geração de métricas de tempo de desenvolvimento por desenvolvedor e quantidade de linhas de código

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

Facilitar gerenciamento do tempo do projeto

6, 3 Minerar e extrair artefatos potencialmente reusáveis

Facilita o planejamento de tempo e custo de uma nova linha de produtos

6 Gerar relatório de percentual de reuso da plataforma

Auxilia o gerenciamento da plataforma, permitindo visualizar eficiência da mesma e possíveis necessidades de mudança.

47

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

Trabalhos 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. Autor (2011)

Origem Feature sugerida Problema que soluciona

Software Engineering Institute

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

Verificar viabilidade financeira do investimento, auxiliando na tomada de decisão sobre os cursos do projeto


Documentar custos esperados para todo o projeto de LPS e refiná-lo de acordo com a realidade do andamento 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


Avaliar a precisão das estimativas de custo iniciais

Permite avaliar se o desenvolvimento Linha de Produtos está se concretizando da maneira como foi planejada


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

Verificar se as metas planejadas estão sendo cumpridas

Proposta pelo Autor

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

Facilita o gerenciamento do tempo, possibilitando que o gerente use estas informações para também gerenciar a equipe

Proposta pelo Autor

Estimar prazo para finalização do projeto

Facilita o gerenciamento de tempo do projeto

Proposta pelo Autor

Estimar tempo restante para a implementação dos artefatos de desenvolvimento individualmente. Calculado a partir do nível de complexidade (que deve ser cadastrado)

Facilita o gerenciamento de tempo do projeto de uma maneira mais refinada

Proposta pelo Autor

Contar quantas vezes cada artefato foi usado em um produto por período (mensal)

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


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 Gerenciamento Organizacional

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


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


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


50

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


apoia

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


Visualização de artefatos inacabados e percentual realizado Gerenciamento Técnico

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


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 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)


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


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


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)


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


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


4.5.1. Conjunto Proposto e Riscos da 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 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 nenhuma “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 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 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

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. Acesso: 08/05/2011.

BERGEY, John K.; CHASTEK, Gary; COHEN, Sholom; DONOHOE, Patrick; JONES,

Lawrence G.; NORTHROP, Linda. Software Product Lines: Report of the 2010 U.S.

Army Software Product Line Workshop. Carnegie Mellon University: June, 2010.

Disponível em: <http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=Get

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: Fundamentos e técnicas. 2ª edição. Campinas: Papirus,

1989.

COHEN, Sholom. Product Line State of the Practice Report. Technical Note

CMU/SEI-2002-TN-017. Pittsburgh: September, 2002. Disponível em <

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

CRONHOLM, S.. Why CASE tools in information systems development? - an

empirical study concerning motives for investing in case tools. In: 18th Information

Systems research In Scandinavia (IRIS 18), Gjern, Denmark, 1995.

DURSCKI, Roberto C.; SPINOLA, Mauro M.; BURNETT, Robert C.; REINEHR,

Sheila S.. Linhas de Produto de Software: riscos e vantagens de sua implantação.

In: VI Simpósio Internacional de Melhoria de Processos de Software São Paulo,

2004.

56

FUGGETTA, Alfonso. A Classification of CASE Technology. In: IEEE Computer

Society Press Los Alamitos, CA, USA. Volume 26 p. 25 - 38. 12, December 1993.

GARCIA, Vinicius Cardoso. RiSE reference model for software reuse adoption in

brazilian companies. Tese (doutorado) – Universidade Federal de Pernambuco.

Recife, 2010.

FUSCO, José Paulo Alves; SACOMANO, José Benedito; BARBOSA, Fábio Alves;

AZZOLINI, Walther Júnior. Administração de operações: da formulação estratégica

ao controle operacional. São Paulo: Arte & Ciência, 2003.

HEINEMANN, Gerrit; SCHWARZL, Christoph. New Online Retailing Innovation

and Transformation. Gabler, 2010.

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

London: Economist Books, 2008.

JIANG, Michael; ZHANG, Jing; ZHAO, Hong; ZHOU, Yuanyuan. Maintaining

Software Product Lines - An Industrial Practice. In: 24th IEEE International

Conference on Software Maintenance. Beijing, 2008.

KAHLMEYER-MERTENS, Roberto S.; FUMANGA, Mario; TOFFANO, Claudia B.;

SIQUEIRA, Fabio. Como elaborar projetos de pesquisa: Linguagem e método. Rio

de Janeiro, Editora FGV, 2007.

LINDEN, Frank van der; SCHMID, Klaus; ROMMES, Eelco. Software Product Lines

in Action: The Best Industrial Practice in Product Line Engineering.Springer, 2007.

MALHOTRA, Naresh K.. Pesquisa de marketing: uma orientação aplicada. 4ª

edição. Bookman, 2006.

MATINLASSI, Mari. Comparison of Software Product Line Architecture Design

Methods: COPA, FAST, FORM, KobrA and QADA. In: ICSE '04 Proceedings of the

26th International Conference on Software Engineering. Edinburgh, 2004.

57

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

MCILROY, Malcom Douglas. Mass Produced Software Components. In: Report on

a conference sponsored by the NATO SCIENCE COMMITTEE. Garmisch, Germany,

7th to 11th October 1968.

NORTHROP, Linda. Software Product Lines Essentials. Software Engineering

Institute, Carnegie Mellon University. Pittsburgh, PA 15213-2612, 2008. Disponível

em: <http://www.sei.cmu.edu/library/assets/spl-essentials.pdf>. Acesso: 31/03/2011.

PARNAS, David L.; On the Design and Development of Program Families. In:

IEEE Transactions on Software Engineering. Vol. SE-2, Nº 1. March 1976.

Disponível em: < http://web.cecs.pdx.edu/~omse532/Parnas_Families.pdf >. Acesso:

08/03/2011.

PINHEIRO, José Maurício dos Santos. Da Iniciação Científica ao TCC: Uma

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: Foundations, Principles, and Techniques. Springer, 2005.

PRESSMAN, Roger S. Software Engineering: A Practitioner's Approach. 5th

edition. McGraw-Hill, 2001.

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

SOUSA, M. R.; RIBEIRO, A. L. P. Systematic Review And Meta-Analysis Of

Diagnostic And Prognostic Studies: A Tutorial. Arquivo Brasileiro de Cardiologia,

V. 92, N. 3, P. 241-251, 2009.

VASCONCELOS, Eduardo; HEMSLEY, James R. Estrutura das 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 da pesquisa. Autor (2011)

Data da

pesquisa Strings utilizadas

Resul-

tado

Scopus 18/04/2011

(TITLE("software product line") OR TITLE("product family")

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

TITLE("report"))

20

SciELO 18/04/2011 ("software product line" OR "product families") AND

("report" OR "tool")

0

IEEE

Xplore 18/04/2011

(((Abstract:"software product line") OR Abstract:"product

families") AND Abstract:"report")

9

(((Abstract:"software product line") OR Abstract:"product

families") AND Abstract:"tool")

47

Science

Direct 18/04/2011

(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

ACM 21/04/2011

("software product line" OR "product families") AND

("management") AND ("report")

87

("software product line" OR "product families") AND

("management") AND ("tool" OR "system")

90

Total: 345 trabalhos

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

Documents

Transcript of Um Estudo sobre Ferramentas CASE para Gerenciamento do Processo de Engenharia de Domínio em Linha...