Mjukvaruföretag idag söker alltid nya metoder för att effektivisera sin utveckling och att förbättra sin produkt. Denna studie undersöker användbarheten av en sådan ny metod kallad repository mining. Inom mjukvaruutveckling är repository mining en metod av kodanalys som utförs för att få ut metadata från ett versionshanteringssystem. Processen utförs med hjälp av ett kodanalysverktyg som i denna studie är verktyget CodeScene. Målet med denna fallstudie är att undersöka vad det finns för användningsfall för repository mining i ett utvecklingssyfte. Studiens syfte är att få förståelse för vilka typer av metadata som är relevanta och vad för faktorer det finns som kan påverka eventuella resultat. Syftet är även att studera om hur repository mining kan hjälpa företag i deras arbete med att öka eller upprätthålla kvaliteten på deras system. Studien utförs i samband med företaget Sandvik Coromant och deras avdelning Machining Foresight för att analysera deras kodbas. Kodbasen analyseras med hjälp av kodanalysverktyget CodeScene för att utvinna metadata som sedan presenteras till utvecklare inom Machining Foresight. Sedan utförs en kvalitativ studie som består av intervjuer och gruppdiskussioner i syfte av att få utvecklarnas reflektioner och tankegångar angående användbarheten av repository mining. Resultatet visar på att det finns användningsfall hos repository mining men dessa kräver att vissa faktorer är bestämda. Första användningsfallet är en analys på ändring i kodkomplexitet som hjälper att förutspå framtida refaktoreringar. Det andra användningsfallet är en analys på författarskap inom systemet för att hitta möjliga platser känsliga för kunskapsförlust, därmed hjälpa i planering av kunskapsdelning. Detta är dock en fallstudie och dessa resultat ska inte användas för att dra generella slutsatser om repository mining i sin helhet. Resultaten ska endast tas som vägriktning och indikation för framtida studier.

Several studies argue that exception handling code is usually of poor quality and that it is commonly neglected by developers. Moreover, it is said to be the least understood, documented, and tested part of the implementation of a system. In spite of this scenario, there are very few studies that analyze the actual exception handling bugs that occur in real software systems and no study that attempts to understand developers’ perceptions about these bugs. In this work we present an exploratory study on exception handling bugs that employs two complementary approaches: a survey of 154 developers and an analysis of 220 bugs from the repositories of Eclipse and Tomcat. Respondents of our survey believe that exception handling bugs are more easily fixed than other kinds of bugs. There is also a significant difference in the opinion of the respondents pertaining to the quality of the exception handling code: more experienced developers tend to believe that it is worse. Analysis of the repositories of Eclipse and Tomcat revealed conflicting results. The fix time for exception handling bugs in Eclipse is significantly shorter than for other bugs. However, exception handling bugs have a significantly greater number of discussion messages than non-exception handling bugs. On the other hand, for Tomcat, we could not find a significant difference for fix time and exception handling bugs have significantly less discussion messages than other bugs. Moreover, we discovered that bug reports describing bugs stemming from overly general catch blocks, a well-known bad smell in programs that use exceptions, are rare, even though there are many opportunities for them to occur. In addition, empty catch blocks are not only prevalent, as previously reported in literature, but they are also commonly used as part of bug fixes, which includes fixes for exception handling bugs. Furthermore, we found very few bug reports whose causes are empty catch blocks, although developers often mention them as causes of bugs they have fixed in the past. And lastly, we present a proposal of the classification of exception handling bugs based on the data we collected. / Submitted by João Arthur Martins (joao.arthur@ufpe.br) on 2015-03-10T18:18:46Z No. of bitstreams: 2 Dissertaçao Felipe Ebert.pdf: 1326280 bytes, checksum: b28c0a4b3a4f5a5d84483b41a94a7a48 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-11T17:40:09Z (GMT). No. of bitstreams: 2 Dissertaçao Felipe Ebert.pdf: 1326280 bytes, checksum: b28c0a4b3a4f5a5d84483b41a94a7a48 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2013-08-02 / FACEPE e CNPq / Vários estudos afirmam que o código de tratamento de exceções em geral tem baixa qualidade e que é geralmente negligenciado por desenvolvedores. Além disso, acredita-se que essa parte da implementação de um sistema é a menos compreendida, documentada e testada. Apesar desse cenário, existem poucos estudos que analisam bugs de tratamento de exceções que ocorrem em sistemas de software reais e nenhum estudo que tente entender a percepção dos desenvolvedores sobre esses bugs. Neste trabalho, apresentamos um estudo exploratório sobre bugs de tratamento de exceções baseado em duas abordagens complementares: uma pesquisa com 154 desenvolvedores e uma análise de 220 bugs dos repositórios do Eclipse e Tomcat. Os desenvolvedores de nossa pesquisa acreditam que bugs de tratamento de exceções são mais facilmente corrigidos do que outros tipos de bugs. Há também uma diferença significativa na opinião dos desenvolvedores sobre a qualidade do código de tratamento de exceções: os desenvolvedores mais experientes tendem a acreditar que é pior. A análise dos repositórios do Eclipse e Tomcat revelou resultados conflitantes. O tempo de correção dos bugs de tratamento de exceções do Eclipse é significativamente menor do que o de outros tipos de bugs. Entretanto, os bugs de tratamento de exceções têm um número significativamente maior de comentários do que os bugs que não são de tratamento de exceções. Por outro lado, para o Tomcat, não conseguimos achar uma diferença significativa para o tempo de correção dos bugs e os bugs de tratamento de exceções tem um número significativamente menor de comentários do que os outros tipos de bugs. Além disso, descobrimos que os bugs decorrentes de blocos catch genéricos, um defeito bem conhecido em programas que usam exceções, são raros, embora existam várias oportunidades para que eles ocorram. Descobrimos também que blocos catch vazios não são só prevalentes, como previamente relatado na literatura, mas também geralmente usados como correções dos bugs, inclusive para bugs de tratamento de exceções. Também achamos poucos bugs reportados em que as causas deles são blocos catch vazios, embora desenvolvedores frequentemente mencionem eles como causas de bugs que já corrigiram no passado. E por fim, apresentamos uma proposta de classificação dos bugs de tratamento de exceções.

