SUMRIO

1. INTRODUO.............................................................................................................................. 4
2. PLANEJAMENTO DA REVISO SISTEMTICA ................................................................. 5
2.1 ELABORAO DAS QUESTES ..................................................................................................... 5
2.1.1 Objetivos da Questo .......................................................................................................... 5
2.1.2 Qualidade e Amplitude da Questo .................................................................................... 5
2.2 SELEO DAS FONTES ................................................................................................................. 7
2.2.1 Critrio de Definio das Fontes........................................................................................ 7
2.2.2 Idioma do Estudo ................................................................................................................ 7
2.2.3 Identificao das Fontes ..................................................................................................... 7
2.3 SELEO DOS ESTUDOS .............................................................................................................. 7
2.3.1 Definio dos Estudos......................................................................................................... 7
2.4 EXTRAO DOS RESULTADOS ..................................................................................................... 8
3. CONDUO DA REVISO SISTEMTICA PROCESSO DE BUSCA ............................ 9
3.1 BUSCA NA BIBLIOTECA DIGITAL DA ACM.................................................................................. 9
3.2 BUSCA NO IEEE........................................................................................................................ 10
3.3. BUSCA NO SPRINGERLINK ........................................................................................................ 12
3.4 BUSCA NO GOOGLE SCHOLAR ................................................................................................... 13
4. CONDUO DA REVISO SISTEMTICA SELEO PRELIMINAR....................... 15
4.1 SELEO PRELIMINAR NA BIBLIOTECA DIGITAL DA ACM ....................................................... 15
4.2 SELEO PRELIMINAR NO IEEE................................................................................................ 15
4.3 SELEO PRELIMINAR NA SPRINGERLINK ................................................................................ 15
4.4 SELEO PRELIMINAR NO GOOGLE SCHOLAR ........................................................................... 15
5. CONDUO DA REVISO SISTEMTICA - EXTRAO DE DADOS ......................... 16
5.1 ESTUDOS DA ACM.................................................................................................................... 16
5.1.1 Estudo 01 - Critrios de Avaliao para o Desenvolvimento de LP ................................ 16
5.2 ESTUDOS DA IEEE .................................................................................................................... 20
5.2.1 Estudo 02 - PuLSE-Eco V2.0: Uma Abordagem de Avaliao para a Anlise de
Benefcios e Riscos de LP .......................................................................................................... 20
5.2.2 Estudo 03 - Recuperao e Incorporao de Artefatos em LP......................................... 25
5.2.3 Estudo 04 - Avaliao de Arquitetura de Software com o Mtodo QADA ....................... 28

5.2.4 Estudo 05 - Influncia de Fatores Organizacionais em Qualidade de Arquitetura de LP

.................................................................................................................................................... 30
5.2.5 Estudo 06 - Mtricas de Utilizao de Servios para Avaliao da Estrutura de
Arquiteturas de LP ..................................................................................................................... 34
5.3 ESTUDOS DO GOOGLE SCHOLAR ............................................................................................... 39
5.3.1 Estudo 07 - Prometheus: Uma Abordagem para a Modelagem de Qualidade em LP..... 39
5.3.2 Estudo 08 - O Modelo BAPO para Avaliao de LP........................................................ 43
5.3.3 Estudo 09 - Avaliao Prtica de Arquiteturas de LP ..................................................... 45
5.4 ANLISE DOS RESULTADOS....................................................................................................... 48
6. CONSIDERAES FINAIS SOBRE A REVISO SISTEMTICA ................................... 53
REFERNCIAS ............................................................................................................................... 54

1. Introduo
A demanda por qualidade tem motivado a comunidade de software para o desenvolvimento
de modelos para qualidade de software. Estes modelos esto orientados por duas vises: viso de
processo e viso de produto. A viso de processo trata da avaliao e melhoria dos processos
utilizados para o ciclo de vida de software. A viso de produto trata da avaliao de um produto de
software, para verificao de sua qualidade.
Nas ltimas dcadas, vrios padres de qualidade de produto e processo de software foram
propostos e esto disponveis na literatura. Dessa forma, este trabalho apresenta o planejamento e a
conduo de uma reviso sistemtica sobre padres de qualidade e avaliao em linha de produto de
software (LP). A reviso visa identificao de padres de qualidade e de avaliao de LP
existentes e apresenta como resultado final uma anlise, a partir do material selecionado, sobre o
estado da arte e da prtica no que diz respeito qualidade de LP.
Esta monografia est organizada da seguinte maneira: a seo 2 apresenta o planejamento da
reviso sistemtica; a seo 3 apresenta o processo de busca dos estudos nas fontes selecionadas; a
seo 4 apresenta a seleo preliminar dos estudos da reviso; a seo 5 apresenta a extrao de
dados dos textos selecionados e uma anlise dos resultados; e a seo 6 apresenta as consideraes
finais a respeito da reviso.

2. Planejamento da Reviso Sistemtica

Este trabalho est relacionado aos padres e normas existentes sobre qualidade e avaliao
em linha de produto de software (LP). O objetivo deste estudo relacionar tais padres
identificando para cada um deles suas principais caractersticas, bem como suas limitaes.
As sees a seguir apresentam o planejamento da reviso sistemtica, de acordo com o
protocolo proposto por Biolchini et al. (2005).
2.1 Elaborao das Questes
2.1.1 Objetivos da Questo

Questo Primria:

Quais os padres e normas de qualidade e avaliao existentes para LP?

2.1.2 Qualidade e Amplitude da Questo

Interveno:

Padres e normas de qualidade e avaliao em LP

Controle:

Nenhuma baseline ou conjunto de dados disponveis para este estudo

Efeito:

Anlise sobre o estado da arte e da prtica sobre qualidade e avaliao de LP, com
base nos materiais selecionados durante a reviso

Estudo inicial para a proposta de um modelo de qualidade para LP

Mtricas:

LP = Quantidade de estudos selecionados sobre qualidade/avaliao de LP como

um todo (incluindo arquitetura de LP)

Arq = Quantidade de estudos selecionados somente sobre qualidade/avaliao de

arquitetura de LP
5

Populao:

Arquitetura de LP

LP como um todo

Resultados:

Padres e/ou normas de qualidade para LP

Aplicao:

Academia e indstria interessadas em avaliao de qualidade de LP

Projeto Experimental:

Nenhum mtodo estatstico ser usado

Anlise quantitativa e qualitativa com base nas mtricas definidas para o estudo

Apresentao de histogramas com os valores calculados para as mtricas

Palavras-Chaves:

Qualidade/avaliao de linha de produto (famlia de produto)

Termos Relacionados:

Qualidade/avaliao de linha de produto (famlia de produto):

o qualidade de linha de produto/famlia de produto (product line/ productline/product family/product-family quality)
o avaliao de linha de produto/famlia de produto:

(product

line/

product-line/product

family/product-family

line/

product-line/product

family/product-family

evaluation)

(product
assessment)

o padro/norma de qualidade (quality standard)

o modelo de qualidade (qualtity model)
o avaliao de qualidade (quality evaluation/assessment)
o maturidade de qualidade (quality maturity)
o atributo de qualidade (quality attribute)
o fator de qualidade (quality factor)

2.2 Seleo das Fontes

2.2.1 Critrio de Definio das Fontes
As fontes selecionadas para o estudo devem ter como caracterstica principal a sua ampla
utilizao e indexao, bem como um vasto acervo disponvel para consulta. Assim, foram
definidas as seguintes fontes de estudos primrios:

bases de dados eletrnicas indexadas;

mquinas de busca eletrnica.

2.2.2 Idioma do Estudo

O idioma definido leva em considerao ampla disponibilidade dos estudos nas fontes.
Assim, somente o idioma ingls foi escolhido para a busca nas fontes.
2.2.3 Identificao das Fontes
As buscas sero realizadas por meio da submisso de strings nas bases de dados eletrnicas
e nas mquinas de buscas conforme a lista a seguir:

bases de dados eletrnicas indexadas:

o ACM
o IEEE
o SpringerLink

Mquina de busca eletrnica:

o Google Scholar

A string geral que ser submetida busca (adaptada para cada uma das fontes) apresentada
a seguir, no forma de uma expresso lgica com os operadores OR e AND:

((product line OR product family OR product-line OR product-family) AND quality AND

(standard OR model OR evaluation OR assessment OR maturity OR attribute OR factor))

2.3 Seleo dos Estudos

2.3.1 Definio dos Estudos
Critrios de Incluso dos Estudos:

Questo Primria: padres/normas de qualidade ou avaliao de LP

Critrios de Excluso dos Estudos:

Questo Primria: padres/normas de qualidade ou avaliao que no se referem

LP; textos que no foram escritos em ingls; textos no disponveis por completo
(menos de 03 pginas), textos muito extensos (mais de 20 pginas), e textos no
formato diferente de PDF.

Definio do Tipo dos Estudos:

qualquer tipo de estudo, por exemplo:

o qualitativos ou quantitativos;
o observacionais;
o de caracterizao;
o de viabilidade.

Procedimentos para Seleo Preliminar:

A seleo acontecer por meio da preparao de strings de busca a partir das
palavras-chaves e dos termos relacionados, apresentados na Seo 2.1.2 e da submisso de tais
strings s fontes.
Para saber se um determinado estudo relevante pesquisa, sero lidos os resumos
(abstracts) e, em caso positivo, estes sero selecionados para serem lidos por completo segundo os
critrios de incluso e excluso.
Procedimentos para Seleo Final:
Para a seleo final sero lidos todos os artigos relevantes identificados na seleo
preliminar.
2.4 Extrao dos Resultados
Ao trmino da seleo final, ser realizada uma sntese de cada estudo, considerando alguns
itens como: identificao, proponente(s), caracterizao e limitaes de cada padro/norma de
qualidade e avaliao de LP.

3. Conduo da Reviso Sistemtica Processo de Busca

