Les logiciels dépendent de bibliothèques tierces pour réduire les coûts liés à leur développement et à leur maintenance. Elles proposent un ensemble de fonctionnalités robustes dont les développeurs peuvent tirer parti depuis une interface de programmation. Cependant, cette forte dépendance entre un logiciel et ses bibliothèques oblige les développeurs à reconsidérer leur rôle lorsque le logiciel évolue. Dans cette thèse, nous identifions plusieurs problématiques impliquant les bibliothèques tierces dans un contexte de maintenance logicielle. Plus particulièrement, une bibliothèque peut ne plus répondre aux besoins d’un logiciel et doit être remplacée par une nouvelle.Nous nommons cette opération une migration de bibliothèque.Nous soulevons dans ce contexte trois points qui caractérisent les difficultés rencontrées par les développeurs. Vers quelle bibliothèque migrer ? Comment appliquer la migration ? Avec l’aide de quels développeurs ? Cette thèse discute de solutions et apporte des contributions autour de ces problèmes. Nous présentons plusieurs approches et les évaluons lors de différents cas d’étude. L’analyse de l’évolution logicielle sera notre support de travail, dont la méthodologie est basée sur l’observation des changements de logiciels. Nous décrivons les limites actuelles de nos contribu-tions et ouvrons des perspectives futures pour enrichir l’état de l’art dans ce domaine / Software depend on third-party libraries to reduce development and maintenance costs. Developers have access to robust functionalities through an application programming interface designed by these libraries. However, due to the strong relationship with these libraries, developers have to reconsider their position when the software evolves. In this thesis, we identify several re-search problems involving these third-party libraries in a context of software maintenance. More specifically, a library may not satisfy the software new requirements and has to be replaced by anew one. We call this operation a library migration.We leverage three points that characterize the impediments met by developers in this situation.To which library should they migrate ? How to migrate their software ? Who can help them in this case ? This thesis suggests answers and exposes several contributions to these problems. We define three approaches that are evaluated through several case studies. To achieve this work, weuse a methodology based on software evolution analysis to observe and understand how software change. We describe numerous perspectives to overcome the current limitations of our solutions.

The problems of software debugging and system reliability/availability are among the most challenging problems the computing industry is facing today, with direct impact on the development and operating costs of computing systems. A promising debugging technique that assists programmers identify and fix the causes of software bugs a lot more efficiently is bidirectional debugging, which enables the user to execute the program in "reverse", and a typical method used to recover a system after a fault is backwards error recovery, which restores the system to the last error-free state. Both reverse execution and backwards error recovery are enabled by creating memory checkpoints, which are used to restore the program/system to a prior point in time and re-execute until the point of interest. The checkpointing frequency is the primary factor that affects both the latency of reverse execution and the recovery time of the system; more frequent checkpoints reduce the necessary re-execution time. Frequent creation of checkpoints poses performance challenges, because of the increased number of memory reads and writes necessary for copying the modified system/program memory, and also because of software interventions, additional synchronization and I/O, etc., needed for creating a checkpoint. In this thesis I examine a number of different hardware accelerators, whose role is to create frequent memory checkpoints in the background, at minimal performance overheads. For the purpose of reverse execution, I propose the HARE and Euripus hardware checkpoint accelerators. HARE and Euripus create different types of checkpoints, and employ different methods for keeping track of the modified memory. As a result, HARE and Euripus have different hardware costs and provide different functionality which directly affects the latency of reverse execution. For improving the availability of the system, I propose the Kyma hardware accelerator. Kyma enables simultaneous creation of checkpoints at different frequencies, which allows the system to recover from multiple types of errors and tolerate variable error-detection latencies. The Kyma and Euripus hardware engines have similar architectures, but the functionality of the Kyma engine is optimized for further reducing the performance overheads and improving the reliability of the system. The functionality of the Kyma and Euripus engines can be combined into a unified accelerator that can serve the needs of both bidirectional debugging and system recovery.

