Modelos de análisis de impacto aplicados a la gestión de riesgos en proyectos de desarrollo de software: una revisión sistemática de la literatura

El análisis de impacto aplicado a un proyecto de desarrollo de software permite determinar entre otros los factores o atributos que se ven afectados de manera positiva o negativa. Los valores de estos atributos como: tiempo, presupuesto y cronograma, entre otros, varían en el tiempo y deben ser controlados por el responsable del proyecto, sin embargo éstos no siempre se apoyan en la gestión de 1s de manera adecuada. El objetivo de este trabajo es identificar modelos de análisis de impacto aplicables para la gestión de riesgos en proyectos de desarrollo de software. Para este estudio se realizó una revisión sistemática de la literatura en bases de datos reconocidas. Se encontraron 1654 estudios primarios de análisis de impacto aplicados a proyectos de desarrollo de software y 17 artículos definiendo 21 modelos de análisis de impacto y 1 artículo de un marco comparativo entre algunos modelos existentes. A partir del análisis realizado de los estudios primarios se puede concluir que existen modelos de análisis de impacto que se han aplicado a proyectos de desarrollo de software en distintas fases y distintos aspectos. Sin embargo, ninguno de ellos aplicado a la gestión de riesgos en proyectos de desarrollo de software.Trabajo de investigació

Desarrollo rápido de software libre de alta calidad : Ingeniería de software asistida por computadora, enfocada en tareas, para agilizar el ciclo de vida de las aplicaciones, mediante mejora continua disciplinada a nivel personal