Submitted by Irene Nascimento (irene.kessia@ufpe.br) on 2016-09-06T17:39:17Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) DissertacaoDeMestrado-IrineuMoura-imlm2.pdf: 1240260 bytes, checksum: 4bbaf8839fa3d5be7fca586e1f290f68 (MD5) / Made available in DSpace on 2016-09-06T17:39:17Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) DissertacaoDeMestrado-IrineuMoura-imlm2.pdf: 1240260 bytes, checksum: 4bbaf8839fa3d5be7fca586e1f290f68 (MD5) Previous issue date: 2015-08-24 / Energy consumption has been gaining traction as yet another major concern that mainstream software developers must be aware of. It used to be mainly the focus of hardware designers and low level software developers, e.g., device driver developers. Nowadays, however, mostly due to the ubiquity of battery-powered devices, any developer in the software stack must be prepared to deal with this concern. Thus, to be able to properly assist them and to provide guidance in future research it is crucial to understand how they have been handling this matter. This thesis aims to aid in this regard by exploring a set of software changes, i.e., commits, to obtain insights into actual solutions implemented by open source developers when dealing with energy consumption. We use as our main data source GITHUB, a source code hosting platform for collaborative development, and extract a sample of the available commits across several different projects. From this sample, we manually curate a set of energy-aware commits, that is, any commit that refers to a source code change where developers intentionally modify, or aim to modify, the energy consumption (or power dissipation) of a system or make it easier for other developers or end users to do so. We then apply a qualitative research method to extract recurring patterns of information and to group the commits that intend to save energy into categories. A small survey was also conducted to assess the quality of our analysis and to further expand our understanding of the changes. During our analysis we also cover different aspects of the commits. We observe that the majority of the changes (~47%) still target lower levels of the software stack, i.e., kernels, drivers and OS-related services, while application level changes encompass ~34% of them. We notice that developers may not always be certain of the energy consumption impact of their changes before actually performing them, among our dataset we identify several instances (~12%) of commits where developers show signs of uncertainty towards their change’s effectiveness. We also highlight the possible software quality attributes that may be favored over energy efficiency. Notably, we spot a few instances of commits where developers performed a change that would negatively impact the energy consumption of the system in order to fix a bug. It is also worth noting, we draw attention to a specific group of changes which we call "energy-aware interfaces". They add tuning knobs that can be used by developers or end users to control the energy consumption of an underlying component. / O controle do consumo de energia tem ganhado cada vez mais atenção como outro tipo de interesse ao qual desenvolvedores de software devem estar atentos. Antes esse tipo de preocupação era principalmente o foco de designers de hardware e desenvolvedores de baixonível, como por exemplo, desenvolvedores de drivers de dispositivos. Entretanto, devido à ubiquidade de dispositivos dependentes de bateria, qualquer desenvolvedor deve estar preparado para enfrentar essa questão. Logo, entender como eles estão lidando com o consumo de energia é crucial para estarmos aptos a auxiliá-los e para prover uma direção adequada para pesquisas futuras. Com o intuito de ajudar nesse sentido, essa tese explora um conjunto de mudanças de software, isto é, commits, para entender melhor sobre os tipos de soluções que são implementadas de fato por desenvolvedores de código aberto quando os mesmos devem lidar com o consumo de energia. Nós utilizamos o GITHUB como nossa principal fonte de dados, uma plataforma de hospedagem de código fonte para o desenvolvimento colaborativo de projetos de software, e extraímos uma amostra dos commits disponíveis entre vários projetos diferentes. Dessa amostra, nós manualmente selecionamos um conjunto de commits "energy-aware", isto é, qualquer commit que se refere a uma modificação de código onde o desenvolvedor propositalmente modifica, ou intenciona modificar, o consumo de energia (ou a dissipação de potência) de um sistema ou torna mais fácil para que outros desenvolvedores ou usuários finais possam fazê-lo. Nós então aplicamos sobre esses commits um método de análise qualitativa para extrair padrões recorrentes de informação e para agrupar os commits que intencionam reduzir o consumo energético em categorias. Uma pequena pesquisa também foi realizada com os autores dos commits para avaliar a qualidade da nossa análise e para expandir nosso entendimento sobre as modificações. Nós também consideramos diferentes aspectos dos commits durante a análise. Observamos que a maioria das modificações (~47%) ainda se aplicam às mais baixas camadas de software, isto é, kernels e drivers, enquanto que mudanças a nível de aplicação compreendem ~34% do nosso conjunto de dados. Nós notamos que os desenvolvedores nem sempre estão seguros do impacto de suas modificações no consumo de energia antes de realizá-las, em nosso conjunto de dados identificamos várias instâncias de modificações (~12%) em que os desenvolvedores demonstram sinais de incerteza em relação à eficácia de suas mudanças. Também apontamos alguns dos possíveis atributos de qualidade de software que são favorecidos em detrimento do consumo de energia. Entre essas, destacamos alguns commits onde os desenvolvedores realizaram uma modificação que impactaria negativamente no consumo de energia com o intuito de consertar algum problema existente no software. Também achamos interessante ressaltar um grupo específico de modificações que chamamos de “interfaces energy-aware”. Elas adicionam controles no software em questão que possibilitam outros desenvolvedores ou usuários finais a ajustar o consumo de energia de algum componente subjacente.

