Upload
vinicius-cardoso-garcia
View
1.160
Download
1
Embed Size (px)
DESCRIPTION
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. Ph.D. Vinícius Cardoso GarciaUma 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.
Citation preview
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 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
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. 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
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.
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
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: 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)
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
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)
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 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
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 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
Feature Problema que soluciona
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)
Feature Problema que soluciona
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
Software Engineering Institute
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
Software Engineering Institute
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
Software Engineering Institute
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
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 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 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)
Gerenciamento Técnico
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)
Gerenciamento Técnico
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
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