Para a realizao desta etapa as strings de busca elaboradas foram submetidas s fontes
previamente selecionadas. Porm, o que se nota que cada mquina de busca possui a sua forma
prpria de submeter s strings para a busca.
A seguir apresentada a descrio da execuo das buscas em cada uma das fontes.
3.1 Busca na Biblioteca Digital da ACM
A busca na biblioteca digital da ACM foi realizada no dia 07/11/2006, por meio do endereo
eletrnico http://portal.acm.org/advsearch.cfm.
A figura a seguir ilustra o mecanismo de busca da ACM.

Figura 1: Mecanismo de Busca da Biblioteca Digital da ACM.

A pgina de busca avanada da ACM foi utilizada, sendo que a pesquisa foi realizada
somente no resumo dos artigos, como mostra o campo Only search in: (Figura 1). Os seguintes
campos foram preenchidos, conforme a seguir:

must have all of the words or phrases: quality

must have any of the words or phrases: "product line " "product family" "productline" "product-family"

Assim, a string final utilizada na busca foi (o + significa obrigatrio):

+abstract:quality abstract:"product line" abstract:"product family" abstract:"product-line"

abstract:"product-family"

Desse modo, a pesquisa retornou 25 resultados, sendo que:

01 texto estava inacessvel;

24 textos estavam disponveis.

Outras 04 strings de busca foram utilizadas para pesquisa. Elas foram submetidas
separadamente umas das outras, sendo elas:
1. +abstract:"product

line"

abstract:evaluation

+abstract:quality

abstract:assessment

abstract:standard

abstract:maturity

abstract:model
abstract:attribute

abstract:factor
2. +abstract:product-line
abstract:evaluation

+abstract:quality
abstract:assessment

abstract:standard
abstract:maturity

abstract:model
abstract:attribute

abstract:factor
3. +abstract:"product family" +abstract:quality abstract:standard abstract:model
abstract:evaluation

abstract:assessment

abstract:maturity

abstract:attribute

abstract:factor
4. +abstract:product-family
abstract:evaluation

+abstract:quality

abstract:assessment

abstract:standard
abstract:maturity

abstract:model
abstract:attribute

abstract:factor
O mecanismo de busca da ACM possui restrio quanto ao tamanho da string de busca.
Dessa forma, uma busca para cada combinao dos termos product line, product-line, product
family e product-family foi realizada. A primeira string retornou 12 textos, a segunda retornou 13
textos, a terceira retornou 01 texto e a quarta retornou 01 texto. Porm, percebeu-se que os textos
encontrados com as 04 strings foram os mesmos encontrados com a string final utilizada para a
ACM e, dessa maneira, optou-se pela string mais simplificada.

3.2 Busca no IEEE

A busca na biblioteca digital do IEEE foi realizada no dia 07/11/2006, por meio do endereo
eletrnico http://ieeexplore.ieee.org/search/advsearch.jsp.
Assim como na ACM, a busca avanada foi realizada no resumo e tambm no ttulo dos
textos, sendo, para isso, utilizada a opo option 2 do IEEE (Figura 2). No campo Enter keywords,
phrases or a Boolean expression foi utilizada a string de busca:

10

((product line <or> product family <or> product-line <or> product-family) <and> quality <and>
(standard <or> model <or> evaluation <or> assessment <or> maturity <or> attribute <or>
factor)) <in> (ab,ti, metadata)

Outras opes foram definidas para esta busca (Figura 2), sendo elas:

Maximum: 100, o valor mximo de resultados da busca

Display: 100, o valor mximo de resultados que devem ser mostrados a partir de
Maximum

A figura a seguir ilustra o mecanismo de busca da IEEE.

Figura 2: Mecanismo de Busca da IEEE.

A busca retornou 49 resultados, sendo todos eles disponveis.

11

3.3. Busca no SpringerLink

A busca no SprilgerLink foi realizada no dia 07/11/2006 por meio da pgina principal de
busca http://www.springerlink.com, em que foi utilizado o mecanismo de composio de strings
(Figura 3). Em tal mecanismo possvel combinar termos de busca com os operadores AND, OR e
NOT, alm de se poder escolher em que local do texto tal string pode ser buscada (ttulo, resumo,
autor, ISSN, ISBN).
A figura a seguir ilustra o mecanismo de busca da SpringerLink.

Figura 3: Mecanismo de Busca da SpringerLink.

Assim, a string final de busca utilizada foi (su significa sumrio):

su:("product line" OR "product-line" OR "product family" OR "product-family") AND su:(quality)

AND su:(standard OR model OR evaluation OR assessment OR maturity)

Dessa forma, a busca retornou 20 resultados. Porm, no dia 21/11/2006 ao tentar efetuar o
download dos textos, o mecanismo de busca da SpringerLink apresentou um erro ao buscar pela
string definida. A Figura 4 apresenta o erro na avaliao da string ao restringir a busca ao resumo
dos textos. O mecanismo no aceitou o ndice de busca su relativo ao resumo de textos.

12

Figura 4: Erro no Mecanismo de Busca da SpringerLink.

Ao entrar em contato, a equipe responsvel pelo SpringerLink reconheceu ser um erro do
software de busca do mecanismo. Porm, o mecanismo encontra-se ainda indisponvel para a
consulta em resumos, o que impossibilitou a anlise dos textos encontrados.

3.4 Busca no Google Scholar

A busca no Google Scholar foi realizada no dia 07/11/2006, de modo avanado por meio do
endereo eletrnico http://scholar.google.com/advanced_scholar_search?hl=en&lr=.
Para tanto, alguns campos da busca foram preenchidos como segue (Figura 5):

With all the words: quality software

With at least one of the words: standard model evaluation assessment maturity
attribute factor

Where my words occur: in the title of the article

A String final de busca utilizada foi:

allintitle: quality ("product line" OR "product-line" OR "product family" OR "product-family")

(standard OR model OR evaluation OR assessment OR maturity OR attribute OR factor)
filetype:pdf

13

Figura 5: Mecanismo de Busca do Google Scholar.

Dessa forma, a busca retornou 01 texto. Para tentar contornar a falta de resultados, foi
realizada a busca novamente, porm no campo Where my words occur optou-se pela opo
anywhere in the article. Assim, o mecanismo de busca retornou 11.600 resultados. Como este um
nmero invivel para a realizao desta reviso sistemtica, somente os 10 primeiros foram
considerados, estando todos eles disponveis.

14

4. Conduo da Reviso Sistemtica Seleo Preliminar

Conforme o planejamento da reviso sistemtica, nesta etapa os resumos de todos os textos
coletados no processo de busca foram lidos.
As sees a seguir apresentam a seleo preliminar dos textos candidatos leitura completa.

4.1 Seleo Preliminar na Biblioteca Digital da ACM

O seguinte texto foi previamente selecionado para sua completa leitura:
1. Product Line Software Engineering of Embedded Systems

4.2 Seleo Preliminar no IEEE

Os seguintes textos foram previamente selecionados para sua completa leitura:
1. An Assessment Approach To Analyzing Benefits and Risks of Product Lines
2. Asset Recovery and Their Incorporation into Product Lines
3. Evaluating the Portability and Maintainability of Software Product Family
Architecture: Terminal Software Case Study
4. The Influence of Organizational Factors on the Success and Quality of a ProductLine Architecture
5. Using Service Utilization Metrics to Assess the Structure of Product Line
Architectures
4.3 Seleo Preliminar na SpringerLink
Nenhum texto selecionado por causa do problema apresentado pelo mecanismo de busca da
SpringerLink.

4.4 Seleo Preliminar no Google Scholar

Os seguintes textos foram previamente selecionados para sua completa leitura:
1. Practical Evaluation of Software Product Family Architectures
2. Quality Modeling for Software Product Lines
3. Software Product Family Evaluation
15

5. Conduo da Reviso Sistemtica - Extrao de Dados

Nesta etapa da reviso sistemtica foi realizada a extrao dos dados a partir da leitura dos
textos previamente selecionados na seo anterior.
Para tanto, foi necessria a elaborao de um formulrio de extrao de dados com o
objetivo de organizar as informaes obtidas na leitura dos textos. Assim, a Figura 6 apresenta o
formulrio elaborado.

Identificao: ___________________________________________________________________
Proponente(s): __________________________________________________________________
Referenciado Por:_______________________________________________________________
Caractersticas e Limitaes: ______________________________________________________

Figura 6: Formulrio de Extrao de Dados.

O formulrio composto por quatro campos principais, sendo eles:

Identificao: texto descritivo do item em questo (padro ou norma);

Proponente(s): indica a pessoa, o grupo ou a organizao que criou o padro/norma

ou item em questo;

Referenciado Por: texto(s) que referencia(m) o item em questo;

Caractersticas e Limitaes: uma sntese do item em questo apresentando as suas

caractersticas principais, bem como as suas limitaes.

Dessa forma, todos os textos selecionados na seo anterior foram lidos por completo. As
sees a seguir apresentam uma sntese de cada estudo e ao final apresentada uma anlise acerca
dos resultados.

5.1 Estudos da ACM

A extrao dos dados dos textos da ACM resultou no item apresentado a seguir.
5.1.1 Estudo 01 - Critrios de Avaliao para o Desenvolvimento de LP

Identificao:
Critrios de Avaliao para o Desenvolvimento de LP
16

Proponente(s):
NIEMEL, E. e IHME, T. (VTT Electronics - Embedded Software - Finland)
Referenciado Por:
Niemel, E., Ihme, T. 2001. Product Line Software Engineering of Embedded Systems.
ACM SIGSOFT Software Engineering Notes, Vol. 26, No 3 (May 2001). pp. 118-125.
Niemel, E.; Matinlassi, M.; Taulavouri, A. 2004. Practical Evaluation of Software Product
Family Architectures, Proceedings of the 3rd International Conference on Software Product Lines,
pp. 130-145.
Caractersticas e Limitaes:
A primeira etapa no desenvolvimento de LP a anlise do negcio e do escopo da LP, que
visa estimar os benefcios da abordagem para a organizao e os domnios potenciais de
reutilizao.
Um dos grandes problemas em LP o conhecimento do domnio, bem como: qual o tipo de
conhecimento que existe sobre o domnio? Como ele representado? Qual a sua qualidade?
Assim, ao se iniciar o desenvolvimento de LP, 03 questes devem ser respondidas, sendo
elas:

