A systematic mapping study on the open source software development process.

Abstract?Background: There is no globally accepted open source software development process to define how open source software is developed in practice. A process description is important for coordinating all the software development activities involving both people and technology. Aim: The research question that this study sets out to answer is: What activities do open source software process models contain? The activity groups on which it focuses are Concept Exploration, Software Requirements, Design, Maintenance and Evaluation. Method: We conduct a systematic mapping study (SMS). A SMS is a form of systematic literature review that aims to identify and classify available research papers concerning a particular issue. Results: We located a total of 29 primary studies, which we categorized by the open source software project that they examine and by activity types (Concept Exploration, Software Requirements, Design, Maintenance and Evaluation). The activities present in most of the open source software development processes were Execute Tests and Conduct Reviews, which belong to the Evaluation activities group. Maintenance is the only group that has primary studies addressing all the activities that it contains. Conclusions: The primary studies located by the SMS are the starting point for analyzing the open source software development process and proposing a process model for this community. The papers in our paper pool that describe a specific open source software project provide more regarding our research question than the papers that talk about open source software development without referring to a specific open source software project.

A systematic mapping study on testing technique experiments: has the situation changed since 2000?

Context: Empirical Software Engineering (ESE) replication researchers need to store and manipulate experimental data for several purposes, in particular analysis and reporting. Current research needs call for sharing and preservation of experimental data as well. In a previous work, we analyzed Replication Data Management (RDM) needs. A novel concept, called Experimental Ecosystem, was proposed to solve current deficiencies in RDM approaches. The empirical ecosystem provides replication researchers with a common framework that integrates transparently local heterogeneous data sources. A typical situation where the Empirical Ecosystem is applicable, is when several members of a research group, or several research groups collaborating together, need to share and access each other experimental results. However, to be able to apply the Empirical Ecosystem concept and deliver all promised benefits, it is necessary to analyze the software architectures and tools that can properly support it.

Diferencias entre las Actividades de Mantenimiento en los Procesos de Desarrollo Tradicional y Open Source

Antecedentes. La creciente importancia del Open Source Software (OSS) ha llevado a los investigadores a estudiar cómo los procesos OSS difieren de los procesos de la ingeniería del software tradicional. Objetivo. Determinar las diferencias y similitudes entre las actividades del proceso de mantenimiento seguido por la comunidad OSS y el establecido por el estándar IEEE 1074:2006. Método. Para conocer las actividades que conforman el proceso de desarrollo OSS realizamos un Systematic Mapping Study. Posteriormente, realizamos un emparejamiento entre las actividades del estándar IEEE 1074:2006 con las actividades del proceso OSS. Resultados. Encontramos un total de 22 estudios primarios. De estos estudios, el 73% contaba con actividades relacionadas con el proceso de mantenimiento. Conclusiones. El proceso de mantenimiento tradicional del software no encaja con lo que ocurre en la comunidad OSS. En su lugar, puede ser mejor caracterizar la dinámica general de la evolución OSS como reinvención. Esta reinvención emerge continuamente de la adaptación, aprendizaje, y mejora de las funcionalidadess y calidad del OSS. Los proyectos OSS evolucionan a través de mejoras menores donde participan tanto usuarios como desarrolladores.

What do we know about successful software project factors

This dissertation discusses how different practitioners define project success and success factors for software projects and products. The motivation for this work is to identify the way software practitioners’ value and define project success. This can have implications for both practitioner motivation and software development productivity. Accordingly, in this work, we are interested in the various perceptions of the term “success” for different software practitioners and researchers. To get this information we performed a systematic mapping of the recent year’s software development literature trying to identify stakeholders’ perceptions about the success of a project and also possible differences among the views of the various stakeholders of a project. Some common terms related to project success (success project; software project success factors) were considered in formulating the search strings. The results were limited to twenty-two selected peer-reviewed conferences, papers/journal articles, published between 2003 and 2012.

Development of a Model for Security and Usability

This research addressed the development of a consolidated model designed especially to cover the security and usability attributes of a software product. As a starting point, we built a new usability model on the basis of well-known quality standards and models. We then used an existing security model to analyse the relationship between these two approaches. This analysis consisted of a systematic mapping study of the relationship between security and usability as global quality factors. We identified five relationship types: inverse, direct, relative, one-way inverse, and no relationship. Most authors agree that there is an inverse relationship between security and usability. However, this is not a unanimous finding, and this study unveils a number of open questions, like application domain dependency and the need to explore lower-level relationships between attribute subcharacteristics. In order to clarify the questions raised during the research, we conducted a second systematic mapping to further analyse the finer-grained structure of these factors, such as authentication as a subset of security and user efficiency as a subset of usability. The most relevant finding is that efficiency does not depend on the security level during the authentication process. There are other subfactors that require analysis. Accordingly, this research is the first part of a larger project to develop a full-blown consolidated model for security and usability.