[pt] Em um sistema de software, as anomalias de código indicam problemas estruturais que podem ser resolvidos através da refatoração. No entanto, desenvolvedores podem negligenciar ou acabar criando novas anomalias ao refatorar. Pouco foi relatado sobre os efeitos benéficos e prejudiciais da refatoração de anomalias de código. Evidências sugerem que os desenvolvedores frequentemente precisam aplicar uma sequência de refatorações (refatoração em lote) para remover completamente as estruturas anômalas. Assim, nesta tese, realizamos uma série de estudos para entender o impacto de refatorações simples e em lote em anomalias de código. Em nossos primeiros estudos, analisamos com que frequência os tipos de refatoração comumente usados afetam a densidade de anomalias ao longo das histórias de dezenas de projetos. Mesmo que 79,4 por cento das refatorações tenham tocado em elementos anômalos, 57 por cento não reduziram suas ocorrências. Surpreendentemente, apenas 9,7 por cento das refatorações removeram anomalias de código, enquanto 33 por cento induziram a introdução de novas. Por um lado, observamos padrões nocivos de introdução de anomalias. Por outro lado, observamos que muitas anomalias podem ser removidas apenas por refatorações em lote. Assim, nossos últimos estudos investigam o impacto de refatorações em lote nas anomalias. Mesmo quando aplicadas em lotes, as refatorações tendem a não afetar ou mesmo aumentar a densidade de anomalias. Também identificamos padrões entre tipos de lotes e tipos de anomalias, levando-nos à criação de heurísticas que podem orientar os desenvolvedores durante tarefas de remoção de anomalias de código. O último estudo avaliou essas heurísticas e concluímos que os resultados são promissores. / [en] Code smells in a program represent indications of structural quality problems, which can be addressed by software refactoring. However, developers may neglect or end up creating new code smells through single refactoring. Little has been reported about recurring beneficial and harmful effects of refactoring on the program structural quality. As a consequence, developers still miss guidance along non-trivial smell-removing tasks. In fact, evidence suggests developers often need to apply a sequence of refactorings, so-called batch refactoring, to entirely remove a smelly code structure. Thus, in this thesis, we have conducted a series of studies to understand the impact of single and batch refactorings on code smells. In our first studies, we analyze how often commonly-used types of single refactoring affect the density of code smells along the version histories of dozens of projects. Even though 79.4 percent of the refactorings touched smelly elements, 57 percent had no impact on the smell removal. Surprisingly, only 9.7 percent of refactorings removed smells, while 33 percent induced the introduction of new ones. On one hand, we observed that harmful refactoring-smell patterns could be used to guide developers to avoid smell-inducing refactoring. On the other hand, we observed that many smells can be removed only through batch refactoring. Thus, our last studies investigate the impact of batch refactorings on smells. Even when applied in batches, refactorings tend to maintain or even increase the density of code smells. We also identified common batch-smell patterns, which enable us to create heuristics that can guide developers through smell-removing tasks. The last study evaluated those heuristics, and we conclude the outcomes are promising.