No description available.

No description available.

No description available.

Scientific software is vital for research across domains and can be reused when it is open-source. To promote this reuse, it is generally beneficial to adopt software engineering best practices to improve accessibility and popularity. However, given the distinct properties of scientific software, there is no consensus on how these practices are being or should be used in scientific software. Since previous evidence on this topic is primarily anecdotal or qualitative, this study used repository mining to quantitatively examine best practices and their relationship with popularity in 90 software engineering artifacts, which are examples of scientific software. The data varied significantly but showed that the studied artifacts generally did not prioritize software engineering best practices, and no significant relationships were found between these aspects and popularity. The results may suggest that scientific software developers prioritize scientific quality over software quality and that traditional software quality measures may not be suitable quality benchmarks in scientific software. However, accessibility issues were identified, highlighting potential societal concerns. Based on these findings, we offer practical advice for quality improvements from a software engineering perspective. Further research is needed to obtain more conclusive and general results.

Made available in DSpace on 2014-12-17T15:48:07Z (GMT). No. of bitstreams: 1 DanielAC_DISSERT.pdf: 1379221 bytes, checksum: 4e8ab78d03e452eecd9c3eaa6906e4ee (MD5) Previous issue date: 2013-02-01 / Coordena??o de Aperfei?oamento de Pessoal de N?vel Superior / Software Repository Mining (MSR) is a research area that analyses software repositories in order to derive relevant information for the research and practice of software engineering. The main goal of repository mining is to extract static information from repositories (e.g. code repository or change requisition system) into valuable information providing a way to support the decision making of software projects. On the other hand, another research area called Process Mining (PM) aims to find the characteristics of the underlying process of business organizations, supporting the process improvement and documentation. Recent works have been doing several analyses through MSR and PM techniques: (i) to investigate the evolution of software projects; (ii) to understand the real underlying process of a project; and (iii) create defect prediction models. However, few research works have been focusing on analyzing the contributions of software developers by means of MSR and PM techniques. In this context, this dissertation proposes the development of two empirical studies of assessment of the contribution of software developers to an open-source and a commercial project using those techniques. The contributions of developers are assessed through three different perspectives: (i) buggy commits; (ii) the size of commits; and (iii) the most important bugs. For the opensource project 12.827 commits and 8.410 bugs have been analyzed while 4.663 commits and 1.898 bugs have been analyzed for the commercial project. Our results indicate that, for the open source project, the developers classified as core developers have contributed with more buggy commits (although they have contributed with the majority of commits), more code to the project (commit size) and more important bugs solved while the results could not indicate differences with statistical significance between developer groups for the commercial project / Minera??o de Reposit?rios de Software (MSR) ? uma ?rea que procura analisar reposit?rios de software em busca de informa??es relevantes para a pesquisa e para a pr?tica na engenharia de software. As minera??es buscam transformar informa??es est?ticas de reposit?rios de software (sistemas de ger?ncia de configura??o e mudan?as) em informa??es relevantes que auxiliam a tomada de decis?o dentro do contexto de projetos de software. Por outro lado, a ?rea de Minera??o de Processos (MP) busca descobrir caracter?sticas dos processos que s?o utilizados em organiza??es para auxiliar na melhoria e documenta??o destes processos. Trabalhos recentes t?m buscado utilizar as t?cnicas de MSR e de MP para realizar diversas an?lises na ?rea de Engenharia de Software, tais como: (i) estudar a evolu??o dos projetos de software (ii) entender o processo de software real utilizado em um determinado projeto; e (iii) criar modelos de predi??es de defeitos. Contudo, poucos destes trabalhos buscam utilizar as t?cnicas de MP e MSR com o objetivo de analisar a contribui??o de desenvolvedores na implementa??o de sistemas de software. Esta disserta??o de mestrado prop?e a condu??o de estudos experimentais que buscam avaliar a contribui??o de desenvolvedores de software para projetos, atrav?s da utiliza??o das t?cnicas de MSR e MP. A contribui??o dos desenvolvedores ? avaliada sob tr?s diferentes perspectivas: (i) commits defeituosos; (ii) tamanho dos commits; e (iii) resolu??o de bugs priorit?rios. Dois projetos de software (um open-source e outro privado) foram analisados sob estas tr?s perspectivas. Para o projeto open-souce, 12.827 commits e 8.410 bugs foram avaliados, enquanto que para o projeto privado, 4.663 commits e 1.898 bugs foram avaliados. Os resultados obtidos indicam que para o projeto open-source os desenvolvedores classificados como desenvolvedores core, s?o os que mais produzem commits defeituosos (embora tamb?m sejam os que mais produzem commits), s?o os que contribuem com commits de maior tamanho de c?digo e tamb?m contribuem com mais bugs priorit?rios solucionados. J? para o projeto privado, os resultados n?o indicaram uma diferen?a estatisticamente significativa entre os grupos de desenvolvedores