A abordagem de LP propcia rea de negcio da organizao?

Onde, quando e como a abordagem de LP poderia ser aplicada?

Que prticas devem ser desenvolvidas para alcanar um custo efetivo com LP?

A identificao dos business drivers e dos stakeholders, bem como uma estimativa dos
possveis consumidores dos produtos ajudam a responder a primeira questo. Uma anlise de custobenefcio deve ser realizada investigando o nmero de possveis produtos que podem ser gerados
pela LP. A primeira questo equivale elaborao de um modelo econmico para LP.
A anlise dos business drivers realizada segundo 03 pontos de vista: processos e cultura da
organizao; arquitetura de LP; e gerenciamento de artefatos (Figura 1).

Figura 1: Vises do Desenvolvimento de LP (NIEMEL, 2001).

17

A primeira viso analisa o estado do desenvolvimento e da conformidade de software entre

as prticas de desenvolvimento de software que esto descritas e as que so aplicadas. A segunda
viso estima as propriedades existentes e desejveis e a qualidade dos produtos inseridos na LP. A
terceira viso estima o potencial de manuteno dos artefatos por meio do desenvolvimento de
mecanismos de suporte como, por exemplo, gerenciamento e configurao de software. A Tabela 1
apresenta as 03 vises e os elementos para cada viso.
Tabela 1: Identificao dos Business Drivers de uma LP (NIEMEL, 2001).

A anlise dos business drivers estima os benefcios da adoo de LP, sendo uma maneira de
manter os gerentes comprometidos com a abordagem.
A anlise de domnio ajuda a responder a segunda questo. O escopo, as semelhanas, as
variabilidades e a qualidade o foco principal, assim como o comprometimento do pessoal, o
conhecimento do domnio e as habilidades tcnicas so analisadas para se saber se uma organizao
possui as habilidades profissionais exigidas para o desenvolvimento de LP. A Tabela 2 apresenta os
elementos e as pr-condies na definio do domnio.
Tabela 2: Identificao do Domnio: Pr-condies de uma LP (NIEMEL, 2001).

18

A anlise de modelos, mtodos e ferramentas, bem como artefatos pr-existentes e prticas

aplicadas ajuda a responder a terceira questo. Para tanto, necessrio definir quais as partes de
software que so valiosas para fazerem parte do ncleo de artefatos. O desenvolvimento do ncleo
de artefatos inicia com uma anlise do estado atual da definio dos requisitos, da arquitetura de
software e da descrio dos componentes. Os artefatos que possuem um maior potencial de
reutilizao sero escolhidos para fazerem parte do desenvolvimento do ncleo de artefatos (Tabela
3).
Tabela 3: Desenvolvimento do Ncleo de Artefatos (NIEMEL, 2001).

19

Uma anlise da evoluo do ncleo de artefatos desejvel para as 03 vises, uma vez que
alguns produtos podem reutilizar somente a arquitetura de LP e mudar totalmente o cdigo para
cada produto gerado.
Um estudo com base no modelo de 03 vises foi desenvolvido na forma de entrevistas em
empresas de desenvolvimento de software embarcado segundo o framework da Figura 2.

Figura 2: Framework de Entrevista (NIEMEL, 2001).

Um dos resultados do estudo mostrou que somente 30% das empresas entrevistadas
possuem uma viso e um entendimento claro de quais so as propriedades mais importantes em
seus produtos.
A grande limitao do modelo encontra-se em como avaliar, com base nos critrios
apresentados, se a organizao est apta a adotar a abordagem de LP. O estudo realizado pelos
autores mostra somente como as 03 vises foram definidas. Porm, a partir da definio destas
como saber se a empresa est preparada para iniciar o desenvolvimento de uma LP para o seu
domnio? Acredita-se que algumas mtricas ou pesos para cada critrio seja uma forma de medir
quantitativamente se a empresa se beneficiar da abordagem de LP.

5.2 Estudos da IEEE

A extrao dos dados dos textos da IEEE resultou nos itens apresentados a seguir.
5.2.1 Estudo 02 - PuLSE-Eco V2.0: Uma Abordagem de Avaliao para a Anlise de Benefcios e
Riscos de LP

Identificao:
20

PuLSE-Eco V2.0: Uma Abordagem de Avaliao para a Anlise de Benefcios e Riscos de

LP
Proponente(s):
SCHMID, K. (Fraunhofer Institute for Experimental Software Engineering- Germany)
Referenciado Por:
Schmid, K. 2001a. An Assessment Approach to Analyzing Benefits and Risks of Product
Lines, Proceedings of the 25th International Computer Software and Applications Conference on
Invigorating Software Development, pp. 525-530.
Caractersticas e Limitaes:
Grande parte das atividades tcnicas de LP concentra-se no desenvolvimento da arquitetura
de LP e na anlise de domnio. Porm, uma anlise de riscos e benefcios fundamental para as
empresas que desejam seguir a abordagem de LP. Algumas questes que precisam ser respondidas
como parte da definio do escopo de LP:

A abordagem de LP deve focar somente uma linha particular de produtos (domnio)?

Todas as reas tcnicas (sub-domnios) devem ser tratadas da mesma maneira, ou

deve-se priorizar somente algumas?

Quais as partes de software que devem ser desenvolvidas para reutilizao?

Quais os benefcios que se pode esperar no desenvolvimento de LP?

Assim, uma metodologia que busca responder tais perguntas est em desenvolvimento como
parte da abordagem PuLSE (Product Line Software Engineering), chamada PuLSE-Eco V2.0. Esta
metodologia visa cobrir todas as questes levantadas, uma vez que a abordagem original (PuLSE)
encontrou problemas em sua aplicao na prtica industrial.
O PuLSE-Eco V2.0 baseia-se em vrios padres de qualidade e de avaliao de processo
como CMM, Bootstrap, SPICE e FAME. No contexto de reutilizao de software, tais padres j
vm sendo usados para cobrir dois aspectos: a dimenso do processo (para reutilizao) e a
dimenso do domnio (conjunto de produtos). Dessa forma, a abordagem PuLSE-Eco V2.0 avalia os
domnios individualmente ao invs da LP como um todo.
A abordagem PuLSE-Eco V2.0 formada por trs fases:

Mapeamento da LP: descrio em alto nvel da LP em anlise e dos domnios

relevantes a ela. Isto fornece uma base de comunicao para as prximas fases da
abordagem;

Definio do Escopo do Domnio: uma avaliao dos benefcios e dos riscos do

desenvolvimento de LP realizada em nvel de LP e para cada sub-domnio. Como
21

resultado, as reas mais promissoras so identificadas e alguns domnios j podem

ser removidos da anlise detalhada. Isso reduz o esforo na definio de escopo dos
artefatos da LP;

Definio do Escopo dos Artefatos: uma fase baseada em anlise quantitativa.

A abordagem PuLSE-Eco V2.0 est organizada de forma que as duas primeiras fases podem
ser aplicadas sem a terceira. Assim, a avaliao dos benefcios e riscos consiste nas duas primeiras
fases. Quando a abordagem foi desenvolvida, foi possvel se basear em abordagens de avaliao de
processos como o FAME, que uma instanciao do SPICE fazendo uso de toda a experincia
adquirida pela comunidade ao longo dos anos. Porm, existe uma diferena entre a avaliao de
maturidade de um processo e a avaliao de potencias LPs. Um mapeamento entre as duas formas
de avaliao apresentado na Tabela 1.
Tabela 1: Mapeamento dos Conceitos de Avaliao (SCHMID, 2001a).

Estas diferenas so traduzidas em trs problemas que devem ser resolvidos no

desenvolvimento de um mtodo de avaliao de LP (PuLSE B&R):

um framework de referncia para LP teve de ser desenvolvido;

medidas de avaliao para benefcios e riscos de LP foram identificadas;

um processo teve de ser definido para a execuo da avaliao de LP.

Em avaliao de LP no usada uma estrutura de referncia fixa, como reas-chaves de

processo do CMM, mas necessrio identificar uma estrutura de referncia que deve ser modelada
para cada LP. Assim, abordagem PLM (Product Line Mapping) foi desenvolvida para tratar as
questes sobre modelos de referncia. Este mtodo serve para dois propsitos: identificar a estrutura
de alto nvel de uma LP em termos das principais funcionalidades e como esta se relaciona aos
produtos da linha e aos domnios tcnicos - assim, a abordagem pode ser usada como um ponto de
incio para a anlise de domnio; e fornecer a base de comunicao para a realizao da avaliao.
A abordagem PLM no foca diretamente nos produtos particulares que podem ser
desenvolvidos, mas modela a interseco dos domnios e das funcionalidades dos produtos. Esta
abordagem dividida em vrias etapas, sendo elas:
1. identificar os produtos existentes e futuros que podem ser relevantes a LP;
22

2. desenvolver um plano de apresentao destes produtos;

3. identificar as maiores funes/caractersticas que so relevantes as funcionalidades
destes sistemas;
4. agrupar tais funes em reas funcionais maiores;
5. desenvolver um plano de apresentao dos domnios que mostram as suas interrelaes;
6. analisar a informao para a existncia de domnios internos adicionais;
7. garantir consistncia dos sistemas existentes;
8. desenvolver uma matriz inicial de produto/funo.
Alm da abordagem PLM, um framework de referncia para realizar a avaliao
necessrio. Este framework usado para determinar a avaliao atual dos domnios ao longo de
varias dimenses. O incio da avaliao se d usando uma abordagem estruturada para derivar as
questes de avaliao, similar ao GQM (Goal Question Metric). Como entrada, so fornecidas as
dimenses de avaliao, resultantes de um survey de avaliaes no contexto de engenharia de
domnio. Tais dimenses so apresentadas na figura a seguir.

Figura 2: Dimenses de Avaliao (SCHMID, 2001a).

Cada uma das dimenses dividida em questes principais (atributos) e questes detalhadas
(indicadores). Um exemplo de arranjo hierrquico entre as dimenses e questes apresentado na
figura a seguir.