[pt] Os elementos de código geralmente mudam ao longo da evolução do sistema, o que implica em uma eventual degradação estrutural do código fonte. Sintomas recorrentes de tal degradação são chamados anomalias de código. Estudos sugerem que quanto mais anomalias de código afetam um sistema, mais alta se torna a propensão a bugs dos elementos de código. Para lidar com tal degradação da qualidade estrutural do código, desenvolvedores geralmente aplicam refatorações no código fonte. No entanto, aplicar refatorações pode não ser suficiente para reduzir a propensão a bugs dos elementos de código degradados. Um estudo recente sugere que refatorações induzem bugs frequentemente. No entanto, os autores não analisam se o código refatorado está, de fato, diretamente relacionado à introdução de bugs. Com isso, nesta dissertação, realizamos dois estudos longitudinais de múltiplos projetos para avaliar a propensão a bugs do código refatorado. Nossa metodologia teve como objetivo abordar várias limitações de estudos anteriores. Por exemplo, definimos duas propriedades complementares da propensão a bugs do código refatorado, sendo elas, frequência e distância. Enquanto a primeira propriedade quantifica a frequência com que um código refatorado está relacionado a bugs que emergiram no código fonte, a distância quantifica o quão próximo um bug surge depois que uma refatoração é aplicada. Nosso primeiro estudo tem como objetivo avaliar a propensão a bugs de refatorações isoladas. Primeiro, nossos resultados mostram que 80 porcento dos elementos degradados que se tornaram bugs não foram previamente refatorados. Este resultado implica que um código refatorado é menos propenso a bugs do que um código não refatorado. Em segundo lugar, em 75 porcento das vezes um bug surge depois de 7 mudanças feitas a partir da operação de refatoração, o que geralmente corresponde à 3 meses nos projetos analisados. Nosso segundo estudo tem como objetivo avaliar a propensão a bugs de refatorações em lote, ou seja, refatorações aplicadas em sequência. Nossos resultados mostram que, na maioria dos casos, o código refatorado em lotes é mais resiliente à introdução de bugs do que o código refatorado por meio de refatorações isoladas. / [en] Programs often change along the system evolution, which implies an eventual code structure degradation. Recurring symptoms of such degradation are code smells. Studies suggest that the more frequently code smells affect a system, the higher becomes the bug-proneness of the code elements. To tackle code structural quality degradation, developers often apply refactorings on smelly program elements. However, applying refactorings might not suffice to reduce the bug-proneness of such degraded program elements. Previous empirical studies do not systematically analyze the bug-proneness of refactored code. Even though a recent study suggests that refactoring induces bugs frequently, the authors do not analyze to what extent refactored code is indeed closely related to the bug occurrence. Thus, in this dissertation, we conducted two longitudinal multi-project studies to assess the bugproneness of refactored code. Our methodology aimed to address various limitations of previous studies. For instance, we have defined two complementary properties of the bug-proneness of refactored code, i.e., frequency and distance. While the former quantifies how often a refactored code is related to emerging bugs, the latter quantifies how close a bug emerges after a refactoring has been applied. The quantitative analysis of such properties was complemented by a manual analysis of refactorings closely related to the bug occurrence. Our first study aims at assessing the bug-proneness of code refactored through isolated refactorings, i.e., a single refactoring operation not performed in conjunction with other refactoring operations. This study reveals that 80 per cent of the smelly elements that became buggy were not previously refactored. This result suggests the refactored code is much less bug-prone than non-refactored code. Moreover, in 75 per cent of the times, a bug emerges in 7 changes far from the refactoring operation; this amount of changes usually corresponds to 3 months in the analyzed projects. Our second study aims at assessing the bug-proneness of code elements refactored through batch refactorings, i.e., a sequence of inter-related refactoring operations. Our results show that code refactored through batches is often more resilient to the introduction of bugs as compared to code refactored through isolated refactorings.

