[pt] O presente trabalho se propõe a aferir a mudança institucional que teve lugar nas atividades da Organização das Nações Unidas (ONU) relacionadas com as Operações de Manutenção da Paz, no período 1992- 2000. A abordagem levada a cabo se localiza no encontro da disciplina das Relações Internacionais com outras Ciências Sociais, através dos autores Ernst Haas e Anthony Giddens. Na Modernidade, organizações sociais, como a ONU, levam a cabo contínuo monitoramento, reflexivo, de suas próprias ações, na busca por solucionar problemas de cuja solução são incumbidos. Nessa dinâmica de monitoramento reflexivo, as organizações sociais podem - ou não - aprender com suas experiências pregressas. / [en] The present research intends to evaluate institutional change that had taken place within United Nations (UN) activities related to Peacekeeping operations, from 1992 to 2000. The following approach is located on the interface between International Relations and other Social Sciences, through the theoretical contributions of Ernst Haas and Anthony Giddens. In Modernity, social organizations (such as UN) continuously monitor its own behavior - reflexively - seeking for solutions for problems to be solved. Amidst this dynamics of reflexive monitoring, social organizations may - or may not - learn from its previous experiences.

[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.

[pt] A Web de Dados cresceu significativamente nos últimos anos, tanto em quantidade de dados, quanto em fontes responsáveis por esses. A partir desse aumento no número de fontes de dados, ligações owl:sameAs têm sido cada vez mais utilizadas para conectar dados equivalentes e publicados por fontes distintas. Com isso, torna-se necessário haver uma rotina de identificação e manutenção dessas conexões. Com o objetivo de automatizar essa tarefa, desenvolvemos o Framework MsA – Materialização de sameAs para materializar e recomputar ligações do tipo owl:sameAs entre bancos de dados locais e dados publicados na Web. Essas ligações, uma vez identificadas, são materializadas juntamente aos dados locais e recomputadas apenas quando necessário. Para isso, a ferramenta monitora as operações (cadastramento, remoção e atualização) realizadas nos dados locais e remotos e, para cada tipo, implementa uma estratégia de manutenção das ligações envolvidas. / [en] The Web of Data has grown significantly in recent years, not only in the amount of data but also in the number of data sources. In parallel with this tendency, owl:sameAs links have been increasingly used to connect equivalent data published by different sources. As a consequence, it becomes necessary to have a routine for the identification and maintenance of these connections. In order to automate this task, we have developed the MsA Framework - sameAs Materialization to materialize and recompute owl:sameAs links between local databases and data published on the Web. These connections, once identified, are materialized along with the local data and recomputed only when necessary. To achieve this goal, the tool monitors the operations (insertion, update and deletion) performed on local and remote records, and for each type of operation it implements a maintenance strategy on the links involved.

[pt] A refatoração de código é uma transformação de código que visa aprimorar a estrutura interna do código. Uma refatoração isolada raramente é suficiente para remover completamente uma estrutura de código ruim, como uma anomalia de código. Os desenvolvedores então aplicam refatorações compostas para remover totalmente uma anomalia de código. Uma refatoração composta consiste em duas ou mais refatorações inter-relacionadas. Um refatoração composta é considerada completa quando elimina totalmente a anomalia de código alvo. Estudos relatam que os desenvolvedores geralmente falham em remover completamente as anomalias de código alvo por meio de refatorações compostas. Refatorações compostas concluídas podem não ser totalmente benéficas para a estrutura do código. Pois, estas podem induzir efeitos colaterais, como a introdução de anomalias de código ou a propagação de anomalias existentes. Há uma compreensão limitada sobre a completude das refatorações compostas e seus possíveis efeitos colaterais. Esta tese investiga como as refatorações compostas removem totalmente as anomalias de código sem induzir efeitos colaterais. Descobrimos que 64 por cento das refatorações compostas completas são formadas por tipos de refatoração não recomendados anteriormente. Dessa forma, derivamos um catálogo de recomendações para apoiar os desenvolvedores na aplicação de refatorações compostas. Na avaliação do catálogo, 85 por cento de 21 desenvolvedores relataram que usariam as recomendações do catálogo e que suas próprias soluções de refatoração teriam induzido efeitos colaterais. Também avaliamos qualitativamente três abordagens existentes para recomendar automaticamente refatorações compostas. Nesse estudo, a maioria (80 por cento) dos 10 desenvolvedores relatou que as abordagens existentes frequentemente induzem efeitos colaterais. No geral, as descobertas e o catálogo proposto podem ajudar os desenvolvedores a realizar refatorações compostas completas. / [en] Code refactoring is a code transformation that aims to enhance the internal code structure. A single refactoring is rarely sufficient to achieve the full removal of a poor code structure, such as a code smell. Developers then apply composite refactorings to fully remove a code smell. A composite refactoring (or, simply, composite) consists of two or more interrelated single refactorings. A composite is considered complete when it fully eliminates the target smell. However, studies report that developers often fail in completely removing target code smells through composites. Even when composite refactorings are complete they may still not be entirely beneficial to the code structure. They may induce side effects, such as the introduction of new smells or the propagation of existing ones. There is a limited understanding of the completeness of composite refactorings and their possible effects on structural quality. This thesis investigates whether and how composite refactorings fully remove smells without inducing side effects. We found that 64 per cent of complete composites in several software projects are formed of refactoring types not previously recommended in the literature. Based on this study, we derived a catalog of recommendations for supporting developers in applying composite refactorings. Out of twenty one developers evaluating our catalog, 85 per cent reported that they would use the catalog recommendations and that their own refactoring solutions would have induced side effects. We also qualitatively evaluated three existing approaches to automatically recommend composite refactorings. In our study with ten developers, most (80 per cent) developers reported that existing approaches frequently induce side effects. Overall, the findings and the proposed catalog can help developers to perform complete composite refactorings with better awareness of possible side effects.

[pt] Pontes rodoviárias são estruturas sujeitas à ação conjunta de fadiga e corrosão. Nesse sentido, este trabalho propõe um protótipo de sistema para auxiliar na tomada de decisão sobre a manutenção de pontes de viga de aço, no qual apenas pontes simplesmente apoiadas são consideradas. O sistema considera os efeitos da corrosão-fadiga e estima o tempo de vida útil dessas estruturas a partir de uma análise de confiabilidade estrutural. Tal análise é baseada nas curvas S-N para fadiga da norma americana AASHTO e na regra do acúmulo de dano de Miner. Para considerar a perda de material e a perda de resistência causadas pela corrosão, são realizados ajustes nos parâmetros de fadiga do modelo de confiabilidade utilizado. Além disso, algumas alternativas de manutenção que reduzem a taxa de degradação são consideradas no sistema com a correção dos parâmetros de corrosão do material. O sistema utiliza uma rede neural artificial para estimar as tensões nas vigas de aço com a passagem de um veículo de fadiga da AASHTO a partir de dados geométricos e de material da ponte. A base de dados utilizada para o desenvolvimento da rede neural foi criada a partir de resultados de simulações por elementos finitos. O ciclo de vida de uma ponte de aço projetada conforme a norma americana é simulado usando o sistema proposto. Através dessa simulação, conclui-se que o tempo de vida útil da mesma está relacionado com a combinação dos parâmetros de tráfego e da agressividade do ambiente. Conclui-se também que o aumento no volume de tráfego médio diário de caminhões (ADTT) pode causar uma redução de 48 por cento a 76 por cento na vida útil e dependendo do aumento na sua taxa de crescimento anual a redução pode ser de até 80 por cento. As alternativas de lavagem da superestrutura proporcionam ganho de vida útil para todos os ambientes, sobretudo no ambiente marinho (podendo chegar até 30 por cento). No entanto, em alguns dos cenários de tráfego testados nas simulações esse ganho não é suficiente para garantir o tempo de vida útil mínimo recomendado pela AASHTO. / [en] Highway bridges are structures subjected to the both action of fatigue and corrosion. In this sense, this research proposes the prototype of a system to assist in the maintenance decision making process of steel beam bridges, in which only simply supported steel girder bridges are considered. The system contemplates the effects of corrosion-fatigue and estimates the lifetime of these structures based on a structural reliability analysis. Such analysis is based on AASHTO S-N fatigue curves and Miner s damage accumulation rule. In order to account for material and resistance loss caused by corrosion, adjustments are made to the fatigue parameters of the reliability model used. In addition, some maintenance strategies that reduce the rate of corrosion are considered in the system by correcting the corrosion parameters of the material. The system uses an artificial neural network model to estimate the stresses in steel beams under the passage of an AASHTO fatigue vehicle using geometric and material data from the bridge. The database used for the development of the neural network was created from finite element simulations results. The life cycle of a steel bridge, designed according to the AASHTO American standard, is simulated using the proposed system. Through this simulation, it is concluded that the structure s lifetime is related to the combination of traffic parameters and the environment corrosivity. It is also observed that the increase in the average daily truck traffic (ADTT) can cause a reduction from 48 percent to 76 percent in the bridge s lifetime and depending on its annual growth increase rate the reduction can go up to 80 percent. Maintenance alternatives for the superstructure such as washing provide a lifetime gain for all environments, especially in the marine environment (up to 30 percent). However, in some of the tested traffic scenarios this gain is not sufficient to guarantee the minimum service life recommended by AASHTO.

[pt] A Manutenção Autônoma (MA) é parte de uma estratégia de manutenção que se centra na relação homem-máquina para efetuar de forma eficaz a limpeza, lubrificação, inspeção e pequenos reparos. Quando devidamente implementada, a MA pode melhorar significativamente a produtividade e a qualidade, bem como reduzir os custos, portanto é uma importante área da Gerência de Operações (OM). No entanto, a indústria tem sido desafiada com inúmeras barreiras para implementar com sucesso a MA, e o meio acadêmico pouco tem feito para ajudar a indústria a este respeito. Esta dissertação aborda essa atual lacuna entre pesquisa e prática, tendo como objetivo principal desenvolver um framework para a implementação da MA com as dimensões Humana, Tecnológica e Organizacional (HTO). O trabalho baseia-se numa pesquisa-ação, conduzida no âmbito de um estudo longitudinal, num processo de laminação de tiras a quente de uma usina siderúrgica. A adoção da abordagem HTO por pesquisadores da OM tem sido conduzida com sucesso em diferentes casos e está bem documentada na literatura. No entanto, o autor sugere que esta é a primeira pesquisa a utilizar esta abordagem dentro da MA. Os resultados da pesquisa indicam a aderência das dimensões HTO para corresponder aos desafios da implementação da MA e reforçar a necessidade de uma perspectiva holística e combinada destas dimensões para o desenvolvimento empresarial, resultando em ganhos de natureza quantitativa e qualitativa e que quatorze lições foram aprendidas com implicações práticas imediatas. Os gestores da indústria podem fazer um balanço das lições aprendidas no âmbito desta pesquisa-ação e utilizar o framework oferecido para ajudar à implementação com sucesso da MA nas suas operações industriais. / [en] Autonomous Maintenance (AM) is part of a maintenance strategy that focuses on the man-machine relationship to effectively carry out cleaning, lubrication, inspection and minor repairs. When properly implemented, AM can significantly improve productivity and quality, as well as reduce cost, therefore, it is an important area of operations management (OM). However, the industry has been challenged with numerous barriers to successfully implement AM and the academy has done little to help industry in this regard. This paper addresses this current research practice gap by offering as its main goal a framework for implementation of AM with the Human, Technological and Organizational (HTO) dimensions. It builds upon an action-research conducted within a longitudinal study in a rolling mill production process. The adoption of the HTO approach by OM scholars has been successfully conducted in different cases and is well documented in the literature. However, the author suggests that this is the first research to use this approach within AM. The research findings indicate the adherence of the HTO dimensions to match the AM implementation challenges and reinforce the need for a holistic and combined perspective of these dimensions for business development, resulting in gains of both a quantitative and qualitative nature and that fourteen lessons were learned with immediate practical implications. Practitioners can take stock of the lessons learnt within this action-research and the offered framework to aid the successful implementation of AM in their industrial operations.

[pt] O planejamento do cronograma de manutenção de unidades geradoras de usinas hidrelétricas é assunto de grande interesse para diversos agentes do setor de energia brasileiro. Uma abordagem correta para este problema, pode prevenir a degradação dos ativos físicos e minimizar a probabilidade de desligamentos forçados de seus equipamentos. Logo, as estratégias operacionais dos agentes são também influenciadas pelo cronograma de manutenção das turbinas. Porém, o sistema brasileiro possui algumas particularidades, a qual os grupos econômicos que vencem o leilão para a construção de novas usinas hidrelétricas, atendam a uma série de especificações técnicas, dentre elas, o Fator de Disponibilidade (FID). O FID é diretamente influenciado pelas horas de manutenção realizadas na usina e, em caso de desempenho abaixo do estipulado nos contratos de concessão, pode acarretar em perdas financeiras aplicadas pela o agente regulador. Com essa motivação em mente, o presente trabalho propõe uma metodologia para Programação da Agenda da Manutenção de Geradores de uma usina hidrelétrica, desenvolvendo um modelo matemático para determinar o momento ideal para realizar a manutenção, considerando restrições operacionais e aspectos regulatórios de usinas hidrelétricas. O trabalho propõe também, a obtenção de um ranking das turbinas com a utilização do método Analytic Hierarchy Process (AHP), com base nos indicadores de manutenção da usina hidrelétrica estudada. O objetivo da classificação gerada é fornecer subsídio para auxiliar o planejamento das manutenções, de forma a aumentar a disponibilidade dos equipamentos. A metodologia de otimização proposta para este problema é feita através de Programação Linear Inteira Mista (PLIM), onde as variáveis inteiras consistem no estado de operação e data de início da manutenção de cada unidade geradora. A representação do parque hidrotérmico é desafiadora, principalmente, devido à estocasticidade das vazões naturais afluentes. Ao final, para validar a modelagem proposta, é realizado um estudo de caso para uma planta real de grande porte do sistema brasileiro, a Usina Hidrelétrica Santo Antônio. / [en] The planning of the maintenance schedule of hydroelectric power plant generating units is a matter of great interest to several agents in the Brazilian energy sector. A correct approach to this problem can prevent the degradation of physical assets and minimize the likelihood of forced shutdown of your equipment. Therefore, the agents operational operations are also influenced by the turbine maintenance schedule. However, the Brazilian system has some particularities, which the economic groups that win the auction for the construction of new hydroelectric plants, meet a series of technical specifications, among them, the Availability Factor (AFA). The AFA is directly influenced by the hours of maintenance performed at the plant and, in case of performance below the stipulated in the concession contracts, it can result in financial losses applied by the regulatory agent. With this motivation in mind, the present work proposes a methodology for Programming the Maintenance Schedule of Generators of a hydroelectric plant, developing a mathematical model to determine the ideal moment to carry out the maintenance, considering operational restrictions and regulatory aspects of hydroelectric plants. The work also offers to obtain a ranking of the turbines using the Analytic Hierarchy Process (AHP) method, based on the maintenance indicators of the studied hydroelectric plant. The purpose of the generated classification is to provide subsidies to assist the planning of maintenance, in order to increase the availability of equipment. The optimization methodology proposed for this problem is done through Mixed Integer Linear Programming (MILP), where the entire variables consist of the state of operation and start data for the maintenance of each generating unit. The representation of the hydrothermal park is challenging, mainly due to the stochasticity of the affluent natural flows. At the end, to validate the proposed modeling, a case study is carried out for a real large plant in the Brazilian system, the Santo Antônio Hydroelectric Plant.

[pt] Projetos de renovação ferroviária apresentam características de projetos complexos e repetitivos, dado seu grande número de recursos e fatores de influência e atividades repetitivas para determinadas unidades de produção. Neste contexto o presente trabalho buscou aplicar conceitos relativos a gerenciamento de projetos desse nicho e desenvolver uma forma integrada de trabalhar com a incerteza nesse ambiente. Foi aplicada a metodologia de planejamento de projetos chamada Linha de Balanço, utilizando informações do projeto em fase de concepção em uma empresa ferroviária. Em sequência foi desenvolvido um protocolo para obtenção da opinião de especialistas em informações críticas para o processo e obtidas as distribuições betas que melhor representam as informações elicitadas. A partir dessas entradas, foi desenvolvido um modelo de simulação das atividades do projeto para analisar o seu funcionamento em um ambiente virtual e livre de riscos e usar como ferramenta para aprimorar seu planejamento. Como resultados são apresentadas e analisadas as principais saídas do modelo e propostas formas de controle que possam auxiliar na retroalimentação do planejamento com informações do andamento do projeto após iniciado. / [en] Project Planning known as Line of Balance (LoB) was applied, using information from a project in the conception stage of a railway company. Next, a protocol was developed to obtain expert opinion on critical information for the process and beta distributions that best represent the elicited information. From these inputs, it was developed a simulation model of the project activities in order to analyze their operation in a virtual and risk-free environment and optimize their scheduling. As a result, the main outputs of the model are presented and analyzed, in addition with the suggestion of methods of control that can assist in the feedback of the planning process with status information of the ongoing project.

[pt] Refatorar código-fonte consiste em aplicar transformações sobre a estrutura de código-fonte de projetos de software. Refatoração é bastante usada para remover estruturas pobres que dificultam a manutenção de sistemas de software. Poucas transformações isoladas são capazes de remover por completo estruturas pobres, mesmo as mais simples. Por exemplo, encurtar um método longo usualmente requer a extração de vários métodos. Até 60 por cento das transformações são inter-relacionadas e aplicadas em lotes, durante a dita refatoração em lote, ao invés de aplicadas isoladamente. Embora lotes serão frequentes na prática, o conhecimento sobre as características que constituem lotes está fragmentado na literatura. Qual o tamanho usual de lotes? As transformações internas a lotes costumam variar? Não há uma sumarização de conhecimento que responda tais questões. Ademais, são poucas as evidências sobre o efeito de lotes sobre a manutenção de sistemas. Lotes tendem a introduzir ou remover estruturas pobres, especialmente aquelas indicadas por anomalias de código-fonte? A resposta a perguntas como essa é insuficiente para apoiar a aplicação de lotes. Esta dissertação de mestrado apresenta dois estudos experimentais complementares visando resolver as limitações supracitadas. A dissertação começa com uma revisão da literatura sobre refatoração em lote baseada em 29 estudos. Nós identificamos sete características de lotes tais como o escopo de código-fonte afetado pela aplicação de um lote, mais sete tipos de efeito de lotes sobre a manutenção de sistemas, tais como a remoção de anomalias. As características e tipos de efeito identificadas foram sumarizadas por um mapa conceitual. A dissertação encerra-se com uma análise quantitativa de 57 projetos de sistemas abertos e fechados. Ao computar 4.607 lotes com uma heurística, nós descobrimos que a maioria dos lotes leva um único commit para ser aplicada (93 por cento) mas afeta mais do que um só método (90 por cento). Surpreendentemente, a maioria dos lotes introduz (51 por cento) ou não remove (38 por cento) anomalias. Revelamos também lotes até então desconhecidos mas capazes de remover por completo certas anomalias. Esta dissertação sugere trabalhos futuros com base em conflitos identificados na literatura quanto a características e tipos de efeito de lotes. / [en] Code refactoring means applying transformations on the code structure of a software project. Refactoring usually intends to remove poor code structures that harm the software maintenance. Each single transformation rarely suffices to fully remove poor code structures, even the simplest ones. For instance, shortening a long method often requires many method extractions. Up to 60 percent of the refactorings in software projects are constituted of a set of interrelated transformations, the so-called batches, rather than single transformations applied in isolation. Although batches are frequent in practice, the knowledge of batch characteristics is fragmented across studies. What is the usual size of batches? How do transformations vary within a batch? There is no summary that helps to address these questions. More critically, there is little empirical evidence of the batch effect on maintenance. Are batches more likely to introduce or remove poor code structures, especially those spotted by code smells? The current answer to questions like this is insufficient to support the batch application in practice. This Master s dissertation presents two complementary empirical studies that address both aforementioned literature gaps. The dissertation starts with a literature review of batch refactoring with 29 studies. We identified seven batch characteristics such as the scope in which batches are applied to code structures, plus seven types of batch effect on software maintenance, including code smell removal. All batch characteristics and types of effect were summarized in a conceptual map. The dissertation ends with the quantitative analysis of 57 open and closed software projects. From 4,607 heuristic-computed batches, we found that most batches occur entirely within one commit (93 percent) but affect more than just one method (90 percent). Surprisingly, batches mostly end up introducing (51 percent) or not removing (38 percent) code smells. Our results enabled us to reveal certain forms of batches, not documented by previous studies, that are useful to fully remove certain types of code smells.