Figura 3: Exemplo de Decomposio de Avaliao (SCHMID, 2001a).

23

O framework atualmente composto de 09 dimenses de avaliao, 25 atributos (questes

principais) e 93 indicadores (questes detalhadas). Durante a execuo da avaliao, as respostas
so contabilizadas de acordo com uma escala de quatro nveis: F=Fully, L=Largely, P=Partially e
N=None.
Dessa forma, um processo de avaliao foi proposto com base na abordagem FAME, e
apresentado na figura a seguir.

Figura 4: Processo de Avaliao (SCHMID, 2001a).

O processo consiste de 3 etapas:

preparao: a equipe de avaliao formada e a finalidade da avaliao definida.

A maior tarefa desta etapa o desenvolvimento do mapeamento da LP gerando uma
descrio detalhada da LP que serve de entrada para a avaliao;

execuo: a avaliao executada como um conjunto de entrevistas estruturadas,

que so dirigidas por questionrios que descrevem o framework de avaliao.
Resultados preliminares so apresentados aos entrevistados para possveis correes;

24

anlise: um relatrio de avaliao preparado e o julgamento final dos benefcios e

riscos de reutilizao nos vrios domnios desenvolvido. Como maior resultado,
so elaboradas recomendaes para quais domnios deve ser aplicado a reutilizao.

A abordagem proposta apresenta a descrio explcita de LP como um modelo de referncia

similar a um modelo de referncia de processo usado pelas abordagens de avaliao de processos.
Alm disso, a abordagem fortemente baseada em trabalhos existentes de avaliao de maturidade
de processos e tem como vantagens o grande conhecimento e experincia no campo de avaliao de
processos. A abordagem tem a vantagem de reduzir o esforo na anlise de sub-domnios que j
podem ter sido excludos em etapas anteriores da abordagem.
Acredita-se que este trabalho esteja limitado com relao falta de um estudo de caso ou de
um projeto piloto para ilustrar as etapas de avaliao de uma potencial LP. Talvez uma verso
estendida do artigo ou um relatrio tcnico possam elucidar a abordagem e a sua aplicao.

5.2.2 Estudo 03 - Recuperao e Incorporao de Artefatos em LP

Identificao:
Recuperao e Incorporao de Artefatos em LP
Proponente(s):
KNODEL, J.; JOHN, I.; DHARMALINGAM, G. (Fraunhofer Institute for Experimental
Software Engineering- Germany)
PINZGER, M. (Institute of Informatics Switzerland)
USERO, F. (Telvent Spain)
ARCINIEGAS, A. L. (Departamento de Ingeniera de Sistemas Telemticos Spain)
RIVA, C. (Software Architecture Group Nokia Research Finland)
Referenciado Por:
Knodel, J.; John, I.; Dharmalingam, G.; Pinzger, M.; Arciniegas, A. L.; Riva, C. 2005. Asset
Recovery and their Incorporation into Product Lines, Proceedings of the 12th Workshop
Conference on Reverse Engineering, pp. 120-129.
Caractersticas e Limitaes:
Raramente uma LP desenvolvida a partir do zero. Na maioria das vezes a LP concebida
quando j existe um nmero suficiente de produtos que tornam o domnio consolidado.

25

Muitas vezes necessrio adicionar novos artefatos ao ncleo de artefatos de uma LP. Tais
artefatos podem ter origem dos mais variados tipos. Para tanto, necessrio estabelecer a forma
como estes sero incorporados ao ncleo de artefatos da LP, sendo que as possveis formas so:

reutilizar o artefato na forma em que ele se encontra: incorporar o artefato na

forma como foi encontrado ou com poucas alteraes, sendo que a qualidade boa o
suficiente para migrar o artefato para o ncleo com esforo limitado;

reutilizar o artefato com modificaes: incorporar o artefato aps mudanas

substanciais;

recuperar e adaptar o artefato: recuperar e adaptar um artefato existente com

tcnicas de engenharia reversa;

re-implementao do artefato: desenvolver um novo artefato baseado no j

existente e descartar o antigo artefato.

Assim, um processo proposto para realizar a incorporao dos artefatos ao ncleo de

artefatos de uma LP. O processo utiliza o Software Process Engineering Meta-model (SPEM) da
OMG como notao para a incorporao de artefatos infra-estrutura da LP. O processo focado
principalmente nas atividades de engenharia de domnio, como mostra a Figura 1.

Figura 1: Atividade de Engenharia de Domnio (KNODEL et al., 2005).

26

Durante a anlise de domnio, uma anlise de necessidades realizada e tem como sada
uma descrio genrica dos artefatos mostrando os requisitos necessrios para que o artefato possa
ser incorporado ao ncleo de artefatos da LP. Em seguida, a atividade de descoberta de artefatos
visa identificar os artefatos existentes que so candidatos a suprir as necessidades j identificadas. A
atividade seguinte visa a avaliao do impacto, do custo e da qualidade necessria para a
incorporao do artefato na LP. A proposta utilizar algum padro para a avaliao como, por
exemplo, a ISO 14598 ou GQM (Goal-Question-Metric).
Ao incorporar o artefato ao ncleo de artefatos da LP necessrio inclu-lo tambm na
arquitetura de LP, o que difcil de conseguir por causa de potenciais efeitos colaterais e restries
tcnicas.
A Figura 2 apresenta todas as atividades do processo de incorporao de artefatos.

Figura 2: Cargos e Atividades na Incorporao de Artefatos (KNODEL et al., 2005).

A grande limitao do trabalho reside na avaliao de qualidade do ncleo de artefatos da
LP. Avaliar o artefato que est sendo incorporado de forma isolada como a avaliao de um
produto especfico - no garante que a qualidade da LP continue a mesma ou melhore. Muito pelo
contrrio, a existncia de uma atividade de anlise tcnica no processo de incorporao uma
evidncia de que a qualidade da LP como um todo deve ser avaliada.

27

5.2.3 Estudo 04 - Avaliao de Arquitetura de Software com o Mtodo QADA

Identificao:
Avaliao de Arquitetura de Software com o Mtodo QADA (Quality-driven Architecture
Design and quality Analysis)
Proponente(s):
MATINLASSI, M. (VTT Technical Research Centre of Finland)
Referenciado Por:
Matinlassi, M. 2004. Evaluating the Portability and Maintainability of Software Product
Family Architecture: Terminal Software Case Study, Proceedings of the 4th Working IEEE/IFIP
Conference on Software Architecture, pp. 295-298.
Caractersticas e Limitaes:
O trabalho apresenta um estudo de caso na avaliao de uma arquitetura de LP para
terminais de coleta pblicos. A LP possui dois tipos de produtos: terminais fixos e terminais
portteis. A idia utilizar o mtodo QADA (Quality-driven Architecture Design and quality
Analysis) para avaliar a portabilidade e manutenibilidade da arquitetura de LP aps a incluso de
um novo membro da LP.
Antes de iniciar a avaliao, todos os produtos da LP foram estudados por meio da
documentao existente e a arquitetura foi documentada usando o QADA. O QADA permite a
descrio da arquitetura em 4 pontos de vista (estrutural, comportamental, implantao e
desenvolvimento) e 2 nveis de abstrao (conceitual e concreto).
O processo de avaliao de portabilidade e manutenibilidade inclui as seguintes etapas:
1. descrio da arquitetura de LP: de acordo com as vises arquiteturais;
2. criao de categorias de cenrios: criar categorias de mudana para o domnio do
problema e identificar categorias de tarefas de manuteno.
3. identificao de cenrios: cenrios de manuteno e mudana so criados baseados
nas categorias definidas na etapa anterior;
4. associar um peso para cada cenrio: pode ser, por exemplo, a probabilidade de
ocorrncia em um certo perodo de tempo (somente para avaliao de
manutenibilidade);
5. avaliar o efeito dos cenrios em elementos da arquitetura;
6. revelar interaes de cenrio: quais cenrios afetam o mesmo componente.

28

A descrio da arquitetura foi feita com base nas vises do QADA, nos diagramas de classe
e de interface de cada componente, bem como entrevistas com os desenvolvedores. Ainda, as
variabilidades da arquitetura foram capturadas.
No estudo de caso, 4 categorias de portabilidade e 4 categorias de manuteno foram
definidas, sendo elas:

Categorias de Portabilidade (Mudana):

o Mudanas de Interface de HW/SW;
o Mudanas de Plataforma de HW;
o Mudanas de Plataforma de SW;
o Mudanas em Requisitos de Segurana.

Categorias de Manuteno:
o Extenses de Features;
o Excluso de Funcionalidades no-desejadas;
o Entrada para Novos Dispositivos;
o Melhorias na Qualidade (Segurana e Desempenho).

Assim, foram definidos 20 cenrios de portabilidade e 17 cenrios de manuteno. Medidas

qualitativas foram associadas ocorrncia dos cenrios. Com relao a perodo de tempo, algumas
medidas como dentro dos prximos 2 anos foram utilizadas.
Aps a criao dos cenrios, estes foram exercitados com relao a quais componentes da
arquitetura foram afetados e que tipos de mudana foram necessrias visando estimar o efeito de
cada cenrio na arquitetura. Um exemplo de cenrio de portabilidade e uma pequena avaliao dos
efeitos na arquitetura so apresentados a seguir.
Cenrio: Conexo da impressora mudou de local para wireless (bluetooth).
Efeito na Arquitetura: A impresso feita por uma API. Uma classe wrapper teve de ser
criada para o componente User Interface para habilitar a impresso no novo ambiente.
Resultado: Mudana moderada em um componente.
Ao final da execuo dos cenrios, foram contabilizados quantos componentes foram
afetados por um cenrio e quantos cenrios afetaram um s componente. Por exemplo, um
componente foi afetado por 07 cenrios. Assim, a interao de cenrios pode ser traduzida como
uma fraca separao de interesses do componente. Por outro lado, um cenrio afetou 5 componentes
diferentes,o que pode ser visto como um risco para a arquitetura.
Como lies aprendidas, a avaliao de portabilidade deve ser feita por um mtodo baseado
em cenrios em nvel arquitetural. A descrio da arquitetura tem papel fundamental em sua
29