Made available in DSpace on 2016-06-02T19:05:51Z (GMT). No. of bitstreams: 1 3771.pdf: 2012363 bytes, checksum: beac2e75d3e67d4b8d96a9b1c3ce98ef (MD5) Previous issue date: 2011-05-27 / Universidade Federal de Sao Carlos / Aspect-Oriented Programming allows encapsulating the so-called "Crosscutting Concerns (CCC) - software requirements whose implementation is tangled and scattered throughout the functional modules - into new abstractions, such as Aspects, Pointcuts, Advices and Inter-type Declarations. The reengineering of an OO software to an AO is not an easy task due to the existence of different abstractions in these technologies. We develop a set of nine refactorings of annotated OO class models to AO class models. In the context of this work, "annotated class models" are UML class diagrams whose elements (classes, interfaces, attributes and methods) are annotated with stereotypes representing the existing CCC in the application source code. The set of refactorings developed is divided into: i) generic refactorings; and ii) specific refactorings. Three generic refactorings and six specific refactorings to the persistence (which is divided into management and connections, transaction and synchronization) and logging concerns and to the Singleton and Observer design patterns were created. The generic refactorings are responsible for transforming an annotated OO model with indications of CCC into a partial AO model. This model is called partial because it is usually not fully modularized, i.e., there are remaining software elements stereotyped with indications of particular concerns. These refactorings are applicable to any kind of CCC; this is possible, because what is taken into consideration is the scenario in which these concerns appear in the class model. The specific refactorings are responsible for transforming partial AO models into final ones, whose CCC have been fully modularized in aspects. For that, each refactoring has a set of specific steps for modularization of a particular kind of concern. An Eclipse plug-in, called MoBRe was developed to assist the software engineer in the tasks of refactoring application. As a major contribution, the refactorings proposed in this paper allow obtaining well designed AO models. This is so because: i) they provide a step-by-step guide to the modularization of certain CCC and can avoid that software engineers choose inappropriate strategies for modularization of these CCC; and ii) they were prepared based on good design practices recommended by the scientific community. Thus, besides, the models the use of refactorings can lead to generation of better-quality code, for example, free of bad smells. A case study was conducted to assess the applicability of the proposed refactorings in order to compare an AO model generated by them with an AO model obtained from the literature. / Orientação a Aspectos (OA) permite encapsular Interesses Transversais (ITs) - requisitos de software cuja implementação encontra-se entrelaçada e espalhada pelos módulos funcionais - em novas abstrações, tais como, Aspectos, Conjuntos de Junção, Adendos e Declarações Inter-tipo. A reengenharia de um software OO para um OA não é uma atividade trivial em consequência da existência de abstrações diferentes entre as tecnologias envolvidas. Neste trabalho é proposto um conjunto de refatorações que pode ser aplicado sobre modelos de classes OO anotados com indícios de ITs para obtenção de modelos de classes OA. Modelos de classes anotados são diagramas de classes da UML cujos elementos (classes, interfaces, atributos e métodos) são anotados com estereótipos referentes aos ITs existentes no software. O conjunto de refatorações desenvolvido é subdivido em: i) refatorações genéricas; e ii) refatorações específicas. As refatorações genéricas são responsáveis por transformar um modelo OO anotado com indícios de ITs em um modelo OA parcial - modelo cujos ITs existentes não são completamente modularizados. Essas refatorações são aplicáveis a qualquer tipo de IT existente no software, considerando o cenário que esses interesses apresentam no modelo de classes. As refatorações específicas são responsáveis por transformar modelos de classes OA parciais em modelos de classes OA finais - modelos nos quais os ITs foram completamente modularizados em aspectos. Para que isso aconteça, cada refatoração possui um conjunto de passos específicos para modularização de um determinado tipo de interesse. Três refatorações genéricas e seis refatorações específicas foram elaboradas para os interesses de persistência (subdividido em: gerenciamento de conexões, de transações e sincronização), de logging e para os padrões de projeto Singleton e Observer. Um plug-in Eclipse, denominado MoBRe, foi desenvolvido para auxiliar o Engenheiro de Software na tarefa de aplicação das refatorações. Como principal contribuição, a utilização das refatorações propostas neste trabalho pode permitir a obtenção de modelos OA que representam bons projetos arquiteturais, pois: i) fornecem um guia para modularização de determinados ITs, podendo evitar que Engenheiros de Software escolham estratégias inadequadas para modularização; e ii) foram elaboradas com base em boas práticas de projeto OA preconizadas pela comunidade científica. Assim, além dos modelos a utilização das refatorações pode levar à geração de códigos de melhor qualidade, por exemplo, livre da presença de bad smells. Um estudo de caso foi conduzido para verificar a aplicabilidade das refatorações propostas e os modelos OA resultantes foram equivalentes aos modelos obtidos na literatura.

