Escolar Documentos
Profissional Documentos
Cultura Documentos
Por
Dissertação de Mestrado
RECIFE, SETEMBRO/2015
Universidade Federal de Pernambuco
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
RECIFE, SETEMBRO/2015
Catalogação na fonte
Bibliotecária Jane Souto Maior, CRB4-571
_______________________________________________
Prof. Hermano Perrelli de Moura
Centro de Informática / UFPE
_______________________________________________
Profa. Isabel Dillmann Nunes
Instituto Metrópole Digital / UFRN
_______________________________________________
Prof. Alexandre Marcos Lins de Vasconcelos
Centro de Informática / UFPE
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do
Centro de Informática da Universidade Federal de Pernambuco.
Agradecimentos
Agradeço a Deus por me guiar e dá forças para traçar essa jornada, mesmo
diante dos contratempos e dificuldades familiares que surgiram. Aos meus pais e
irmão, por todo apoio, amor e ensinamento de vida.
A minha esposa Vanessa, pela compreensão, por todo amor e carinho, por
sempre estar ao meu lado e por ter me proporcionado o prazer e felicidade de ser pai.
Hoje, sou mais feliz com a existência do meu filho Christopher e minha vontade de lutar
pela vida, por meus objetivos e por um futuro melhor é cada vez maior.
As amizades construídas durante o período em que morei em Recife e em
especial aos amigos do meu grupo de pesquisa, Aline Chagas, Bruno Nascimento e
Leandro Melo pela dedicação e auxílio prestado a esta pesquisa.
Agradeço especialmente ao professor Alexandre Vasconcelos pela orientação
dada, por toda confiança e compreensão durante a condução desta pesquisa.
Aos professores do programa da Pós-Graduação que tive o prazer de conhecer
e através deles adquirir novos conhecimentos durante as disciplinas cursadas. E aos
professores que formaram a banca, Hermano Perrelli de Moura e Isabel Dillmann
Nunes, por terem aceito o convite e pela contribuição dada na avaliação deste trabalho.
Por fim, à CAPES e ao Centro de Informática pela bolsa de estudos concedida
durante o curso.
Resumo
Contexto: a mudança faz parte da evolução e durante o ciclo de vida do
software a maior parte dos custos está associada a esta tarefa. Poder fazer previsões
sobre os potenciais efeitos causados através de uma mudança é uma forma de
minimizar esses custos. Neste contexto, surge então a Análise de Impacto (AI) para
medir o esforço que será necessário à mudança e para nortear como realizar a mesma
da maneira mais adequada, entretanto o resultado gerado pode ser insuficiente, pois é
possível existirem erros na identificação dos elementos possivelmente impactados, não
contemplando todos os problemas existentes.
Objetivo: este trabalho tem como objetivo investigar o que se tem feito para
permitir um resultado mais preciso na AI, gerando um catálogo de benefícios e
limitações e propondo um guia de boas práticas, respondendo as perguntas de
pesquisa – O que se sabe atualmente sobre os benefícios e limitações da AI em
mudança de software? O que se tem feito para minimizar os erros gerados na análise?
Método: para a condução da pesquisa fez-se necessário a busca de dados na
literatura, através de uma pesquisa exploratória, por meio de uma revisão sistemática
com o intuito de investigar as técnicas de AI relatadas em pesquisas dos últimos anos.
Resultados: de posse dos dados resultantes da extração e análise dos dados,
os resultados são: (1) evidências de técnicas existentes que conseguiram minimizar
imprecisões nos resultados da análise, (2) geração de catálogo de benefícios e
limitações em seu uso e ainda, um guia de propostas de boas práticas a serem
adotadas para permitir que a análise apresente melhores resultados.
Conclusão: os resultados fornecem uma melhor visão dos fatores que precisam
ser melhorados e, além disso, possibilitaram a criação de um guia de boas práticas.
Com isto, pretendemos contribuir fornecendo uma melhor compreensão sobre as
técnicas existentes, de que forma melhorias vêm sendo propostas e quais práticas
permitem a maximização dos resultados gerados através da análise de impacto.
AI Análise de Impacto
AIS Actual Impact Set
ASCM Architectural Software Components Model
CCGImpact Control Call Graph Impact
CIASYS Change Impact Analysis at System Level
CIGs Change Impact Graphs
CIN Centro de Informática
CIS Candidate Impact Set
CISE Change Impact Size Estimation
DiSE Direct Incremental Symbolic Execution
EIS Estimated Impact Set
FCA Formal Concept Analysis
FNIS False Negative Impact Set
FPIS False Positive Impact Set
HSMImpact Hierarchical Slicing Model
LoCMD Lattice of Class and Method Dependence
OOCMDG Object Oriented Class and Member Dependence Graph
RSL Revisão Sistemática da Literatura
SAMCIS Software Assessment Method based Change Impact Simulation
SEA Static Execution After
SIS Starting Impact Set
UFPE Universidade Federal de Pernambuco
SUMÁRIO
1. INTRODUÇÃO ................................................................................................................................12
1.1 DEFINIÇÃO DO PROBLEMA ........................................................................................ 13
1.2 MOTIVAÇÃO ............................................................................................................ 13
1.3 QUESTÃO DE PESQUISA ........................................................................................... 14
1.4 OBJETIVO GERAL .................................................................................................... 14
1.4.1 Objetivos Específicos........................................................................................ 14
1.5 CONTEXTO .............................................................................................................. 14
1.6 CONTRIBUIÇÕES E RESULTADOS ESPERADOS ............................................................ 14
1.7 ESTRUTURA DO TRABALHO ....................................................................................... 15
2. REVISÃO DA LITERATURA ....................................................................................................16
2.1 REFERENCIAL TEÓRICO ............................................................................................ 16
2.1.1 Análise de Impacto ........................................................................................... 16
2.1.2 Classes da Análise de Impacto: Dependência x Rastreabilidade ..................... 19
2.1.3 Abordagens: Estática, Dinâmica e Híbrida ....................................................... 20
2.2 TRABALHOS RELACIONADOS ..................................................................................... 22
2.2.1 Change Impact Analysis for the Software Development Phase: State-of-the-art
(Nazri Kama, 2013) ....................................................................................................... 22
2.2.2 The Hybrid Technique for Object-Oriented Software Change Impact Analysis
(Mirna Maia, 2010) ........................................................................................................ 23
2.2.3 On the Precision and Accuracy of Impact Analysis Techniques (Lile Hattori,
2008) 24
2.3 RELAÇÃO DESTA PESQUISA COM OS TRABALHOS RELACIONADOS ................................. 25
2.4 CONSIDERAÇÕES FINAIS DO CAPÍTULO ....................................................................... 26
3. METODOLOGIA DA PESQUISA ............................................................................................27
3.1 CLASSIFICAÇÃO DA PESQUISA .................................................................................. 27
3.2 CICLO DA PESQUISA ................................................................................................ 29
3.3 REVISÃO SISTEMÁTICA DA LITERATURA ..................................................................... 30
3.4 CONSIDERAÇÕES FINAIS DO CAPÍTULO ....................................................................... 33
4. RESULTADOS ................................................................................................................................34
4.1 RESULTADOS DA BUSCA E SELEÇÃO DOS ESTUDOS ................................................... 34
4.2 MAPEAMENTO DAS EVIDÊNCIAS ................................................................................ 39
4.3 DISCUSSÃO DOS RESULTADOS ................................................................................. 59
5. CONSIDERAÇÕES FINAIS .......................................................................................................71
5.1 LIMITAÇÕES E AMEAÇAS À VALIDADE ......................................................................... 74
5.2 IMPLICAÇÕES PARA A PESQUISA E PRÁTICA ............................................................... 75
5.3 RECOMENDAÇÕES PARA TRABALHOS FUTUROS ......................................................... 75
5.4 CONCLUSÕES .......................................................................................................... 76
REFERÊNCIAS ............................................................................................................................................77
APÊNDICE A – PROTOCOLO DA REVISÃO SISTEMÁTICA.................................................81
APÊNDICE B – RESULTADO DA AVALIAÇÃO DA QUALIDADE DOS ESTUDOS
PRIMÁRIOS ...................................................................................................................................................98
APÊNDICE C – DADOS DE CONTEXTO .......................................................................................100
APÊNDICE D – EVIDÊNCIAS DAS MELHORIAS ENCONTRADAS NOS ESTUDOS108
12
1. INTRODUÇÃO
Durante o ciclo de vida do software, mudanças ocorrem para atender a demanda
de atualizações ou até mesmo correções de bugs de acordo com as necessidades do
cliente. Mudar não é uma tarefa tão simples, uma vez que acarreta um aumento no
esforço e consequentemente no custo associado ao produto. As atividades
relacionadas à implementação de mudanças são caras e consomem mais de 50% do
custo total do projeto (ERLIKH, 2000). Em alguns contextos, como em sistemas
orientados a objetos, esse custo pode aumentar ainda mais devido à presença de
características especiais, como a complexidade das relações entre as entidades, que
afetam a forma de propagação dos efeitos das mudanças pelo sistema (LEE, 2000).
Conforme BOHNER (2002), uma mudança no código do sistema compreende: 1)
entender como a mudança afeta o software; 2) implementar a mudança proposta; e 3)
testar o sistema alterado. A análise de impacto é uma atividade de estimar o efeito,
seja antes, ou depois de fazer um conjunto de alterações em um sistema de software
(TURVER e BOHNER, 1993). De modo geral, existem duas classificações para o tipo
da técnica utilizada na análise de impacto: a estática e a dinâmica.
O problema em torno da análise de impacto está associado aos seus resultados,
isso porque, é possível errar na identificação dos elementos do sistema possivelmente
impactados. Sendo assim, a análise pode conter erros relacionados à presença de
entidades não impactadas (falso-positivos) ou a ausência de entidades impactadas
(falso-negativos), o que indica certa imprecisão. Além da imprecisão, outro problema
ligado à análise de impacto diz respeito à forma com que os resultados são
organizados. Quando o conjunto de impacto resultante é grande, a informação
construída pode acabar confundindo o engenheiro de software na realização da
análise.
Identificar e investigar as técnicas existentes permite ter uma visão do que vem
sendo estudado e até que ponto foi possível evoluir. A análise dos resultados
fornecidos através da utilização das técnicas existentes e a descoberta dos pontos
onde elas falham, permitirá a projeção de melhorias em busca de reduzir as
imprecisões.
A proposta desta pesquisa é fazer uma revisão na literatura referente à temática,
com o objetivo de conhecer a forma com que a análise de impacto é abordada, seus
benefícios e limitações, bem como identificar as melhorias já propostas, para o
provimento de um catálogo de benefícios e limitações de seu uso e um guia de boas
13
1.2 Motivação
De acordo com a definição do problema apresentado, a motivação para esta
pesquisa consiste em investigar como as técnicas de análise de impacto, com foco,
naquelas que apresentam uma abordagem para a fase de manutenção do software e
que tenham de alguma forma apresentado melhorias na obtenção de resultados mais
precisos. Essa investigação permitirá a geração de um guia de boas práticas, que
14
poderá ser adotado como uma forma de produzir novas técnicas, ou adaptar as já
existentes com o objetivo de maximizar os resultados produzidos através da análise.
1.5 Contexto
Esta pesquisa foi elaborada no seguinte contexto:
Condução de uma pesquisa secundária, através de uma revisão sistemática da
literatura (RSL) com objetivo geral de investigar características e como as técnicas
apresentam melhorias na análise de impacto em mudanças de software.
2. REVISÃO DA LITERATURA
Este capítulo apresenta o referencial teórico sobre análise de impacto em mudança
de software, extraído a partir de uma revisão não sistemática da literatura (adhoc) para
apoiar esta pesquisa e permitir uma melhor compreensão do estudo. Inicialmente são
abordados os conceitos básicos e a problemática a cerca do assunto, finalizando com o
apontamento de trabalhos relacionados e uma discussão de suas relações com esta
pesquisa. Este capítulo esta dividido nas seguintes seções:
Referencial teórico: apresenta os conceitos sobre a análise de impacto;
Trabalhos relacionados: apresenta os principais trabalhos relacionados a
esta pesquisa;
Considerações finais do capítulo: fecha o capítulo.
modo geral, o processo da análise de impacto pode ser definido em entrada (change
set), processamento (impact analysis) e saída (impact set) como apresentado por SUN
et al. (2013).
Nesta pesquisa, para ilustrar de melhor forma o processo da AI, foi utilizado o
desenho de LI et al. (2013) conforme apresentado a seguir na Figura 1.
que realmente não precisam ser modificados ou retrabalhados e a este conjunto dá-se
o nome de false positive impact set (FPIS), o que representa uma superestimava de
impactos da análise. Logo, existe uma relação entre os quatro conjuntos que envolvem
a análise, onde a soma dos elementos do EIS mais os do FNIS e a subtração dos
elementos FPIS deve resultar no AIS (AIS = EIS + FNIS - FPIS).
Normalmente, quando ocorre a mudança, outras entidades do sistema são
afetadas e a identificação dessas entidades é o principal objetivo da AI. Uma técnica de
AI eficiente deve identificar apenas as partes do sistema que são impactadas pela
mudança (BOHNER, 1996), entretanto, identificar o impacto causado pela mudança
não é uma tarefa trivial, isso porque, geralmente a análise é manual, os analistas
utilizam ferramentas inadequadas ou porque o conjunto de informações analisada é
muito grande. Além disso, na prática, a AI identifica entidades “possivelmente”
afetadas, ou seja, essas entidades não representam exclusivamente as entidades que
são afetadas. Sendo assim, dizemos que o resultado da análise apresenta falhas,
podendo apresentar erros por superestimar ou subestimar o impacto.
Quando o resultado apresenta entidades não impactadas, consideramos que
este possui falso-positivos. Por outro lado, quando não possui entidades impactadas,
consideramos que o resultado possui falso-negativos.
Análise estática
As técnicas estáticas analisam o código-fonte do software para identificar os
elementos possivelmente impactados por uma mudança. Elas mapeiam o sistema para
um conjunto de grafos, no qual os nós representam as entidades e as arestas são as
dependências entre as entidades. Esses grafos podem ser construídos em nível de
método ou em um nível mais detalhado, o de sentenças.
O resultado das técnicas estáticas é conhecido como conjunto de impacto
estático. Estudos mostram que o conjunto de impacto estático chega a atingir cerca de
90% do código do programa (ORSO, 2005; APIWATTANAPONG, 2007). Essa situação
acontece principalmente devido a análise estática considerar todos os comportamentos
do sistema, inclusive aqueles impossíveis de acontecer (ORSO, 2003). Por esse
motivo, podemos dizer que a maioria das técnicas de análise estática superestima o
impacto, incluindo elementos que não são afetados, ou seja, os falso-positivos.
Análise dinâmica
As técnicas dinâmicas analisam rastros de execução de programas para
identificar os elementos impactados por uma mudança. Há duas categorias de análise
dinâmica: online e offline. Elas se assemelham em relação aos dados coletados, à
forma de analisar os impactos de uma mudança e aos resultados encontrados. A
diferença é que a offline coleta os dados dos rastros para analisá-los após o fim da
execução, enquanto a online analisa os rastros durante a execução do programa
(BREECH, 2005).
O conjunto dinâmico de elementos impactados é definido como o subconjunto das
entidades do programa que é afetado por uma mudança durante, pelo menos, uma de
suas execuções (ORSO, 2005). A análise de impacto dinâmica computa,
22
positivos), o recall avalia os elementos não identificados, mas que são impactados
(falso-negativos).
A técnica proposta utiliza tanto a abordagem estática, quanto a dinâmica, é
empregada em softwares de código-fonte orientado a objetos e promove a melhoria na
estimativa de impacto em termos de recall. A realização da análise de impacto foi
dividia em três etapas: 1) a análise estática identifica dependências estruturais entre as
entidades do código; 2) a análise dinâmica identifica dependências com base em uma
relação de sucessão derivada de rastros da execução do código; e 3) os resultados de
ambas as análises são unidos e classificados de acordo com sua relevância, gerada
através de um fator de impacto.
Como resultado final, concluiu-se que a técnica híbrida conseguiu reduzir o
número de falsos-negativos e melhorou o recall entre 90 e 115% em comparação com
a técnica estática e, entre 21.2 e 39% em comparação a uma dinâmica. Em
contrapartida, a técnica estática mostrou-se melhor em relação aos falsos-positivos e
em precisão, já a técnica dinâmica apresentou os piores resultados.
3. METODOLOGIA DA PESQUISA
Este capítulo apresenta detalhadamente o método de pesquisa utilizado durante a
condução deste trabalho, com o intuito de aumentar a confiabilidade dos resultados
alcançados e permitir a replicabilidade desde estudo por outros pesquisadores.
De acordo com WAZLAWICK (2009), um método de pesquisa é definido como a
sequência de passos necessários para demonstrar que o objetivo da pesquisa proposto
foi alcançado, sendo assim, ao executar as etapas descritas no método serão obtidos
resultados, e esses devem ser convincentes.
Entretanto, de acordo com as recomendações de ESTERBOOK et al. (2008) é
necessário definir um posicionamento filosófico que permite a escolha do método de
pesquisa mais apropriado. Este posicionamento pode ser classificado em: positivista ou
pós-positivista, construtivista ou interpretativista, teoria crítica e pragmático ou eclético.
Nesta pesquisa, o posicionamento adotado foi o positivista, uma vez que, esse
pensamento afirma que todo conhecimento deve ser baseado na inferência lógica de
um conjunto básico de fatos observáveis.
Este capítulo está dividido nas seguintes seções:
Classificação da Pesquisa: apresenta a classificação da pesquisa de acordo
com os parâmetros definidos.
Ciclo da Pesquisa: nesta seção são apresentadas as fases para a condução
desta pesquisa.
Revisão Sistemática da Literatura: é apresentado o procedimento adotado
para coleta de dados e elaboração do protocolo de pesquisa.
O método de abordagem indutivo foi adotado por ser o que mais se enquadra
dentro das características desta pesquisa, uma vez que, a partir de dados particulares,
suficientemente constatados é inferida uma verdade geral ou universal, não contida nas
partes examinadas, ou seja, os argumentos indutivos têm o objetivo de levar a
conclusões com conteúdo mais amplo do que o das premissas nas quais se basearam
(LAKATOS e MARCONI, 2011).
Considerou-se como uma pesquisa exploratória, pois segundo GIL (2007) este tipo
de pesquisa objetiva obter maior familiaridade com o problema, tornando-o mais
explícito. Além disso, pode-se dizer que pesquisas assim definida tem como objetivo
principal o aprimoramento de ideias ou mesma a descoberta de intuições.
Para obtenção de maior conhecimento a cerca do tema proposto nesta
dissertação, foi conduzida uma revisão ad-hoc da literatura como forma de descrever
os conceitos e termos geralmente empregados sobre a análise de impacto.
O escopo desta pesquisa envolveu como técnica de pesquisa: a condução de
uma Revisão Sistemática da Literatura (RSL) com o objetivo de identificar, analisar e
interpretar as evidências empíricas da literatura (KITCHENHAM, 2007), no que se
29
refere aos benefícios e limitações da análise de impacto e sobre o que se tem feito
para minimizar os erros gerados com a análise, permitindo assim, a construção de um
catálogo que sumariza os benefícios e limitações de sua utilização e um guia com
práticas de sucesso adotadas.
Por fim, de acordo com a definição de Lakatos e Marconi (2008) sobre variáveis,
neste trabalho temos a análise de benefícios e limitações da análise de impacto e
propostas de melhoria de resultados como variáveis dependentes, que são afetadas
pelas variáveis independentes análise de impacto e mudança de software.
(1) Para a fase de concepção, foi realizada uma revisão ad-hoc da literatura com o
objetivo de entender o que está sendo pesquisado sobre análise de impacto em
mudanças de software. Foram utilizados artigos e livros como fontes de leitura. De
30
3 - Fontes de busca
Foram realizadas buscas automáticas nos principais engenhos, conforme
indicados por KITCHENHAM et al. (2007), ao total 4 engenhos, Scopus, Science Direct,
Compendex e IEEE.
5 - Avaliação da qualidade
Como resultado da fase anterior, foi gerada uma lista contendo apenas estudos
incluídos e estes nesse momento passaram por uma avaliação de qualidade, seguindo
critérios pré-estabelecidos para tanto. Os critérios aqui adotados foram baseados no
estudo de Dyba (2008), com o intuito de compreender as evidências que
respondessem as questões de pesquisa desta RSL.
Novamente os estudos foram divididos e avaliados por quatro grupos de
pesquisadores, adotando-se o mesmo procedimento da fase anterior para os conflitos.
4. RESULTADOS
Este capítulo apresenta os resultados obtidos na execução da Revisão
Sistemática da Literatura com o objetivo de responder as questões de pesquisa deste
trabalho, permitindo a construção de um catálogo de benefícios e limitações na
utilização da análise de impacto, bem como um guia de boas práticas, baseado em
casos que propuseram melhorias.
Fase 1 – Busca automática: nesta fase foi construída uma String genérica, tendo em
vista que em cada engenho existe uma sintaxe específica, onde esta string genérica
deve ser adaptada para correta captura dos estudos.
Com a String definida, a busca automática foi executada e resultou em 6.088
estudos, obtidos através de quatro engenhos de busca e distribuídos conforme
apresentado na Figura 5, sendo 2.004 do Compendex, 642 do IEEE, 395 do
ScienceDirect e 3.047 do Scopus. Todos esses estudos foram identificados com um
identificador ID e seus dados catalogados em uma planilha Excel™. Antes do início do
processo de seleção pela leitura do título e resumo, a planilha foi analisada para
detectar a existência de estudos replicados, o que permitiu a exclusão de 2.008
estudos, restando para a fase seguinte 4.080 estudos. Para armazenamento e
compartilhamento dos arquivos com os demais pesquisadores envolvidos nesta
pesquisa, foi criado uma base de dados e hospedada em um repositório online.
36
33%
50%
11%
6%
Fase 2 – Seleção dos estudos pelo título e resumo: nesta fase foi preciso fazer a
leitura apenas dos título e resumo para conhecer mais sobre o estudo e saber se ele
poderia ser considerado potencialmente relevante de acordo com os critérios
estabelecidos nesta pesquisa. Os pesquisadores foram orientados quanto aos
procedimentos e conceitos empregados nesta RSL antes de iniciar o trabalho.
Cada um dos 4.080 estudos foi analisado individualmente, mas obedecendo a
uma divisão em duplas para garantir que um mesmo estudo fosse avaliado por dois
pesquisadores. Após isso, as planilhas de seleção foram comparadas e os conflitos
foram discutidos em reunião de consenso pela dupla. Dessa forma, foram rejeitados
3.760 estudos por serem considerados irrelevantes, restando assim, 320 estudos
potencialmente relevantes.
estavam indisponíveis). Assim, foram enviados e-mails para os autores solicitando uma
cópia destes artigos inacessíveis e conseguimos obter resposta de 11 autores,
reduzindo este número para 28. Assim, dos 320 estudos iniciais, conseguimos analisar
292 e destes 211 foram considerados irrelevantes, restando 81 para a fase seguinte.
80
70 73 75
60 63,5 63
62
50
51 50,5
40 46
30
20 25,5
19
10
0
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10
Fase 5 – Análise e extração dos dados: esta fase foi realizada integralmente pelo
autor da pesquisa e revisada pelo orientador e constituiu em fornecer os dados
demográficos dos 50 estudos resultantes da fase anterior. Assim, na extração foram
retirados dos estudos os dados de contexto e publicação e as tabelas com estas
informações podem ser consultadas no APÊNDICE C.
Dentre os estudos desta fase, foi possível identificar 26 técnicas empregadas para
a análise de impacto, foram elas: Chianti, Control Call Graph Impact (CCGImpact),
ChAT, Field Data, Static Execution After (SEA), PathImpact, Object Oriented Class and
Member Dependence Graph (OOCMDG), Hierarchical Slicing Model (HSMImpact),
Direct Incremental Symbolic Execution (DiSE), iDiSE (extensão da DiSE), Formal
Concept Analysis (FCA), Architectural Software Components Model (ASCM), Software
Assessment Method based Change Impact Simulation (SAMCIS), Change Impact
Graphs (CIGs), Change Impact Analysis at System Level (CIASYS), UCM Impact
Analysis, WAVE-CIA, Jripples, Celadon, Iterative IA, Sieve, CollectEA, SD-Impala,
Lattice of Class and Method Dependence (LoCMD), EMFTrace e Change Impact Size
39
Estimation (CISE). Desses estudos, 72% foram conduzidos por pesquisa quantitativa,
16% qualitativa, 4% mista (qualitativa e quantitativa) e 8% não tinham uma definição. O
método de pesquisa predominante nos estudos foi de estudo de caso, 22 dos estudos
utilizaram tal método, 13 conduziram experimentos, em 3 foi feito um estudo empírico,
1 fez uma revisão, 1 aplicou questionários e também houve estudos em que não foi
possível identificar qual método de pesquisa foi empregado, pois não existia uma
definição explícita para isso, da mesma forma, em alguns estudos não existia uma
nomenclatura para a técnica de análise de impacto utilizada.
Para responder as questões da pesquisa, as evidências foram extraídas dos
estudos utilizando uma técnica de análise de síntese qualitativa, a síntese de linha de
argumento citada por KITCHENHAM et al. (2007). Esses dados permitiram a
construção do catálogo de benefícios e limitações do uso da análise de impacto e um
guia de boas práticas que estão sendo propostas e adotadas na busca da geração de
melhores resultados na análise.
Questão de Pesquisa 1
Para responder a esta pergunta foi preciso buscar nos estudos as evidências
que tratem das características da análise de impacto. Para melhor entendimento ela
será respondida de forma separada, uma parte apresentará os benefícios e a outra as
limitações.
Benefícios
As evidências apontam que o principal benefício fornecido pela análise de
impacto é o de permitir a identificação dos efeitos ocasionados pela mudança. Esses
efeitos podem ser identificados antes [S0671], depois [S0094] ou mesmo durante
40
ID Evidências
[S0031] determining the effects of source code modifications
[S0054] allow the maintenance responsible to know change consequences
[S0094] allows developers assessing the possible effects of a given source code
modification;
used to evaluate the effects of a change on a system after that change is
instantiated
[S0199] determining the potential effects (or impacts) on a software system resulting
from a program change
[S0259] determine the potential effect of a proposed software change on a subset or
the whole of a given program
[S0275] discover what other program points are affected by a change of a particular
program point
[S0478] essential technique to identify the unpredicted and potential effects caused by
software changes;
identify the ripple effects and prevent side effects of a proposed change
[S0484] aims at identifying software artefacts being affected by a change;
it provides the potential consequences of a change and estimates the set of
artefacts that must be modified to accomplish a change
[S0648] provides the guidance for change propagation, change effects traceability and
regression testing during and/or after change implementation
[S0668] determine the potential impact of rest system parts of a local modification,
41
which being hoped to support the plan of change, the decision making of
change and the forecast of change
[S0671] provides visibility into the potential effects of changes before the changes are
implemented
[S0827] change impact analysis techniques compute which parts of the program may
be impacted by the changes
[S0982] used to identify a change in flow of instructions (semantic differences),
structural changes (textual differences) and affected test cases due to change
in code
[S1093] CIA contains a collection of techniques for determining the effects on other
parts of the software for proposed changes
[S1152] provides the entities that are potentially affected by a proposed change in a
system and its documentation
[S1213] understanding the software helps to discover which parts of the system are
potentially affected by a change and where these ripples may occur
[S2283] Its purpose is to decide on the strategy for the change and to find all classes
that are going to be affected
[S2367] provides feedback on the semantic impact of a set of program changes
[S3251] identify work products that may be affected by a change, time required and
cost of the change with information on the objects that may be affected
[S3320] reduces the risk to deal with expensive and unpredictable changes
[S3338] can help the software project managers through the decisions to accept,
modify, defer, or even reject the change requests based on their predicted
consequences
ID Evidência
[S0094] Impact analysis information can be used when planning changes, making
changes, and tracking the effects of changes
[S0462] Before changes are made, we can employ CIA for program understanding,
change impact prediction and cost estimation;
After changes have been implemented in the original system, CIA can be
applied to trace ripple effects, select test cases, perform change propagation
and ripple effect analysis
[S0496] can be used for maintainers to make decision among various change
solutions
[S0608] With information on potentially affected software artifacts, effective planning
can be made on what action will be undertaken with respect to the change
[S0671] quantitative assessment can provide insight and understanding of the
system
ID Evidência
[S0054] allows to estimate change cost and to make a compromise between various
suggested changes
[S0106] can improve the accuracy of required resource estimates, allow more
accurate development schedules to be set
[S0178] estimating the parts of the software that can be affected if a proposed
software change is made
[S0433] estimating the potentially impacted entities of a system due to a proposed
change;
43
ID Evidência
[S0094] proactive approaches use impact analysis to predict the effects of a change
before it is implemented
[S0199] applying impact analysis before a change is made allows a software
engineer to determine what components may be affected by the change and
gauge the cost of the change
[S0355] predictive impact analysis can allow maintainers to work to a plan, rather
than simply deal with consequences
[S0608] If the estimation is conducted before making changes, the impact analysis
helps software developers to determine components of software to be
affected
A análise de impacto pode ser aplicada em diferentes contextos e para isso ela
utiliza diferentes fontes de informação para geração de resultado, como pode ser visto
nas evidências do estudo S0827:
change set can be computed based on a variety of program representations;
Computing changes based on source code is commonly used in practice
because it is efficient and automated;
The graphical representations of code encode additional information about
the program, e.g., control and data dependences, that is useful for computing
more precisely the impact of source code changes;
Techniques which use dynamic information have the potential to compute
more precise impact sets because they are based on actual program
execution paths
E para apoiar a análise, a utilização de uma ferramenta que automatize o
processo torna-se muito útil, tal fato é apontado pela evidência do estudo S1051:
a tool that is able to (partly) automate the process of impact analysis is very
useful in different phases of software development
Isso pode ser confirmado, ao imaginarmos uma análise realizada de forma
manual, ela depende da experiência e habilidade de quem a conduz, o que a torna
insegura.
Mesmo sabendo que uma análise pode ser feita de forma estática ou dinâmica,
há uma evidência que indica que o uso da abordagem dinâmica oferece melhor
benefício, conforme o estudo S3307:
Dynamic analysis results tend to be more practically useful (compared to
those of static analysis) since they better reflect how the system is actually
being used, and consequently do not have computed impacts derived from
impossible system behavior
Além disso, a análise apoia outra atividade, testes de software, conforme
apontado nas evidências presentes na Tabela 5. Assim, é possível determinar quais
testes precisarão ser executados novamente devido à mudança e orientar os esforços
necessários em testes de regressão, ignorando as partes que não são afetadas pela
mudança, além de apoiar também a tarefa de depuração. Nesse caso, os testes são
otimizados em termos de recursos e esforços despendidos.
45
ID Evidência
[S0031] analysis determines a subset of those tests associated with a program
which need to be rerun
[S0094] It allows identifying components that can be affected by a given change
and must therefore be tested again
[S0199] after a change is made, impact analysis can be used to guide regression
test efforts by reducing the test cases to be run to those cases that traverse
the change;
the dynamic impact analysis provides results that more accurately reflect
how a program is actually being used which can decrease the amount of
time a software engineer has to spend retesting different components
[S0275] safely reduce the necessary testing steps by taking into account the
changes and thus making the continually running regression tests more
effective
[S0536] determine which parts of a program to re-analyze and which parts can
safely be ignored because they are not impacted by the changes
[S0608] if the estimation is conducted after making changes, the impact analysis
guides software testers to run regression test efforts by reducing the set of
test cases to be run to those cases that traverse the change
[S0827] can be used to support a range of software maintenance tasks, including
regression testing, debugging and regression verification
[S1051] optimizing software testing especially in terms of resources and efforts;
useful to identify which test cases are required to be rerun in order to test
exactly those parts of the system that are influenced by the change
(selective testing)
[S2367] analysis can be used to determine the regression test drivers that are
affected by a set of changes
preditiva, evitam que falhas mais graves possam acontecer depois da implementação
das mudanças.
ID Evidência
[S1051] locating the potential bugs in the system;
analyzing the impact of a change to discover the potential bugs or errors
[S1152] Inconsistencies within the documentation or between documentation and
code can be avoided and ripple effects can be controlled. This results in
higher quality of the changed software system;
the system includes fewer faults and is more cohesive
[S3338] Predicting the change size of impacted classes is not only important for
change acceptance decisions, but also for preventing more dangerous
faults after implementing the changes
ID Evidência
[S0031] allowing programmers to experiment with different edits, observe the code
fragments that they affect, and use this information to determine which edit
to select and/or how to augment test suites;
reducing the amount of time and effort needed in running regression tests,
by determining that some tests are guaranteed not to be affected by a
given set of changes;
reducing the amount of time and effort spent in debugging, by determining
a safe approximation of the changes responsible for a given test's failure
47
Limitações
As limitações encontradas nas evidências foram classificadas em limitações
gerais, apresentadas de forma resumida abaixo:
Incapacidade de análise em diferentes fases do ciclo de desenvolvimento –
compreende a incapacidade de uma técnica oferecer suporte para a análise
em diferentes fases do software;
Dificuldade para descobrir o impacto – relacionada às dificuldades
encontradas para identificar o impacto gerado por uma mudança;
Imprecisão – corresponde a erros contidos no resultado da análise;
Conjunto de impacto grande – quando se torna difícil tratar um grande
número de dados, ou por ter dados em excesso, mas desnecessários;
Qualificação e experiência – indica problemas relacionados à falta de
conhecimento;
Superestima – quando o conjunto de impacto contem dados que não deveria
conter;
Subestima – quando o conjunto de impacto deixa de conter dados
importantes;
Grau de granularidade – corresponde à granularidade aplicada na análise.
Vale destacar ainda a existência de momentos em que essas limitações se
interligam, sendo complementares, onde a ocorrência de uma, consequentemente
acarreta a existência de outra. As evidências para cada limitação aqui definida são
apresentadas a seguir:
software e não servir para a fase de desenvolvimento, levando em conta que nesta, as
classes não estão completamente desenvolvidas. Da mesma forma, uma técnica pode
ser limitada ao tipo de artefato que ela analisa. A Tabela 8 apresenta as evidências
relacionadas a esta limitação.
ID Evidência
[S0031] intended for use during the earlier stages of software development, to give
developers immediate feedback on changes they make
[S0608] in the software development phases, where the software is still under
development, not all the classes are completely developed
[S1093] Different CIA techniques are often conducted based on different
representations according to specific situations
[S3321] most impact analysis approaches are not able to detect the possible side
effects of changes when different types of software artifacts are involved
ID Evidência
[S0054] change impacts are subtle and difficult to discover
[S0106] the complex relationships among classes make it difficult to anticipate and
identify the ripple effects of changes
[S0275] call graph only does not give sufficient information about the possible impact
sets
[S0484] in object-oriented programs, the relationships between classes make change
49
3) Imprecisão
A imprecisão é definida pelas falhas das técnicas na obtenção de um melhor
resultado. Isso se deve aos diferentes tipos de contexto em que as mudanças são
aplicadas, assim, alguns fatores podem influenciar o resultado, como o tipo de
mudança, o tamanho e o conteúdo da solicitação de mudança. Na Tabela 10 são
apresentadas as evidências para tal limitação.
ID Evidência
[S0199] transitive closure on call graphs might be inexpensive, but it can be highly
inaccurate;
dynamic slicing can produce impact sets of reasonable size, related to
specific execution profiles, but it does not guarantee safety
[S0275] the disadvantages of the dynamic approaches reside in the process and
storage of the execution traces and in the fact that the results depend on
how the traces can reflect the general behaviour of the given program;
50
the impact sets determined by the call graph only can hardly approximate the
real impact sets;
a complex computation like slicing, it is easier to make a mistake
[S0355] it can be highly inaccurate, identifying impact where none exists and failing
to identify impact where it does exist;
techniques for impact analysis may over- or underestimate change impact,
relative to a specific set of program behaviors as captured in a profile, a
specific execution, or a test suite;
predict impact relative to specific program executions or operational profiles,
which may be useful for many maintenance tasks, but it sacrifices safety in
the resulting impact assessment
[S0688] difficulty of measuring change impact is posed by the uncertainty and the
differences of type, size and content of change requirements
[S0827] techniques based on textual differences, however, are often sensitive to
formatting and syntactic changes that may not affect the way the program
executes;
computes change impact based strictly on differences in the source code
structure will have limited capabilities to reason about the impact of the
changes on the execution of the code;
[S1243] Analyzing change impacts with requirements traceability usually encounter
three main problems: (1) the traceability relations to be maintained are often
imprecise and out of date, (2) the establishment of traceability relations
among requirements and work products is not integrated with the
development process, and (3) the manual impact analysis is tedious and
time consuming
[S1306] compute a large set of potentially impacted elements with many false-
positives, which will waste resource in later analysis
[S3321] Most impact analysis approaches are further limited by the amount of
change types they support. They treat different types of changes equally and
assume that they result in the same consequences
ID Evidência
[S0199] static slicing can perform safe analysis, but may yield impact sets that are
too large to be used in practice
[S0275] the main disadvantage of the static slice is said to be the fact that it contains
almost the whole program, so the use of the static slice is not so effective
[S0355] by focusing on all possible program behaviors, it may return impact sets that
are too large, or too imprecise relative to the expected operational profile of
a system, to be useful for maintainers
[S0462] the impact sets they compute are very large and difficult for practical use
[S0496] Static CIA techniques take all possible behaviors and inputs into account,
thus are safe but at the cost of precision
[S3251] Commonly, the impact of change depends on the change volume, smaller
project will have less impact, and larger projects will have more
5) Qualificação e experiência
Há uma necessidade em compreender os efeitos de uma mudança para que as
estimativas sejam feitas de forma correta e para que não conduza a um aumento nos
custos e riscos da mudança. A falta de conhecimento pode introduzir erro, assim os
mantenedores do software precisam de mecanismos para analisar as mudanças e
saber como elas são propagadas em todo o sistema. É importante destacar também
que um trabalho realizado de forma totalmente manual torna a existência de erros mais
propícios. As evidências desta limitação estão presentes na Tabela 12.
52
ID Evidência
[S0106] without understanding their effects can lead to poor estimates of effort,
delays in release schedules, degraded software design, unreliable software
products, and the premature retirement of the system
[S0259] the qualifications and experience of the participants also affected the
composition of the impact sets
[S0484] can lead to poor effort estimation and delays in release schedules because
of their dire consequences, e.g., the introduction of bugs
[S0668] knowing little about the changes or change propagation is the most
significant reason which increased the cost and risk of the changes
[S1051] The experience and the skills of an expert are very important, but manual
work always includes potential mistakes
[S1152] even experienced software professionals predict incomplete sets of change
impacts
[S1213] Without complete comprehension of the change impact, it is likely that there
will be unwanted side effects
6) Superestima
A superestima também pode ser chamada de introdução de falso-positivos, isso
porque, ela ocorre quando o resultado da análise contém entidades que são
identificadas como impactadas, mas que de fato, não são. Esse erro é um dos
problemas presentes em técnicas de análise de impacto e comumente característico
das técnicas estáticas, já que elas analisam um conjunto grande de dados (quase todo
o programa). Na Tabela 13 são apresentadas as evidências relacionadas a
superestima na análise de impacto.
ID Evidência
[S0355] Overestimates force maintainers to spend additional, unneeded time
investigating potential impacts
[S0827] it may also mark code as impacted, when in fact, it is not
53
[S1093] Static CIA techniques often analyze the semantic dependencies of the
program (or its change history repositories), construct an intermediate
representation (e.g. call graph), and then conduct analysis based on these
representations. The impact sets they compute have too many false-
positives, as many of their elements are not really affected
[S1306] The resultant impact set often has many false-positives, with many of its
elements not really impacted
[S3224] Overestimating impact generates false-positives, which may confuse the
analyst because it contains unnecessary information
[S3307] forces the software maintainers to spend additional, unneeded time
investigating the impact set that contains unnecessary information
7) Subestima
Ao contrário da superestima, a subestima deixa de conter em seu resultado
entidades que de fato são impactadas por uma mudança e é definida como a presença
de falso-negativos. Isso ocorre comumente em técnicas dinâmicas, onde o conjunto de
impacto resultante tende a ser menor quando comparado à técnica estática. A Tabela
14 apresenta evidências desta limitação.
ID Evidência
[S0355] underestimates may cause maintainers to omit, in their investigations,
important potential impacts
[S1093] dynamic CIA techniques consider part of the inputs in practical use, and their
impact sets are more precise but the impact results may be incomplete.
Dynamic CIA techniques compute the impact set by relying on the analysis
of the information collected during the execution, such as execution traces
information, coverage information. The impact sets they compute often lack
some of the real impacted elements, i.e. the false-negatives
[S2267] change impact can be severely underestimated in real projects even when
such impact analysis is conducted by professional developers
[S3224] change impact analysis techniques that underestimate impact may cause
important financial losses from the point of view of an IT services company;
54
8) Grau de granularidade
Quanto mais baixo o grau de granularidade, melhores serão os resultados, já
que estaríamos analisando o sistema mais a fundo, a sua realidade.
Consequentemente, empregar uma baixa granularidade exigirá uma maior
complexidade de análise. A evidência identificada sobre tal limitação é apresentada na
Tabela 15.
ID Evidência
[S3307] analysis at a finer level of granularity would give a more accurate result but
attract more computational overhead
Além desses aspectos, existe uma evidência indicando que as soluções dadas
pelas técnicas de análise de impacto atuais falham em cumprir com as exigências da
indústria:
[S1051] - current solutions lack a whole-system view and give either precise
results with high computation costs or less precise results with fast algorithms.
For these reasons, they are not applicable to large industrial systems where both
scalability and precision are very important
Isso de certa forma limita sua aplicação, mas por outro lado, motiva mais
pesquisas, buscando atender suas necessidades de escalabilidade e precisão para
permitir que a análise seja empregada com sucesso.
55
Questão de Pesquisa 2
QP2: O que se tem feito para minimizar os erros gerados na análise (reduzir
imprecisões)?
BENEFÍCIOS
Identificação do impacto
totalidade;
determinar os componentes afetados;
descobrir que outras partes são afetadas dado um ponto
particular;
identificar efeitos imprevisíveis;
permite identificar os efeitos em cascata;
identificar efeitos colaterais;
identificar artefatos afetados;
identificar o que deve ser mudado;
orientar a propagação da mudança;
orientar a rastreabilidade;
determina as partes que precisam de uma reanálise.
Compreensão do programa
planejar mudanças;
fazer à mudança;
entender o programa;
apoio a tomada de decisão;
fornecimento de informações adicionais através de representação
gráfica.
Fazer estimativas
Fornecer previsão
Análise automática
Identificar erros
Melhorar a produtividade
LIMITAÇÕES
Incapacidade da análise em diferentes fases
Imprecisão
pode gerar resultados imprecisos;
o fechamento transitivo em gráficos de chamada pode ser
impreciso;
o corte dinâmico pode não garantir com segurança o fechamento
transitivo;
a abordagem dinâmica pode falhar no processo de
armazenamento dos rastros de execução;
o resultado da análise dinâmica depende de como os traços
coletados podem refletir no comportamento geral do sistema;
é mais fácil cometer um erro utilizando a complexidade do corte;
pode identificar impacto onde não existe (falso-positivos);
pode não identificar impacto onde existe (falso-negativos);
técnicas podem superestimar ou subestimar impacto;
a análise preditiva pode colocar em risco a avaliação do impacto
resultante;
técnicas baseadas na diferença textuais computam o impacto
baseado estritamente na estrutura do código-fonte e são sensíveis
a alteração de formatação;
a análise feita de forma manual é tediosa e demorada;
informações sobre a rastreabilidade podem ser imprecisas e/ou
desatualizadas;
abordagens são limitadas ao tipo de mudança que suportam.
Qualificação e experiência
Superestimar
Subestimar
Granularidade
Evidências de melhorias
Portanto, para obter detalhes é necessária a consulta aos estudos identificados nesta
revisão.
Dada as duas abordagens da aplicação da análise de impacto, estática e a
dinâmica, e conhecendo suas limitações, as evidências indicam propostas híbridas
como uma alternativa de melhoria, uma vez que, esta une os dados coletados de
ambas abordagens para gerar um resultado mais preciso. Mas também, existem
pesquisas buscando melhorar cada abordagem individualmente, acrescentando novos
tratamentos e/ou métodos para construção da análise.
Com base nas melhorias propostas, são apresentadas algumas orientações que
podem servir como um guia de boas práticas:
Identificar uma abordagem apropriada – a análise pode ser aplicada em
diferentes cenários (e granularidades) e utilizar artefatos diferentes para isso. Logo,
para cada caso há suas especificidades e não há uma técnica capaz de cobrir todos os
cenários possíveis (ex.: sistema estrutural, orientado a objetos, orientado a agentes,
etc.). A maioria das técnicas costuma analisar o código-fonte, mas existem outras que
analisam diagramas UML, por exemplo.
Assim, cabe uma análise do cenário em que será aplicada a análise de impacto
para determinar qual técnica dá suporte ao ambiente e poderá ser adotada.
A maior parte das técnicas levantadas nesta revisão oferece assistência para
sistemas orientados a objetos, como pode ser observado na Tabela 19 e isso indica
que encontraremos mais suporte na literatura para este tipo de ambiente. Assim
também pode-se dizer que possivelmente a aplicação da análise em outros ambientes
pode sofrer dificuldades por não ter dispor de tanto suporte.
Calcular o impacto da mudança com rigor – é necessário apoiar-se em
técnicas que ofereçam segurança no conjunto de dados obtidos através da análise,
para permitir a geração de estimativas mais precisas e reduzir assim o possível esforço
desnecessário e consequente custo associado a mudança.
Nesse caso, é necessário levar em conta que o resultado pode sofrer influência
de quem faz a análise e deve-se evitar a introdução de viés. Para isso, é preciso adotar
um padrão de rigor ao aplicar a análise de impacto, sendo atencioso e criterioso.
Fazer o uso de uma abordagem dinâmica – mesmo podendo apresentar falso-
negativos, a análise dinâmica gera resultados mais precisos, quando comparado à
análise estática. Logo, pode-se dizer que esta abordagem deve ser adotada
preferencialmente.
66
mas não teríamos mais detalhes sobre o que exatamente sofreria impacto em outro
método (mais alto nível).
Sendo assim, com a análise e emprego de granularidades diferentes, é possível
obter um melhor resultado. Cabe avaliar a possibilidade de trabalhar com
granularidades diferentes ao mesmo tempo ou adotar a que mais se adapte a
necessidade do negócio.
Buscar redução no número de falso-positivos – se a abordagem adotada
conseguir reduzir o número de falso-positivos consequentemente o tempo despendido
na análise será reduzido, uma vez que, não será necessário dedicar tempo extra na
análise, pois o resultado conterá um número menor de entidades falsamente
identificadas como impactadas pela mudança.
A exemplo, no estudo S1306 foi utilizada uma abordagem baseada no fenômeno
da propagação de ondas de água que conseguiu reduzir o número de falso-positivos.
Em uma outra abordagem exemplificada no estudo S0982, foi possível reduzir em 80%
do número de falso-positivos recorrentes.
Buscar redução no número de falso-negativos – se a abordagem utilizada
diminui o número de falso-negativos a análise torna-se mais precisa, por conter um
número maior de entidades de fato impactadas pela mudança.
Como exemplo, o estudo S1093, apresentou uma proposta para utilizar regras
de impacto, obtendo como resultado um conjunto potencial e final de impacto com
redução de muitos falso-negativos.
Analisando o negócio, é possível dizer que é melhor reduzir o número de falso-
negativos do que o de falso-positivos, pois é melhor e mais fácil trabalhar com as
entidades que de fato são impactadas por uma mudança, do que despender tempo e
esforço em analisar entidades que foram identificadas como impactadas, mas que não
causam nenhum impacto ao software.
Utilizar as informações disponíveis para complementar a análise – o
resultado da análise normalmente é gerado pela avaliação de um único artefato de
software, mas isso não significa uma limitação. Outras fontes de informação podem ser
analisadas para avaliar seu uso como uma forma de construir ou complementar a
análise.
Como por exemplo, encontrado no estudo S0484, que além da técnica de
análise de impacto, aplicou o conceito da sismologia para analisar a propagação da
mudança, identificando como a mudança (epicentro) impacta no resto do programa.
68
Com o intuito de fazer uma prévia e simples avaliação sobre o guia de boas
práticas, foi elaborado um questionário para analisar os pontos abordados deste guia.
Ao total, foram indicadas 9 práticas como medidas positivas a serem adotadas para
que seja alcançado resultados mais precisos com a aplicação da análise de impacto.
A ideia desta avaliação é verificar se essas práticas levantadas, fundamentadas
de acordo com o que a literatura aponta são compatíveis com o entendimento de
especialistas, sendo assim considerados, aqueles que já tenham empregado alguma
técnica na prática, que tenham experiência sobre e/ou vivência em sua rotina.
Assim, foram criadas 12 questões, onde as 3 iniciais estão interessadas em
coletar dados sobre a experiência dos entrevistados e as demais relacionadas a cada
uma das práticas levantadas e essas são apresentadas a seguir.
a) Fazer a análise manualmente, pois não haverá risco de erros e não será
consumido muito tempo de trabalho
b) Não fazer a análise de forma manual
c) Apoiar-se com o uso de ferramentas, como plug-ins que automatizem o
processo
d) As alternativas b e c estão corretas
9) A granularidade aplicada pode afetar a análise de impacto, uma vez que:
a) Quanto mais baixo nível, mas complexa será a análise
b) Quando a análise é aplicada em baixo nível, os resultados são mais precisos
c) Analisar e empregar a análise em diferentes níveis de granularidade é uma
prática em busca da obtenção de melhores resultados
d) Todas as alternativas anteriores estão corretas
10) Reduzir o tempo despendido na análise de impacto é um benefício ligado a redução
de:
a) Falso-positivos, pois o conjunto de impacto a ser analisado será menor
b) Falso-positivos, pois o conjunto de impacto a ser analisado é menos complexo
c) Falso-negativos, pois o conjunto a ser analisado não é impactado pela mudança
d) Falso-negativos, pois o conjunto de impacto a ser analisado torna-se nulo
11) Reduzir o número de falso-negativos é um benefício que permite:
a) Dificultar a análise de impacto
b) Tornar a análise mais fácil
c) Consequentemente diminuir o número de falso-positivos
d) Tornar a análise de impacto mais precisa, pois o conjunto final de impacto terá
um número maior de entidades que de fato são impactadas pela mudança
12) Para que uma análise possa apresentar melhores resultados, é possível utilizar
outros artefatos durante a análise que complementem e ou melhorem o resultado?
Responda de acordo com suas experiências vividas.
a) Sim, já cheguei a analisar código-fonte e diagramas UML
b) Sim, mas há necessidade de verificar como fazer e se surtirá efeito positivo
c) Não, pois a técnica impõe suas especificidades
d) Não, pois para a análise de impacto apenas um único artefato deve ser utilizado
que mais possuem experiência (A e C), logo existe a necessidade de fazer essa
verificação para empregar a técnica que mais se adapte ao tipo de ambiente.
Em relação a calcular o impacto com rigor, a resposta que prevaleceu foi a (b)
que fala do comportamento a ser adotado, sabendo que a experiência pode afetar o
resultado, é agir com rigor e criteriosidade ao estimar para evitar a introdução de viés.
Neste ponto houve concordância de resposta entre o entrevistado mais experiente (A)
e o menos experiente (C).
A indicação em dar preferência na utilização de uma abordagem dinâmica, ao
invés de uma estática, foi mais respondida conforme a alternativa (b) da questão 6 e,
de fato, com a redução do número de falso-negativos é possível trabalhar com um
conjunto de elementos que realmente são impactados pela mudança no software,
sendo esta a melhor alternativa para o negócio.
Na questão 7, ao tratar da combinação de abordagem todos os entrevistados
compartilharam da mesma opinião, que o uso de uma abordagem híbrida pode resultar
numa melhoria significativa na redução de imprecisões (b).
Ao tratar do uso de uma ferramenta que apoie a análise de impacto, todos os
entrevistados também concordam que o seu uso automatiza o processo (c), assim,
consequentemente é possível reduzir a introdução de erros humanos e por outro lado
uma redução no tempo consumido para execução da análise, uma vez que, o trabalho
manual exigiria muito mais tempo, atenção e certamente mais experiência.
Ainda compartilhando do mesmo pensamento, os entrevistados, no que diz
respeito ao emprego de diferentes granularidades, responderam que todas as
alternativas dadas estão corretas (d), isso porque, se a análise é feita em um baixo
nível de granularidade, consequentemente o resultado será mais preciso, mas por
outro lado será feita de forma mais complexa. Da mesma forma, aplicar a análise em
diferentes granularidades pode ser uma alternativa na busca da obtenção de resultados
mais precisos.
Na questão 10, que trata da redução de tempo despendido na análise como um
benefício da redução de falso-positivos, apenas o um entrevistado (C) discordou desta
afirmação. De fato, ao reduzir o número de falso-positivos ganha-se tempo na análise,
pois o conjunto de informação a ser analisado será menor, uma vez que, será reduzida
a quantidade de informações desnecessárias (entidades falsamente identificadas como
impactadas, mas que não causam impacto).
73
5. CONSIDERAÇÕES FINAIS
Neste capítulo serão descritas as limitações e ameaças à validade desta pesquisa,
implicações para a pesquisa e prática, recomendações trabalhos futuros e algumas
conclusões sobre este trabalho.
extração de dados foi realizada por um único pesquisador, o autor desta dissertação e
auxiliado pelo orientador deste trabalho.
Investigar o que ainda precisa ser feito para que as técnicas de análise de
impacto apresentem resultados mais precisos (próximo do real) e assim, avaliar
se é possível ou será possível criar uma técnica que não apresente falhas.
5.4 Conclusões
Esta pesquisa teve o objetivo de investigar características da análise de impacto
que permitissem a construção de um catálogo contendo os benefícios e limitações do
seu uso/aplicação, bem como identificar entre várias técnicas, quais melhorias foram
propostas e permitiram a geração de resultados mais precisos. Para isso, conduziu-se
uma revisão sistemática como fonte de dados.
Foi possível identificar algumas outras características através da síntese da
revisão, como por exemplo, a maior parte das pesquisas existentes em análise de
impacto foram conduzidas utilizando como método de pesquisa estudo de casos, mas
os pesquisadores também utilizaram experimento. Isso nos levar a crer, que a
realização de estudos de caso pode ser uma boa prática para avaliar fatores de
sucesso na aplicação da análise de impacto.
O catálogo de benefícios e limitações permitiu termos uma visão mais ampla
sobre a empregabilidade da análise de impacto e através do guia de boas práticas
podemos ter um roteiro de indicações para a obtenção de bons resultados na análise.
Embora ainda, seja preciso investigar a possibilidade de unir tais sugestões na
construção de novas técnicas, buscando sempre o resultado ótimo, sem ou quase sem
falhas.
77
REFERÊNCIAS
ALI, Hassan Osman; ROZAN, Mohd Zaidi Abd; SHARIF, Abdullahi Mohamud.
Identifying challenges of change impact analysis for software projects. In:
Innovation Management and Technology Research (ICIMTR), 2012 International
Conference on. IEEE, 2012. p. 407-411.
GIL, A. C. Como elaborar projetos de pesquisa. 5. ed. - São Paulo: Atlas, 2010.
HUANG, Lulu; SONG, Yeong-Tae. Dynamic impact analysis using execution profile
tracing. In: Software Engineering Research, Management and Applications, 2006.
Fourth International Conference on. IEEE, 2006. p. 237-244.
HUANG, LULU AND SONG, YEONG-TAE. Precise dynamic impact analysis with
dependency analysis for object-oriented programs. In SERA ’07: Proceedings of the
5th ACIS International Conference on Software Engineering Research, Management &
Applications (SERA 2007), pages 374–384, Washington, DC, USA, 2007. IEEE
Computer Society.
KAMA, Nazri. Change impact analysis for the software development phase: State-
of-the-art. International Journal of Software Engineering And Its Application, v. 7, n. 2,
2013.
LIONS, J.L. ARIANE 5, Flight 501 Failure, Report by the Inquiry Board. European
Space Agency, July 1996.
SUN, X., LI, B., TAO, C., WEN, W., ZHANG, S. Change Impact Analysis Based on a
Taxonomy of Change Types. IEEE 34th Annual Computer Software and Applications
Conference, 2010.
80
SUN, X. et al. Analyzing impact rules of different change types to support change
impact analysis. International Journal of Software Engineering and Knowledge
Engineering, v. 23, n. 03, p. 259-288, 2013.
(Protocolo de Pesquisa)
2013
Equipe
83
1. INTRODUÇÃO
2. PROBLEMA
Uma técnica de análise de impacto eficiente deve identificar apenas as partes do
sistema que são impactadas pela mudança [19], entretanto a obtenção de uma solução
ótima não é uma tarefa trivial e ainda não foi alcançada devido à presença de erros nos
resultados, como apresentado por [1, 14, 15].
Desta forma, é necessário realizar uma investigação na literatura, para identificar o
que se sabe sobre os benefícios e limitações das técnicas de análise de impacto e as
possíveis melhorias já propostas.
3. OBJETIVO
4. PROTOCOLO
4.1 CONTEXTO
Uma revisão sistemática da literatura (RSL) é uma forma de identificar, avaliar e
interpretar todas as pesquisas disponíveis relevantes para uma questão de pesquisa
específica, área temática, ou fenômeno de interesse [11].
Existem várias razões para a utilização de uma RSL, entre elas, sumarizar
evidências acerca de determinado tema; identificar lacunas na área investigada ou
sugerir futuras pesquisas; fornecer um estrutura/background para direcionar
adequadamente as novas atividades de pesquisa. Assim, ela pode ser uma alternativa
na busca de evidências para identificar os benefícios e limitações sobre a análise de
impacto e as melhorias já propostas na busca de análises com resultados mais
precisos.
86
String de busca
(“software” OR “development” OR “project” OR “software development” OR
“development application” OR “information system development” OR “software
project” OR “software engineering” OR “software production”) AND (“change” OR
“maintenance” OR “modification” OR “alteration” OR “evolution”) AND (“impact
analysis” OR “static analysis” OR “dynamic analysis”)
Estratégia de busca
Busca automática
Fase 1
Fase 1:
A estratégia de busca nesta fase é realizada através da execução da busca
automática. A string de pesquisa é executada para obter os artigos relevantes para
esta revisão. Após obter a lista resultante da busca, os artigos serão identificados
através de um ID único em uma planilha Excel™ para que possa facilitar a
comunicação entre os pesquisadores. Além disso, esta lista deverá ser armazenada
em um repositório online e compartilhada por todos os pesquisadores.
Fase 2:
Esta fase será realizada por quatro pesquisadores sendo que, estes foram
divididos em duas duplas. A lista contendo todos os artigos capturados durante a busca
foi dividida em duas partes, ficando cada dupla responsável por avaliar uma parte.
Cada membro das duas duplas é responsável pela leitura do título e resumo de cada
estudo e deverá incluir ou excluir o artigo. Será formada uma lista de estudos incluídos
e excluídos por cada pesquisador de ambas duplas. As listas serão comparadas e os
conflitos serão discutidos entre os pesquisadores, se não chegarem a um consenso
90
Fase 3:
De posse da lista da fase 2 com os potenciais estudos primários, todos os
artigos deverão ser avaliados pelos quatro pesquisadores utilizando a mesma formação
em duas duplas e garantido que cada estudo seja analisado por dois pesquisadores,
mediante a aplicação dos critérios de inclusão e exclusão, através da leitura do título,
resumo, introdução, conclusão. Caso necessário, será realizada uma leitura completa
do estudo. Caso exista desacordo entre os pesquisadores sobre a inclusão ou exclusão
de um estudo nessa fase, será considerada a opinião de um terceiro para cada dupla,
sendo este um dos pesquisadores da outra dupla.
Fase 4:
Tendo como resultado da fase 3, somente a lista de artigos incluídos será
iniciada a avaliação da qualidade dos estudos e extração dos dados em que será
necessária a leitura completa dos estudos. Quanto à avaliação da qualidade, os
estudos serão avaliados pelas duplas, mediante a aplicação dos critérios contidos no
Formulário A (vide seção 4.9). Caso exista desacordo entre os pesquisadores sobre a
nota de qualidade atribuída a um critério, será considerada a opinião de um terceiro
pesquisador, da mesma forma que na fase anterior.
Considere o seguinte:
- Existe uma razão por que o estudo foi realizado?
- Objetivo é o foco do estudo ou o foco principal é a Análise de
Impacto em mudança de software?
- O estudo apresenta dados empíricos?
Quanto ao contexto
2 Existe uma descrição adequada do contexto em que a
pesquisa foi realizada?
Considere se o pesquisador identificou:
- A indústria em que os produtos são usados (por exemplo, bancos,
telecomunicações, bens de consumo, viagens, etc)
- A natureza da organização de desenvolvimento de software (por
exemplo, in-house ou departamento fornecedor independente de
software)
- As habilidades e a experiência do time de software (por exemplo,
com uma linguagem, um método, uma ferramenta, um domínio de
aplicação)
- Os tipo de produtos de software utilizados (por exemplo, uma
ferramenta de design, um compilador)
- Os processos de software que estão sendo usados (por exemplo,
processo padrão da empresa, os procedimentos de garantia de
qualidade, o processo de gerenciamento de configuração).
Quanto ao projeto de pesquisa
3 O projeto de pesquisa foi adequado para abordar os objetivos
da pesquisa?
Considere o seguinte:
- O pesquisador justificou o projeto de pesquisa (por exemplo, ele
discutiu como decidiu quais os métodos a utilizar)?
Quanto ao tipo de estudo
4 A abordagem de pesquisa está definida claramente?
Considere o seguinte:
- O pesquisador explicitou se o estudo é qualitativo, quantitativo, ou
misto?
Quanto à amostragem
5 A estratégia de pesquisa foi adequada aos objetivos da
pesquisa?
Considere o seguinte:
- O pesquisador explicou como os participantes ou casos foram
identificados e selecionados?
- Os casos são definidos e descritos com precisão?
- Os casos foram representantivos de uma população definida?
- Os pesquisadores explicaram por que os participantes ou casos
selecionados foram os mais adequados para permitir o acesso ao
tipo de conhecimento buscado pelo estudo?
- O tamanho da amostra foi suficientemente grande?
Quanto à coleta de dados
6 Os dados foram coletados de uma forma que abordou a
questão de pesquisa?
Considere o seguinte:
- Todas as medidas foram claramente definidas (por exemplo,
unidade e regras de contagem)?
- Está claro como os dados foram coletados (por exemplo,
entrevistas semiestruturadas, grupos focais, etc)?
92
Neutro (0.5): deve ser concedido no caso em que o trabalho não deixa claro se
atende ou não ao critério avaliado;
Atende (1): deve ser concedido no caso em que o trabalho apresente no texto
atendimento ao critério avaliado.
ID:
Descrição da evidência:
QP2: O que se tem feito para minimizar os erros gerados na análise (reduzir imprecisões)?
ID:
Descrição da evidência:
REFERÊNCIAS DO PROTOCOLO
[1] Alessandro Orso, Taweesup Apiwattanapong, and Mary Jean Harrold. Leveraging
field data for impact analysis and regression testing. In ESEC/FSE-11: Proceedings
of the 9th European software engineering conference held jointly with 11th ACM
SIGSOFT international symposium on Foundations of software engineering, pages
128–137, New York, NY, USA, 2003. ACM.
[4] CRUZES, Daniela S.; DYBÅ, Tore. Research synthesis in software engineering:
A tertiary study. Information and Software Technology, v. 53, n. 5, p. 440-455, 2011.
[6] EASTERBROOK, S. M.; et al. (2007). Selecting Empirical Methods for Software
Engineering Research. In F. Shull, J. Singer and D. Sjøberg (eds) Guide to Advanced
Empirical Software Engineering, Springer.
[7] GIL, A. C. Como elaborar projetos de pesquisa. 5. ed. - São Paulo: Atlas, 2010.
[8] J. Hassine, J. Rilling, J. Hewitt and R. Dssouli. Change Impact Analysis for
Requirement Evolution Using Use Case Maps. Proceeding of the 8th International
Workshop on Principles of Software Evolution, (2005) September 5, Washington, US.
[9] J. L. Lions. ARIANE 5, Flight 501 Failure, Report by the Inquiry Board. European
Space Agency, July 1996.
[12] Len Erlikh. Leveraging legacy system dollars for e-business. IT Professional,
2(3):17– 23, 2000.
[14] Lulu Huang and Yeong-Tae Song. Dynamic impact analysis using execution
profile tracing. SERA, 0:237–244, 2006.
[15] Lulu Huang and Yeong-Tae Song. Precise dynamic impact analysis with
dependency analysis for object-oriented programs. In SERA ’07: Proceedings of the
5th ACIS International Conference on Software Engineering Research, Management &
Applications (SERA 2007), pages 374–384, Washington, DC, USA, 2007. IEEE
Computer Society.
[16] Maia, Mirna C. Oliveira. Técnica Híbrida de Análise de Impacto para Sistemas
Orientados a Objetos. Master’s thesis, Universidade Federal de Campina Grande,
Campina Grande, Brasil, Agosto de 2009.
[17] R. J. Turver and M. Munro. An Early Impact Analysis Technique for Software
Maintenance. Journal of Software Maintenance: Research and Practice. vol. 6, no. 1,
(1993).
[19] S. Bohner and R. Arnold. Software Change Impact Analysis. IEEE Computer
society Press, Los Alamitos, CA, USA, 1996.
98
ID Ano Referência
Ren, X., et al. "Chianti: A tool for change impact analysis of java
programs". 19th Annual ACM Conference on Object-Oriented
S0031 2004 Programming, Systems, Languages, and Applications, OOPSLA'04,
2004. 432-448.
Abdi, M. K; Lounis, H. and Sahraoui, h. "Analyzing change impact
in object-oriented systems". 32nd Euromicro Conference on
S0054 2006 Software Engineering and Advanced Applications, SEAA, 2006.
310-317
Bradi, L; Bradi, M. and St-Yves, D. "Supporting predictive change
impact analysis: A control call graph based technique".
S0094 2005 Proceedings of Asia-Pacific Software Engineering Conference,
APSEC, 2005. 167-175.
Lee, M.; Jefferson Offutt, A. and Alexander, R. T. "Algorithmic
analysis of the impacts of changes to object-oriented software".
S0106 2000 Proceedings of 34th International Conference on Technology of
Object-Oriented Languages and Systems TOOLS 34, 2000. 61-70.
Sun XB, Li BX, Tao CQ, Wen WZ, Zhang S. "Change impact analysis
based on a taxonomy of change types". International Conference
S0462 2010 on Computer Software and Applications, Seoul, Korea, 2010. 373–
382.
Sun, X., Li, B., Li, B., Wen, W. "A comparative study of static cia
S0478 2012 techniques". In Proceedings of the Fourth Asia-Pacific Symposium
on Internetware, 2012
Hassaine, S., Boughanmi, F., Gu´eh´eneuc, Y.G., Hamel, S.,
S0484 2011 Antoniol, G. "A seismology-inspired approach to study change
propagation". In: ICSM (2011). 53-62.
Sun, X. et al. "HSM-based change impact analysis of object-
S0496 2011 oriented java programs". Chinese Journal of Electronics, Vol. 20,
No. 2, 2011. 247-251.
Rungta, N. ; Person, S. ; Branchaud, J. "A change impact analysis to
characterize evolving program behaviors". 28th IEEE International
S0536 2012 Conference on Software Maintenance (ICSM), 2012. 109-118.
Gethers, M., Kagdi, H., Dit, B., and Poshyvanyk, D., "An Adaptive
Approach to Impact Analysis from Change Requests to Source
S0776 2011 Code", In Proceedings of International Conference on Automated
Software Engineering, 2011
Person, S. and Rungta, N. "Maintaining the health of software
S0827 2013 monitors". Innovations in Systems and Software Engineering, Vol.
9, No 4, 2013. 257-269.
Bharti Chimdyalwar and Shrawan Kumar. "Effective false positive
S0982 2011 filtering for evolving software". In Proceedings of the 4th India
Software Engineering Conference, 2011.
G. Tóth, C. Nagy, J. Jász, Á. Beszédes, and L. Fülöp, “CIASYS –
change impact analysis at system level”. In Proceedings of the
S1051 2010 14th European Conference on Software Maintenance and
Reengineering (CSMR’10), 2010.
X. Sun, B. Li, W. Wen, and S. Zhang. "Analyzing impact rules of
different change types to support change impact analysis".
S1093 2013 International Journal of Software Engineering and Knowledge
Engineering, 2013. 259–288
A. von Knethen. “A Trace Model for System Requirements
S1152 2001 Changes on Embedded Systems”. International Workshop on
Principles of Software Evolution (IWPSE’ 01), 2001.
Hassine, J., Rilling, J., Hewitt, J. and Dssouli, R. "Change Impact
Analysis for Requirement Evolution using Use Case Maps". Proc. of
S1213 2005 the 8th Int. Workshop on Principles of Software Evolution, 2005.
81-90
W.-T. Lee, W.-Y. Deng, J. Lee, and S.-J. Lee, “Change Impact
S1243 2010 Analysis with a Goal-Driven Traceability-Based Approach”. Int. J. of
Intelligent Systems, Vol.25 , 2010. 878-908
Li, B. , Zhang, Q., Sun, X., Leung, H. "Using water wave
propagation phenomenon to study software change impact
S1306 2013 analysis". Advances in Engineering Software, Vol. 58, 2013. 45-53
S0054 Orientado a
Experimento Quantitativa Meta modelo Objetos Estática Dependência
CCGImpact
S0094 (Control Call Orientado a
Experimento Quantitativa Graph Impact) Objetos Estática Dependência
S0178 Orientado a
Experimento Quantitativa Field Data Objetos Dinâmica Dependência
S0199 Oerientado a
Experimento Quantitativa Objetos Dinâmica Dependência
S0259 Experimento Qualitativa Estática Dependência
Satatic
S0275 Execution Orientado a
Experimento Quantitativa After (SEA) Objetos Estática Dependência
S0355 Experimento
controlado Quantitativa PathImpact Dinâmica Dependência
OOCMDG
(Object
S0462 Oriented Class
and Member
Estudo de Dependence Orientado a
caso Quantitativa Graph) Objetos Estática Dependência
iDiSE (Uma
extensão para
S0536 DiSE - Direct
Incremental
Estudo de Symbolic
caso Quantitativa Execution) Procedural Híbrida Dependência
S0608 Revisão Qualitativa Híbrida Dependência
FCA (Formal
S0648 Estudo Concept Orientado a
empírico Qualitativa Analysis) Objetos Estática Dependência
ASCM
(Architectural
S0665 Software
Estudo de Components Orietado a
Caso Qualitativa Model) Objetos Dependência
SAMCIS
(Software
S0668 Assessment
Method based
Estudo de Change Impact Orientado a
caso Quantitativa Simulation) Objetos Estática Dependência
S0671 Quantitativa Estática Rastreabilidade
CIASYS
(Change
S1051 Impact
Estudo de Analysis at Orientado a
Caso System Level) Objetos Híbrida
OOCMDG
(Object
S1093 Oriented Class
and Member
Estudo de Dependence Orientado a
caso Quantitativa Graph) Objetos Estática Dependência
Um
experimento
S1152 controlado e Sistemas de
dois estudos Qualitativa e controle
de caso Quantitativa embarcados Estática Rastreabilidade
S1243 Orientado a
Objetos Estática Rastreabilidade
S1324 Estudo
empírico Quantitativa Híbrida Dependência
S2283 Orientado a
Qualitativa Jripples Objetos Estática Depêndencia
S2284 Orientado a
Quantitativa Celadon Aspectos Estática Dependência
S2294 Experimento Qualitativa Estática Dependência
S2295 Estudo de
caso Quantitativa Iterative IA Estática Dependência
S2344 Experimento Quantitativa Sieve Procedural Dinâmica Dependência
S2367 Orientado a
Experimento Qualitativa Objetos Estática Dependência
S3078 Estudo de
caso Quantitativa Estática Rastreabilidade
S3218 Estudo de
caso Quantitativa Estática Depêndencia
107
Estudo de
S3224 caso de
mútliplo Orientado a
casos Quantitativa SD-Impala Objetos Híbrida Depêndencia
S3320 Orientado a
Quantitativa Objetos
S3321 Estudo de
caso Quantitativa EMFTrace Estática Rastreabilidade
CISE (Change
S3338 Estudo de Impact Size Esática e Rastreabilidade
caso Quantitativa Estimation) Dinâmica e Depêndencia
Fonte: Próprio Autor (2015).
108
ID Evidência
[S0054] this model is one of the most general, and it allows impact calculation in a
systematic way. It is an important factor concerning effort and maintenance
cost reduction
[S2295] a variable granularity improves the precision of IA, saving the programmers
the extra work that is needed to inspect the false positives;
smaller, have fewer dependencies, and therefore the resulting inspected set
is smaller
[S0106] provides the ability to compile, analyze and view results within the same
environment
identify potential impacts before making a change, the risks of embarking on
a costly change can be greatly reduced by identifying problems early
provide visibility into the potential effects of changes before the changes are
implemented, and identify the consequences or ripple effects of proposed
software changes
[S2344] automatically detects functions in a newer version that are (un)affected by
the modifications made to an older version
examines the execution of two binaries on the same test input to yield the
affected functions in the newer version, along with the regions in these
functions where the change manifests
Experimental results on a number of open source programs shows that
Sieve reduces the size of the impact set
[S2283] The programmer starts impact analysis by identifying at least one class of
the impact set
Any imprecision that arises during the analysis process is immediately
corrected through the close interaction between the programmer and the tool
[S0433] approach uses a scenario-driven combination of information retrieval (IR),
dynamic analysis, and mining software repositories techniques (MSR)
integrate information from orthogonal sources to attain potentially more
accurate results
109
proposed changes into account to improve the precision of the impact results
inspired by a natural phenomenon ‘‘water wave propagation’’
can compute a more precise impact set with fewer false-positives at the cost
of missing a few false-negatives
[S0484] assume that change impact is most severe near the epicenter class, i.e.,
more the classes are near to the epicenter class more the impact is
important
uses structural and historical analysis with the specific aim to study the
scope of change propagation
changes did not propagate through different class levels with the same
proportion in each program
determining what levels might have been affected by certain changes, we
can help maintainers to rapidly pinpoint the source of a bug
maintainer needs to only examine the indicated levels in priority instead of
inspecting all the source code: our method is time saving
[S0688] applying the approach of simulated analysis to object-oriented software
change propagation
Ant is well-design, and it has a good quality to defense change propagation
resist the happening of broad ripple effect, enhance software quality and
reduce the maintenance cost
[S1152] facilitate estimating costs of a proposed change and implementing a change
by providing a precise set of change impacts
providing a fine-grained trace model for impact analysis
The trace model determines types of documentation entities and
relationships to be traced, in addition, the model includes constraints on
these relationships
[S1213] change impact analysis can be applied at the UCM requirement level, to
support an early analysis and localization of the system parts that are
affected by a requirement change
[S1243] goal-driven approach to managing requirements traceability and analyzing
change impacts by fusing the goal-driven and design structure matrix (DSM)
techniques
provide a visual way for project managers to organize project tasks, facilitate
team communication, and perform change impact analysis
112
estimating which parts of the original system may be affected by this change
proposal, evaluating to what degree the change proposal affecting original
system, and providing some maintenance guidance which can reduce the
maintenance cost
more accurate impact set with fewer false-negatives and false-positives to
predict the ripple effects induced by the change proposal
[S3321] combining impact analysis with the concept of multi-level modeling, to assist
with maintaining software through impact analysis of different UML models,
Java source code, and related JUnit tests
approach relies on change propagation rules, which analyze dependency
relations between software artifacts according to the type of change which is
applied upon them