Submitted by Erika Demachki (erikademachki@gmail.com) on 2017-11-06T19:48:59Z No. of bitstreams: 2 Dissertação - Marcello Henrique Dias de Moura - 2013.pdf: 3325482 bytes, checksum: 45be62e46fd5fda90d1d0561482a3d85 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Approved for entry into archive by Erika Demachki (erikademachki@gmail.com) on 2017-11-06T19:49:14Z (GMT) No. of bitstreams: 2 Dissertação - Marcello Henrique Dias de Moura - 2013.pdf: 3325482 bytes, checksum: 45be62e46fd5fda90d1d0561482a3d85 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Made available in DSpace on 2017-11-06T19:49:14Z (GMT). No. of bitstreams: 2 Dissertação - Marcello Henrique Dias de Moura - 2013.pdf: 3325482 bytes, checksum: 45be62e46fd5fda90d1d0561482a3d85 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) Previous issue date: 2013-03-22 / Version Control Systems are repositories that store source code changes done by software developers. Research that extracts data from these repositories for analysis can be classified into two groups: those that focus on the development process and the ones that focus on the developers. The present dissertation investigates the second case and contributes to the field by providing: (a) the definition of a history file that summarizes changes made to software in line and file levels, (b) a set of metrics to evaluate the work of the developers; and (c) two approaches for comparing the developers based on their metrics. A computational system that implements these metrics and approaches was built and applied to two case studies of real software development projects. The results obtained in the studies were positive. They were consistent with the general perception of project managers about the work done by the developers. They also leaded to new ideas for improving the research.We believe that these contributions are a step towards a better understanding and characterization of the way about how software developers work. / Repositórios de Controle de Versão são sistemas que armazenam mudanças no código fonte realizadas por desenvolvedores de software. As pesquisas que extraem dados desses repositórios para análise podem ser classificadas em dois grupos: as que focam no processo de desenvolvimento e as que focam no desenvolvedor. O presente trabalho investiga o segundo aspecto contribuindo para o assunto com: (a) a definição de um histórico de arquivos que sumariza as mudanças realizadas no software em nível de linha e de arquivo; (b) um conjunto de métricas visando avaliar o trabalho dos desenvolvedores; e (c) duas propostas de abordagem para comparar os desenvolvedores. Um sistema computacional que implementa essas métricas e as abordagens foi construído, tendo sido aplicado em dois estudos de casos envolvendo projetos reais de desenvolvimento de software. Os resultados obtidos nos estudos foram positivos, coincidindo, em geral, com a percepção de gerentes de projetos sobre o trabalho dos desenvolvedores e apontando para novas ideias de evolução da pesquisa. Consideramos que este é um passo no sentido de entender e caracterizar melhor a forma de trabalho dos desenvolvedores.

Free and Open-Source Software (FOSS) has become an integral part of the software supply chain in the past decade. Various entities (automated tools and humans) are involved at different stages of the software supply chain. Some actions that occur in the chain may result in vulnerabilities or malicious code injected in a published artifact distributed in a package repository. At the end of the software supply chain, developers or end-users may consume the resulting artifacts altered in transit, including benign and malicious injection. This dissertation starts from the first link in the software supply chain, ‘developers’. Since many developers do not update their vulnerable software libraries, thus exposing the user of their code to security risks. To understand how they choose, manage and update the libraries, packages, and other Open-Source Software (OSS) that become the building blocks of companies’ completed products consumed by end-users, twenty-five semi-structured interviews were conducted with developers of both large and small-medium enterprises in nine countries. All interviews were transcribed, coded, and analyzed according to applied thematic analysis. Although there are many observations about developers’ attitudes on selecting dependencies for their projects, additional quantitative work is needed to validate whether behavior matches or whether there is a gap. Therefore, we provide an extensive empirical analysis of twelve quality and popularity factors that should explain the corresponding popularity (adoption) of PyPI packages was conducted using our tool called py2src. At the end of the software supply chain, software libraries (or packages) are usually downloaded directly from the package registries via package dependency management systems under the comfortable assumption that no discrepancies are introduced in the last mile between the source code and their respective packages. However, such discrepancies might be introduced by manual or automated build tools (e.g., metadata, Python bytecode files) or for evil purposes (malicious code injects). To identify differences between the published Python packages in PyPI and the source code stored on Github, we developed a new approach called LastPyMile . Our approach has been shown to be promising to integrate within the current package dependency management systems or company workflow for vetting packages at a minimal cost. With the ever-increasing numbers of software bugs and security vulnerabilities, the burden of secure software supply chain management on developers and project owners increases. Although automated program repair approaches promise to reduce the burden of bug-fixing tasks by suggesting likely correct patches for software bugs, little is known about the practical aspects of using APR tools, such as how long one should wait for a tool to generate a bug fix. To provide a realistic evaluation of five state-of-the-art APR tools, 221 bugs from 44 open-source Java projects were run within a reasonable developers’ time and effort.