One of the important aims of the continuous software development process is to localize and remove all existing program bugs as fast as possible. Such goal is highly related to software engineering and defectiveness estimation. Many big companies started to store source code in software repositories as the later grew in popularity. These repositories usually include static source code as well as detailed data for defects in software units. This allows analyzing all the data without interrupting programing process. The main problem of large, complex software is impossibility to control everything manually while the price of the error can be very high. This might result in developers missing defects on testing stage and increase of maintenance cost. The general research goal is to find a way of predicting future software defectiveness with high precision. Reducing maintenance and development costs will contribute to reduce the time-to-market and increase software quality. To address the problem of estimating residual defects an approach was found to predict residual defectiveness of a software by the means of machine learning. For a prime machine learning algorithm, a regression decision tree was chosen as a simple and reliable solution. Data for this tree is extracted from static source code repository and divided into two parts: software metrics and defect data. Software metrics are formed from static code and defect data is extracted from reported issues in the repository. In addition to already reported bugs, they are augmented with unreported bugs found on “discussions” section in repository and parsed by a natural language processor. Metrics were filtered to remove ones, that were not related to defect data by applying correlation algorithm. Remaining metrics were weighted to use the most correlated combination as a training set for the decision tree. As a result, built decision tree model allows to forecast defectiveness with 89% chance for the particular product. This experiment was conducted using GitHub repository on a Java project and predicted number of possible bugs in a single file (Java class). The experiment resulted in designed method for predicting possible defectiveness from a static code of a single big (more than 1000 files) software version.

When performing an analysis of the evolution of software quality and software metrics,there is a need to get access to as many versions of the source code as possible. There isa lack of research on how data or source code can be extracted from the source controlmanagement system Git. This thesis explores different possibilities to resolve thisproblem. Lately, there has been a boom in usage of the version control system Git. Githubalone hosts about 6,100,000 projects. Some well known projects and organizations thatuse Git are Linux, WordPress, and Facebook. Even with these figures and clients, thereare very few tools able to perform data extraction from Git repositories. A pre-studyshowed that there is a lack of standardization on how to share mining results, and themethods used to obtain them. There are several tools available for older version control systems, such as concurrentversions system (CVS), but few for Git. The examined repository mining applicationsfor Git are either poorly documented; or were built to be very purpose-specific to theproject for which they were designed. This thesis compiles a list of general issues encountered when using repositorymining as a tool for data gathering. A selection of existing repository mining tools wereevaluated towards a set of prerequisite criteria. The end result of this evaluation is thecreation of a new repository mining tool called Doris. This tool also includes a smallcode metrics analysis library to show how it can be extended.