A crescente demanda por novas aplicações informatizadas, e a evolução da sua complexidade, faz com que seja cada vez mais importante a correta aplicação de esforços no processo de desenvolvimento de software. Apesar da dificuldade em se obter dados, estudos empíricos sobre a evolução do software podem auxiliar na criação de modelos e teorias que aperfeiçoem os esforços de desenvolvimento. Tendo acesso a uma base de informações de mais de cinco anos de solicitações de mudanças (que incluem melhorias e correções) de uma mesma organização de desenvolvimento, o problema da pesquisa era obter indicadores dos projetos de desenvolvimento que estivessem relacionados aos maiores custos de mudanças. A partir dessa formulação, foi definido como objetivo efetuar a análise dos custos de mudanças e, para isso, os casos com os maiores tempos de desenvolvimento foram classificados (utilizando a classificação ODC – Orthogonal Defect Classification), analisados individualmente, comparados entre si e com outros estudos. Como resultado do trabalho de análise dos custos de mudanças de software, são apresentadas faixas de valores (no início de entrada em produção e ao final de vinte meses de utilização em produção) de métricas de software pela quais são efetuadas comparações e que, eventualmente, podem ser utilizadas como comparação para outros projetos da mesma ou de outras empresas. Foram identificadas características em um projeto em específico que propõe associar a métrica de entrelaçamento de pacotes, no momento de entrada em produção, com o principal impacto da dimensão ODC. Essa associação pode ser considerada como a principal indicação relacionada aos custos de manutenção do software e, por meio do estabelecimento dessa associação entre métricas observadas durante o processo de desenvolvimento de sistemas, pode-se diminuir custos futuros na etapa de manutenção de software. / The increasing demand for new computer applications and the evolution of its complexity makes increasingly important the correct application of effort in the process of software development. Despite the difficulty in obtaining data, empirical studies on the evolution of software can assist in the creation of models and theories that enhance development efforts. Having access to a database of information of more than five years of change requests (including improvements and fixes) of the same development organization, the research problem was to obtain indicators of development projects that were related to higher costs of change. From this formulation, was set to perform the objective analysis of the costs of change and, therefore, the cases with the greatest development times were classified (using the ODC - Orthogonal Defect Classification) analyzed individually, compared with each other and with other studies. Resulting of the work for examining costs of software changes, ranges of values are presented (early start of production and at the end of twenty months of production use) software metrics for which comparisons are made and eventually may be used as a comparison to other projects of the same or other companies. There were characteristics, in a specific project, that proposes to associate the Package tangle index at the time of entry into production, with the main impact of the size ODC. This association can be regarded as the main indication related to software maintenance costs, and by establishing an association between this metric observed during the development of systems, can reduce future costs in the software maintenance phase.

A classificação das issues ou questões nos repositórios de manutenção de software é realizada atualmente pelos desenvolvedores de software. Entretanto, essa classificação manual não é livre de erros, os quais geram problemas na distribuição das issues para as equipes de tratamento. Isso acontece porque os desenvolvedores, geralmente os propositores das issues, possuem o mal hábito de classificá-las como bugs. Essas classificações errôneas produzem a distribuição de issues para uma equipe de tratamento de outro tipo de issue, gerando retrabalho para as equipes entre outras desvantagens. Por isso, o principal objetivo almejado com o estudo é a melhoria dessa classificação, utilizando de uma abordagem de classificação das issues realizada de maneira automatizada. Essa abordagem foi implementada com técnicas de Aprendizado de Máquina. Estas técnicas mostram que as palavras-chave discriminantes dos tipos de issues podem ser utilizadas como atributos de classificadores automáticos para a predição dessas issues. A abordagem foi avaliada sobre 5 projetos open source extraídos de 2 issue trackers conhecidos, Jira e Bugzilla. Por se tratarem de issue trackers de longa data, os projetos escolhidos forneceram boa quantidade de issues para este estudo. Essas issues, cerca de 7000, foram classificadas por especialistas humanos no trabalho [Herzig, Just e Zeller 2013], produzindo um gabarito utilizado para a realização deste estudo. Este trabalho produziu um classificador automático de issues, com acurácia de 81%, capaz de discriminá-las nos tipos bug, request for enhancement e improvement. O bom resultado de acurácia sugere que o classificador concebido possa ser utilizado em sistemas de encaminhamento de issues para as equipes de tratamento, com a Ąnalidade de diminuir retrabalho dessas equipes que ocorre em virtude da má classificação. / The classification of issues in software maintenance repositories is currently done by software developers. However, this classification is conducted manually and is not free of errors, which cause problems in the distribution of issues to the maintenance teams. This happen because the developers, which usually are the proponents of the issues, have the bad habit of classifying them as bugs. This erroneous rating generates rework and other disadvantages to the teams. Therefore, the main objective of this study is to improve this classification, using an issue classification approach conducted in an automated manner. In turn, this approach was implemented based on machine learning tecniques. These tecniques show that keywords discriminant of issues types can be used as attributes of automatic classifiers for prediction of these issues. The approach was evaluated on five open source projects extracted from two widely used issue trackers, Jira and Bugzilla. Because they are old issue trackers, the chosen projects provided good number of issues for this study. These issues, about 7.000, were classified by human experts at work [Herzig, Just e Zeller 2013], producing a feedback which was used for this study. This present work produced an automatic issues classifier, with 81% of accuracy, able to predict them in types of bug, request for enhancement and improvement. The result of accuracy obtained by this classifier suggests that it can be used in delivery systems to treatment teams with the purpose of reducing rework that occurs in these teams because of the poor issues rating. / Dissertação (Mestrado)