avaliao de qualidade. Os pontos de vista arquiteturais do QADA so projetados especialmente em

atributos de qualidade. A avaliao de manutenibilidade bastante parecida com a de portabilidade.
Cenrios de manuteno incluem modificaes em funcionalidade e os diagramas na viso
comportamental so usados como fonte de informao.
A avaliao realizada revelou novas solues para a arquitetura existente ser usada em um
novo produto operando em um PDA, alm de fornecer um feedback em como melhor as descries
do mtodo QADA para um maior suporte avaliao de qualidade.
Acredita-se que o estudo seja limitado pelo fato da avaliao ser somente qualitativa. Talvez
o processo de avaliao usando o mtodo QADA possa ser complementado com um conjunto de
mtricas relacionadas aos cenrios e aos componentes, dando subsdio para a realizao de vrios
estudos experimentais com relao a portabilidade e manuteno da arquitetura ao se desenvolver
um novo membro da LP.
Outra limitao, j que o trabalho foi realizado em uma LP, a necessidade de se avaliar
no somente a arquitetura de LP, mas tambm um subconjunto de todas as possveis arquiteturas
derivadas da LP para seus membros, o que no uma tarefa simples. Talvez o uso de cenrios possa
ajudar na avaliao de cada arquitetura do subconjunto de produtos da LP.

5.2.4 Estudo 05 - Influncia de Fatores Organizacionais em Qualidade de Arquitetura de LP

Identificao:
Influncia de Fatores Organizacionais em Qualidade de Arquitetura de LP
Proponente(s):
JAKTMAN, C. B. (University of Technology Sidney)
Referenciado Por:
Jaktman, C. B. 1998. The Influence of Organisational Factors on the Success and Quality of
a Product-line Architecture, Proceedings of the Software Engineering Conference, pp. 02-11.
Caractersticas e Limitaes:
Normalmente, as organizaes medem o sucesso de suas LP por meio das vendas de seus
produtos no mercado, ajudando a organizao a determinar a aceitao de seus produtos no
mercado. Porm, tais medidas na maioria das vezes no refletem a qualidade da LP e, em particular,
no refletem diretamente a qualidade da arquitetura de LP. A facilidade com que a arquitetura pode
evoluir um dos fatores que determinam a qualidade da LP.

30

Uma organizao precisa entender os fatores que afetam tanto o sucesso quanto a qualidade
da arquitetura para garantir a capacidade da LP de estar apta s oportunidades de negcio futuras de
maneira eficiente e efetiva de custo.
Uma arquitetura de LP pode ser afetada por vrios fatores durante a sua manuteno,
desenvolvimento e implantao. Os trs maiores fatores que podem influenciar a qualidade da
arquitetura de LP so:

o ambiente de negcio da LP;

o processo de software e as ferramentas usadas para criar e evoluir a arquitetura;

a estrutura, o gerenciamento, as prticas e o pessoal da organizao.

Contudo, os fatores organizacionais so to difceis de monitorar quanto os fatores

ambientais e de processo. Todos os aspectos de manuteno e evoluo da LP devem ser estudados
para se entender o efeito de um fator organizacional. Os fatores organizacionais podem influenciar
as mudanas em um cronograma de um projeto e este pode afetar a qualidade do cdigo
desenvolvido. Por exemplo, mudanas no prazo de entrega podem restringir o tempo disponvel
para teste.
Um grande problema em entender o impacto dos fatores organizacionais que estes no so
documentados em termos de como e quanto estes influenciam na qualidade de uma LP. Vrios
estudos de casos tm documentado os fatores organizacionais, porm estudos experimentais so
necessrios para relacionar os fatores organizacionais com processo de software e o ambiente de
negcio.
Dois estudos de caso foram realizados em empresas australianas de desenvolvimento de
software com o objetivo de mostrar como os fatores organizacionais afetam a qualidade e a
manutenibilidade de uma LP. Alm disso, apresentado como o impacto dos fatores
organizacionais variou com relao ao tamanho, ao estilo de gerenciamento e volatilidade da LP.
Os fatores organizacionais so estudados segundo 04 perspectivas:

a estrutura organizacional: a hierarquia e a estrutura das reas envolvidas com a

arquitetura de LP;

o domnio de negcio: reputao e presena de mercado da LP;

as prticas de gerenciamento: polticas e procedimentos na evoluo da LP;

as caractersticas do pessoal: perfil pessoal de quem d manuteno ao software

conhecimento do domnio, experincia com LP e preocupao com a qualidade da
arquitetura.

31

Essas perspectivas foram escolhidas, pois ajudam a entender a demanda do mercado, os

procedimentos para a evoluo, e como o pessoal trabalha na evoluo dos produtos.
Cada fator organizacional inclui propriedades que podem ter impacto direto em como a
manuteno realizada, o que pode influenciar na qualidade do cdigo. Estas propriedades e seus
objetivos so apresentados na Tabela 1.
Tabela 1: Fatores Organizacionais e seus Objetivos (JAKTMAN, 1998).

Os estudos de caso foram realizados em duas organizaes, sendo que o primeiro foi
realizado em 1997 durou 3 meses, pois no possua documentao da arquitetura de LP - em uma
empresa de telecomunicao e o segundo em 1998 (3 semanas de durao) em uma empresa de
telecomunicao multinacional. As empresas se diferenciaram pelo tamanho dos produtos e os
estilos de gerenciamento.
As tcnicas aplicadas para entender os fatores organizacionais foram: grfico
organizacional, diagrama de comunicao para o fluxo de informao entre a equipe de software e
32

gerenciamento e os entrevistados envolvidos com LP. A abordagem seguiu um ciclo de entrevistas,

documentao, feedback e reviso pela equipe de software e gerentes.
A Tabela 2 apresenta o perfil organizacional de cada empresa.
Tabela 2: Perfil Organizacional das Empresas (JAKTMAN, 1998).

Os dados capturados a respeito da localizao geogrfica do centro de desenvolvimento de

software e sua matriz em ambos os estudos de caso no afetaram a arquitetura.
Os resultados so apresentados na forma de tabelas de acordo com os fatores
organizacionais (JAKTMAN, 1998). Por exemplo, no primeiro estudo de caso, o fator
Caractersticas do Pessoal identificou que a mudana freqente do lder da equipe de software
resultou em: mudanas no projeto do software e decises tcnicas de implementao; mudanas nos
prazos e prioridades; falta de tempo para as atividades de qualidade de software, entre outros.
Assim, os fatores organizacionais que mais contribuem para a qualidade da arquitetura
identificados em ambos os estudos de caso foram:

experincia organizacional com o domnio permite um planejamento para as

mudanas de mercado;

baixa rotatividade de pessoal significa manter o conhecimento da LP, permitindo

mudanas no software melhor planejados e mais consistentes;

conscincia no entendimento da qualidade pelo gerente ajuda a planejar atividades

de melhoria de software.

Os fatores que mais contribuem com o sucesso da arquitetura em ambos os estudos de caso
foram:

abordagem dirigida ao cliente significa entender as mudanas futuras e novos

requisitos e planejar a evoluo do produto;

o tamanho da LP e a taxa de mudana podem ser uma indicao do sucesso da

arquitetura.

33

Acredita-se que a limitao do trabalho est na dificuldade de relacionar as habilidades do

pessoal (motivao e treinamento, por exemplo) com a qualidade dos produtos, uma vez que
difcil obter tais medidas.

5.2.5 Estudo 06 - Mtricas de Utilizao de Servios para Avaliao da Estrutura de Arquiteturas

de LP

Identificao:
Mtricas de Utilizao de Servios para Avaliao da Estrutura de Arquiteturas de LP
Proponente(s):
VAN DER HOEK, A. (Institute for Software Research University of California - USA)
DINCEL, E. e MEDVIDOVIC, N. (University of Southern California - USA)
Referenciado Por:
van der Hoek, A.; Dincel, E.; Medvidovic, N. 2003. Using Service Utilization Metrics to
Assess the Structure of Product Line Architectures, Proceedings of the 9th International Software
Metrics Symposium, pp. 298-308.
Caractersticas e Limitaes:
Este trabalho foca a avaliao de qualidade de arquitetura de LP por meio de mtricas para
medir o atributo de qualidade chamado structure soundness. A estrutura criada pelos componentes
forma a abstrao central na qual todas as outras informaes a respeito da arquitetura de LP se
baseiam.
Existem algumas mtricas como, por exemplo, fan-in/fan-out e complexidade ciclomtica,
mas so difceis de serem aplicadas diretamente em arquiteturas de LP. Isto se deve por causa de
duas caractersticas herdadas das arquiteturas de LP:

opcionalidade: mesmo que alguns componentes formem o ncleo da arquitetura e

estejam presentes em todos os membros da linha, outros componentes podem ou no
ser includos em um produto final, dependendo, por exemplo, da preferncia do
cliente;

variabilidade: existem variaes no ncleo da arquitetura de LP que capturam

alternativas lgicas como um conjunto de componentes dos quais somente um pode
ser selecionado para fazer parte de um produto final.

34

Apesar de estas caractersticas serem teoricamente simples por natureza, elas violam as
suposies crticas a respeito de mtricas de software, nas quais o sistema a ser medido
estruturado de forma fixa.
Baseado no conceito de utilizao de servio, que mede o percentual de servios fornecidos
ou requeridos de um componente, as mtricas propostas neste trabalho so capazes de identificar
potencias deficincias estruturais em arquiteturas de LP e guiar o arquiteto na avaliao de
diferentes solues para corrigir tais problemas. As mtricas no revelam se a arquitetura est boa
ou ruim, mas identificam problemas com base em valores relativos. Como exigem a interpretao
humana, as mtricas so informativas.
As mtricas so aplicadas a trs arquiteturas de LP: a primeira uma arquitetura obtida por
engenharia reversa de um curso da Universidade da Carolina do Sul; a segunda uma arquitetura
desenvolvida pelo grupo de estudo dos autores; e a terceira uma arquitetura real fornecida de um
estudo de caso de uma biblioteca.
As mtricas baseiam-se no conceito de servio, que inclui: mtodos pblicos ou funes,
estruturas de dados de acesso direto, e qualquer outro tipo de recurso com acesso pblico. O termo
servio utilizado para evitar a utilizao das mtricas em uma determinada ADL. Pelo contrrio,
fazer um mapeamento das construes das ADLs para o conceito de servio permite aplicar as
mtricas em qualquer ADL em que uma arquitetura de LP possa ser modelada.
Assim, as mtricas definidas so:

Provided Service Utilization (PSU): definida como

Required Service Utilization (RSU): definida como

Pactual o nmero de servios oferecidos por um componente X que usado por outro
componente da arquitetura e Ptotal o nmero total de servios oferecidos pelo componente X. Ractual
e Rtotal tem significado anlogo aos servios requeridos.
As mtricas RSU e PSU so dependentes de contexto. Um determinado componente pode
ter valores diferentes de PSU e RSU dependendo da configurao particular da arquitetura da qual
este faz parte. Por exemplo, considere a arquitetura da Figura 1a. O componente B fornece servios
ao componente A1 e requer servios do componente C1. Dos 3 servios fornecidos pelo
componente B, somente 1 utilizado pelo componente A1. Assim, PSUB 1/3. Devido ao
componente C1 oferecer somente 1 dos 3 servios requeridos pelo componente B, o RSUB = 1/3.
35

Tais valores so baixos se comparados aos valores da arquitetura da Figura 1b, que so PSUB = 1 e
RSUB = 2/3.

Figura 1: Exemplos de Arquiteturas (VAN DER HOEK; DINCEL; MEDVIDOVIC, 2003).

Apesar dos valores absolutos de PSU e RSU poderem indicar potenciais problemas
componente com RSU tendendo a 0 pode no funcionar bem na arquitetura; e componente com
PSU tendendo a 0 significa um monte de funcionalidades extras que no so usadas por outros
componentes - valores relativos so mais teis ainda na comparao de duas arquiteturas
relacionadas, mas diferentes. PSUB e RSUB, por exemplo, mostram que o componente B se encaixa
melhor na arquitetura da Figura 1b do que na arquitetura da Figura 1a.
Para determinar o papel de cada componente na arquitetura, os valores de PSU e RSU
devem ser calculados e analisados. Analisando os componentes da Figura 1, percebe-se que alguns
possuem um conjunto vazio de servios requeridos ou fornecidos.
As mtricas PSU e RSU esto relacionadas com o tamanho do componente. Valores altos
podem ser atingidos com componentes pequenos ou grandes, contanto que seus servios requeridos
e fornecidos sejam realmente usados.
Outro ponto importante a considerar a anlise da arquitetura como um todo em funo de
seus componentes e de suas mtricas PSU e RSU. Para tanto, as mtricas CPSU (Compound PSU) e
CRSU (Compound RSU) so definidas como segue:

36

Pactual, Ptotal, Ractual e Rtotal so definidos da mesma forma que em PSU e RSU, enquanto n o
nmero de componentes da arquitetura. Nos exemplos da Figura 1a e Figura 1b, os valores de
CPSU so, respectivamente 1/2 e 1, e os valores de CRSU so, respectivamente, 1/2 e 5/6.
As mtricas CPSU e CRSU so usadas para avaliar a coeso interna de uma arquitetura.
Valores prximos de 1 significa que a arquitetura auto-contida, arquiteturas completamente
funcionais. Valores baixos indicam uma arquitetura desbalanceada. Valor baixo de CPSU
combinado com valor alto de CRSU implica que a arquitetura mais ampla do que necessrio, ou
seja, os componentes fornecem mais servios do que realmente precisam para o funcionamento
correto do sistema. Valor alto de CPSU com valor baixo de CRSU indica que a arquitetura est
funcionalmente degradada, ou seja, so necessrios novos componentes.
Com relao a arquiteturas de LP, a opcionalidade deve ser vista de acordo com: o prprio
componente opcional; os outros componentes no-opcionais; e a arquitetura como um todo.
O clculo de PSU e RSU para um componente opcional s interessante se este fizer parte
do produto final, pois pode ser tratado como um componente no-funcional. Porm, quando o
componente includo, a anlise dos componentes no-funcionais deve ocorrer para cada
possibilidade de produtos finais. Por exemplo, a Figura 2 apresenta uma arquitetura com 2
componentes opcionais, D1 e D2. Assim, existem 4 possveis produtos finais:
1. componentes D1 e D2 no so includos na arquitetura final do produto;
2. somente o componente D1 includo na arquitetura final do produto;
3. somente o componente D2 includo na arquitetura final do produto;
4. ambos os componentes D1 e D2 so includos na arquitetura final do produto;

37

Figura 2: Exemplo de Arquitetura com Componentes Opcionais (VAN DER HOEK; DINCEL;
MEDVIDOVIC, 2003).
Dessa forma, os valores PSU e RSU para cada componente no-opcional devem ser
calculados para cada possibilidade de produto final. possvel, assim, analisar se a incluso de cada
componente e o impacto na arquitetura como um todo.
Com relao arquitetura de LP, a variabilidade deve ser vista na perspectiva: do
componente variante; de outros componentes; e da arquitetura como um todo.
A incluso de um componente variante representa um desafio no clculo de PSU e RSU dos
componentes no-variantes. A Figura 3 apresenta um exemplo de arquitetura com componentes
variantes. Da mesma forma, a anlise de PSU e RSU deve ser feita para cada possibilidade.
Para analisar o impacto da variabilidade em toda a arquitetura usado o valor mdio de
CPSU e CRSU. As mdias destas mtricas devem ser mantidas altas, indicando uma arquitetura
altamente coesa.
Uma limitao a falta de orientaes (guidelines) absolutas para saber se uma arquitetura
est estruturada de forma correta.

38

Figura 3: Arquitetura com Componentes Variantes (VAN DER HOEK; DINCEL; MEDVIDOVIC,
2003).

5.3 Estudos do Google Scholar

A extrao dos dados dos textos do Google Scholar resultou nos itens apresentados a seguir.

5.3.1 Estudo 07 - Prometheus: Uma Abordagem para a Modelagem de Qualidade em LP

Identificao:
Prometheus: Uma Abordagem para a Modelagem de Qualidade em LP
Proponente(s):
TRENDOWICZ, A. e PUNTER, T. (Fraunhofer Institute for Experimental Software
Engineering - Germany)
Referenciado Por:
Trendowicz, A; Punter, T. 2003. Quality Modeling for Software Product Lines, Proceedings
of the 7th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering.
Caractersticas e Limitaes:
39

O trabalho investiga qual o modelo existente que facilita alcanar a qualidade de LP em

termos de requisitos no-funcionais. Assim, trs requisitos para a modelagem de qualidade so
definidos:

flexibilidade: um modelo de qualidade deve ser flexvel, por causa da dependncia

de contexto da qualidade. Existem vrios contextos de qualidade:
o empresa: inclui as caractersticas da empresa em que o modelo usado. Um
modelo de qualidade deve ser aplicvel em diferentes empresas;
o projeto: combinas as caractersticas de um projeto em particular como o seu
domnio ou diferentes vises de qualidade, representadas pelos diferentes
stakeholders;
o processo: reflete as caractersticas de um processo de desenvolvimento de
software como sua estabilidade e disponibilidade para medir objetos em
diferentes fases do processo.

reusabilidade: modelos de qualidade devem permitir a reutilizao de experincias

de qualidade empacotadas em modelos de qualidade existentes em outros projetos.
Dependendo do nvel de similaridade dos projetos, o modelo permite a reutilizao
de dados de medidas, bem como as caractersticas de qualidade e suas relaes;

transparncia: um modelo de qualidade deve fornecer a descrio de como certas

caractersticas esto relacionadas a outras e como identificar sub-caractersticas. O
modelo deve permitir que o gerente de projeto intervenha para modific-lo se
necessrio.

Existem dois tipos de abordagem para modelar qualidade em LP:

fixed-model: fornece um conjunto fixo de qualidades tal que a identificao de

caractersticas especficas do cliente resulta em um subconjunto daquelas publicadas
no modelo. Para medir as caractersticas de qualidade, as caractersticas, medidas e
relaes associadas com o modelo fixo so usadas. O problema de modelos fixos
que estes so limitados a dados quantitativos e relacionados ao produto.

define-your-own-model: em contraste, as caractersticas no so definidas de forma

fixa, mas com a ajuda do cliente um consenso entre as caractersticas de qualidade
mais relevantes para um determinado sistema. Estas caractersticas so decompostas
em caractersticas mensurveis de qualidade e mtricas relacionadas. Este tipo de
modelo abrange tanto flexibilidade quanto transparncia.

Apesar da existncia de vrios modelos de qualidade como ISO 9126 e o modelo de McCall,
muitos deles dificilmente cobrem os requisitos de flexibilidade, reusabilidade e transparncia.
40

Assim, o modelo SQUID pode ser utilizado, porm GQM deve ser usado para melhorar a fase de
especificao do SQUID, assim como Bayesian Belief Nets pode ser usada para estimativas
qualitativas e quantitativas.
Prometheus uma abordagem de modelagem de qualidade e combina as caractersticas de
vrios modelos existentes com o objetivo de abranger os requisitos de flexibilidade, reusabilidade e
transparncia. A abordagem consiste de 3 fases:

especificao: um modelo de qualidade desenvolvido, conforme a Figura 1;

aplicao: o modelo aplicado para avaliar requisitos no-funcionais especficos;

empacotamento: coleta as experincias adquiridas durante a aplicao do modelo

para melhor-lo este e ser reutilizado em outros projetos.

Figura 1: Atividades da Fase de Especificao da Abordagem Prometheus (TRENDOWICZ;

PUNTER, 2003).
A fase de especificao consiste das seguintes atividades:

definio das metas de qualidade: o usurio do sistema especifica as metas de