El presente artículo resume el estudio, desarrollo e implementación de un marco de trabajo teórico/práctico para creación y mantenimiento ágil de software libre, orientado al desarrollo de aplicaciones empresariales centradas en datos (principalmente transaccionales, con bases de datos relacionales, lenguaje de programación dinámico e interfaces web y visuales). Se analiza el estado del arte respecto a proyectos libres y abiertos (producción por pares, fomento, motivación, diversidad, gobernanza, calidad, etc.) y se exploran técnicas para migración de lenguajes legados discontinuados (VB clásico, usando técnicas EBNF). Se incluye el desarrollo de artefactos de software: herramientas integradas para ingeniería asistida por computadora (ICASE), contemplando la recolección automática de datos estadísticos. Se proponen varias mejoras al estado del arte respecto a mayor precisión en la medición de tiempos (detección facial vía WebCam) y seguimiento de líneas de código por identificadores globales (UUID); presentando los resultados preliminares de una prueba piloto (experiencia personal investigación-acción), para validación cualitativa y cuantitativa inicial, relevancia, implicaciones y trabajos futuros.Sociedad Argentina de Informática e Investigación Operativa (SADIO

Towards the exploration strategies by mining Mylyns' interaction histories

When developers perform a maintenance task, they always explore the program, i.e., move from one program entity to another. However, even though maintenance is a crucial task, the exploration strategies (ES) used by developers to navigate through the program entities remain unstudied. This lack of study prevents us from understanding how developers explore a program and perform a change task, from recommending strategies to developers, and (ultimately) from critically evaluating a developer's exploration performance. As a first step towards understanding ES, we mined interaction histories (IH) gathered using the Eclipse Mylyn plugin from developers performing a change task on four open-source projects (ECF, Mylyn, PDE, and Eclipse Platform). An ES is defined and characterized by the way (how) the developers navigate through the program entities. Using the Gini inequality index on the number of revisits of program entities, we observe that ES can be either centralized (CES) or extended (EES). We automatically classified interaction histories as CES or EES and performed an empirical study to ascertain the effect of the ES on the task duration and effort. We found that, although an EES requires more exploration effort than a CES, an EES is less time consuming than a CES. Extensive work (number of days spent performing a task) typically imply a CES. Our results show that developers who follow an EES have a methodical investigation of source code while developers who follow a CES have an opportunistic exploration of source code

Swarm Debugging: the Collective Intelligence on Interactive Debugging

One of the most important tasks in software maintenance is debugging. To start an interactive debugging session, developers usually set breakpoints in an integrated development environment and navigate through different paths in their debuggers. We started our work by asking what debugging information is useful to share among developers and study two pieces of information: breakpoints (and their locations) and sessions (debugging paths). To answer our question, we introduce the Swarm Debugging concept to frame the sharing of debugging information, the Swarm Debugging Infrastructure (SDI) with which practitioners and researchers can collect and share data about developers’ interactive debugging sessions, and the Swarm Debugging Global View (GV) to display debugging paths. Using the SDI, we conducted a large study with professional developers to understand how developers set breakpoints. Using the GV, we also analyzed professional developers in two studies and collected data about their debugging sessions. Our observations and the answers to our research questions suggest that sharing and visualizing debugging data can support debugging activities

Swarm Debugging: the Collective Intelligence on Interactive Debugging

One of the most important tasks in software maintenance is debugging. To start an interactive debugging session, developers usually set breakpoints in an integrated development environment and navigate through different paths in their debuggers. We started our work by asking what debugging information is useful to share among developers and study two pieces of information: breakpoints (and their locations) and sessions (debugging paths). To answer our question, we introduce the Swarm Debugging concept to frame the sharing of debugging information, the Swarm Debugging Infrastructure (SDI) with which practitioners and researchers can collect and share data about developers’ interactive debugging sessions, and the Swarm Debugging Global View (GV) to display debugging paths. Using the SDI, we conducted a large study with professional developers to understand how developers set breakpoints. Using the GV, we also analyzed professional developers in two studies and collected data about their debugging sessions. Our observations and the answers to our research questions suggest that sharing and visualizing debugging data can support debugging activities

Studying and Assisting the Practice of Java and C# Exception Handling

Programming languages provide features that handle exceptions. These features separate error-handling from regular code and aim to assist software maintenance. Nevertheless, their misuse can cause reliability degradation or even catastrophic failures. Prior studies on exception handling aim to understand the practices of exception handling and their anti-patterns. However, little knowledge was shared about the prevalence of these anti-patterns, nor the relationship between exception handling practices and software quality. In this thesis, I, first, study the exception handling features by enriching the knowledge of handling code with a flow analysis of exceptions. Second, I investigate the prevalence of exception handling anti-patterns. Finally, I investigate the relationship between software quality and: (i) flow characteristics and (ii) 17 handling anti-patterns. Our case study is conducted with over 10K handling blocks, and over 77K related flows from 16 Java and C# projects. I built statistical models of the chance of post-release defects using traditional software metrics and exception handling metrics. Our case study results show the complexity of exception handling. Moreover, I found that although exception handling anti-patterns widely exist in all of our subjects, only a few anti-patterns can be commonly identified. Finally, I conclude that exception flow characteristics in Java projects and some exception handling anti-patterns can provide significant explanatory power to the chance of post-release defects

An Empirical Study of the Effect of File Editing Patterns on Software Quality

Abstract—While some developers like to work on multiple code change requests, others might prefer to handle one change request at a time. This juggling of change requests and the large number of developers working in parallel often lead to files being edited as part of different change requests by one or several developers. Existing research has warned the community about the potential negative impacts of some file editing patterns on software quality. For example, when several developers concurrently edit a file as part of different change requests, they are likely to introduce bugs due to limited awareness of other changes. However, very few studies have provided quantitative evidence to support these claims. In this paper, we identify four file editing patterns. We perform an empirical study on three open source software systems to investigate the individual and the combined impact of the four patterns on software quality. We find that: (1) files that are edited concurrently by many developers have on average 2.46 times more future bugs than files that are not concurrently edited; (2) files edited in parallel with other files by the same developer have on average 1.67 times more future bugs than files individually edited; (3) files edited over an extended period (i.e., above the third quartile) of time have 2.28 times more future bugs than other files; and (4) files edited with long interruptions (i.e., above the third quartile) have 2.1 times more future bugs than other files. When more than one editing patterns are followed by one or many developers during the editing of a file, we observe that the number of future bugs in the file can be as high as 1.6 times the average number of future bugs in files edited following a single editing pattern. These results can be used by software development teams to warn developers about risky file editing patterns. Keywords-file editing pattern; change request; bug; software quality; empirical software engineering; mylyn. I

Automated Improvement of Software Design by Search-Based Refactoring

Le coût de maintenance du logiciel est estimé à plus de 70% du coût total du système, en raison de nombreux facteurs, y compris les besoins des nouveaux utilisateurs, l’adoption de nouvelles technologies et la qualité des systèmes logiciels. De ces facteurs, la qualité est celle que nous pouvons contrôler et continuellement améliorer pour empêcher la dégradation de la performance et la réduction de l’efficacité (par exemple, la dégradation de la conception du logiciel). De plus, pour rester compétitive, l’industrie du logiciel a raccourci ses cycles de lancement afin de fournir de nouveaux produits et fonctionnalités plus rapidement, ce qui entraîne une pression accrue sur les équipes de développeurs et une accélération de l’évolution de la conception du système. Une façon d’empêcher la dégradation du logiciel est l’identification et la correction des anti-patrons qui sont des indicateurs de mauvaise qualité de conception. Pour améliorer la qualité de la conception et supprimer les anti-patrons, les développeurs effectuent de petites transformations préservant le comportement (c.-à-d., refactoring). Le refactoring manuel est coûteux, car il nécessite (1) d’identifier les entités de code qui doivent être refactorisées ; (2) générer des opérations de refactoring pour les classes identifiées à l’étape précédente ; (3) trouver le bon ordre d’application des refactorings générés, pour maximiser le bénéfice pour la qualité du code et minimiser les conflits. Ainsi, les chercheurs et les praticiens ont formulé le refactoring comme un problème d’optimisation et utilisent des techniques basées sur la recherche pour proposer des approches (semi) automatisées pour le résoudre. Dans cette thèse, je propose plusieurs méthodes pour résoudre les principaux problèmes des outils existants, afin d’aider les développeurs dans leurs activités de maintenance et d’assurance qualité. Ma thèse est qu’il est possible d’améliorer le refactoring automatisé en considérant de nouvelles dimensions : (1) le contexte de tâche du développeur pour prioriser le refactoring des classes pertinentes ; (2) l’effort du test pour réduire le coût des tests après le refactoring ; (3) l’identification de conflit entre opérations de refactoring afin de réduire le coût de refactoring ; et (4) l’efficacité énergétique pour améliorer la consommation d’énergie des applications mobiles après refactoring.----------ABSTRACT: Software maintenance cost is estimated to be more than 70% of the total cost of system, because of many factors, including new user’s requirements, the adoption of new technologies and the quality of software systems. From these factors, quality is the one that we can control and continually improved to prevent degradation of performance and reduction of effectiveness (a.k.a. design decay). Moreover, to stay competitive, the software industry has shortened its release cycles to deliver new products and features faster, which results in more pressure on developer teams and the acceleration of system’s design evolution. One way to prevent design decay is the identification and correction of anti-patterns which are indicators of poor design quality. To improve design quality and remove anti-patterns, developers perform small behavior-preserving transformations (a.k.a. refactoring). Manual refactoring is expensive, as it requires to (1) identify the code entities that need to be refactored; (2) generate refactoring operations for classes identified in the previous step; (3) find the correct order of application of the refactorings generated, to maximize the quality effect and to minimize conflicts. Hence, researchers and practitioners have formulated refactoring as an optimization problem and use search-based techniques to propose (semi)automated approaches to solve it. In this dissertation, we propose several approaches to tackle some of the major issues in existing refactoring tools, to assist developers in their maintenance and quality assurance activities