Submitted by Nayara Passos (nayara.passos@ufpe.br) on 2015-03-13T13:04:40Z No. of bitstreams: 2 TESE Yaguaratã Cerqueira Cavalcanti.pdf: 2989671 bytes, checksum: cdde3d6cea6de1cabb90748865421b78 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-13T13:04:40Z (GMT). No. of bitstreams: 2 TESE Yaguaratã Cerqueira Cavalcanti.pdf: 2989671 bytes, checksum: cdde3d6cea6de1cabb90748865421b78 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2014 / The efficient management of Change Requests (CRs) is fundamental for successful software maintenance; however the assignment of CRs to developers is an expensive aspect in this regard, due to the time and expertise demanded. To overcome this, researchers have proposed automated approaches for CR assignment. Although these proposals present advances to this topic, they do not consider many factors inherent to the assignments, such as: developers’ workload, CRs severity, interpersonal relationships, and developers know-how. Actually, as we demonstrate in this work, CR assignment is a complex activity and automated approaches cannot rely on simplistic solutions. Ideally, it is necessary to consider and reason over contextual information in order to provide an effective automation. In this regarding, this work proposes, implements, and validates a context-aware architecture to automate CR assignment. The architecture emphasizes the need for considering the different information available at the organization to provide a more context-aware solution to automated CR assignment. The development of such architecture is supported by evidence synthesized from two empirical studies: a survey with practitioners and a systematic mapping study. The survey provided us with a set of requirements that automated approaches should satisfy. In the mapping study, in turn, we figured out how state-of-the-art approaches are implemented in regarding to these requirements, concluding that many of them are not satisfied. In addition, new requirements were identified in this mapping study. For the implementation of the proposed architecture, we developed a strategy to automate CR assignments which is based on two main components: a Rule-Based Expert System (RBES) and an Information Retrieval (IR) model. The strategy coordinately applies these two components in different steps to find the potential developer to a CR. The RBES takes care of the simple and complex rules necessary to consider contextual information in the assignments, e.g., to prevent assigning a CR to a busy or unavailable developer. Since these rules vary from one organization/project to another, the RBES facilitates their modification for different contexts. On the other hand, the IR model is useful to make use of the historical information of CR assignments to match CRs and developers. Results from the validation study showed that our solution is promising. It is, by comparing the solution with an approach that uses only a machine learning algorithm, such as the Support Vector Machine (SVM), we could improve the accuracy of assignments by almost 50%. The analysis of the solution’s payoff also pointed that such an accuracy is able to pay for the efforts necessary to deploy the solution.-------------------------------------O gerenciamento eficiente de solicitações de mudança (SM) é fundamental para o sucesso das atividades de manutenção e evolução de software. Entretanto, a atribuição de SMs a desenvolvedores é um aspecto custoso desse gerenciamento, pois demanda tempo e conhecimento apropriado do projeto de software. Várias pesquisas já propuseram métodos de atribuição automática de SMs. Embora representem avanços na área, existem fatores inerentes a atribuição de SMs que não são considerados nessas pesquisas e são essenciais para a automação. Como demonstrado nesse trabalho, a atribuição automática deve, por exemplo, considerar a carga de trabalho, a experiência e o conhecimento dos desenvolvedores, a prioridade e a severidade das SMs, a afinidade dos desenvolvedores com os problemas descritos nas SMs, e até mesmo os relacionamentos interpessoais. Para tornar esse cenário ainda mais complexo, esses fatos podem variar de acordo com o projeto de software que está sendo desenvolvido. Assim, uma solução para o problema de atribuição de SMs depende de informações contextuais. Assim, esse trabalho propõe, implementa e valida uma solução arquitetural sensível ao contexto para atribuição automática de SMs. Dado o aspecto contextual da solução, a arquitetura considera diversas fontes de informações presentes na organização, assim como a necessidade de se desenvolver algorítimos que implementem diferentes estratégias de atribuição. Nossa proposta de solução é embasada em resultados de duas pesquisas quantitativas: um estudo de mapeamento sistemático da literatura, e uma pesquisa de questionário com desenvolvedores de software. Esse último forneceu um conjunto de requisitos que a solução automatizada deve satisfazer para que as estratégias de atribuição sejam atendidas, enquanto o mapeamento da literatura identificou técnicas, algoritmos, e outros requisitos necessários a automação. A implementação da arquitetura segue uma estratégia de automação, definida nesse trabalho, que possui dois componentes principais: um sistema especialista baseado em regras (SEBR); e um modelo de recuperação de informação (MRI) com técnicas de aprendizagem. Em nossa estratégia, esses dois componentes são executados alternadamente em momentos diferentes a fim de atribuir uma SM automaticamente. O SEBR processa regras, considerando informações contextuais do projeto de software e da organização que o desenvolve. O MRI é utilizado para fazer o casamento entre SMs e desenvolvedores de acordo com o histórico de atribuições. Os resultados do estudo de validação apontaram que a solução é promissora. Isto é, ao compararmos nossa solução com uma abordagem que utiliza apenas um algoritmo de aprendizado de máquina, como o Support Vector Machine (SVM), pudemos melhorar em quase 50% a acurácia de atribuição. Já a análise de custo de implantação apontou que a acurácia atingida pela solução possui um bom custo benefício.