qualidade com base em um template de metas de medio (Tabela 1);

especificao das caractersticas de qualidade: refinamento das metas de

qualidade em um conjunto de caractersticas e sub-caractersticas. Uma caracterstica
mensurvel quando possvel associar algum componente da LP e definir uma ou
mais mtricas. Entrevistas com quem tem conhecimento do domnio so realizadas;

especificao dos relacionamentos: a importncia relativa das caractersticas

determinado e contradies e redundncias entre eles so detectadas. Dois tipos de
relaes devem ser distinguidos:
41

o decomposio: especifica como as caractersticas de alto nvel podem ser

decompostas em sub-caractersticas mais detalhadas;
o influncia: define quais sub-caractersticas influenciam no valor de outras
caractersticas.

reviso do modelo: o modelo revisado com relao a implementao;

operacionalizao do modelo: consiste na quantificao do modelo. Apesar do

termo quantificao, as mtricas associadas s caractersticas podem ter carter
quantitativo. Para combinar relacionamentos quantitativos com qualitativos so
usadas Bayesian Belief Nets (BBN).

Tabela 1: Template de Metas de Medio (TRENDOWICZ; PUNTER, 2003).

Aps a reviso de vrios modelos de qualidade de software observa-se que nenhum deles
abrange os requisitos no-funcionais de flexibilidade, reusabilidade e transparncia para LP.
Com base nos modelos existentes, foi proposta a abordagem Prometheus para a modelagem
de qualidade em LP. A abordagem propcia s organizaes que desejam realizar avaliaes em
estgios iniciais do desenvolvimento de LP, mesmo no tendo dados anteriores.
A limitao est na falta de detalhes em como analisar os atributos no-funcionais. O
trabalho apresenta somente a abordagem de modo geral e as etapas da especificao, mas no entra
em detalhes de como realizar a avaliao usando a abordagem proposta.

42

5.3.2 Estudo 08 - O Modelo BAPO para Avaliao de LP

Identificao:
O Modelo BAPO para Avaliao de LP
Proponente(s):
VAN DER LINDEN, F. (Philips Medical Systems)
BOSCH, J. (University of Groningen)
KAMSTIES, E. (University of Duisburg-Essen)
KNSL, K. (Nokia Research Center)
OBBINK, H. (Philips Medical Systems)
Referenciado Por:
van der Linden, F.; Bosch,J.; Kamsties, E.; Knsl, K.; Obbink, H. 2004. Software Product
Family Evaluation, Proceedings of the 3rd International Conference on Software Product Lines, pp.
110-129.
Niemel, E.; Matinlassi, M.; Taulavouri, A. 2004. Practical Evaluation of Software Product
Family Architectures, Proceedings of the 3rd International Conference on Software Product Lines,
pp. 130-145.
Caractersticas e Limitaes:
Neste trabalho um framework de avaliao de LP apresentado, bem como um estudo de
caso.
Quatro interesses no desenvolvimento de software so identificados (BAPO), sendo eles:

Business: como se beneficiar de seus produtos;

Architecture: meios tcnicos de construir software;

Process: cargos, responsabilidades e relacionamentos no desenvolvimento de

software;

Organisation:

mapeamento

de

cargos

responsabilidades

da

estrutura

organizacional.
A Figura 1 apresenta o relacionamento de cada um dos interesses.
Cada organizao ter um nvel de avaliao diferente para cada interesse, uma vez que
estes so independentes.
Por meio do framework BAPO, a avaliao coleta e estrutura as caractersticas da unidade
de produo, diviso ou companhia de software. O propsito do modelo servir como um
benchmark efetivo de LP; apoiar a avaliao de LP em termos das unidades, divises ou
43

companhias de desenvolvimento de software; e apoiar a melhoria de LP, que envolve a avaliao e

melhorias de planos.

Figura 1: Interesses BAPO.

Assim, quatro dimenses de avaliao so desejveis: Business, Architecture, Process e
Organisation.
A dimenso de negcio (business) trata da habilidade de uma organizao em gerenciar,
predizer e estimar os custos e os benefcios do desenvolvimento. O custo depende da arquitetura e
da organizao escolhidas. A principal preocupao est na forma como a organizao pode
determinar o custo de uma LP.
Uma das questes a considerar na dimenso de negcio o escopo, ou seja, quais produtos
devem estar sujeitos LP baseado nas expectativas do mercado. No framework de avaliao, 4
aspectos so considerados, sendo eles: identidade, viso, objetivos e planejamento estratgico. Estes
aspectos so parcialmente dependentes uns dos outros.
Na dimenso de arquitetura (architecture) essencial detectar, projetar e modelar as
partes variveis e comuns da LP. Alguns aspectos so considerados na dimenso de arquitetura,
sendo eles: a prpria arquitetura, a qualidade dos produtos, os nveis de reutilizao, e o
gerenciamento de variabilidades.
A dimenso de processo (process) enfatiza os cargos, os produtos, e as responsabilidades e
relacionamentos do desenvolvimento de software. Nessa dimenso, CMMI utilizado para avaliar o
processo na abordagem BAPO.
A dimenso organizacional (organisational) trata a maneira com que a organizao est
apta a lidar com as relaes e responsabilidades complexas. Alguns aspectos influenciam a

44

avaliao da organizao, sendo eles: a distribuio geogrfica, a cultura, os cargos e

responsabilidades, e o ciclo de vida dos produtos.
Um estudo de caso apresentado para ilustrar a aplicao da abordagem BAPO em scanners
de ressonncia em tecidos humanos.
A abordagem BAPO apresenta melhorias com relao ao modelo de van der Linden et al.
(2004), uma vez que existem quatro grupos de interesse (BAPO). Uma organizao pode usar o
framework para saber se possui um perfil adequado ao tipo de produtos que desenvolve. No caso de
no possui o perfil adequado, o framework ajuda na escolha das aes a serem tomadas para a sua
adequao.
A limitao do trabalho a falta de detalhes na apresentao das dimenses e como
realmente avaliar cada uma delas. Falta uma descrio mais clara de cada fase da abordagem
BAPO, pois est descrito em muito alto nvel comparado com outras abordagens e modelos.

5.3.3 Estudo 09 - Avaliao Prtica de Arquiteturas de LP

Identificao:
Avaliao Prtica de Arquiteturas de LP
Proponente(s):
NIEMEL, E.; MATINLASSI, M.; TAULAVUORI, A. (VTT Technical Research Centre of
Finland)
Referenciado Por:
Niemel, E.; Matinlassi, M.; Taulavouri, A. 2004. Practical Evaluation of Software Product
Family Architectures, Proceedings of the 3rd International Conference on Software Product Lines,
pp. 130-145.
Caractersticas e Limitaes:
O trabalho investiga os interesses relacionados avaliao de arquiteturas de LP, e apresenta
um mtodo de avaliao que usa informaes empricas coletadas de empresas por meio de
entrevistas estruturais ao longo de revises de artefatos da arquitetura de LP.
Os critrios de avaliao de LP propostos por Niemel e Ihme (2003) representam os
elementos categorizados a serem investigados nas prticas de adoo de LP, bem como esto
baseados no conhecimento obtido de empresas por meio de um conjunto de entrevistas e do
desenvolvimento de vrias arquiteturas baseadas em componentes para sistemas embarcados.

45

A abordagem BAPO (BAN DER LINDEL et al. 2004) identifica as relaes lgicas entre
negcio e arquitetura, e arquitetura e processo. A abordagem FEF d suporte s quatro dimenses
de BAPO e sugere cinco nveis arquiteturais.
O mtodo FAE (Family Architecture Evaluation) foi desenvolvido para ser usado por
empresas e arquitetos de LP que desejam ter um benchmark de sua arquitetura de LP. Ele define
como usar as abordagens citadas na avaliao de arquitetura de LP.
O mtodo FAE inclui quatro passos:

Framework de Avaliao para Entrevistas: empresas que adotam LP nos mais

variados contextos so escolhidas para as entrevistas. As questes so avaliadas com
base nos critrios de avaliao de Niemel e Ihme (2003). O nmero de questes
limitado ao tempo de 3 horas. Os critrios so usados, pois o framework suporta a
classificao das questes em 3 categorias: negcio, domnio e tecnologia
relacionadas ao desenvolvimento e manuteno de arquiteturas de LP;

Reviso/Inspeo dos Artefatos da Arquitetura: entender o tipo de abordagem de

LP que a empresa adota. Se a arquitetura documentada e encontra-se atualizada,
descries arquiteturais fornecem a melhor fonte para a sua avaliao. Dependendo
do tamanho da arquitetura, a reviso/inspeo pode levar duas semanas;

Anlise dos Resultados: os resultados das entrevistas so coletados e reformulados

para um framework de comparao, que foi criado para reorganizar as questes do
framework de entrevistas de tal forma que eles vo de encontro aos aspectos da
dimenso de arquitetura da abordagem BAPO;

Framework de Avaliao para a Realizao de Benchmark: baseado no

framework de comparao e nos nveis e aspectos definidos na dimenso arquitetural
do framework de avaliao de arquitetura, um framework de avaliao foi construdo
(Tabela 1).

46

Tabela 1: Framework de Avaliao de Arquiteturas de LP (NIEMEL; MATINLASSI;

TAULAVUORI, 2004).

47

Trs estudos de caso so apresentados para a dimenso arquitetural de FEF. Alguns pontos
so considerados na realizao dos estudos de caso: o negcio das empresas entrevistadas, prcondies para a arquitetura de LP, o conhecimento do domnio e as variabilidades, e a ligao
entre arquitetura e o processo e a organizao.
Alguns pontos considerados na discusso a respeito dos resultados dos estudos de caso: o
tamanho das empresas, os cargos de negcio, e o tipo dos produtos. Duas empresas eram pequenas
e a outra era mdia. O tamanho da empresa mostrou-se ter grande influncia em como as relaes
da arquitetura para negcio, processo e organizao so gerenciadas. Assim, a abordagem FEF
categoriza as relaes entre arquitetura e as outras dimenses de acordo com o tamanho da empresa
(por exemplo, pequena, mdia, entre outros).

