dissertação de mestrado§ão... · dissertação de mestrado apresentada por joelson isidro da...
TRANSCRIPT
Pós-Graduação em Ciência da Computação
“ANÁLISE DE IMPACTO EM MUDANÇA DE
SOFTWARE: UM GUIA DE ORIENTAÇÃO”
Por
JOELSON ISIDRO DA SILVA ARAÚJO
Dissertação de Mestrado
Universidade Federal de Pernambuco
www.cin.ufpe.br/~posgraduacao
RECIFE, SETEMBRO/2015
Universidade Federal de Pernambuco
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
JOELSON ISIDRO DA SILVA ARAÚJO
“ANÁLISE DE IMPACTO EM MUDANÇA DE
SOFTWARE: UM GUIA DE ORIENTAÇÃO"
ORIENTADOR: Prof. Alexandre Marcos Lins de Vasconcelos
RECIFE, SETEMBRO/2015
Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571
A662a Araújo, Joelson Isidro da Silva Análise de impacto em mudança de software: um guia de
orientação / Joelson Isidro da Silva Araújo – Recife: O Autor, 2015.
115 f.: il., fig., tab., quadro. Orientador: Alexandre Marcos Lins de Vasconcelos. Dissertação (Mestrado) – Universidade Federal de
Pernambuco. CIn, Ciência da Computação, 2015. Inclui referências e apêndices.
1. Ciência da computação. 2. Engenharia de software. 3. Evolução de software. I. Vasconcelos, Alexandre Marcos Lins de (orientador). II. Título. 004 CDD (23. ed.) UFPE- MEI 2016-007
Dissertação de Mestrado apresentada por Joelson Isidro da Silva Araújo à Pós-
Graduação em Ciência da Computação do Centro de Informática da Universidade
Federal de Pernambuco, sob o título “ANÁLISE DE IMPACTO EM MUDANÇA DE
SOFTWARE: UM GUIA DE ORIENTAÇÃO” orientado pelo Prof. Alexandre Marcos
Lins de Vasconcelos e aprovada pela Banca Examinadora formada pelos
professores:
_______________________________________________ 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
Visto e permitida a impressão. Recife, 04 de setembro de 2015. ___________________________________________________ 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.
Palavras-chave: Análise de impacto, Impacto da mudança, Mudança de software,
Evolução de software.
Abstract
Context: Changing is part of the evolution and during the software lifecycle most cost is
associated with this task. Being able to make predictions about the potential effects
caused by a change is a way to minimize these costs. In this context, the Impact
Analisys (IA) can be used to measure the effort it will take to change and to guide how
to do the same in the most appropriate way, however the results generated may be
insufficient, it is possible to detect errors on the elements identification possibly
impacted, not including all the existing problems.
Objective: This study has the objetive to investigate what has been done to allow more
accurate result in IA , generating a catalog of benefits and limitations and proposing a
guide of good practice by answering the research questions - What is currently known
about the benefits and IA limitations on software changes? What has been done to
minimize errors generated in the analysis?
Methodology: To conduct this research it is necessary to search data in the literature,
through an exploratory research using a systematic review that will allow an
investigation about the most IA techniques used in the last years.
Results: With the data generated through the extration and analisys of data, the results
are: evidences of techniques which can be used to minimize inaccuracies in test results,
(2) generation of catalog of benefits and limitations in its use and also a good practice
guide to be adopted to allow the analysis present better results.
Conclusion: the expected results will provide a better view of the factors that need to
be improved and, besides, will enable the creation of a good practice guide. With this,
we intend to contribute by providing a better understanding of existing techniques, how
improvements have been proposed and what practices has been used to improve the
results generated by impact analysis.
Keywords: Impact analysis, Change impact, Software change, Software evolution.
Lista de Figuras
Figura 1: Processo da análise de impacto. .................................................................... 18 Figura 2: Classes da análise de impacto. ...................................................................... 20 Figura 3: Ciclo de desenvolvimento da pesquisa .......................................................... 29
Figura 4: Processo de seleção da revisão ..................................................................... 35 Figura 5: Distribuição percentual de captura por engenho de busca ............................. 36 Figura 6: Pontuação geral dos critérios de qualidade .................................................... 38 Figura 7: Respostas coletadas da entrevista aplicada. ................................................. 71
Lista de Quadros Quadro 1: Comparativo entre este estudo e os trabalhos relacionados ........................ 25
Quadro 2: Quadro metodológico da pesquisa ............................................................... 28
Lista de Tabelas
Tabela 1: Evidências relacionadas a identificação de efeitos de uma mudança. .......... 40 Tabela 2: Evidências relacionadas a compreensão do programa. ................................ 42
Tabela 3: Evidências relacionadas a construção de estimativas. .................................. 42 Tabela 4: Evidências relacionadas a previsão de efeitos. ............................................. 43 Tabela 5: Evidências relacionadas ao suporte a atividades de teste. ........................... 45 Tabela 6: Evidências relacionadas a identificação de erros. ......................................... 46 Tabela 7: Evidências relacionadas a produtividade. ...................................................... 46
Tabela 8: Evidências relacionadas a capacidade de análise em diferentes fases. ....... 48 Tabela 9: Evidências relacionadas a dificuldade para descobrir o impacto. .................. 48
Tabela 10: Evidências relacionadas a imprecisão. ........................................................ 49
Tabela 11: Evidências relacionadas ao conjunto de impacto. ....................................... 51 Tabela 12: Evidências relacionadas a qualificação e experiência. ................................ 52 Tabela 13: Evidências relacionadas a superestima. ...................................................... 52 Tabela 14: Evidências relacionadas a subestima. ......................................................... 53 Tabela 15: Evidência do grua de granularidade. ........................................................... 54
Tabela 16: Benefícios da análise de impacto. ............................................................... 60 Tabela 17: Limitações da análise de impacto. ............................................................... 62 Tabela 18: Lista de estudos incluídos na revisão. ....................................................... 100 Tabela 19: Dados de contexto dos estudos incluídos. ................................................ 104
Tabela 20: Evidências de melhorias em técnicas de análise de impacto. ................... 108
Lista de Abreviaturas e Siglas
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 práticas para orientar sua aplicação, buscando reduzir a geração de resultados
imprecisos.
1.1 Definição do Problema
O impacto da mudança em uma parte de um sistema pode ser caro e até mesmo
desastroso, isso porque, os softwares tornam-se cada vez maiores e mais complexos
(LIONS, 1996). A análise de impacto auxilia o planejamento de modificações, através
da previsão de efeitos e os custos associados (BOHNER, 1996).
A realização da atividade de análise de impacto requer diferentes abordagens e
implementações (HASSINE, 2005) para diferentes fases, tais como a de manutenção e
a do desenvolvimento de software, visto que, enquanto na fase de manutenção o
software está completamente desenvolvido, permitindo uma análise geral, na fase de
desenvolvimento a análise é feita apenas na parte desenvolvida.
Apesar de existirem diferentes abordagens para a aplicação da análise de
impacto, nesta pesquisa o foco é em abordar as técnicas apropriadas para a fase de
manutenção do software.
Neste contexto, uma técnica de análise de impacto eficiente deve identificar
apenas as partes do sistema que são impactadas pela mudança (BOHNER, 1996),
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 (ALI, ROZAN e SHARIF, 2012;
KAMA, 2013). Se o resultado apresenta entidades não impactadas, dizemos que este
possui falso-positivos. Em contrapartida, se o resultado não possui entidades
impactadas, dizemos que o resultado possui falso-negativos.
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.
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.3 Questão de Pesquisa
Diante da problemática apresentada, este trabalho visa responder as seguintes
questões de pesquisa:
QP1: O que se sabe atualmente sobre os benefícios e limitações da Análise de
Impacto em mudança de software?
QP2: O que se tem feito para minimizar os erros gerados na análise (reduzir
imprecisões)?
1.4 Objetivo Geral
Investigar dentro de um determinado intervalo de tempo, informações relevantes
sobre técnicas de análise de impacto, identificando características e as melhorias já
propostas.
1.4.1 Objetivos Específicos
i. Compreender o estado da arte sobre a análise de impacto em mudança de
software;
ii. Através de uma revisão sistemática, identificar as técnicas utilizadas, seus
pontos falhos e de que forma apresentaram melhorias;
iii. Gerar um catálogo de benefícios e limitações do uso da análise de impacto;
iv. Propor um guia de boas práticas com base nos dados extraídos da revisão;
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.
1.6 Contribuições e Resultados Esperados
Algumas contribuições são esperadas ao término desta pesquisa:
Evidências de técnicas existentes que conseguiram minimizar imprecisões;
15
Auxiliar a academia com evidências empíricas, através da fundamentação
em torno do que vem sendo feito para aperfeiçoar os resultados na análise
de impacto;
Geração de um catálogo de benefícios e limitações do uso da análise de
impacto e construção de um guia de boas práticas, buscando indicar as
formas para produzir resultados mais precisos.
1.7 Estrutura do Trabalho
Além deste capítulo introdutório, este trabalho está organizado nos seguintes
capítulos:
Capítulo 2 – Revisão da literatura: apresenta o referencial teórico dos
principais assuntos e os trabalhos relacionados com esta pesquisa.
Capítulo 3 – Metodologia da Pesquisa: apresenta o quadro metodológico,
o ciclo da pesquisa, assim como, as justificativas de escolha dos métodos;
Capítulo 4 – Resultados: são apresentados os resultados obtidos na revisão
sistemática da literatura e é construído um catálogo de benefícios e
limitações da análise de impacto, bem como também um guia de boas
práticas na busca de resultados mais precisos;
Capítulo 5 – Considerações finais: são apresentadas as limitações e
ameaças à validade da pesquisa, assim como suas implicações, conclusões
finais do trabalho e recomendações para trabalhos futuros;
Apêndices: apresentam os modelos, resultados e formulários relevantes
para a pesquisa.
16
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.
2.1 Referencial teórico
Esta seção apresenta uma descrição dos principais conceitos utilizados para a
condução desta pesquisa, resultante de uma revisão não sistemática da literatura
(adhoc) de publicações relevantes sobre análise de impacto em mudança de software.
2.1.1 Análise de Impacto
Conforme afirma SUN et. al (2010), a mudança de software é a principal
operação na evolução de software. Mudanças podem ocorrer devido a diversos fatores,
como novos requisitos, a existência de falhas, as solicitações de mudanças, etc.
Quando são feitas, elas inevitavelmente trarão alguns efeitos imprevisíveis e potenciais
ao software e ainda podem causar inconsistências em outras partes do software
original.
A análise de impacto em mudanças de software, ou simplesmente análise de
impacto (AI), surge para auxiliar neste processo, ela é uma etapa importante ao mudar
ou manter o software, especialmente em processos incrementais (RAJLICH, 2004).
Como a manutenção de software é considerada a fase mais cara (BENNETT, 1990) e
de maior duração no ciclo de vida da maioria dos sistemas (LEE, 2000), é preciso
buscar formas de economizar tempo e dinheiro e uma dessas formas é utilizar-se de
mecanismos que auxiliem as tarefas de desenvolvimento ou análise. Quando
mudanças são implementadas de forma parcial apresentam riscos elevados e são
17 susceptíveis a causar efeitos colaterais indesejados, induzir a novos erros e causar
mais instabilidade, ao invés de melhorar o software.
Nesse contexto, os desafios da AI já são abordados desde a década de 70,
quando a manutenção e a evolução de software começaram a atrair o interesse de
pesquisadores em engenharia de software (LEHNERT, 2011). Mas apesar de ser
conhecida e praticada há algumas décadas, não existe uma definição para AI que seja
de uso comum por parte dos pesquisadores. PFLEEGER (1990) define AI como sendo
a avaliação dos riscos associados a uma mudança, incluindo a estimativa dos efeitos
sobre os recursos, esforço e escalonamento. Para TURVER (1993), a AI determina o
escopo de uma mudança e provê uma mensuração de sua complexidade. Já BOHNER
e ARNOLD (1996), investigaram os fundamentos da AI e chegaram a uma definição
que é a mais adotada pelos pesquisadores: identificar as potenciais consequências de
uma mudança, ou estimar o que precisa ser modificado para realizar uma mudança.
A informação gerada a partir da AI pode ser usada para planejar mudanças e
realizar, adaptar e configurar o software para as mudanças, bem como para rastrear os
seus efeitos, além de permitir que os potenciais efeitos da mudança fiquem visíveis
antes de sua realização (ORSO, 2003; MAIA, 2009). Além disso, permite também
avaliar a quantidade de trabalho necessário para implementar uma mudança, propor
quais artefatos de software devem ser alterados (BOHNER, 1996) e ajuda identificar os
casos de teste que devem ser executados novamente, como forma de garantir que a
mudança foi implementada corretamente (RYDER, 2001). Conhecer o impacto causado
pela mudança é fundamental para decidir qual a melhor alternativa para mudar, assim,
a informação resultante da realização da análise, auxilia os engenheiros de software na
tomada desta decisão (MAIA, 2009).
Como observado, a AI desempenha um papel importante em várias atividades
de manutenção de software. Ela pode ser usada antes ou depois da implementação da
mudança. Antes das alterações serem feitas podemos empregar a AI para entender o
programa, alterar a previsão do impacto e estimativa de custo. Após as alterações
serem implementadas no sistema, a AI pode ser aplicada para traçar os efeitos em
cascata, selecionar os casos de teste, executar a propagação da mudança e a análise
do efeito cascata (ROVEGARD, 2008; SUN, 2009).
Conforme BOHNER (2002), o processo da AI é classificado em três etapas
principais, são elas: analisar a solicitação da mudança e o software; rastrear os
impactos potenciais; e por último implementar as mudanças solicitadas. Assim, de
18 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.
Fonte: Li et al. (2013)
Inicialmente é analisado a solicitação de mudança e o software para identificar o
conjunto de elementos supostamente afetados pela mudança. Em seguida, através da
aplicação de uma técnica de AI, outros elementos que provavelmente são afetados
pelos elementos do conjunto de mudança anteriormente identificados são estimados.
Esse novo conjunto é chamado de estimated impact set (EIS), mas também pode ser
chamado de candidate impact set (CIS). Por fim, ao implementar a mudança, é
identificado o conjunto de elementos impactados que são realmente modificados
durante a execução da mudança e esse é chamado de actual impact set (AIS).
Como pode ser visto na Figura 1, o processo da análise de impacto é interativo,
isso porque, durante a fase de implementação da mudança, outros elementos
impactados não presentes no EIS podem ser descobertos. O conjunto de tais
elementos é chamado de false negative impact set (FNIS), o que representa uma
subestimativa do impacto. Por outro lado, o EIS normalmente inclui alguns elementos
Figura 1: Processo da análise de impacto.
19 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.
2.1.2 Classes da Análise de Impacto: Dependência x Rastreabilidade
As duas classes da AI são a análise de dependência e a análise de
rastreabilidade (BOHNER, 1996). Essas classes trazem uma abordagem para a AI sob
diferentes perspectivas e possuem suas respectivas vantagens para aumentar o
potencial de identificação dos impactos no software. A Figura 2 ilustra ambas as
classes e conforme HATTORI (2008) a combinação destas classes pode aumentar a
precisão na AI.
20
Fonte: Hattori (2008).
A análise de dependência envolve o exame detalhado das relações de
dependência entre as entidades do programa. Ela propõe uma avaliação detalhada das
dependências de baixo nível de código e não se interessa tanto em outros artefatos do
software, como documentação, requisitos ou testes. Assim, ela é considerada
tipicamente como sendo uma análise do código-fonte (BOHNER, 1996), fazendo
análise das relações de dependência entre controle, dados e componentes do
programa.
As técnicas de AI baseadas na análise de dependência procuram avaliar os
efeitos de uma mudança em relação a dependências dinâmicas de entidades do
programa, identificando dependências sintáticas que podem sinalizar a presença de
tais dependências dinâmicas (LAW, 2003).
Enquanto que a análise de rastreabilidade envolve o exame das relações de
dependência entre todos os artefatos de um sistema. Podendo relacionar, por exemplo,
requisitos com os componentes do design associado (HATTORI, 2008).
2.1.3 Abordagens: estática, dinâmica e híbrida
Existem, duas abordagens de AI: a estática e a dinâmica. Mas também, podemos
considerar uma terceira, a híbrida, trata-se da junção das abordagens estática e
dinâmica.
A análise estática avalia o código fonte do software para identificar os impactos
possivelmente causados por uma mudança no software. Ela é empregada, geralmente,
Figura 2: Classes da análise de impacto.
21 antes da implementação da mudança, para estimar os esforços necessários na
implementação ou ajudar o especialista a escolher a opção menos custosa dentre as
possíveis opções de mudança (HATTORI, 2008).
Conforme ORSO (2004) as técnicas de análise de impacto dinâmicas são
aplicadas após a mudança ser implementada no software. Elas coletam os rastros das
execuções do software e analisam quais entidades chamam as entidades modificadas
para adicioná-las ao conjunto de impactos. Sendo assim, quanto maior for a
abrangência das possíveis execuções, maior será a precisão do resultado obtido.
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 aproximadamente, o conjunto dinâmico de elementos impactados, pois ela depende do
conjunto de execuções e da entrada para cada execução. Como não é possível
assegurar que a análise dinâmica capture rastros para todas as possíveis execuções
de um programa e todos os possíveis valores de entrada, sabe-se que técnicas
dinâmicas geram falso-negativos. Entretanto, pesquisas apontaram que a utilização da
análise de informação dinâmica representa a obtenção de resultados mais precisos
quando comparados à abordagem estática (APIWATTANAPONG, 2005; BREECH,
2004; LAW, 2003).
2.2 Trabalhos relacionados
Os trabalhos apresentados nesta seção são resultantes da revisão da literatura
realizada de forma ad-hoc, com o objetivo de buscar trabalhos similares a esta
pesquisa, além de discutir o que está sendo pesquisado em análise de impacto. Uma
tabela comparativa mostrando as diferenças e similaridades entre este estudo e os
trabalhos relacionados é apresentada no fim desta seção.
2.1.1 Change Impact Analysis for the Software Development Phase:
State-of-the-art (Nazri Kama, 2013)
Partindo do princípio que a análise de impacto requer diferentes abordagens e
implementações para diferentes fases do software e que a maioria dos trabalhos
existentes na área focam a fase de manutenção, este estudo revisa a capacidade de
técnicas atuais para apoiar a análise na fase de desenvolvimento do software.
O grande desafio apontado nesse contexto é que nem todas as classes do
sistema estão completamente desenvolvidas, o que torna as técnicas existentes
inadequadas esta finalidade. Sendo assim, foi realizada uma investigação entre
diferentes técnicas com o objetivo de oferecer uma visão abrangente sobre a
capacidade das técnicas atuais de análise de impacto.
Como critério para avaliar a capacidade das técnicas, foram adotados quatro
elementos:
Fonte de dados utilizada - podendo ser gerada a partir de artefatos de requisitos
e de design, ou ainda, artefatos de classes ou código fonte;
Técnica para desenvolvimento do modelo de análise de impacto - podendo ser
uma técnica preditiva ou de engenharia reversa;
23
Desenvolvimento parcial das classes - onde é considerado se a técnica tem a
capacidade analisa uma classe parcialmente desenvolvida, uma vez que, nem
todas as classes estão completamente desenvolvidas na fase de
desenvolvimento do software;
Implementação da análise de impacto - podendo ser do tipo estática ou
dinâmica.
Foram analisadas as técnicas: Use Case Maps, Requirement Interdependency,
Class Interacions Prediction, CoverageImpact, PathImpact e Influence Graph. Ao
compará-las, pode-se concluir que nenhuma destas técnicas dá suporte a todos os
elementos importantes para a implementação da análise de impacto na fase de
desenvolvimento de software. Assim, essas técnicas não se mostraram eficazes para
serem usadas na fase de desenvolvimento e por isso é sugerida a construção de uma
nova técnica de análise de impacto.
Essa nova técnica deve conter as seguintes características: utilizar artefatos de
alto nível como fonte para o desenvolvimento do modelo de análise; aplicar a técnica
preditiva como modelo para o desenvolvimento da técnica de análise de impacto; incluir
a análise de desenvolvimento parcial das classes na implementação da técnica de
análise dinâmica; e combinar a técnica de análise de impacto estática e a técnica de
análise dinâmica para implementar a análise de impacto.
2.2.2 The Hybrid Technique for Object-Oriented Software Change
Impact Analysis (Mirna Maia, 2010)
Neste estudo foi apresentada uma nova forma de efetuar a análise de impacto,
através da combinação de diferentes abordagens da análise, mais precisamente
unindo práticas da análise estática e dinâmica, com o objetivo de reduzir o número de
falsos negativos presentes em técnicas. Como já explanado na Seção 2.1, isto ocorre
porque as técnicas de análise de impacto subestimam o impacto, na medida em que, a
análise deixa de conter entidades de fato impactadas pela mudança.
Foram desenvolvidos para a avaliação do estudo, um protótipo chamado de SD-
Impala, que implementa a técnica híbrida proposta e um estudo de caso de múltiplo
caso quantitativo para comparar a solução com uma técnica estática (Impala) e uma
dinâmica (CollectEA), tal comparação, foi feita adotando quatro métricas: número de
falso-negativos, número de falso-positivos, precisão e recall. Enquanto a precisão
mede a quantidade de elementos identificados que não são impactados (falso-
24 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.
2.2.3 On the Precision and Accuracy of Impact Analysis Techniques
(Lile Hattori, 2008)
Neste estudo foi defendido que embora existam algumas pesquisas na literatura
buscando avaliar a precisão em técnicas de análise de impacto, as medidas utilizadas
para isso, não são formalmente definidas ou fracas, pois nestes casos, os algoritmos
são supostamente seguros por não excluir do conjunto de impacto identificado qualquer
entidade realmente impactada, entretanto, não há uma prova para esta hipótese.
Sendo assim, é proposto e avaliado o uso de duas medidas de recuperação da
informação, com o objetivo de expressar e comparar a precisão das técnicas de análise
de impacto. As medidas adotadas foram precisão e recall, quando combinadas, elas
permitem informar a precisão de uma técnica.
Como forma de avaliar essas medidas, foi implementada uma ferramenta JAVA
de análise de impacto estática, chamada Impala, ela calcula os elementos impactos,
identificando todas as dependências diretas e indiretas de uma mudança. Para que
haja uma redução de falsos-positivos, o algoritmo desenvolvido permite o ajuste de um
ponto de parada na identificação de dependências indiretas. Foi conduzido um estudo
empírico com três diferentes projetos JAVA, incluindo a própria ferramenta
25 desenvolvida (Impala) com o intuito de valida-la e outras duas, DesignWizard e
OurGrid.
2.3 Relação desta pesquisa com os trabalhos relacionados
Analisando os trabalhos mencionados na seção anterior, é possível notar que a
problemática em torno dos resultados gerados através da análise de impacto vem
sendo abordada na literatura, por apresentar-se como um problema constante, dado
que, encontrar uma solução ideal não é uma tarefa simples, pois como apresentado na
Seção 2.1, existem diferentes abordagens para sua aplicação, o que significa que um
determinado contexto, pode exigir uma determinada configuração e esta pode ser não
útil para aplicação em contextos diferentes.
Nesse sentido, investigar formas de mitigar o problema torna-se o principal
objetivo de pesquisas na área.
Da mesma forma que este trabalho, o trabalho de Nazri Kama (2013) fez o uso de
uma revisão para conduzir a pesquisa, porém de forma não sistemática e seu objetivo
foi investigar a capacidade das técnicas de impacto para apoiar especificamente a
análise na fase de desenvolvimento do software e como resultado, identificou a
necessidade da construção de uma nova técnica. Enquanto que nesta pesquisa, foi
conduzida uma revisão sistemática, com o objetivo é investigar dentro de um contexto
geral, quais os benefícios e limitações do uso de técnicas e apontar o que se tem feito
para que estas apresentem resultados mais precisos, gerando informações que podem
ser utilizadas como um guia na prática.
O trabalho de Mirna Maia (2010) e Lile Hattori (2008) estão direcionados no
sentido de expressar resultados, seja através de uma combinação de técnicas para
proporcionar um melhor resultado com a análise, ou mesmo, numa forma de utilizar
métricas para avaliar a precisão. Por outro lado, este trabalho se preocupa em
evidenciar tais contribuições. O Quadro 1 faz um comparativo, mostrando a correlação
entre os estudos.
Quadro 1: Comparativo entre este estudo e os trabalhos relacionados
Categoria Este estudo Nazri Kama
(2013)
Mirna Maia
(2010)
Lile Hattori
(2008)
Objetivo Identificar os
benefícios e
Investigar a
capacidade das
Avaliar o uso de
uma abordagem
Propor e
avaliar o uso
26
limitações da
análise de
impacto e
investigar
propostas de
melhoria
técnicas atuais
de análise de
impacto em
apoiar a análise
na fase de
desenvolvimento
híbrida de
análise com o
objetivo de
reduzir o número
de falsos-
negativos
de medidas
para expressar
a precisão de
técnicas de
análise de
impacto
Método de
Pesquisa
Revisão
sistemática da
literatura
Revisão Estudo de caso Estudo
empírico
Coleta dos
Dados
Revisão
sistemática da
literatura
Comparação
entre 6 técnicas
Protótipo e
outras 2 técnicas
3 projetos
JAVA
Análise
dos Dados
Qualitativa Qualitativa Quantitativa Quantitativa
Fonte: Próprio autor (2015).
2.4 Considerações finais do capítulo
Este capítulo apresentou os principais conceitos referentes à análise de impacto
em mudança de software. Além disso, explanou sobre os principais trabalhos que se
relacionam com o tema desta pesquisa, apresentando uma tabela comparativa para
melhor ilustração dos objetivos dos trabalhos relacionados e o deste estudo. O próximo
capítulo apresenta a metodologia de pesquisa utilizada para a concretização desta
dissertação.
27
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.
3.1 Classificação da Pesquisa
Diante da especificação do quadro metodológico pode-se compreender a teoria
utilizada na pesquisa, assim como, a metodologia específica empregada e desta forma,
obter o rigor científico a este estudo (LAKATOS e MARCONI, 2011).
No Quadro 2 será apresentada a abordagem utilizada no estudo, o objetivo, a
construção do referencial teórico, as técnicas de pesquisa, o método de procedimento,
a natureza das variáveis e as variáveis independentes e dependentes.
28
Quadro 2: Quadro metodológico da pesquisa
Método de abordagem Indutivo
Objetivo da pesquisa Exploratória
Construção do referencial teórico Revisão ad-hoc da literatura
Técnica de pesquisa Revisão Sistemática da Literatura (RSL).
Método de procedimento
(Codificação e Análise dos dados)
Síntese narrativa para a RSL
Natureza das variáveis Qualitativa
Variáveis independentes Análise de impacto
Mudança de software
Variáveis dependentes Benefícios e limitações da análise de impacto
Propostas de melhoria de resultados
Fonte: Próprio autor (2015).
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.
3.2 Ciclo da Pesquisa
Esta seção apresenta as principais fases realizadas ao longo deste estudo, com
uma breve descrição e o relacionamento entre estas etapas. A Figura 3 ilustra o
processo de desenvolvimento desta pesquisa.
Fonte: Próprio autor (2015).
(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
Figura 3: Ciclo de desenvolvimento da pesquisa
30 posse dos conceitos e teorias inerentes ao tema da pesquisa foram identificadas as
lacunas sobre a área de estudo. Sendo assim, definiu-se o problema de pesquisa e os
objetivos a serem investigados.
(2) Com a base teórica adquirida, iniciou-se a fase de planejamento com a definição
das questões de pesquisa a serem respondidas com o resultado desta dissertação. Por
conseguinte, o instrumento para coleta de dados (revisão sistemática da literatura) foi
planejado e elaborado.
(3) Para a fase de coleta de dados, com base no protocolo da Revisão Sistemática da
Literatura (RSL) desenvolvido na fase anterior, foi conduzida a RSL com as seguintes
atividades: busca automática, aplicação dos critérios de inclusão e exclusão, avaliação
da qualidade, extração e síntese dos dados.
(4) Após os dados serem coletados, através da RSL, eles foram analisados visando
responder as questões de pesquisas propostas nesta dissertação.
(5) Na última etapa, a fase de consolidação, de posse dos dados analisados, foi
construído um catálogo de benefícios e limitações e um guia de boas práticas na busca
de melhores resultados com a análise de impacto. Também foram apresentadas as
contribuições para a teoria e para a prática, as limitações desta dissertação e a
descrição de possíveis trabalhos futuros.
Na seção a seguir, será melhor detalhado o procedimento de coleta de dados
utilizado nesta dissertação (RSL).
3.3 Revisão Sistemática da Literatura
Com o intuito de responder as questões de pesquisa e alcançar os objetivos
elencados nesta dissertação, foi selecionado um método de pesquisa para a coleta de
dados. Esta seção visa explicar o procedimento usado para a coleta de dados,
baseado no protocolo da revisão, documento importante para futuras replicações desta
RSL.
Segundo KITCHENHAM et al. (2007), uma RSL é um estudo secundário com um
processo de pesquisa metodologicamente bem definido, cujo o objetivo é encontrar o
maior número possível de estudos primários relacionados com a questão de pesquisa.
Além disso, uma RSL precisa ser auditável e confirme sugere a autora deve ser
desenvolvido um protocolo descrevendo todos os procedimentos adotados durante sua
realização. O rigor adotado no processo de busca é um fator que distingue RSLs de
revisões tradicionais.
31
RANDOLPH (2009) apresenta algumas razões para se realizar uma revisão
sistemática: delimitar o problema de pesquisa; buscar novas linhas de investigação;
evitar abordagens infrutíferas; buscar conhecimentos metodológicos; identificar
recomendações para futuras pesquisas e buscar fundamentação teórica.
KITCHENHAM et al. (2007) complementam essa lista afirmando que as revisões
sistemáticas podem ser realizadas para resumir as evidências empíricas existentes,
identificar lacunas nos estudos atuais, suportar ou refutar uma hipótese ou até mesmo
auxiliar na geração de novas hipóteses.
A seguir é apresentado um resumo do protocolo que foi desenvolvido e utilizado
na condução desta revisão. Mais detalhes podem ser consultados na versão completa
disponível no APÊNDICE A.
1 – Definição das questões de pesquisa
Para compreender o estado da arte sobre os benefícios e limitações da análise
de impacto e investigar as melhorias propostas para a redução de imprecisões, foram
formuladas as seguintes questões de pesquisa, as quais esta pesquisa visa responder:
QP1: O que se sabe atualmente sobre os benefícios e limitações da Análise de
Impacto em mudança de software?
QP2: O que se tem feito para minimizar os erros gerados na análise (reduzir
imprecisões)?
2 – Definição de estratégias de busca
Uma das estratégias de busca para os estudos primários pode ser automática
e/ou manual. Este estudo adota uma abordagem de busca automática, realizada a
partir da execução da string de busca, no período de 2000 a 2013, totalizando 13 anos
de pesquisas em análise de impacto.
A fim de encontrar o maior número possível de artigos nessa busca relacionados
à análise de impacto, procurou-se abranger as palavras-chave desta RSL,
combinando-as e concatenando com operadores booleanos OR e AND.
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 "change impact" OR "static analysis" OR "dynamic analysis").
32 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.
4 - Critérios de seleção dos estudos
Os estudos primários resultantes do processo de busca foram avaliados
conforme os critérios de inclusão e exclusão pré-estabelecidos. Foram definidos 8
critérios de inclusão e 8 de exclusão para serem aplicados na seleção dos estudos. Se
o estudo atendesse os critérios de inclusão ele era mantido na tabela de avaliação dos
estudos, caso contrário era removido da mesma.
A aplicação destes critérios se dividiu em três etapas: primeiramente foi feita
uma leitura de identificação dos estudos, consistindo na leitura de Título e Resumo dos
estudos. Em um segundo momento foi lido a Introdução, Metodologia e Conclusão,
ainda assim, para os estudos que não ficaram claros, partimos para uma última etapa,
a completa leitura.
Esse processo de seleção envolveu 4 (quatro) pesquisadores, mestrandos do
Centro de Informática (CIn) da Universidade Federal de Pernambuco (UFPE) e 1 (um)
revisor, assumindo este papel o orientador desta pesquisa. Foram formados grupos,
divididos em duplas, para garantir que cada estudo fosse avaliado por dois
pesquisadores. Para os estudos que apresentaram avaliações diferentes, inicialmente
foi feita a tentativa de acordo no resultado, através de uma reunião para solução de
conflitos, ainda assim, caso as divergências não tivessem sido solucionadas, um
terceiro pesquisador faria a avaliação e tomaria a decisão final sobre aquele estudo.
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.
6 - Extração e análise dos dados
33 Nesta fase, apenas um pesquisador realizou o procedimento de extração e
análise dos estudos, sendo revisada pelo orientador da pesquisa. A partir da leitura dos
estudos, foram extraídas todas as evidências que respondessem as perguntas de
pesquisa.
A análise ocorreu ao mesmo tempo que a extração, com o objetivo de melhorar
a compreensão dos estudos, permitindo que toda a informação relevante fosse reunida
para utilização na fase seguinte.
7 - Síntese dos dados
A síntese dos dados pode ser quantitativa e/ou qualitativa, sendo um processo
que reúne e resume as evidências extraídas dos estudos primários incluídos na
pesquisa (KITCHENHAM et al., 2007). Esta pesquisa tem natureza qualitativa, logo
será realizada uma síntese qualitativa dos dados.
KITCHENHAM et al. (2007) apresentam três abordagens para a síntese
qualitativa, e estudo será baseado na abordagem de Síntese de Linha de Argumento
que é utilizada quando os pesquisadores querem inferir sobre um tema como um todo
a partir de um conjunto de estudos selecionados.
Os dados de caracterização de cada estudo como: autor(es), ano, técnica
utilizada, método de pesquisa entre outros, foram extraídos e sintetizados em uma
planilha do Microsoft Excel™.
3.4 Considerações finais do capítulo
Este capítulo apresentou a metodologia adotada para condução desta pesquisa,
onde foi construído o quadro metodológico para sintetizar as técnicas de pesquisa, o
instrumento de coleta de dados e métodos de análise. Também foi apresentado o ciclo
da pesquisa, uma breve descrição sobre a definição de uma RSL o os procedimentos
para elaboração desta revisão. O próximo capítulo apresenta os resultados obtidos
após a execução das etapas previstas na metodologia.
34
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.
4.1 Resultados da Busca e Seleção dos Estudos
Esta seção descreve os resultados obtidos através da condução da RSL, os quais
permitem responder as questões de pesquisa.
No início da pesquisa foi formada uma equipe com 5 pesquisadores, sendo 4 do
mestrado em Ciência da Computação no Centro de Informática da UFPE e 1 professor
orientador, todos instruídos e com experiência no processo de condução de revisões
sistemáticas.
Com o intuito de minimizar um possível viés na seleção de estudos, todas as
fases da revisão foram executadas por pelo menos dois pesquisadores. Assim, ficou
garantido que um mesmo estudo seria revisado por mais de um pesquisador. Após as
etapas de seleção e avaliação de qualidade dos estudos, a pesquisa passou a ser
conduzida pelo autor desta pesquisa, ou seja, apenas a fase de extração, análise e
síntese dos dados foi conduzida por uma única pessoa.
A Figura 8 ilustra de forma resumida e quantitativa o processo de seleção da RSL,
com indicação dos estudos resultantes em cada fase. A seguir serão descritas todas as
fases da RSL de acordo com o protocolo apresentado no capítulo 3 de forma resumida
e disponível em sua forma completa no APÊNDICE A.
35
Fonte: Próprio autor (2015).
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.
Figura 4: Processo de seleção da revisão
36
Fonte: Próprio autor (2015).
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.
Fase 3 – Seleção através da aplicação dos critérios: foram estabelecidos critérios
de inclusão e exclusão e como na fase anterior, uma reunião de esclarecimento foi feita
entre os pesquisadores. Nesta fase, a seleção entre os 320 estudos se deu através da
leitura da introdução e conclusão, mas caso fosse verificada a necessidade de um
melhor entendimento, o estudo seria lido por completo.
No repositório criado com uma cópia digital de cada estudo, tínhamos a
ausência de 39 estudos, pois alguns estudos estavam inacessíveis (eram pagos ou
33%
11%
6%
50%
Compendex IEEE ScienceDirect Scopus
Figura 5: Distribuição percentual de captura por engenho de busca
37 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.
Fase 4 – Avaliação da qualidade: nesta fase 5 estudos foram identificados
como replicados, pois na planilha já havia um outro de mesma autoria e com mesma
problemática abordada, restando assim 76 estudos. Estes foram analisados de acordo
com os critérios de qualidade estabelecidos no protocolo da revisão e o resultado pode
ser consultado no APÊNDICE B. Cada estudo foi distribuído em uma faixa de qualidade
disposta em: Baixa (1), Média (6), Boa (27), Muito Boa (34) e Excelente (12). Ainda
nessa fase, após a leitura completa dos estudos foi necessária a exclusão de 26, pois
os mesmos não apresentavam evidências para responder as questões de pesquisa.
A classificação da qualidade foi uma consequência direta das notas atribuídas
aos 10 critérios de qualidade para cada estudo. A Figura 6 apresenta a nota geral de
cada critério, obtida através da soma de todas as notas deste. Esses dados permitiram
avaliar de forma geral o comportamento dos critérios aplicados, na medida em que,
quanto mais baixa a pontuação geral, tal atributo de qualidade era pouco presente ou
inexistente nos estudos. Por outro lado, quanto maior a pontuação, mais presente era
aquele atributo de qualidade nos estudos.
Para compreender melhor essa presença ou ausência dos critérios de qualidade
nos estudos, estas qualidades são apresentadas de forma resumida:
Q1: Objetivo bem definido;
Q2: Descrição adequada do contexto;
Q3: Método definido e justificado;
Q4: Abordagem explícita (qualitativa, quantitativa ou mista);
Q5: Amostragem bem definida e justificada;
Q6: Clara descrição do procedimento de coleta de dados;
Q7: Rigor na análise dos dados;
Q8: Avaliação da relação do autor com a pesquisa – viés (reflexibilidade);
Q9: Resultado claro e discutido;
Q10: Valor do estudo para a pesquisa e prática.
38
Fonte: Próprio autor (2015).
Pode-se dizer que o critério Q4 foi o de menor pontuação e, consequentemente
os estudos falharam mais em não explicitar a abordagem dada em sua pesquisa, já o
critério Q2 recebeu a maior pontuação, o que significa que os estudos mantêm uma
definição adequada do contexto em que estão inseridos.
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
73 75
51
19
63,5 62 63
25,5
50,5 46
0
10
20
30
40
50
60
70
80
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10
Figura 6: Pontuação geral dos critérios de qualidade
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.
4.2 Mapeamento das Evidências
Nesta seção são apresentadas as evidências e os resultados para cada questão
de pesquisa. A síntese dos dados permitiu a construção de dois artefatos, cada qual
originado de uma questão de pesquisa.
Questão de Pesquisa 1
QP1: O que se sabe atualmente sobre os benefícios e limitações da análise de
impacto em mudança se software?
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 [S0648] a implementação da mudança e podem estar relacionadas à mudança de
código-fonte [S0031][S0094][S0982][S2367] e/ou artefatos [S0484][S1152].
O conjunto resultante da análise apresenta entidades potencialmente
impactadas pela mudança [S0199][S0478], através da avaliação completa ou parcial de
um sistema [S0259][S0275][S0668][S0827][S1093]. Essa informação é muito útil
[S0054][S1213] e auxilia a equipe responsável pela manutenção na identificação dos
efeitos cascata e na prevenção de efeitos colaterais [S0478], reduzindo assim, o risco
de trabalhar com mudanças de alto custo e imprevisíveis [S3320]. Permite também o
apoio a tomada de decisão [S3338] por meio de planejamento [S2283][S3251]. Tais
características são apresentadas nas evidências da Tabela 1.
Tabela 1: Evidências relacionadas a identificação de efeitos de uma mudança.
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
Fonte: Próprio autor (2015).
A informação gerada através da análise de impacto permite uma melhor
compreensão do programa, uma vez que, apoia tarefas relacionadas ao gerenciamento
da mudança, como o planejamento da mudança, o rastreamento dos efeitos da
mudança, a seleção dos casos de teste que precisam ser executados novamente, a
construção de estimativas de custo e consequentemente fornece aos mantenedores do
software suporte na hora de tomar uma decisão, conforme as evidências presentes na
Tabela 2.
42
Tabela 2: Evidências relacionadas a compreensão do programa.
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
Fonte: Próprio autor (2015).
Ainda nesse contexto, é possível afirmar que a análise de impacto possibilita a
construção de estimativas que auxiliam o trabalho do gerente de projetos e
desenvolvedores, como apresentado nas evidências da Tabela 3. Sendo assim, a
estimativa de custo dos recursos necessários para a mudança, pode ser feita de forma
mais precisa, fornecendo prazos mais próximos do real.
Tabela 3: Evidências relacionadas a construção de estimativas.
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
the applications of IA include cost estimation, resource planning, testing,
change propagation, managing ripple effects, and traceability
[S1051] estimating what needs to be modified to accomplish a change;
estimating the cost of development, the cost of a bugfix
[S3218] estimate the (complete closure of) ripple effects and prevent side effects of a
proposed change
[S3251] estimating the cost of development, the cost of the project, change
management, the stability of the system, or locating the potential bugs in the
system; estimates what will be impacted in the project and related
documentation if a proposed project change is made
Fonte: Próprio autor (2015).
Como já visto, a análise de impacto pode determinar os potencias impactos de
uma mudança, antes, durante ou depois de sua implementação e há relatos positivos
de seu uso na previsão dos efeitos, como pode ser visto nas evidências da Tabela 4.
Neste cenário, a predição pode fornecer informações úteis antes mesmo da
implementação de uma mudança, como por exemplo, identificando quais componentes
serão afetados pela mudança, permitindo que seja criado e trabalhado em um plano de
mudança, ao invés de lidar apenas com as suas consequências.
Tabela 4: Evidências relacionadas a previsão de efeitos.
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
Fonte: Próprio autor (2015).
44
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
Tabela 5: Evidências relacionadas ao suporte a atividades de teste.
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
Fonte: Próprio autor (2015).
Um outro benefício também, é o de permitir a identificação de erros, de acordo
com as evidências apresentadas na Tabela 6. Assim, a análise de impacto permite
localizar os potenciais bugs e erros de um sistema e quando são detectados de forma
46 preditiva, evitam que falhas mais graves possam acontecer depois da implementação
das mudanças.
Tabela 6: Evidências relacionadas a identificação de erros.
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
Fonte: Próprio autor (2015).
Depois de apresentado esses benefícios, é possível afirmar ainda que a análise
de impacto fornece melhor produtividade e tal característica pode ser notada conforme
as evidências presentes na Tabela 7. Isso porque há uma redução no tempo e esforço
necessários para a execução de testes de regressão, na depuração, em manutenção
corretiva e em teste e verificação do sistema modificado, orientando a análise apenas
para as partes do software afetadas pela mudança.
Tabela 7: Evidências relacionadas a produtividade.
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
[S0106] reduce the amount of corrective maintenance by reducing the number of
errors introduced as a by-product of the maintenance effort
[S0827] reduce the time and cost of testing and verification of the changed system
by guiding the analysis toward the parts of the system impacted by the
changes
Fonte: Próprio autor (2015).
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:
1) Incapacidade de análise em diferentes fases do ciclo de desenvolvimento
Normalmente uma técnica é capaz de suportar apenas uma fase específica do
ciclo de vida de desenvolvimento e esta limitação deve-se ao contexto em que ela é
empregada, por exemplo, uma técnica pode suportar apenas a fase de manutenção de
48 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.
Tabela 8: Evidências relacionadas a capacidade de análise em diferentes fases.
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
Fonte: Próprio autor (2015).
2) Dificuldade para descobrir o impacto
Essa limitação é explicada devido à complexidade das relações entre as partes
de um sistema e isso se torna mais evidente em abordagens orientadas a objetos.
Esse problema também é agravado, pois frequentemente há inconsistências entre os
diferentes tipos de artefatos do software. Tudo isto, torna difícil a escolha da técnica
mais adequada para uma dada necessidade. Tais características foram identificadas
através das evidências presentes na Tabela 9.
Tabela 9: Evidências relacionadas a dificuldade para descobrir o impacto.
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
impact difficult to anticipate because of possible hidden propagation
[S0787] is difficult for researchers or practitioners to decide which technique is most
appropriate for their needs
[S1093] impact analysis of object-oriented programs still remains to be a challenging
problem due to the complicated relations between their entities
[S1152] relationships between system parts are often not defined or documented
explicitly
[S1324] modifications are done during the maintenance by software developers who
are not native to the software project or unknowledgeable of the code. Thus,
they find it hard and in some cases impossible to determine the closely
related entities for a change;
Even if developers are native to project, they lose their grasp on system with
passage of time as it ages
[S3321] understanding and implementing these changes is often aggravated by
inconsistencies and dependencies between different types of software
artifacts
Fonte: Próprio autor (2015).
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.
Tabela 10: Evidências relacionadas a imprecisã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
Fonte: Próprio autor (2015).
51
4) Conjunto de impacto grande
Quando a análise apresenta um conjunto muito grande de impacto, trabalhar
com esse conjunto pode ser uma tarefa bastante difícil para os mantenedores do
software, uma vez que, eles podem acabar se confundindo com tanta informação e,
além disso, será necessário dedicar mais tempo de trabalho. Percebe-se que isso
acontece com frequência em análises estáticas, já que elas cobrem quase todo o
programa. Tal limitação é caracterizada pelas evidências apresentadas na Tabela 11.
Tabela 11: Evidências relacionadas ao conjunto de impacto.
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
Fonte: Próprio autor (2015).
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
Tabela 12: Evidências relacionadas a qualificação e experiência.
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
Fonte: Próprio autor (2015).
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.
Tabela 13: Evidências relacionadas a superestima.
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
Fonte: Próprio autor (2015).
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.
Tabela 14: Evidências relacionadas a subestima.
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
underestimating impact produces false-negatives that, when kept
unchanged, may negatively affect the changed software, usually in the form
of bugs that need to be fixed;
false-negatives may cause important financial losses to the software
company
[S3307] leads the software maintainer to omit important impacts of a change. If such
impacts continue being omitted when implementing the change, they may
cause inconsistencies in the software which result in bugs
Fonte: Próprio autor (2015).
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.
Tabela 15: Evidência do grua de granularidade.
ID Evidência
[S3307] analysis at a finer level of granularity would give a more accurate result but
attract more computational overhead
Fonte: Próprio autor (2015).
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)?
Para responder esta pergunta de pesquisa, foi necessário investigar as
evidências em técnicas que propuseram melhorias. Algumas evidências indicam que
existem pesquisas interessadas nesse cenário, mas ainda não foi possível obter uma
solução ideal. Neste momento, não é de interesse desta pesquisa identificar ou avaliar
as limitações dessas soluções, mas em apontar apenas o que já foi proposto para
obtenção de melhores resultados. Vale frisar que nem todos os estudos incluídos nesta
revisão foram capazes de responder a esta pergunta.
As evidências foram sintetizadas para responder a QP2 e foi criada uma tabela
contendo um identificador ID e os trechos (evidências) extraídos dos estudos fonte.
Devido à extensão dessa tabela ela foi inserida no APÊNDICE D. Os estudos são
referenciados na resposta construída pelo seu identificador.
Entre as diferentes formas da aplicação da AI apresentadas nos estudos,
quando o cálculo do impacto é feito sistematicamente, pode trazer benefício em relação
ao esforço empregado na análise e consequentemente permitir a redução nos custos
da manutenção [S0054]. Empregar diferentes níveis de granularidade também é uma
excelente alternativa, pois melhora a precisão da análise, além de permitir a redução
de trabalho extra do programador na verificação de falso-positivos [S2295].
A utilização de uma ferramenta de análise automatizada pode resultar num
conjunto de impacto menor [S2344] e permitir que os resultados sejam analisados
dentro de um mesmo ambiente, além de reduzir o risco de trabalhar em uma mudança
de alto custo, pois os problemas podem ser identificados previamente [S0106]. Outra
solução encontrada é utilizar uma ferramenta que dê apoio ao processo de análise de
forma semiautomática, onde o programador interage com a mesma [S2283].
O resultado da combinação de diferentes abordagens/técnicas vem sendo
bastante evidenciado por apresentar dados bastante satisfatórios
[S0433][S0536][S0608][S0665][S0776][S0827][S1051][S1324][S3218][S3224][S3237].
Buscando a precisão em seu resultado, diferentes abordagens de análise de
impacto têm surgido. Uma abordagem com base no fenômeno de propagação de
56 ondas de água consegue calcular um conjunto de impacto mais preciso, reduzindo o
número de falso-positivos, mas perdendo alguns falso-negativos quando comparada a
uma técnica tradicional baseada em gráficos de chamada [S1306]. Outra abordagem
apresenta uma solução escalável para grandes sistemas e suprime cerca de 80% dos
falso-positivos recorrentes [S0982]. Há também uma abordagem sismológica, que
promete encomia de tempo, já que nessa solução o mantenedor examina apenas os
níveis indicados ao invés de todo o código-fonte, o que permite uma rápida
identificação da origem de um erro [S0484]. Além dessas, foram identificadas outras,
conforme são apresentadas a seguir.
A análise simulada ajuda a manter um prognóstico do sistema [S0827] ou pode
ainda melhorar a qualidade do software e reduzir o custo de manutenção [S0688].
Na análise com base no histórico de mudança, pode ser gerado um gráfico de
impacto da mudança para identificar de forma rápida a origem de um erro de acordo
com a localização da falha relatada, assim, os desenvolvedores focam sua atenção nos
nós que são as causas mais prováveis da falha [S0727]. Uma outra forma de analisar é
através da mineração de repositório para descobrir informações importantes e as
tendências de mudanças utilizadas para fazer previsões [S1324].
Com a análise em nível de requisitos, o cálculo dos custos de uma proposta e
implementação de uma mudança em software embarcado pode ser facilitado [S1152].
Também a nível de requisitos, apoiar-se em requisitos de mapas de casos de uso pode
permitir uma análise antecipada e identificar as partes afetadas por uma solicitação de
mudança [S1213] ou ainda fornecer um aparato visual (diagramas) que permite os
gerentes de projetos organizarem as tarefas do projeto, promovendo a melhor
comunicação e execução da análise de impacto [S1243].
Na análise de acordo com o tipo de mudança, modelos podem ser especificados
para ajudar os desenvolvedores a prever as necessidades futuras. Quando o conjunto
inicial de impacto é estimado corretamente, consequentemente o conjunto potencial de
impacto será obtido com mais precisão [S0462]. Ao utilizar um modelo hierárquico, um
algoritmo de corte gradual é usado para gerar um conjunto de impacto mais preciso e
de menor custo, se comparado as tradicionais técnicas de corte estático [S0496].
Regras de impacto também podem ser utilizadas para melhorar a precisão dos
resultados, nessa abordagem o conjunto de impacto inicial apresenta uma alta precisão
e um menor número de falso-positivos, já o conjunto de impacto potencial e o conjunto
final tem alta revocação, o que significa que a proporção das entidades modificadas foi
57 corretamente estimada como impactada, permitindo assim, a remoção de muitos falso-
negativos [S1093].
Com a análise de impacto online, ao utilizar um compilador dinâmico, é possível
dimensionar de melhor forma o software, comparado a técnicas atuais de análise de
impacto dinâmica [S0199].
Na análise com base em mecanismos de influência, esses mecanismos são
coletados para gerar um gráfico de influência e melhorar a precisão de técnicas de alto
nível de granularidade, realizando a análise em um tempo razoável [S2372].
Mesmo esta pesquisa sendo direcionada a investigação em técnicas de análise
de impacto para a fase de manutenção do software, foi possível identificar evidências
em duas abordagens para suporte a análise na fase de desenvolvimento de software.
Neste caso, deve-se levar em conta que o software não está completamente
desenvolvido e sendo assim, torna-se necessário a aplicação de uma abordagem
diferenciada, já que as técnicas conhecidas não fornecem aparato apropriado para
tanto. A primeira abordagem identificada faz a análise em alto nível para apoiar a
inclusão de classes parcialmente desenvolvidas com uma técnica dinâmica,
identificando o conjunto de impacto potencial de acordo com a especificação da
solicitação da mudança e utilizando um filtro para remover alguns possíveis resultados
falsos e assim produz resultados mais precisos [S2542]. E a segunda, se preocupa em
calcular o tamanho da mudança para uma determinada solicitação de mudança,
fazendo o uso integrado de técnicas, uma estática e outra dinâmica, podendo executar
automaticamente os processos da análise, tendo como resultado final de seu processo
um conjunto priorizado de classes impactadas e o tamanho da mudança estimado em
percentagem, produzindo uma taxa média de erro de 6,3%, indicando assim uma
precisão de 93,7% [S3338].
Na análise de conceito formal, em um tipo de abordagem é definido um fator de
impacto para ranquear a lista dos métodos potencialmente impactados, priorizando
assim uma ordem para inspeção destes métodos [S3272]. Em outra abordagem, o
impacto pôde ser definido com mais precisão, através de um menor número de falso-
negativos e falso-positivos para prever os efeitos em cascata induzidos por uma
proposta de mudança [S0648].
A análise multi-perspectiva, ganha uma nova dimensão, dado que as
abordagens da análise de impacto se concentram normalmente na avaliação de
apenas um artefato. Aqui é combinado o conceito de análise de impacto com o da
58 modelagem multi-nível, poucos falso-positivos são identificados e o resultado não
superestima a propagação da mudança, assim, essa estratégia fornece dados
confiáveis e estáveis de precisão e revocação [S3321].
A análise em nível de solicitação de mudança, baseada em dados de repositório
e técnica de recuperação de informação, analisa como solicitações de mudanças
passadas foram resolvidas para identificar as entidades afetadas de acordo com
pedidos semelhantes de mudança, apresentando uma melhoria de 10% ao custo de
gastar mais tempo e espaço para armazenar [S3078].
A análise de impacto em sistemas baseados em agentes inteligentes, que são
entidades de um ambiente que possuem autonomia computacional, capazes de operar
de forma independente, tomando suas próprias decisões sobre quais atividades devem
ser executadas, utilizou uma técnica estática para calcular o impacto da mudança
analisando o código-fonte e identificando dependências do sistema e também uma
técnica dinâmica para construir uma representação do comportamento de um agente
por meio da análise de seus rastros de execução. Assim, concluiu-se que empregando
a análise dinâmica foi possível obter um melhor resultado tanto em revocação, quanto
em precisão se comparada a aplicação da técnica estática [S3307].
A análise PathImpact identifica o impacto em alto nível e se mostra mais precisa
do que análise baseada em Call Graph, além disso, ela não requer acesso ao código-
fonte e utiliza um algoritmo para reduzir o tamanho do traço de execução recolhido na
análise [S0355].
A análise Field Data é uma abordagem dinâmica que recolhe traços de
execução do programa, mas que requer uma leva instrumentação, recolhendo dados
em ordem de kilobytes por execução e quando os esses dados são estáveis a técnica
apresenta exatidão [S0178].
A análise baseada na técnica Control Call Graph, quando comparada à técnica
tradicional de Call Graph se mostra mais precisa, ela permite a redução de tamanho do
conjunto de métodos que podem ser afetados após uma dada mudança e considera
apenas o conjunto que poderia ser diretamente afetado [S0094].
A análise dinâmica baseada em Execute-After coleta e analisa apenas uma
quantidade pequena de informação, assim, consome tempo e espaço de forma
eficiente, tornando-se prática para ser usada em grandes programas, de longa
execução e comparada as abordagens PathImpact e CoverageImpact, se mostrou
melhor [S3040].
59
Por fim, há evidência de uma nova abordagem estática que se beneficia de
técnicas de redução de dimensionamento para reduzir a complexidade das
informações coletadas e para poder executar o processo de análise de impacto de
forma mais rápida [S2294].
Dado a resposta para a QP1, as evidências foram analisadas e sintetizadas para
permitir a construção do catálogo de benefícios e limitações do uso da análise de
impacto. Já com a resposta para a QP2, foi possível construir um guia de boas práticas
baseado no que se tem feito para melhorar os resultados da análise de impacto. Para
melhor representar e distribuir os dados, essas construções serão apresentadas na
seção 4.3, sobre a discussão dos resultados.
4.3 Discussão dos Resultados
Nesta seção são apresentadas algumas discussões sobre os resultados obtidos
nesta pesquisa, os quais serviram de insumo para a construção de um catálogo que
apresenta os benefícios e limitações da análise de impacto, conforme resposta à
primeira questão de pesquisa (QP1) e um guia de boas práticas, conforme resposta à
segunda questão de pesquisa (QP2).
Evidências sobre os benefícios e limitações da análise de impacto A análise dos dados extraídos da revisão permitiu identificar os benefícios e
limitações da análise de impacto, respondendo assim a QP1. Para melhor ilustração e
entendimento foi possível categorizar essas características em alguns conceitos gerais.
Os benefícios foram classificados em 10 conceitos, são eles: identificação do impacto,
compreensão do programa, fazer estimativas, fornecer previsão, utilizar diferentes
fontes de informação, análise automática, utilizar técnica dinâmica, suporte a atividades
de teste, identificar erros e melhorar a produtividade. Já as limitações foram
classificadas em 8 conceitos, são eles: incapacidade da análise em diferentes fases,
dificuldade para descobrir o impacto, imprecisão, conjunto de impacto muito grande,
qualificação e experiência, superestimar, subestimar e por último granularidade.
Os benefícios indicam a importância em utilizar a análise de impacto, que além
de permitir a identificação de possíveis impactos ocasionados por uma mudança
60 oferece suporte para uma melhor compreensão do programa e atividades de teste,
podendo fornecer uma melhor produtividade. De posse dos resultados da análise é
possível fazer estimativas dos custos associados à atividade da mudança e auxiliar a
tomada de decisão.
Por outro lado, a maior parte das limitações identificadas aponta para a
imprecisão gerada no resultado da análise. As evidências enfatizam a imprecisão como
sendo a grande problemática que restringe a capacidade das técnicas de análise. Ela
pode ser ocasionada por diversos motivos, dentre os quais se destacam a superestima
ou a subestima dos resultados. A superestima acontece quando o conjunto de dados a
ser analisado é grande e apresenta dados desnecessários, os falso-positivos,
normalmente surgem da execução de uma técnica estática. Por outro lado, a
subestimativa acontece quando o resultado da análise deixa de apresentar dados
importantes, as entidades que de fato são impactadas por uma mudança, os falso-
negativos e, normalmente surgem da aplicação de uma técnica dinâmica.
Desse modo, tanto a técnica estática quanto dinâmica apresentam erros em seu
resultado, a aplicação da técnica estática fornecerá um grande volume de dados e
exigirá mais tempo de análise (esforço) e consequentemente um custo maior
associado. Na análise dinâmica o conjunto de dados a ser analisado tende a ser menor
que o da abordagem estática, logo, necessitará de menos esforço e representará um
menor custo.
Nesse contexto, é necessário analisar a necessidade do ambiente onde a
análise será aplicada para decidir qual abordagem adotar, conhecendo suas limitações,
mas tentando aproveitar ao máximo de todos os benefícios que a análise de impacto
oferece. Espera-se que o catálogo apresentado possa fornecer informações
preliminares para um melhor entendimento sobre a análise de impacto.
O catálogo está dividido em duas tabelas, onde a Tabela 16 apresenta os
benefícios da análise de impacto e a Tabela 17 suas limitações.
Tabela 16: Benefícios da análise de impacto.
BENEFÍCIOS
Identificação do impacto
determinar os efeitos de uma mudança;
o efeito pode ser avaliado antes, durante ou depois da implementação da mudança;
determinar o efeito de um subconjunto do software ou em sua
61
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
tempo necessário para fazer uma mudança;
custo da mudança;
custo do projeto;
custo de desenvolvimento;
custo da fixação de um erro.
Fornecer previsão
permite prever uma mudança;
permite prever falhas perigosas.
Utilizar diferentes fontes de informação
apoia-se numa coleção de técnicas;
conjunto de impacto pode ser computado por diferentes representações do programa;
mudanças podem ser identificadas no fluxo de ilustração (diferenças semânticas), em mudanças estruturais (diferenças textuais) e nos casos de teste afetados.
Análise automática
apoio em ferramentas que dinamizam o processo e evita a introdução de erro humano.
62
Utilizar técnica dinâmica
apresenta resultado mais preciso.
Suporte a atividades de teste
orienta testes de regressão;
auxilia no processo de selecionar os casos de teste;
determina o conjunto de testes que precisam ser executados novamente;
permite reduzir os casos de testes que precisam ser executados;
permite reduzir com segurança as etapas de teste necessárias;
otimiza os testes.
Identificar erros
localiza os potenciais bugs e erros.
Melhorar a produtividade
reduz o tempo e esforço necessário para rodar testes de regressão;
reduz o tempo e esforço no debug;
reduz a quantidade de manutenção corretiva;
reduz tempo e custo para teste e verificação.
Fonte: Próprio autor (2015).
Tabela 17: Limitações da análise de impacto.
LIMITAÇÕES
Incapacidade da análise em diferentes fases
a técnica se limita ao contexto em que é empregada;
a maioria das técnicas não é capaz de detectar os efeitos em diferentes artefatos
Dificuldade para descobrir o impacto
complexidade das relações entre as entidades de um sistema;
é difícil decidir qual a técnica é mais apropriada;
se as relações entre as partes do sistema não estiverem definidas ou documentadas;
é difícil ou mesmo impossível para programadores não nativos de um sistema determinar as entidades relacionadas a uma mudança;
se não conhecer o código-fonte;
desenvolvedores nativos podem perder sua compreensão sobre o
63
sistema com o tempo;
pode existir inconsistências no software;
dependência entre diferentes artefatos.
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.
Conjunto de impacto muito grande
abordagens estáticas podem produzir um conjunto de impacto muito grande;
a abordagem estática contém quase todo o programa;
a abordagem estática gera um maior custo e tem precisão comprometida;
se o projeto é grande, consequentemente o volume de impacto da mudança é maior
Qualificação e experiência
é preciso compreender os efeitos;
a qualificação e experiência afeta a composição do conjunto de impacto;
a falta de conhecimento pode conduzir a uma má estimativa de esforço e atrasos de cronograma;
conhecer pouco sobre a mudança causa um aumento no custo e riscos de mudança;
o trabalho manual pode incluir erros;
profissionais experientes podem prever conjuntos de impacto incompletos;
64
se a mudança não é compreendida de forma completa, efeitos colaterais indesejados podem surgir
Superestimar
perde-se um tempo desnecessário para investigar os potenciais efeitos;
elementos são identificados como impactados, mas quando na verdade não são;
abordagem estática apresenta muitos falso-positivos;
confunde a análise por conter informações desnecessárias
Subestimar
potenciais impactos são omitidos;
abordagem dinâmica analisa um conjunto menor de dados e pode conter falso-negativos;
pode causar perdas financeiras importantes;
erros podem surgir
Granularidade
análise em baixo nível de granularidade gera uma sobrecarga computacional
Fonte: Próprio autor (2015).
Evidências de melhorias Para construção do guia de boas práticas foi preciso analisar o conjunto de
todas as informações coletadas nos estudos selecionados e avaliar quais e como
poderiam ser indicadas para obtenção de melhores resultados. Analisando então a
resposta para QP2 foi possível identificar as principais práticas adotadas que surtem
um efeito positivo ao empregar a análise de impacto, apresentando um resultado mais
satisfatório.
Não são abordados de forma detalhada os processos das técnicas que
apresentaram alguma melhoria, o objetivo é em apenas evidenciar que existem
pesquisas interessadas em fornecer melhores soluções para a análise de impacto.
65 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
Essa prática torna-se evidente, porque o resultado da análise dinâmica tende a
ser mais útil, uma vez que, reflete de melhor forma como o sistema está sendo
realmente usado e consequentemente não são identificados impactos derivados de
comportamentos impossíveis de acontecer no sistema, conforme indica o estudo
S3307.
Experimentar abordagens híbridas – essas abordagens unem o melhor de
cada técnica para gerar um resultado mais preciso. As abordagens existentes utilizam
a técnica estática e dinâmica de forma combinada, ou ainda, utilizam outras fontes de
informação para complementar a análise, como por exemplo, combinar uma técnica de
análise impacto dinâmica, com uma técnica de recuperação da informação e outra de
mineração de dados, como feito no estudo S0776, onde é feita a análise das
solicitações de mudança, dos rastros de execução e das mudanças anteriores para
assim estimar o conjunto de impacto.
Quando a abordagem combinada uma técnica estática e dinâmica, também é
possível obter um melhor resultado, como no estudo S3224, que conseguiu reduzir o
número de falso-negativos e assim fornecer um resultado mais preciso.
Apoiar-se de ferramentas – com o objetivo de reduzir o risco da introdução de
erros humanos na análise, é ideal utilizar ferramentas automatizem o processo. Além
disso, uma representação visual permite uma melhor organização das tarefas do
projeto.
Isso é possível, por exemplo, com a utilização de plug-ins adicionados ao
ambiente de desenvolvimento, que fazem o rastreamento do código-fonte e criam as
relações de dependência das entidades do software. Se essas relações fossem feitas
de forma manual, estariam sujeitas a erros, pois uma dependência poderia deixar de
ser identificada, ou ainda poderia ser identificada mais sem existir tal relação.
Empregar diferentes granularidades – é possível aplicar uma granularidade de
mais alto ou mais baixo nível, o grau da granularidade irá definir o resultado da análise.
Uma granularidade de baixo nível pode fornecer dados mais precisos, por está mais
próxima do software (realidade da mudança), por outro lado, a análise torna-se mais
complexa.
Por exemplo, uma análise a nível de variáveis seria mais precisa que uma
análise em nível de método, pois seria possível detectar quais partes seriam afetadas
especificadamente por aquela variável (mais baixo nível). Já se analisarmos a nível de
método, podemos descobrir que outros métodos seriam impactados pela mudança,
67 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 Assim, é feita uma analogia da propagação da mudança com as ondas de propagação
sísmicas da sismologia.
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.
1) Como você avalia seu nível de conhecimento sobre análise de impacto?
a) Alto, mais de 5 anos de experiência
b) Médio, mais de 1 ano a 5 anos de experiência
c) Baixo, mais 6 meses a 1 ano de experiência
d) Iniciante, menos de 6 meses de experiência
2) Qual a sua atual situação perante ao mercado?
a) Estou empregado, assumindo cargo de chefia
b) Estou empregado, assumindo cargo de controle/gerência
c) Estou empregado, assumindo cargo de analista/desenvolvimento
d) Estou desempregado
3) Em cerca de quantos projetos aproximadamente você já trabalhou e aplicou alguma
técnica de análise de impacto em mudança de software?
a) De 21 a mais projetos
b) Entre 11 a 20 projetos
c) Entre 6 a 10 projetos
d) Entre 1 a 5 projetos
4) Considerando que o software pode ser desenvolvido seguindo diferentes
paradigmas e a análise de impacto pode utilizar diferentes artefatos para ser
executada, quais dessas alternativas você considera ser a mais correta
69
a) Uma determinada técnica pode ser generalizada e aplicada em qualquer
cenário, seja um sistema estrutural ou orientado a objetos, por exemplo
b) Uma determinada técnica é capaz de avaliar o impacto dado qualquer que seja o
artefato utilizado como entrada
c) Uma determinada técnica impõe suas limitações e restringe seu uso em um
ambiente específico
d) Uma determinada técnica não dá suporte a análise de impacto em mudança de
software
5) Dado que a experiência pode ser um fator que influência o resultado da análise de
um conjunto de impacto estimado, principalmente quando este conjunto de dados é
muito grande ou quando contém relações de dependência complexas. Avalie qual
deve ser o comportamento de quem conduz a análise.
a) Ignorar a possibilidade de o resultado sofrer com sua influência
b) Agir com rigor e criteriosidade ao estimar para evitar a introdução de viés
c) Seguir o processo da técnica aplicada e direcionar o resultado para alterar o
cronograma do projeto
d) Estimar o impacto da mudança de acordo com o custo estimado para o projeto
6) Analisando o melhor para o negócio, sabendo que uma técnica pode conter falso-
positivos e/ou falso-negativos é preferível utilizar uma técnica que:
a) Reduza o número de falso-positivos
b) Reduza o número de falso-negativos
c) Reduzir o número de falso-positivos ou falso-negativos
d) Reduzir o número de falso-positivos e falso-negativos
7) Se por um lado técnicas estáticas costumam apresentar falso-positivos e por outro
técnicas dinâmicas apresentam falso-negativos, é possível afirmar que o uso de
uma técnica que combine as duas abordagens pode resultar em um resultado mais
preciso?
a) Sim, pois eliminaria qualquer resultado impreciso
b) Sim, pois apresentaria uma melhoria significativa na redução de imprecisões
c) Não, pois a aplicação de uma combinada com a outra anularia o resultado
d) Não, pois não haveria qualquer melhoria
8) Buscando obter um melhor resultado na aplicação da análise de impacto, qual das
seguintes práticas deve ser adotada:
70
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
Para responder ao questionário três especialistas foram convidados a participar da
entrevista e o resultado é apresentado de forma resumida na Figura 7.
71
Fonte: Próprio autor (2015).
A análise das respostas permite concluir que o Entrevistado A é o que mais
possui experiência, em segundo lugar o Entrevistado C e por último e Entrevistado B. A
partir da questão 4 é possível associar cada uma a uma prática indicada no guia
construído, conforme a ordem:
Questão 4, relacionada a identificação da abordagem apropriada;
Questão 5, relacionada a calcular o impacto com rigor;
Questão 6, relacionada a dá preferência ao uso de abordagens dinâmicas;
Questão 7, relacionada a utilização de abordagens híbridas;
Questão 8, relacionada a utilizar ferramentas que apoiem o processo da análise;
Questão 9, relacionada ao emprego de diferentes granularidades;
Questão 10, relacionada a redução de falso-positivos;
Questão 11, relacionada a redução de falso-negativos;
Questão 12, relacionada a utilização de outros artefatos.
Diante da amostra utilizada nesta entrevista a conclusão é dada pelo maior
número de alternativas respondida da mesma forma. E assim, foram criadas as
relações que validam as práticas levantadas nesta pesquisa.
Quanto a prática de identificar uma abordagem apropriada a alternativa mais
respondida (c) diz que uma determinada técnica impõe suas limitações e restringe seu
uso em um ambiente específico. E esta resposta foi a mesma entre os entrevistados
Figura 7: Respostas coletadas da entrevista aplicada.
72 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 Já a questão 11, questionou sobre o benefício obtido com a redução de falso-
negativos e neste momento todos os entrevistados voltaram a concordar, respondendo
que esta redução torna a análise mais precisa, pois o conjunto final de impacto terá um
número maior de entidades de fato impactadas pela mudança (d).
Por fim, na questão 12, questionados sobre a utilização de outros artefatos
durante a análise para complementá-la, a experiência fez com que cada um desse uma
resposta diferente (b, d e a). Logo, é possível afirmar que não há uma resposta
totalmente considerada correta, uma vez que, apenas quando o utilizador da técnica
tentar utilizar um outro artefato e obtém sucesso, ele estará convencido de que isto é
possível. Mas neste aspecto, a literatura já indica casos de sucesso.
74
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.
5.1 Limitações e Ameaças à Validade
Apesar da adoção de um rigoroso quadro metodológico nesta dissertação,
conforme descrito no capítulo 3, esta pesquisa ainda possui algumas limitações que
são descritas a seguir:
Segundo KITCHENHAM (2007) uma limitação comum em revisões e
mapeamentos sistemáticos, é encontrar todos os artigos relevantes existentes sobre o
tema a ser pesquisado. Neste trabalho, foram utilizados os quatro engenhos de buscas
considerados mais relevantes para esta pesquisa e que trouxeram um número maior
de artigos condizentes com o que estava sendo analisado.
Adicionalmente, foi analisada a necessidade de uma busca manual, mas não foi
possível determinar algum evento especifico na área que servisse como fonte para
essa busca. Além disso, também foi feita uma tentativa de busca manual nas
referências dos estudos, porém verificou-se que não seria uma boa alternativa, pois as
referências para fontes potencialmente relevantes conduziam a estudos já capturados
na busca automática. Sendo assim, como esta pesquisa adotou apenas a busca
automática, ocorre à possibilidade de algum estudo não relevante não ter sido
encontrado.
Outra limitação está relacionada à string de busca, pois a mesma foi formada por
diversas palavras, entretanto, alguma palavra importante pode não ter sido incluída
neste termo. Sendo assim, a string foi bem abrangente para evitar este problema, tanto
que chegou a capturar com a busca estudos fora do contexto de interesse.
Em relação aos critérios de inclusão e exclusão, o ano de publicação dos estudos
foi limitado no intervalo contemplando o ano 2000 até 2013, já que a string de busca foi
rodada no início 2014 e necessitava-se do ano completo, objetivando buscar o maior
período possível para minimizar o viés do período de buscas na revisão sistemática. E
por fim, como alternativa para evitar o viés na seleção dos estudos, testes pilotos foram
realizados em cada etapa da pesquisa e estas foram realizadas por mais de um
pesquisador. Quando houve conflitos entre opiniões na seleção dos estudos, era
acionado um terceiro pesquisador para resolver a divergência. Somente a fase de
75 extração de dados foi realizada por um único pesquisador, o autor desta dissertação e
auxiliado pelo orientador deste trabalho.
5.2 Implicações para a Pesquisa e Prática
Os resultados alcançados com a conclusão deste trabalho possuem implicações
tanto para a pesquisa, quanto para a prática.
No campo de pesquisa:
Aumento no número de pesquisas sobre a análise de impacto;
Sumarização dos benefícios e limitações em um catálogo;
A maior parte dos estudos identificados e utilizados na síntese desta pesquisa
obtiveram resultado através da aplicação de estudos de caso e pouco (ou não)
foi aplicados surveys, pesquisa-ação e grounded theory, logo abre-se a
oportunidade para pesquisas com a aplicação destes métodos.
Para a prática:
Os resultados podem ajudar a entender melhor a aplicação da análise de
impacto, através do conhecimento de seus benefícios e limitações;
O guia de boas práticas pode servir como roteiro de orientação para aplicar a
análise de impacto da melhor forma.
5.3 Recomendações para Trabalhos Futuros
A partir da condução deste trabalho, podem ser adotadas as seguintes
recomendações para futuras pesquisas com novos direcionamentos:
Complementar esta pesquisa através da construção de um survey para
investigar as práticas de sucesso em empresas e comparar com o guia
produzido nesta dissertação (originado da revisão sistemática), assim, será
possível analisar se a realidade encontrada dentro das empresas é a mesma
encontrada na literatura.
Atualizar os dados da revisão sistemática, incluindo os anos seguintes a que
esta pesquisa foi limitada (2013), procurando identificar alguma possível nova
técnica ou solução que tenha apresentado um resultado em sua análise,
significativamente mais preciso, quando comparado a técnicas já identificadas.
Para isso, pode ser conduzido um experimento que compare técnicas e avalie
qual pode ser melhor adotada.
Figura 8:
Processo de seleção da revisão
76
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. APIWATTANAPONG, T.; ORSO, A.; HARROLD, M. J. Efficient and precise dynamic impact analysis using execute-after sequences. In: Proceedings of the 27th international conference on Software engineering (ICSE ’05). New York, NY, USA: ACM, 2005. p. 432–441. ISBN 1-59593-963-2. APIWATTANAPONG, TAWEESUP. Identifying testing requirements for modified software. PhD thesis, Georgia Institute of Technology, 2007. BENNETT, K. H. An introduction to software maintenance. Information and Software Technology, vol. 12, no. 4, pp. 257–264, 1990. BOHNER, S AND ARNOLD, R. Software Change Impact Analysis. IEEE Computer society Press, Los Alamitos, CA, USA, 1996. BOHNER, S. A. A graph traceability approach for software change impact analysis. Ph.D. dissertation, George Mason University, Fairfax, VA, USA, 1995. BOHNER, S. A. Impact analysis in the software change process: a year 2000 perspective. In Proceedings of the 12th International Conference on Software Maintenance (ICSM’96), Monterey, CA, November 1996, pp. 42–51. BOHNER, S. A. Software change impacts - an evolving perspective. In: Proceedings of the International Conference on Software Maintenance (ICSM’02). Washington, DC, USA: IEEE Computer Society, 2002. p. 263–2. ISBN 0-7695-1819-2. BOHNER, S. AND ARNOLD, R. Impact Analysis - Towards a Framework for Comparison. Proceeding of the International Conference on Software Maintenance, (1993) September 27-30, Montreal, Canada. BREECH, B.; DANALIS, A; SHINDO, S. AND L. POLLOCK. Online impact analysis via dynamic compilation technology. pages 453–457, Sept. 2004. BREECH, B.; TEGTMEYER, M.; POLLOCK, L. A comparison of online and dynamic impact analysis algorithms. In: Proceedings of the Ninth European Conference on Software Maintenance and Reengineering (CSMR ’05). Washington, DC, USA: IEEE Computer Society, 2005. p. 143–152. ISBN 0-7695-2304-8. DYBÅ, T.; DINGSøYR, T. Empirical Studies of Agile Software Development: A
Systematic Review. Information and Software Technology, Butterworth-Heinemann
Newton, MA, USA, v. 50, n. 9, p. 833-859, August 2008.
78 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.
ERLIKH, LEN. Leveraging legacy system dollars for e-business. IT Professional, 2(3):17– 23, 2000. GIL, A. C. Como elaborar projetos de pesquisa. 5. ed. - São Paulo: Atlas, 2010.
HASSINE, J. RILLING, J., HEWITT, J. AND DSSOULI, R. 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. HATTORI, LILE PALMA. Análise probabilística de impacto de mudanças baseada
em históricos de mudanças de software. Master’s thesis, Universidade Federal de
Campina Grande, Campina Grande, Brasil, Fevereiro 2008.
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. KITCHENHAM, B. Guidelines for performing Systematic Literature Reviews in Software Engineering. Software Engineering Group, School of Computer Sciences and Mathematics, Keele University, and Department of Computer Science, University of Durham.[S.l.]. 2007. LAKATOS, E. M.; MARCONI, M. A. Fundamentos de Metodologia Científica. São
Paulo: Atlas, 2011.
LAW, JAMES AND ROTHERMEL, GREGG. Whole program path-based dynamic impact analysis. In ICSE ’03: Proceedings of the 25th International Conference on Software Engineering, pages 308–318, Washington, DC, USA, 2003. IEEE Computer Society. LEE, M; OFFUTT, A. J. AND ALEXANDER, R. T. Algorithmic analysis of the impacts of changes to object-oriented software. In Proceedings of the 34th International Conference on Technology of Object- Oriented Languages and Systems (TOOLS 34), Santa Barbara, CA, USA, July 2000, pp. 61–70.
79 LEHNERT, Steffen. A review of software change impact analysis. Ilmenau University of Technology, Tech. Rep, 2011.
LI, BIXIN et al. A survey of code‐based change impact analysis techniques. Software Testing, Verification and Reliability, v. 23, n. 8, p. 613-646, 2013. LIONS, J.L. ARIANE 5, Flight 501 Failure, Report by the Inquiry Board. European Space Agency, July 1996. 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. ORSO, A. et al. An empirical comparison of dynamic impact analysis algorithms. In: Proceedings of the 26th International Conference on Software Engineering (ICSE ’04). Washington, DC, USA: IEEE Computer Society, 2004. p. 491–500. ISBN 0-7695-2163-0. ORSO, ALESSANDRO; TAWEESUP, APIWATTANAPONG and HARROLD, MARY JEAN. 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. PFLEEGER, SHARI LAWRENCE AND BOHNER, SHAWN A. A framework for software maintenance metrics. In IEEE Transactions on Software Engineering, pages 320–327, May 1990. RAJLICH, V. AND GOSAVI, P. Incremental change in object-oriented programming. IEEE Software, vol. 21, no. 4, pp. 62–69, 2004. RANDOLPH, JUSTUS. A Guide to Writing the Dissertation Literature Review. Practical Assessment, Research & Evaluation, 14(13), 2009. ROVEGARD, P.; ANGELIS, L. AND WOHLIN, C. An empirical study on views of importance of change impact analysis issues. IEEE Transactions on Software Engineering, 34(4):516–530, 2008. RYDER, B. AND TIP, F. Change impact analysis for object-oriented programs. In Proceedings of the 2001 ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering (PASTE ’01), Snowbird, Utah, USA, June 2001, pp. 46–53. SUN, X. B. AND LI, B. X. Change impact analysis techniques. Technical report, Institute of Software Testing and Verification, Southeast University, Nanjing, China, 4 2009. 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. TURVER, R. J. AND MUNRO, M. An Early Impact Analysis Technique for Software Maintenance. Journal of Software Maintenance: Research and Practice. vol. 6, no. 1, (1993). WAZLAWICK, R. Metodologia de pesquisa para ciência da computação. Páginas 40 – 45. Elsevier Brasil, 2009.
81
APÊNDICE A – PROTOCOLO DA REVISÃO SISTEMÁTICA
O conteúdo deste apêndice refere-se ao protocolo da revisão sistemática
conduzida para esta dissertação, utilizada como forma de coleta de dados.
Participaram da RSL 04 pesquisadores, alunos do mestrado, Aline Chagas Rodrigues
Marques, Bruno, Leandro Melo e Joelson Isidro da Silva Araújo e orientação do
professor Alexandre Marcos Lins de Vasconcelos, o qual atuou como revisor deste
protocolo.
A versão final deste protocolo foi elaborada por Joelson Isidro da Silva Araújo,
sob orientação dos professores Alexandre Marcos Lins de Vasconcelos.
82
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
REVISÃO SISTEMÁTICA SOBRE A ANÁLISE DE IMPACTO EM MUDANÇA DE
SOFTWARE
(Protocolo de Pesquisa)
JOELSON ISIDRO DA SILVA ARAÚJO
Prof. Supervisor: Alexandre Vasconcelos ([email protected])
UNIVERSIDADE FEDERAL DE PERNAMBUCO
WWW.CIN.UFPE.BR/~POSGRADUACAO
2013
Equipe
83
Nome Afiliação Papel
Joelson Isidro da Silva Araújo
CIn – Universidade Federal de Pernambuco
Autor
Aline Chagas Rodrigues Marques
CIn – Universidade Federal de Pernambuco
Autora
Bruno Nascimento CIn – Universidade Federal de Pernambuco
Autor
Leandro Melo CIn – Universidade Federal de Pernambuco
Autor
Alexandre Marcos Lins de Vasconcelos
CIn – Universidade Federal de Pernambuco
Co-autor e Revisor
84 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 [12].
O impacto da mudança em uma parte de um sistema pode ser caro e até mesmo
desastroso, isso porque, os softwares tornam-se cada vez maiores e mais complexos
[9]. A análise de impacto auxilia o planejamento de modificações, através da previsão
de efeitos e os custos associados [19].
A realização de atividade da análise de impacto requer diferentes abordagens e
implementações [8] para diferentes fases, tais como a de manutenção e a do
desenvolvimento de software.
Conforme [3], 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 [17, 18]. De
modo geral, existem duas categorias que classificam o tipo da técnica utilizada na
análise de impacto: a estática (artefatos são analisados a fim de identificar
dependências estruturais entre as demais entidades do sistema e as entidades da
mudança) e a dinâmica (a dependência entre artefatos é obtida pela análise de dados
da execução do programa).
O problema em torno da análise de impacto está associado aos seus resultados,
uma vez que, a análise contém 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 [16].
Tendo em vista o contexto apresentado, faz-se necessário a construção de
pesquisas que tratem dos erros encontrados na análise de impacto para buscar a
melhoria em seu processo, permitindo assim, a redução de imprecisões no resultado
gerado.
85 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
Realizar uma revisão sistemática da literatura para identificar em um determinado
intervalo de tempo todas as informações relevantes sobre melhorias em técnicas de
análise de impacto que propuseram uma redução de imprecisão.
4. PROTOCOLO Kitchenham et al. (2007) apresentam um guia para a elaboração de revisões
sistemáticas que divide o processo em três partes fundamentais, são elas: o
planejamento, a condução da revisão e a divulgação dos resultados. Como ponto de
partida é necessário à construção de um protocolo de pesquisa, onde estão
especificados os métodos que serão utilizados. Além disso, sua construção permite a
redução de viés do pesquisador.
Sendo assim, esta pesquisa se baseia nos procedimentos indicados por [11] e
serão apresentados nas subseções seguintes.
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
4.2 QUESTÕES DE PESQUISA
Conforme [7], toda pesquisa se inicia com algum tipo de problema, ou indagação
e o mesmo deve ser formulado como pergunta. Para compreender o estado da arte
sobre os benefícios e limitações da análise de impacto e investigar as melhorias
propostas para a redução de imprecisões, foram formuladas as seguintes questões de
pesquisa, as quais esta pesquisa visa responder:
QP1: O que se sabe atualmente sobre os benefícios e limitações da Análise de
Impacto em mudança de software?
QP2: O que se tem feito para minimizar os erros gerados na análise (reduzir
imprecisões)?
4.3 ESTRATÉGIA DE BUSCA
Segundo Kitchenham et al. (2007) o objetivo de uma RSL é encontrar o maior
número possível de estudos primários relacionados com a questão de pesquisa e para
isso se faz necessário a utilização de uma estratégia de busca que deve ser
determinada e seguida. O rigor adotado no processo de busca é um fator que distingue
RSLs de revisões tradicionais.
Uma das estratégias de busca para os estudos primários pode ser automática
e/ou manual. Este estudo adota uma abordagem de busca automática que será
realizada a partir da execução da string de busca, no período de 2000 a 2013.
O processo para definir a estratégia está dividido em: definir os termos de busca
da pesquisa, criação da string de busca, elencar as fontes de buscas, relatar os
critérios de seleção, descrever o processo de seleção dos estudos e os recursos a
serem pesquisados.
4.4 TERMOS DA BUSCA Dybå e Dingsøyr (2008) recomendam que os termos da busca sejam
abrangentes para incluir o maior número de estudos e evitar perda de pesquisas
relevantes. Sendo assim, procurou-se agrupar o maior número de palavras que
pudessem estar relacionadas ao propósito desta revisão.
Os termos de busca, seus sinônimos ou palavras relacionadas estão
apresentados na Tabela 1.
87 Tabela 1: Termos de busca e equivalência para o inglês
Termos de busca Sinônimos ou Palavras Relacionadas
Software, desenvolvimento, projeto, desenvolvimento de software, desenvolvimento de aplicações, desenvolvimento de sistema de informação, projeto de software, engenharia de software, produção de software
Software, development, project, software development, development application, information system development, software project, software engineering, software production
Mudança, manutenção, alteração, evolução
Change, maintenance, modification, alteration, evolution
Análise de impacto, análise estática, análise dinâmica
Impact analysis, static analysis, dynamic analysis
4.5 STRING DE BUSCA De posso dos termos de busca definidos, cabe agora agrupa-los para a
construção da string de busca. Será utilizado o booleano OR para incorporar as grafias
alternativas para os principais termos e o booleano AND para compor as junções.
Tabela 2: String de busca
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”)
4.6 FONTES DE BUSCA As fontes selecionadas para esta revisão são as principais bases de dados
eletrônicas de relevância, citadas por [5] e [11].
Base de dados Eletrônica Website Compendex (Engineering Village) http://www.engineeringvillage.com
ScienceDirect – Elsevier http://www.sciencedirect.com/ Scopus – Elsevier http://www.scopus.com/ IEEE Xplore http://ieeexplore.ieee.org/
4.7 CRITÉRIOS DE SELEÇÃO DOS ESTUDOS Os principais métodos empíricos aplicáveis e relevantes para a engenharia de
software baseada em evidências são apresentados por [6]. Sendo assim, a seleção dos
estudos será guiada pelos seguintes métodos: experimentos controlados (incluindo
quasi-experimentos), estudos de caso (do tipo exploratório e de confirmação), pesquisa
de opinião (survey), etnografias e pesquisa-ação.
88
Dessa forma, os critérios de inclusão e exclusão são baseados nas questões de
pesquisa e são apresentados a seguir.
4.7.1 CRITÉRIOS DE INCLUSÃO CI1: Somente estudos primários;
CI2: Estudos que apresentem dados empíricos;
CI3: Estudos industriais e/ou acadêmicos que apresentam dados sobre análise de
impacto em mudança de software;
CI4: Papers contendo técnicas, métodos ou qualquer tipo de iniciativa para avaliar a
análise de impacto em mudança de software;
CI5: Estudos que apresentam dados em formato científico;
CI6: Somente estudos escritos em inglês;
CI7: Estudos publicados entre (e incluídos) 2000 e 2013;
CI8: Trabalhos completos publicados em revistas revisadas por pares ou conferências.
4.7.2 CRITÉRIOS DE EXCLUSÃO CE1: Estudos cujo foco não é em análise de impacto;
CE2: Estudos que não apresentam dados empíricos sobre melhorias no processo ou
técnica de análise de impacto;
CE3: Resumo de palestras, tutoriais e documentos incompletos;
CE4: Papers com resultados duplicados em diferentes fontes;
CE5: Estudo não empírico, estudos não acessíveis, secundários ou terciários;
CE6: Papers não relacionados à análise de impacto;
CE7: Artigos com apenas lições aprendidas e relato de experiência;
CE8: Artigos meramente baseados na opinião de especialistas.
4.8 PROCESSO DE SELEÇÃO DOS ESTUDOS PRIMÁRIOS Esta fase tem o objetivo de identificar os principais estudos primários, sendo
assim, quatro pesquisadores farão a análise dos artigos de acordo com as 4 fases
descritas na Figura 1 a seguir:
89 Figura 1: Processo de seleção dos estudos
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
Lista com os estudos resultantes da busca
Obtenção da lista de estudos primários relevantes e avaliação da qualidade Fase 4
Identificação dos potenciais estudos primários relevantes através da leitura do título e resumo
Fase 2
Aplicação dos critérios de inclusão e exclusão Fase 3
Busca automática
Fase 1
Estratégia de busca
90 sobre as divergências, os pesquisadores devem incluir os artigos que motivaram as
divergências para análise mais detalhada numa fase posterior. Será formada uma lista
consolidada com os estudos potencialmente relevantes.
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.
4.9 AVALIAÇÃO DA QUALIDADE DOS ESTUDOS Para avaliar a qualidade dos trabalhos foram estabelecidos alguns critérios de
qualidade sugeridos em [5], [10] e [11]. Tais critérios estão descritos conforme
Formulário A abaixo:
O formulário A será utilizado para registrar os dados relativos à avaliação da
qualidade dos estudos dos estudos incluídos na pesquisa.
Formulário A - Avaliação da Qualidade
ID do estudo: Pesquisador: Data de Avaliação:
Avaliação da qualidade
Legenda: Não atende = 0, Neutro = não deixa claro = 0.5, Atende = 1.
Item Critérios de qualidade Nota de avaliação
Quanto ao objetivo
1 Existe uma clara declaração dos objetivos da pesquisa?
91
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
- O pesquisador justificou os métodos que foram escolhidos?
- O pesquisador fez os métodos explícitos (por exemplo, há uma
indicação de como as entrevistas foram realizados, eles usaram
um guia de entrevista)?
- Se os métodos foram modificados durante o estudo, o
pesquisador explicou como e por quê?
- O formulário de dados é claro (por exemplo, gravação, material
de vídeo, notas, etc)
- Foram utilizados métodos de controle de qualidade para garantir
a integridade e precisão da coleta de dados?
Quanto à análise de dados
7 A análise dos dados foi suficientemente rigorosa?
Considere o seguinte:
- Houve uma descrição detalhada do processo de análise?
- Se foi utilizada a análise temática, como as categorias / temas
foram obtidas a partir dos dados?
- Têm sido apresentados dados suficientes para apoiar os
resultados?
- Até que ponto os dados contraditórios foram levados em conta?
- Os métodos de controle de qualidade foram utilizados para
verificar os resultados?
Quanto à Reflexividade (relações de parceria de pesquisa / reconhecimento de viés
pesquisador)
8 A relação entre o pesquisador e os participantes foi
considerada adequadamente?
Considere o seguinte:
- Será que o pesquisador examina criticamente o seu próprio
papel, preconceito e potencial influência na formulação de
questões de investigação, o recrutamento da amostra, coleta de
dados e análise e seleção de dados para a apresentação?
- Como o pesquisador respondeu a eventos durante o estudo e se
considerou as implicações de quaisquer alterações no projeto de
pesquisa?
Quanto às descobertas
9 Existe uma declaração clara dos resultados?
Considere o seguinte:
- Os resultados são explícitos (por exemplo, magnitude de efeito)?
- Uma discussão adequada da prova, a favor e contra argumentos
do pesquisador, foi demonstrada?
- O pesquisador discutiu a credibilidade dos seus resultados (por
exemplo, a triangulação, validação com entrevistado, mais do que
um analista)?
- As limitações do estudo são discutidas explicitamente?
- Os resultados são discutidos em relação às questões de
investigação originais?
- As conclusões são justificadas pelos resultados?
Quanto ao valor da pesquisa
10 O estudo apresenta o valor do estudo para pesquisa ou
prática?
Considere o seguinte:
- O pesquisador discutiu a contribuição do estudo (por exemplo, ele
considera os resultados em relação à prática atual ou literatura
baseada em pesquisa relevante)?
93
- Será que a pesquisa identifica novas áreas em que a investigação
é necessária?
- Será que o pesquisador discutiu se e como os resultados podem
ser transferidos para outras populações, ou considera outras
maneiras em que a pesquisa possa ser utilizada?
NOTA TOTAL (NT)
CLASSIFICAÇÃO = (NT / TOTAL POSSÍVEL)X100 = N (%)
OBS:
N >= 86% (Excelente)
66% =< N <= 85% (Muito Boa)
46% =< N <= 65% (Boa)
26% =< N <= 45% (Média)
N < 26% (Baixa)
Para realizar a avaliação de qualidade, será necessário considerar os critérios
do Formulário A e fornecer uma nota, a qual será com base na escala Likert de três
pontos [13], que é um instrumento que permite aos pesquisadores atribuírem respostas
gradativas sobre suas opiniões a respeito dos itens. Nesta revisão, os dois
pesquisadores utilizarão os seguintes itens de likert para avaliar os critérios:
Não Atende (0): deve ser concedido no caso em que não existe nada no
trabalho que atenda ao critério avaliado.
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.
Por fim, é feito o somatório da pontuação, atribuindo, assim, a nota total do
estudo em relação à qualidade. Os estudos serão avaliados por dois pesquisadores.
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.
A classificação da qualidade dos estudos será feita em cinco faixas conforme [2],
a partir da nota total da avaliação do estudo. As faixas de classificação da qualidade
são apresentadas na Tabela 3 a seguir:
Tabela 3: Classificação da qualidade dos estudos
Nota do Estudo (%) Classificação da qualidade
N >= 86% Excelente
66% =< N <= 85% Muito Boa
94
46% =< N <= 65% Boa
26% =< N <= 45% Média
N < 26% Baixa
4.10 ESTRATÉGIA DE EXTRAÇÃO DOS DADOS O processo de extração e a análise ocorrerão paralelamente, em que os dados
serão recolhidos e analisados com o objetivo de responder cada questão de pesquisa.
Os estudos que não apresentem informações relevantes para responder as questões
de pesquisa serão excluídos.
A extração dos dados será realizada por um pesquisador, que aplicará os
critérios contidos no Formulário B, registrando as informações relevantes. A revisão
desse processo será feita pelo orientador desta pesquisa.
O formulário B será utilizado para registrar os dados relativos à coleta de dados
dos estudos incluídos na pesquisa.
Formulário B - Coleta de dados
Pesquisador:
Data da coleta:
ID Autores Ano Fonte Título Método de
pesquisa
Coleta
de
dados
Análise dos dados
(qualitativa,
quantitativa, mista).
Tamanho
da amostra
Técnica
Coleta de Evidências
QP1: O que se sabe atualmente sobre os benefícios e limitações da Análise de Impacto em mudança de
software?
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:
4.11 SÍNTESE DOS DADOS A síntese dos dados pode ser quantitativa e/ou qualitativa, sendo um processo
que reúne e resume as evidências extraídas dos estudos primários incluídos na
pesquisa (KITCHENHAM et al., 2007). Esta pesquisa tem natureza qualitativa, logo
será realizada uma síntese qualitativa dos dados.
O processo de sintetizar os estudos primários qualitativos consiste da integração
de estudos que se constituem de conclusões e resultados em linguagem natural.
95 Nesses resultados em linguagem natural podem conter termos e conceitos similares
atribuídos por diferentes pesquisadores, porém, com alguns significados diferentes
(KITCHENHAM et al., 2007).
Para realizar a síntese dos dados, assim como evitar essa confusão de termos e
conceitos durante a integração dos estudos, Kitchenham et al. (2007) apresentam três
abordagens para a síntese qualitativa, de acordo como proposto por Noblit e Hare
(1988): A abordagem de tradução recíproca, a abordagem de síntese refutacional, e à
abordagem de Síntese de linha de Argumento.
Este estudo será baseado na abordagem de Síntese de Linha de Argumento
que é utilizada quando os pesquisadores querem inferir sobre um tema como um todo
a partir de um conjunto de estudos selecionados. A análise baseada nessa abordagem
é divida em duas partes:
1 - Os estudos primários são analisados individualmente, logo depois se tenta
analisar o conjunto de estudos como um todo.
2 - Evidências importantes são identificadas, organizadas e documentadas em
tabelas.
O processo de identificação, coleta e codificação dos dados qualitativos consiste
na marcação de partes de textos nos estudos qualitativos. Essas partes devem
fornecer informações para responder as questões de pesquisa. Esses textos
encontrados são associados a um identificador único, que mostram qual tipo, ou
categoria de informação esse texto apoia.
Assim, para esta técnica será empregada para auxiliar no processo de síntese
dos dados. Desta forma, esta revisão sistemática de natureza qualitativa, tenta procurar
as soluções propostas na literatura que conseguiram minimizar as imprecisões na
análise de impacto.
4.12 ESTRATÉGIA DE DIVULGAÇÃO DOS RESULTADOS Nesta etapa os resultados desta pesquisa serão apresentados conforme
guideline proposto por [11]: Título; Autores; Resumo; Background (justificativa da
necessidade da revisão); Questões da RSL; Método da RSL (estratégia de busca, fonte
de dados, seleção dos estudos, avaliação da qualidade, extração e síntese dos dados,
divulgação dos dados); Estudos incluídos e excluídos; Resultados; Discussão e
Conclusões.
96 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.
[2] BEECHAN, S. et al. Motivation in Software Engineering: A systematic literature
review. Information and Software Technology: Elsevier, v. 50, n. 860 -878, 2007.
[3] BOHNER, S. A. Software change impacts - an evolving perspective. In:
Proceedings of the International Conference on Software Maintenance (ICSM’02).
Washington, DC, USA: IEEE Computer Society, 2002. p. 263–2. ISBN 0-7695-1819-2.
[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.
[5] DYBÅ, T.; DINGSøYR, T. Empirical Studies of Agile Software Development: A
Systematic Review. Information and Software Technology, Butterworth-Heinemann
Newton, MA, USA, v. 50, n. 9, p. 833-859, August 2008.
[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.
[10] KAMEI, F., K. Benefícios e limitações das metodologias ágeis no
desenvolvimento de software. Dissertação (mestrado em ciências da computação) -
Centro de Informática- CIn, Universidade Federal de Pernambuco - UFPE, Recife,
2012.
[11] Kitchenham, B.; Charters, S. Guidelines for Performing Systematic Literature
Reviews in Software Engineering. Keele University. [S.I.], 2007.
[12] Len Erlikh. Leveraging legacy system dollars for e-business. IT Professional,
2(3):17– 23, 2000.
[13] LIKERT, R. A Technique for the Measurement of Attitudes. Archives of
Psychology 140: pp. 1-55, 1932.
97 [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).
[18] S. Bohner and R. Arnold. Impact Analysis - Towards a Framework for
Comparison. Proceeding of the International Conference on Software Maintenance,
(1993) September 27-30, Montreal, Canada.
[19] S. Bohner and R. Arnold. Software Change Impact Analysis. IEEE Computer
society Press, Los Alamitos, CA, USA, 1996.
98
APÊNDICE B – RESULTADO DA AVALIAÇÃO DA QUALIDADE DOS ESTUDOS PRIMÁRIOS
ID CQ1 CQ2 CQ3 CQ4 CQ5 CQ6 CQ7 CQ8 CQ9 CQ10 NOTA(NT)
CLASSIFICAÇÃO = (NT / TOTAL POSSÍVEL)X100 = N
(%) QUALIDADE
S0031 1 1 1 0,5 1 1 1 0 0,5 0 7 70 Muito boa
S0054 1 1 1 0,5 1 0,5 1 0 0,5 0 6,5 65 Boa
S0089 1 1 1 0 0,5 0,5 0,5 0 0,5 0 5 50 Boa
S0094 1 1 1 0 1 1 1 0 0,5 0 6,5 65 Boa
S0106 1 1 0,5 0 0,5 0,5 0,5 0 0 0 4 40 Média
S0178 1 1 1 0,5 1 1 1 1 0,5 0,5 8,5 85 Muito boa
S0199 1 1 1 0,5 1 1 1 1 0,5 0,5 8,5 85 Muito boa
S0259 1 1 1 0 1 1 1 1 1 0,5 8,5 85 Muito boa
S0275 1 1 1 0 1 1 1 0 0 0 6 60 Boa
S0355 1 1 1 0 1 1 1 1 0,5 0 7,5 75 Muito boa
S0433 1 1 1 0 1 1 1 1 0,5 0,5 8 80 Muito boa
S0462 1 1 1 0 1 1 1 1 0,5 0,5 8 80 Muito boa
S0478 1 1 1 0 1 1 1 1 0,5 0,5 8 80 Muito boa
S0484 1 1 1 1 1 1 1 1 0,5 0,5 9 90 Excelente
S0496 1 1 1 0,5 1 1 1 0 0,5 0 7 70 Muito boa
S0536 1 1 1 0 1 1 1 0 1 0,5 7,5 75 Muito boa
S0608 1 0,5 0 0 1 0,5 1 0 1 0,5 5,5 55 Boa
S0648 1 1 0 0 1 0 0,5 0 0,5 0,5 4,5 45 Média
S0661 1 1 0,5 1 1 0,5 0,5 0 0,5 1 7 70 Muito boa
S0665 1 1 0 0 0,5 0,5 1 0 0,5 0,5 5 50 Boa
S0668 1 1 0 0,5 0,5 0,5 0,5 0 0,5 0,5 5 50 Boa
S0671 1 1 0,5 0,5 0,5 1 0,5 0 0,5 0 5,5 55 Boa
S0727 1 1 0,5 0 1 1 0,5 0 1 0,5 6,5 65 Boa
S0776 1 1 0 0 1 0,5 1 0 0,5 0 5 50 Boa
S0787 1 1 1 0,5 1 1 1 0,5 1 1 9 90 Excelente
S0827 1 1 0 0 0,5 1 0,5 0 0,5 0,5 5 50 Boa
S0982 1 0,5 0 0 0,5 0,5 0 0 0,5 0,5 3,5 35 Média
S1051 1 1 0 0 0,5 0,5 0,5 0 0,5 0,5 4,5 45 Média
S1093 1 1 1 0,5 1 1 1 1 1 0,5 9 90 Excelente
S1152 1 1 1 0 0,5 1 0,5 1 0,5 0 6,5 65 Boa
S1213 1 1 0,5 0,5 0,5 0,5 0,5 1 1 1 7,5 75 Muito boa
S1243 1 1 0 0,5 0,5 1 1 0 0,5 1 6,5 65 Boa
S1244 0,5 1 0 0 0,5 0 0 0 0 0 2 20 Baixa
S1306 1 1 1 0,5 1 1 1 1 1 1 9,5 95 Excelente
S1324 1 1 1 0 0,5 1 1 0 1 1 7,5 75 Muito boa
S1330 1 1 0 0 0,5 1 0,5 0 0 0 4 40 Média
S1540 0,5 1 0,5 1 0,5 1 1 0 1 0,5 7 70 Muito boa
S2155 1 1 1 0 1 1 1 1 1 1 9 90 Excelente
S2265 1 1 0 0 1 0,5 0,5 0 0,5 0,5 5 50 Boa
99
S2267 1 1 0 0 0,5 1 1 0 0,5 1 6 60 Boa
S2280 1 1 0 0 0,5 0,5 1 0 1 1 6 60 Boa
S2283 0,5 1 0 0 1 0,5 0,5 0 0,5 1 5 50 Boa
S2284 1 1 0 0 1 1 1 0 0,5 0,5 6 60 Boa
S2294 1 1 1 0,5 1 1 1 0 0,5 0,5 7,5 75 Muito boa
S2295 1 1 1 0 1 0,5 1 1 1 1 8,5 85 Muito boa
S2344 1 1 1 0 1 0,5 1 0 0,5 0,5 6,5 65 Boa
S2367 1 1 0,5 0 0,5 0,5 0,5 0 0 0 4 40 Média
S2372 1 1 1 0 1 1 1 0 0,5 0 6,5 65 Boa
S2542 1 1 1 0,5 1 1 1 0 0,5 0,5 7,5 75 Muito boa
S2564 1 1 1 0,5 1 1 1 0 1 1 8,5 85 Muito boa
S2609 1 1 1 1 1 1 1 0 1 1 9 90 Excelente
S2718 1 1 1 1 1 1 1 1 1 1 10 100 Excelente
S2930 1 1 1 1 1 1 1 0 1 1 9 90 Excelente
S2942 1 1 1 0,5 1 1 1 1 1 1 9,5 95 Excelente
S2944 1 1 1 0,5 1 1 1 1 1 1 9,5 95 Excelente
S2951 1 1 1 0 1 1 1 0 1 1 8 80 Muito boa
S3040 1 1 1 0 1 1 1 0 0,5 0,5 7 70 Muito boa
S3078 1 1 1 0 1 1 1 0 0,5 0 6,5 65 Boa
S3218 1 1 1 0,5 1 1 1 1 0,5 0,5 8,5 85 Muito boa
S3220 1 1 1 0,5 1 1 1 0 0,5 0,5 7,5 75 Muito boa
S3224 1 1 1 1 1 0,5 0,5 0 1 0,5 7,5 75 Muito boa
S3235 0,5 1 0,5 0 1 0,5 1 1 1 1 7,5 75 Muito boa
S3237 1 1 1 0 1 0,5 1 1 1 1 8,5 85 Muito boa
S3248 1 1 0 0 0,5 1 0,5 0 0,5 1 5,5 55 Boa
S3251 0,5 1 1 1 0,5 0,5 0,5 0 0,5 1 6,5 65 Boa
S3259 1 1 0 0 1 1 0,5 0 0,5 1 6 60 Boa
S3272 1 1 1 0 0,5 0,5 1 1 1 1 8 80 Muito boa
S3307 1 1 0 0 1 1 0,5 1 1 1 7,5 75 Muito boa
S3320 1 1 1 0 0,5 1 0,5 1 1 1 8 80 Muito boa
S3321 1 1 1 0,5 1 0,5 1 1 1 1 9 90 Excelente
S3338 1 1 1 0,5 1 1 1 0 0,5 1 8 80 Muito boa
S3515 0,5 1 1 0,5 0,5 1 1 0 1 1 7,5 75 Muito boa
S3518 1 1 0 0 0,5 0,5 1 0 1 1 6 60 Boa
S3522 1 1 0 0 0,5 1 0,5 0 0,5 0,5 5 50 Boa
S3543 1 1 1 0 1 1 1 0 0,5 1 7,5 75 Muito boa
S3586 1 1 1 0 1 1 1 1 1 1 9 90 Excelente
100
APÊNDICE C – DADOS DE CONTEXTO
Tabela 18: Lista de estudos incluídos na revisão.
ID Ano Referência
S0031 2004
Ren, X., et al. "Chianti: A tool for change impact analysis of java programs". 19th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA'04, 2004. 432-448.
S0054 2006
Abdi, M. K; Lounis, H. and Sahraoui, h. "Analyzing change impact in object-oriented systems". 32nd Euromicro Conference on Software Engineering and Advanced Applications, SEAA, 2006. 310-317
S0094 2005
Bradi, L; Bradi, M. and St-Yves, D. "Supporting predictive change impact analysis: A control call graph based technique". Proceedings of Asia-Pacific Software Engineering Conference, APSEC, 2005. 167-175.
S0106 2000
Lee, M.; Jefferson Offutt, A. and Alexander, R. T. "Algorithmic analysis of the impacts of changes to object-oriented software". Proceedings of 34th International Conference on Technology of Object-Oriented Languages and Systems TOOLS 34, 2000. 61-70.
S0178 2003
Orso, Alessandro; Apiwattanapong, Taweesup and Harrold, Mary Jean. "Leveraging Field Data for Impact Analysis and Regression Testing". Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering, 2003. 128-137.
S0199 2005
Breech, B. et al. "A comparison of online and dynamic impact analysis algorithms". Ninth European Conference on Software Maintenance and Reengineering, 2005. 143-152.
S0259 2010
Tóth, G. "A comparison of programmers' opinions in change impact analysis". Periodica Polytechnica, Electrical Engineering, Vol. 54, No. 3-4 (2010). 111-121.
S0275 2008
Jász, Judit. "Static execute after algorithms as alternatives for impact analysis". Period. Polytech. Elec. Eng., Vol. 52, No. 3-4 (2008). 163-176.
S0355 2003
Law, J., and Rothermel, G. "Whole program path-based dynamic impact analysis". In Proceedings of the International Conference on Software Engineering (2003). 308–318.
S0433 2012
M. Gethers, B. Dit, H. Kagdi, and D. Poshyvanyk. “Integrated impact analysis for managing software changes”. In Proceedings of the 34th IEEE/ACM International Conference on Software Engineering (ICSE’12), Zurich, Switzerland, June 2-9, 2012. 430–440.
101
S0462 2010
Sun XB, Li BX, Tao CQ, Wen WZ, Zhang S. "Change impact analysis based on a taxonomy of change types". International Conference on Computer Software and Applications, Seoul, Korea, 2010. 373–382.
S0478 2012
Sun, X., Li, B., Li, B., Wen, W. "A comparative study of static cia techniques". In Proceedings of the Fourth Asia-Pacific Symposium on Internetware, 2012
S0484 2011
Hassaine, S., Boughanmi, F., Gu´eh´eneuc, Y.G., Hamel, S., Antoniol, G. "A seismology-inspired approach to study change propagation". In: ICSM (2011). 53-62.
S0496 2011
Sun, X. et al. "HSM-based change impact analysis of object-oriented java programs". Chinese Journal of Electronics, Vol. 20, No. 2, 2011. 247-251.
S0536 2012
Rungta, N. ; Person, S. ; Branchaud, J. "A change impact analysis to characterize evolving program behaviors". 28th IEEE International Conference on Software Maintenance (ICSM), 2012. 109-118.
S0608 2013
Kama, N. "Change impact analysis for the software development phase: State-of-the-art". International Journal of Software Engineering and its Applications, Vol. 7, No. 2, 2013. 235-244.
S0648 2011
Xiaobing Sun and Bixin Li. "Using formal concept analysis to support change analysis". In 26th International Conference on Automated Software Engineering (ASE), 2011. 641–645.
S0665 2010
M. O. Hassan, L. Deruelle, and H. Basson. “A knowledge-based system for change impact analysis on software architecture”. In Proceedings of the Fourth International Conference on Research Challenges in Information Science (RCIS), Nice, France, 2010. 545–556.
S0668 2010
Li, L. et al. "Assessing object-oriented software systems based on change impact simulation". Proceedings - 10th IEEE International Conference on Computer and Information Technology (CIT), 7th IEEE International Conference on Embedded Software and Systems (ICESS), 10th IEEE Int. Conf. Scalable Computing and Communications (ScalCom), 2010. 1364-1369.
S0671 2010
Ge, Y. and Bai, L. "Probability-based safety related requirements change impact analysis". Proceedings 3rd IEEE International Conference on Computer Science and Information Technology (ICCSIT), 2010. 719-722.
S0727 2008
D. M. German, A. E. Hassan, and G. Robles. “Change impact graphs: Determining the impact of prior code changes". Information and Software Technology, Vol. 51, 2008. 1394–1408.
102
S0776 2011
Gethers, M., Kagdi, H., Dit, B., and Poshyvanyk, D., "An Adaptive Approach to Impact Analysis from Change Requests to Source Code", In Proceedings of International Conference on Automated Software Engineering, 2011
S0827 2013
Person, S. and Rungta, N. "Maintaining the health of software monitors". Innovations in Systems and Software Engineering, Vol. 9, No 4, 2013. 257-269.
S0982 2011
Bharti Chimdyalwar and Shrawan Kumar. "Effective false positive filtering for evolving software". In Proceedings of the 4th India Software Engineering Conference, 2011.
S1051 2010
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 14th European Conference on Software Maintenance and Reengineering (CSMR’10), 2010.
S1093 2013
X. Sun, B. Li, W. Wen, and S. Zhang. "Analyzing impact rules of different change types to support change impact analysis". International Journal of Software Engineering and Knowledge Engineering, 2013. 259–288
S1152 2001
A. von Knethen. “A Trace Model for System Requirements Changes on Embedded Systems”. International Workshop on Principles of Software Evolution (IWPSE’ 01), 2001.
S1213 2005
Hassine, J., Rilling, J., Hewitt, J. and Dssouli, R. "Change Impact Analysis for Requirement Evolution using Use Case Maps". Proc. of the 8th Int. Workshop on Principles of Software Evolution, 2005. 81-90
S1243 2010
W.-T. Lee, W.-Y. Deng, J. Lee, and S.-J. Lee, “Change Impact Analysis with a Goal-Driven Traceability-Based Approach”. Int. J. of Intelligent Systems, Vol.25 , 2010. 878-908
S1306 2013
Li, B. , Zhang, Q., Sun, X., Leung, H. "Using water wave propagation phenomenon to study software change impact analysis". Advances in Engineering Software, Vol. 58, 2013. 45-53
S1324 2010
Malik, H. and Shakshuki, E. 2010. "Predicting Function Changes by Mining Revision History". Information Technology: New Generations (ITNG), 2010 Seventh International Conference on (Apr. 2010), 950–955.
S2283 2005
Buckner, J., Buchta, J. , Petrenko, M. , Rajlich, V. "JRipples: A tool for program comprehension during incremental change". 13th International Workshop on Program Comprehension, IWPC 2005.
S2284 2008
Zhang, S. , Gu, Z. , Lin, Y. , Zhao, J. "Change impact analysis for AspectJ programs". 24th IEEE International Conference on Software Maintenance, ICSM 2008. 87-96
S2294 2008
Jashki, M.-A. , Zafarani, R. , Bagheri, E. "Towards a more efficient static software change impact analysis method". Workshop on Program Analysis for Software Tools and Engineering, PASTE '08, 2008.
103
S2295 2009
Petrenko, M. , Rajlich, V. "Variable granularity for improving precision of impact analysis". IEEE 17th International Conference on Program Comprehension, ICPC '09, 2009. 10-19
S2344 2006
Krishna Ramanathan, M.; Grama, A.; Jagannathan, S. "Sieve: A tool for automatically detecting variations across program versions". 21st IEEE/ACM International Conference on Automated Software Engineering, ASE '06, 2006. 241-252
S2367 2001
Ryder, B.G., Tip, F. "Change impact analysis for object-oriented programs". ACM SIGPLAN -SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE'01), 2001. 46-53
S2372 2006
Breech, B. , Tegtmeyer, M. , Pollock, L. "Integrating influence mechanisms into impact analysis for increased precision". 22nd IEEE International Conference on Software Maintenance - ICSM, 2006. 55-64
S2542 2013
Kama, N. "Integrated change impact analysis approach for the software development phase". International Journal of Software Engineering and its Applications, 2013. 293-304.
S3040 2005
Apiwattanapong, T., Orso, A., Harrold, M. J. "Efficient and precise dynamic impact analysis using execute-after sequences". In Proceedings of the 27th international conference on Software engineering ICSE' 05, 2005. 432-441.
S3078 2006
Canfora, G., Cerulo, L. "Fine grained indexing of software repositories to support impact analysis". In Proceedings of the 2006 international workshop on Mining software repositories MSR' 06, 2006. 105-111.
S3218 2010
Kagdi, H., Gethers, M., Poshyvanyk, D., Collard, M.L. "Blending conceptual and evolutionary couplings to support change impact analysis in source code". In 17th Working Conference on Reverse Engineering, WCRE 2010. 119-128.
S3224 2010
Maia, M.C.O. et al. "The hybrid technique for object-oriented software change impact analysis". In 14th European Conference on Software Maintenance and Reengineering, CSMR 2010.
S3237 2012
Li, B. , Sun, X., Leung, H. "Combining concept lattice with call graph for impact analysis". Advances in Engineering Software, Vol. 53, 2012. 1-13
S3251 2012
Ali, H.O., Rozan, M.Z.A. , Sharif, A.M. "Identifying challenges of change impact analysis for software projects". International Conference on Innovation, Management and Technology Research, ICIMTR 2012.
S3272 2011
Sun, X. et al. "Using lattice of class and method dependence for change impact analysis of object oriented programs". 26th Annual ACM Symposium on Applied Computing, SAC 2011. 1439-1444
104
S3307 2013
Dam, H.K., Ghose, A. "Supporting change impact analysis for intelligent agent systems". Science of Computer Programming, Vol. 78, No 9, 2013. 1728-1750
S3320 2009
Abdi, M.K. , Lounis, H. , Sahraoui, H. "A probabilistic approach for change impact prediction in object-oriented systems". In 5th IFIP Conference on Artificial Intelligence Applications and Innovations, Vol. 475, 2009. 189-200
S3321 2013
Lehnert, S., Farooq, Q.-U.-A. , Riebisch, M. "Rule-based impact analysis for heterogeneous software artifacts". 17th European Conference on Software Maintenance and Reengineering, CSMR 2013. 209-218
S3338 2013
Asl, M.H. , Kama, N. "A change impact size estimation approach during the software development". 22nd Australasian Conference on Software Engineering, ASWEC, 2013. 68-77
Fonte: Próprio autor (2015).
Tabela 19: Dados de contexto dos estudos incluídos.
ID Método de Pesquisa
Análise dos Dados Técnica Ambiente Abordagem Classe
S0031 Estudo de caso Quantitativa Chianti
Orientado a Objetos Estática Rastreabilidade
S0054 Experimento Quantitativa Meta modelo
Orientado a Objetos Estática Dependência
S0094
Experimento Quantitativa
CCGImpact (Control Call
Graph Impact) Orientado a
Objetos Estática Dependência
S0106 Estudo de caso Quantitativa ChAT
Orientado a Objetos Estática Dependência
S0178 Experimento Quantitativa Field Data
Orientado a Objetos Dinâmica Dependência
S0199 Experimento Quantitativa
Oerientado a Objetos Dinâmica Dependência
S0259 Experimento Qualitativa Estática Dependência
S0275
Experimento Quantitativa
Satatic Execution After (SEA)
Orientado a Objetos Estática Dependência
S0355 Experimento controlado Quantitativa PathImpact Dinâmica Dependência
S0433 Estudo de caso Quantitativa
Orientado a Objetos Dinâmica Rastreabilidade
105
S0462
Estudo de caso Quantitativa
OOCMDG (Object
Oriented Class and Member Dependence
Graph) Orientado a
Objetos Estática Dependência
S0478 Estudo comparativo Quantitativa
Orientado a Objetos Estática Dependência
S0484 Estudo empírico
Qualitativa e Quantitativa
Orientado a Objetos Estática Dependência
S0496 Estudo de caso Quantitativa
HSMImpact (Hierarchical
Slicing Model) Orientado a
Objetos Estática Dependência
S0536
Estudo de caso Quantitativa
iDiSE (Uma extensão para DiSE - Direct Incremental
Symbolic Execution) Procedural Híbrida Dependência
S0608 Revisão Qualitativa Híbrida Dependência
S0648 Estudo empírico Qualitativa
FCA (Formal Concept Analysis)
Orientado a Objetos Estática Dependência
S0665
Estudo de Caso Qualitativa
ASCM (Architectural
Software Components
Model) Orietado a
Objetos Dependência
S0668
Estudo de caso Quantitativa
SAMCIS (Software
Assessment Method based Change Impact
Simulation) Orientado a
Objetos Estática Dependência
S0671 Quantitativa Estática Rastreabilidade
S0727 Estudo de caso Quantitativa
Change Impact Graphs (CIGs)
Oerientado a Objetos Estática Dependência
S0776 Dinâmica Dependência
S0827
Quantitativa
Directed Incremental
Symbolic Execution
(DiSE) Orientado a
Objetos Híbrida
S0982 Experimento Quantitativa Procedural Estática Dependência
106
S1051
Estudo de Caso
CIASYS (Change Impact
Analysis at System Level)
Orientado a Objetos Híbrida
S1093
Estudo de caso Quantitativa
OOCMDG (Object
Oriented Class and Member Dependence
Graph) Orientado a
Objetos Estática Dependência
S1152
Um experimento controlado e dois estudos
de caso Qualitativa e Quantitativa
Sistemas de controle
embarcados Estática Rastreabilidade
S1213 Estudo de caso
UCM Impact Analysis Estática Rastreabilidade
S1243
Orientado a Objetos Estática Rastreabilidade
S1306 Estudo de caso Quantitativa WAVE-CIA
Orientado a Objetos Estática Dependência
S1324 Estudo empírico Quantitativa Híbrida Dependência
S2283 Qualitativa Jripples
Orientado a Objetos Estática Depêndencia
S2284 Quantitativa Celadon
Orientado a 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 Experimento Qualitativa
Orientado a Objetos Estática Dependência
S2372 Estudo de caso Quantitativa
Orientado a Objetos Híbrida Dependência
S2542 Estudo de caso Quantitativa Híbrida
Dependência e Rastreabilidade
S3040 Estudo de caso Quantitativa CollectEA
Orientado a Objetos Dinâmica Depêndencia
S3078 Estudo de caso Quantitativa Estática Rastreabilidade
S3218 Estudo de caso Quantitativa Estática Depêndencia
107
S3224
Estudo de caso de mútliplo
casos Quantitativa SD-Impala Orientado a
Objetos Híbrida Depêndencia
S3237 Estudo de caso Quantitativa
Orientado a Objetos Híbrida Depêndencia
S3251 Entrevistas Qualitativa Estática
S3272 Estudo de
caso Quantitativa
LoCMD (Lattice of Class and Method
Dependence) Orientado a
Objetos Estática Depêndencia
S3307 Experiemento Quantitativa
Orientado a Agentes
Estática e Dinâmica Depêndencia
S3320 Quantitativa
Orientado a Objetos
S3321 Estudo de caso Quantitativa EMFTrace Estática Rastreabilidade
S3338 Estudo de caso Quantitativa
CISE (Change Impact Size Estimation)
Esática e Dinâmica
Rastreabilidade e Depêndencia
Fonte: Próprio Autor (2015).
108
APÊNDICE D – EVIDÊNCIAS DAS MELHORIAS ENCONTRADAS NOS ESTUDOS
Tabela 20: Evidências de melhorias em técnicas de análise de impacto.
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
combinations help counter the precision or recall deficit of individual
techniques and improve the overall accuracy
outlines integrated approaches to provide automated support to software
developers in different impact analysis scenarios
defines several sources of information, the analyses used to derive the data,
and how the information can be combined to support impact analysis at the
change request level
shows statistically significant gains in precision and recall up to 17% and
41% respectively
[S0536] combines static and dynamic calling context information to efficiently
generate impacted program behaviors across calling contexts
can generate impacted behaviors and avoid exploring behaviors that are not
impacted by the change
[S0608] to identify thorough consequences of making a change in a software project,
an effective combination between the traceability analysis and the
dependency analysis is important
[S0665] approach to deal with the change impact analysis between software
architecture and its source code implementation
allows representing the informations extracted from architectural
descriptions, independently of architecture description languages
[S0776] integrate information from orthogonal sources to attain potentially more
accurate results for change impact analysis
approach to IA at change request level that automatically adapts to the
specific software maintenance scenario at hand
approach uses a scenario driven combination of IR, dynamic analysis, and
MSR techniques to analyze incoming change requests, execution traces and
prior changes to estimate an impact set
[S0827] combines the efficiency of static program analysis techniques with the
precision of dynamic analysis techniques to compute the impact of software
changes in terms of program execution behaviors
addresses the scalability issues associated with symbolic execution using
the results of the static analysis to direct symbolic execution toward the parts
of the program impacted by the changes
DiSE is a precise and conservative technique for generating the set of
110
impacted program execution behaviors
The application of DiSE results to the coloring of the nodes in the Bayesian
network is quite useful for manually inspecting the effects of a change to the
monitored system
DiSE could be adapted to generate impacted simulations of a system based
on the changes
The impacted simulations could then be used to help maintain the
prognostics system
[S1051] The suite will use hybrid analysis techniques to benefit from all the
advantages of static and dynamic analyses
Hybrid and higher level methods are potential solutions for the weaknesses
of static analysis and dynamic analysis
[S1324] combine the best of data mining and impact analysis to guide change
propagation
provides the recommendation to developers based on the best heuristic that
tends to be the best predictor for change entity
MSR takes a multi-version view to software-change prediction
past versions of the software artefacts are analyzed to uncover pertinent
information and trends of software changes that are then used to predict
changes
[S3224] combines program static and dynamic analysis into a hybrid technique and
ranks results based on dynamic information
technique to reduce the number of false-negatives in impact analysis
improved recall between 90 and 115% compared to the static technique, and
between 21.2 and 39% compared to the dynamic one
[S3237] provide a combined approach based on concept lattice and call graph that
can remove more false-positives over these two standalone approaches
improves the precision of the impact set without severely decreasing its
recall, when compared to other two standalone approaches
[S0982] an effective idea of suppressing recurring false positives in evolving large
software systems
The solution is scalable on millions of LOC and can suppress about 80% of
the already reviewed false positives without adding any significant overhead
[S1306] call graph-based CIA technique, which takes the interference among multiple
111
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
[S0727] a method which determines the impact of historical code changes on a
particular code segment
determines all the changed areas of the software system which affect the
reported location of a failure
creates a change impact graph to determine what areas might have been
affected by certain changes to help maintainers rapidly pinpoint the source of
a bug given the reported location of a failure
permits developers to considerably prune the size of the investigated
dependence graph
developers can better focus their attention to the nodes that are most likely
the cause for the failure
[S2372] improving the precision of the less expensive coarse-grained techniques by
supplementing the impact analysis with knowledge of how impacts can
propagate among functions
influences can be derived by a fast scan of the program’s source code
The time required to perform the analysis is reasonable
[S0199] performing impact analysis online, using a dynamic compiler, scales better
than current dynamic impact analysis algorithms
[S0462] depends on two respects: the change types of a modified entity and the
dependence types between other entities and the modified entity
precision can be reached based on the thought that: if the initial impact set is
estimated more accurately, then the potential impact set depending on this
initial impact set will be obtained more precisely
[S0496] conducted as three steps: first, hierarchical change sets are defined at
different granularity levels, then CIA process is promoted based on the HSM,
finally the hierarchical impact sets are computed from package-level to
statement-level
Stepwise slicing algorithm (SSA) is used and thus can improve the precision
of the impact sets in comparison to traditional static CIA techniques,
particularly at finer-granularity level
When we obtain statement level slices, many irrelevant packages, classes
and methods have been ignored, thus the whole cost is decreased
compared to traditional slicing approaches
[S1093] impact rules of different change types to support change impact analysis and
113
improve the precision of the impact results
Impact rule of a change considers two aspects: change types of a modified
entity and the dependencies between other entities and the modified one
factor to improve the precision of the impact set is to first compute an initial
impact set (IIS) having direct dependency with the program entities in the
change set
utilize the history of changes to measure the accuracy of the CIA techniques
The initial impact set has high precision with fewer false-positives
potential impact set and final impact set have high recall, which can removes
many false-negatives
[S2542] provides high level steps that support the inclusion of the partially developed
class analysis in the dynamic analysis technique implementation
impact analysis process identifies a set of potential impacted classes using
the class interactions prediction according to change request specification.
The outcome of this process is a set of initial impacted classes
The filtration process aims at eliminating some typically false results
generated by the impact analysis process
gives higher accuracy of results over the selected current impact analysis
approaches
[S3338] change impact size estimation (CISE) approach that utilizes an integrated
impact analysis technique for the software development phase
can automatically perform all the processes of integrated change impact
analysis and change
impact size estimation predict the impacted classes and then estimate their
change size
The MMRE value which used to measure the mean error rate of this
approach is calculated to be 6.30%, which demonstrates that the CISE
approach is 93.7% accurate
[S3272] calculates a ranked list of potential impacted methods according to a metric,
impact factor, which corresponds to the priority of these methods to be
inspected
[S0648] support various change analysis activities in the framework
support change analysis for a given change proposal before change
implementation
114
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
approach is able to determine impacted artifacts with reliable precision and
recall
determine the impact sets defined by our oracle with an average precision
and recall of well above 80%
identified only few false-positives and did not overestimate the propagation
of changes
propagation strategy provided reliable and stable figures for precision and
recall
[S3078] predict impacted files from a change request definition
method exploits information retrieval algorithms to link the change request
description and code entities impacted by similar past change requests
data stored in software repositories are a good descriptor on how past
change requests have been resolved
consider a finer level of granularity, lines of code, and we show that this
introduces an improvement at least of 10%, at the cost of spending more
time and space for the index
[S3307] dynamic technique improved both recall (123% and 133%) and precision
(between 25% and 76%) compared to the static technique
[S3218] disjunctive combination of IR and MSR techniques, across several cut points
(impact set sizes), provides statistically significant improvements in accuracy
over either of the two standalone techniques
findings indicate that in certain cases an improvement of 20% in recall is
115
achieved when conceptual and evolutionary coupling is combined
Information Retrieval (IR) is used to derive conceptual couplings from the
source code in a single version (release) of a software system
Evolutionary couplings are mined from source code commits
[S0355] identifies impact at a coarser level than that provided by fine-grained
analyses, but it is much more precise than call graph based analysis, and
requires no dependence analysis
instrumentation on which the technique is based has a relatively low
overhead and can be performed on binaries, so the technique does not
require access to source code
The SEQUITUR data compression algorithm is used to reduce the size of
the trace that is collected
[S0178] To use field data, a technique must constrain both the instrumentation
required to collect the data and the data collected for each execution
requires only lightweight instrumentation and collects data on the order of a
few kilobytes per execution
when using stable field data, technique FIELD provided, by definition,
accurate information on the actual impact of the changes
[S0094] contrary to traditional static techniques based on Call Graphs (CG), our
technique is more precise. It captures the control related to calls between
components
It allows reducing the size of the sets of methods that can be affected after a
given change
we build the set of potential methods that may be affected by a given change
incrementally. In this way, the technique allows avoiding the eventual too
large sets such as it is the case in others approaches
[S3040] algorithm that collects and analyzes only a small amount of dynamics
information and is, thus, time and space efficient
technique is practical: it is almost as efficient as CoverageImpact and as
precise as Path-Impact
[S2294] method benefits from dimensionality reduction techniques to reduce the
complexity of the collected information and perform the impact analysis
process faster
Fonte: Próprio autor (2015).