Submitted by Renata Lopes (renatasil82@gmail.com) on 2017-01-16T13:41:31Z No. of bitstreams: 1 marcosalexandremiguel.pdf: 10203756 bytes, checksum: 35844967ee919f58955320a1c591c5dc (MD5) / Approved for entry into archive by Diamantino Mayra (mayra.diamantino@ufjf.edu.br) on 2017-01-31T10:34:46Z (GMT) No. of bitstreams: 1 marcosalexandremiguel.pdf: 10203756 bytes, checksum: 35844967ee919f58955320a1c591c5dc (MD5) / Made available in DSpace on 2017-01-31T10:34:46Z (GMT). No. of bitstreams: 1 marcosalexandremiguel.pdf: 10203756 bytes, checksum: 35844967ee919f58955320a1c591c5dc (MD5) Previous issue date: 2016-09-01 / Muitas organizações encontram problemas na tentativa de estimar esforço em atividades de manutenção de software. Quando a estimativa de esforço não está bem definida ou é imprecisa, os resultados obtidos podem refletir diretamente na entrega do software, causando insatisfação do cliente ou diminuição da qualidade do produto. O sucesso ou fracasso de projetos depende da precisão do esforço e do cronograma das atividades envolvidas. O surgimento de métodos ágeis no campo de desenvolvimento de software tem apresentado muitas oportunidades e desafios para pesquisadores e profissionais da área. Um dos principais desafios é a estimativa de esforço para as atividades de manutenção no desenvolvimento ágil de software. Nesse contexto, este trabalho apresenta um framework, nomeado GiveMe Effort, o qual objetiva apoiar as atividades de estimativa de esforço na manutenção de software usando dados históricos e informações de compreensão de software. / Many organizations encounter problems when estimating effort for software maintenance activities. When estimating effort is not well defined or are inaccurate, the results may reflect directly into the software delivery, causing customer dissatisfaction or decreased product quality. The success or failure of projects depends on the accuracy of the effort and the schedule of involved activities. The rise of agile methods in software development has presented many opportunities and challenges for researchers and professionals. In this context, a key challenge is the effort estimate for maintenance activities in the agile software development context. This work presents a framework, called GiveMe Effort, to support the effort estimation activities in software maintenance. It is based on historical data and software comprehension information.