5.4 Anlise dos Resultados

Com base nos dados extrados foi possvel realizar uma anlise com relao aos estudos
selecionados considerando:

as mtricas estabelecidas no protocolo da reviso sistemtica;

a relao, por fonte, entre a quantidade de estudos primrios encontrados no processo

de busca e quantidade de estudos primrios da seleo preliminar;

a porcentagem, por fonte, entre a quantidade de estudos primrios encontrados e o

total de estudos primrios.

Com relao s mtricas definidas no protocolo de reviso sistemtica, estas foram medidas
e os seus valores so apresentados:

LP = Quantidade de estudos selecionados sobre qualidade/avaliao de LP como

um todo (incluindo arquitetura de LP) = 03

Arq = Quantidade de estudos selecionados somente sobre qualidade/avaliao de

arquitetura de LP = 06

A seguir so apresentados os valores de tais mtricas na forma de um grfico de pizza. O

grfico mostra que 67% dos textos analisados nesta reviso sistemtica esto focados na avaliao
de qualidade de arquitetura de LP. Acredita-se que isto se deva a trs fatores:

o primeiro por considerar a abordagem de LP relativamente recente aplicada ao

contexto de software;

48

o segundo pela arquitetura ser o artefato mais importante de uma LP, bem como a
sua avaliao implicar na avaliao do conjunto de todas as possveis arquiteturas de
produtos gerados a partir da LP;

o terceiro justificado pelo estado da arte, comprovado por esta reviso sistemtica.

Figura 7: Valores Obtidos para as Mtricas LP e Arq.

Por estas razes, acredita-se que a avaliao de arquiteturas de LP seja um tema ainda em
aberto e com a possibilidade de realizao de vrios trabalhos.
Outro ponto importante a ser analisado so as relaes entre as fontes de busca dos estudos
primrios e a quantidade de estudos encontrados e selecionados. A Tabela 1 apresenta os nmeros
relacionados s fontes e aos estudos primrios desta reviso sistemtica.
Tabela 1: Nmeros sobre os Estudos Primrios e as Fontes de Busca.
Estudos Primrios

Estudos Primrios

Porcentagem

Porcentagem

Encontrados

Selecionados

de Estudos

de Estudos

(Processo de Busca)

(Seleo Preliminar)

Selecionados

Encontrados

ACM

25

01

4%

29,8%

IEEE

49

05

10,2%

58,3%

10

03

30%

84

09

10,7%

Fonte

Google
Scholar

11,9%
100%

49

Com base na Tabela 1 possvel analisar algumas relaes. Uma delas a relao entre o
nmero de estudos primrios encontrados nas fontes, durante o processo de busca, e o nmero de
estudos primrios selecionados, durante o processo de seleo preliminar. O grfico da Figura 8
apresenta esta relao para cada fonte de busca.

Figura 8: Grfico da Relao entre Estudos Primrios Encontrados e Selecionados.

Na Figura 8 pode-se perceber que a fonte ACM resultou em 25 estudos durante o processo
de busca, porm somente 01 estudo foi selecionado para leitura completa, o que significa que
somente 4% dos estudos encontrados foram selecionados. A fonte IEEE resultou em 49 estudos
durante o processo de busca, mas somente 05 estudos foram selecionados, o que significa que
somente 10,2% dos estudos foram selecionados. Por ltimo percebe-se que a fonte Google Scholar
obteve a melhor porcentagem em termos de estudos selecionados, pois tal fonte resultou em 10
estudos, sendo que 03 foram selecionados (30%).
Outra relao interessante a quantidade total de estudos primrios encontrados e a
quantidade de estudos encontrados, para cada fonte de busca, ou seja, a porcentagem total de
estudos encontrados por cada fonte de busca. Nota-se no grfico que a fonte de busca que teve um
melhor aproveitamento em relao ao nmero de estudos encontrados foi a IEEE. Isto se deve ao
fato do amplo acervo eletrnico especializado na rea.
50

Figura 9: Porcentagem de Estudos Selecionados por Fonte de Busca.

Com relao aos estudos selecionados e lidos por completo possvel, a partir desta reviso
sistemtica, mostrar indcios de que atualmente o estado da arte em avaliao de qualidade de LP
concentra-se em modelos e abordagens de descrio de arquitetura de LP, bem como a identificao
de atributos de qualidade (portabilidade, manutenibilidade, flexibilidade, reusabilidade e
transparncia) e mtricas para a medio destes atributos. A grande dificuldade em avaliao de
arquitetura de LP a necessidade de abstrao de todo o conjunto de arquiteturas dos produtos
gerados por uma LP. Tal conjunto depende da composio das estruturas opcionais e variantes da
LP como os componentes, por exemplo.
O que se percebe que existem vrias abordagens com o propsito de avaliar qualidade em
LP, ilustradas com vrios estudos de caso, porm tais propostas ainda deixam a desejar com relao
sua aplicao prtica.
Abordagens propostas para a avaliao de LP como um todo fazem uso de padres de
qualidade de software j consolidados na literatura como, por exemplo, a utilizao da ISO 15498
combinada com a abordagem Goal-Question-Metric. Todas estas abordagens baseiam-se em
modelo de qualidade de propsito especfico ao contexto de LP. Algumas fazem uma adaptao de
modelos j existentes, enquanto outras abordagens propem seus prprios modelos. A escassez de
mtricas de LP evidente com base nos estudos analisados. Mtricas convencionais no podem ser
aplicadas na abordagem de LP, por causa da estrutura flexvel de suas arquiteturas. A opcionalidade
e a variabilidade tornam a avaliao de LP um desafio para a comunidade de engenharia de
software.

51

Um ponto interessante que nenhum trabalho analisado nesta reviso sistemtica abordou a
realizao de experimentos com vistas avaliao de LP, o que se acredita ser um ponto
fundamental na proposta e comprovao de novos modelos e abordagens como as apresentadas
neste trabalho.
Dessa forma, acredita-se que vrios trabalhos no sentido de avaliar LP e suas arquiteturas
podem ainda ser desenvolvidos, principalmente no que se refere realizao de estudos
experimentais para a avaliao de LP.

52

6. Consideraes Finais sobre a Reviso Sistemtica

A realizao desta reviso sistemtica mostrou algumas dificuldades com relao aos
mecanismos de buscas disponveis em cada uma das fontes de pesquisa.
O mecanismo da ACM, por exemplo, restrito quanto ao tamanho da string de busca. Para
contornar este problema necessrio quebrar a string de busca principal em vrias sub-strings. No
foi o caso desta reviso sistemtica, mas isso pode prejudicar a busca por estudos na biblioteca
digital da ACM.
Outro mecanismo que tambm apresentou alguma dificuldade foi o do Google Scholar, pois
este no permite a busca no resumo dos trabalhos. A busca pode ser feita ou no corpo todo do texto
ou pelo ttulo do trabalho. Isto ruim, pois o Google possui um acervo muito grande de estudos
cientficos, alm de indexar outras fontes de busca.
No caso particular desta reviso sistemtica, a fonte SpringerLink no aceitou a busca por
resumo, por causa de um erro interno no algoritmo de busca que rejeitou o termo su relativo ao
resumo dos estudos (do ingls summary).
Com relao s 03 fontes de busca utilizadas e no trabalho desenvolvido, acredita-se que a
fonte mais adequada para a realizao de uma reviso sistemtica seja a IEEE, levando em
considerao a qualidade dos artigos encontrados - peridicos e anais de eventos internacionais
muito bem conceituados - e a facilidade de uso do mecanismo de busca e de suas propriedades
como, por exemplo, a string de busca.
Acredita-se que a realizao desta reviso sistemtica possa apoiar a comunidade acadmica
que vem trabalhando para a melhoria continua da abordagem de LP, bem como a indstria que, por
meio de empresas comprometidas com os seus clientes e com a qualidade de seus produtos, adota
tais abordagens e contribuem com projetos reais e relatos sobre a adoo e desenvolvimento de LP.

53

Referncias

Biolchini, J.; Mian, P. G.; Natali, A. C. C.; Travassos, G. H. 2005. Systematic Reviews in Software
Engineering, Technical Report ES 679/05, 31 p.
Jaktman, C. B. 1998. The Influence of Organisational Factors on the Success and Quality of a
Product-line Architecture, Proceedings of the Software Engineering Conference, pp. 02-11.
Knodel, J.; John, I.; Dharmalingam, G.; Pinzger, M.; Arciniegas, A. L.; Riva, C. 2005. Asset
Recovery and their Incorporation into Product Lines, Proceedings of the 12th Workshop
Conference on Reverse Engineering, pp. 120-129.
Matinlassi, M. Evaluating the Portability and Maintainability of Software Product Family
Architecture: Terminal Software Case Study, Proceedings of the 4th Working IEEE/IFIP
Conference on Software Architecture, pp. 295-298.
Niemel, E., Ihme, T. 2001. Product Line Software Engineering of Embedded Systems. ACM
SIGSOFT Software Engineering Notes, Vol. 26, No 3 (May 2001). pp. 118-125.
Schmid, K. 2001a. An Assessment Approach to Analyzing Benefits and Risks of Product Lines,
Proceedings of the 25th International Computer Software and Applications Conference on
Invigorating Software Development, pp. 525-530.
Schmid, K. 2001b. A Framework for Product Line Quality Model Development: The PuLSE-Eco
Meta Quality Model, Technical Report No. 047.00/E, 41 p.
Trendowicz, A; Punter, T. 2003. Quality Modeling for Software Product Lines, Proceedings of the
7th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering.
van der Hoek, A.; Dincel, E.; Medvidovic, N. 2003. Using Service Utilization Metrics to Assess the
Structure of Product Line Architectures, Proceedings of the 9th International Software Metrics
Symposium, pp. 298-308.
van der Linden, F.; Bosch,J.; Kamsties, E.; Knsl, K.; Obbink, H. 2004. Software Product Family
Evaluation, Proceedings of the 3rd International Conference on Software Product Lines, pp. 110129.

54