Submitted by Geandra Rodrigues (geandrar@gmail.com) on 2018-10-30T13:39:57Z No. of bitstreams: 1 helenodesouzacamposjunior.pdf: 1434985 bytes, checksum: 4307be9bfd2ca9825bcd2ce10bfc824e (MD5) / Approved for entry into archive by Adriana Oliveira (adriana.oliveira@ufjf.edu.br) on 2018-11-23T12:26:30Z (GMT) No. of bitstreams: 1 helenodesouzacamposjunior.pdf: 1434985 bytes, checksum: 4307be9bfd2ca9825bcd2ce10bfc824e (MD5) / Made available in DSpace on 2018-11-23T12:26:30Z (GMT). No. of bitstreams: 1 helenodesouzacamposjunior.pdf: 1434985 bytes, checksum: 4307be9bfd2ca9825bcd2ce10bfc824e (MD5) Previous issue date: 2018-09-19 / CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Testes de regressão são executados após cada mudança no software. Em ambientes de desenvolvimento de software que adotam práticas da Engenharia de Software Contínua, como a Integração contínua, por exemplo, software é modificado, e testado diversas vezes em curtos prazos. Cada execução dos testes pode levar horas para terminar, gerando atraso em relação à descoberta de falhas no projeto. Para prevenir esse atraso, técnicas de otimização são utilizadas. Uma delas é a priorização de casos de testes (TCP). Nessa técnica, a execução dos testes é reordenada de acordo com um objetivo, que normalmente é a detecção de falhas. Dessa forma, testes que têm maior probabilidade de falhas são executados primeiro. Um problema com essa abordagem é que existem diversas técnicas na literatura, mas pouca evidência em relação ao seu uso. Além disso, quase não existe infra estrutura para apoiar a adoção dessas técnicas no contexto industrial. O objetivo deste trabalho é planejar e implementar um framework que permita o uso, experimentação e implementação de técnicas de TCP. Esperamos que isso ajude praticantes a adotar essas técnicas no contexto industrial, principalmente da engenharia de software continua. Esperamos também que a criação dessa infra estrutura ajude pesquisadores a executar mais estudos experimentais sobre a eficiência do uso dessas técnicas. Para mostrar a viabilidade do framework proposto, é executado um estudo experimental com 16 técnicas de priorização diferentes, executadas em um total de 22 versões de 2 projetos open source. Os resultados coletados sugerem que o uso das técnicas de priorização resultam em retornos mais rápidos em relação à existência de falhas nos projetos, possivelmente resultando em ciclos mais rápidos de desenvolvimento. / Regression tests are executed after every change in software. In a software development environment that adopts Continuous Software Engineering practices such as Continuous Integration, software is changed, built and tested many times in a short period. Each execution can take hours to finish, delaying feedback about failures to the developer. To prevent this, regression test optimization techniques are used. One such technique is test case prioritization (TCP), which reorder the execution of the test cases according to some goal. The most common goal is fault detection, in which test cases are ordered so that those that have higher probability of detecting faults are executed first. One problem with this approach is that there are lots of different available techniques in the literature, but the amount of evidence of its use is low. Furthermore, there is almost no infrastructure support to adopt those techniques at the industry context. The goal of this work is to design and implement a framework that allows the use, experimentation and implementation of TCP techniques. We hope that this will help practitioners on adopting these techniques at the industry context, more specifically, in the continuous software engineering environment. We also hope that creating this infrastructure will encourage researchers on performing more empirical studies regarding test case prioritization techniques effectiveness. In order to show the feasibility of the proposed framework, we perform an empirical study with 16 different TCP techniques executed on a total of 22 versions of 2 different open source projects. Results suggest that using those TCP techniques result in faster feedback about the existence of failures in the projects, possibly resulting in shorter development cycles.