Valentina Lenarduzzi

Functional Size Measures and Effort Estimation in Agile Development: a Replicated Study

To help developers during the Scrum planning poker, in our previous work we ran a case study on a Moonlight Scrum process to understand if it is possible to introduce functional size metrics to improve estimation accuracy and to measure the accuracy of expert-based estimation. The results of this original study showed that expert-based estimations are more accurate than those obtained by means of models, calculated with functional size measures. To validate the results and to extend them to plain Scrum processes, we replicated the original study twice, applying an exact replication to two plain Scrum development processes. The results of this replicated study show that the accuracy of the effort estimated by the developers is very accurate and higher than that obtained through functional size measures. In particular, SiFP and IFPUG Function Points, have low predictive power and are thus not help to improve the estimation accuracy in Scrum.

Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation

Microservices have been getting more and more popular in recent years, and several companies are migrating monolithic applications to microservices. Microservices allow developers to independently develop and deploy services, and ease the adoption of agile processes. However, many companies are still hesitant to migrate because they consider microservice as a hype or because they are not aware of the migration process and the benefits and issues related to migration. For this purpose, we conducted a survey among experienced practitioners who already migrated their monoliths to microservices. In this paper, we identify a process framework based on the comparison of three different migration processes adopted by the interviewed practitioners, together with the common motivations and issues that commonly take place during migrations. In this work, we describe the results and provide an analysis of our survey, which includes a comparison of the migration processes, a ranking of motivations, and issues and some insights into the benefits achieved after the adoption. Maintainability and scalability were consistently ranked as the most important motivations, along with a few other technical and nontechnical motivations. Although return on investment was expected to take longer, the reduced maintenance effort in the long run was considered to highly compensate for this.

Comparing Requirements Decomposition Within the Scrum, Scrum with Kanban, XP, and Banana Development Processes

Context: Eliciting requirements from customers is a complex task. In Agile processes, the customer talks directly with the development team and often reports requirements in an unstructured way. The requirements elicitation process is up to the developers, who split it into user stories by means of different techniques. Objective: We aim to compare the requirements decomposition process of an unstructured process and three Agile processes, namely XP, Scrum, and Scrum with Kanban. Method: We conducted a multiple case study with a replication design, based on the project idea of an entrepreneur, a designer with no experience in software development. Four teams developed the project independently, using four different development processes. The requirements were elicited by the teams from the entrepreneur, who acted as product owner and was available to talk with the four groups during the project. Results: The teams decomposed the requirements using different techniques, based on the selected development process. Conclusion: Scrum with Kanban and XP resulted in the most effective processes from different points of view. Unexpectedly, decomposition techniques commonly adopted in traditional processes are still used in Agile processes, which may reduce project agility and performance. Therefore, we believe that decomposition techniques need to be addressed to a greater extent, both from the practitioners’ and the research points of view.

A Study on OSS Marketing and Communication Strategies

The goal of every open source project is to gain as many satisfied users as possible. To this end, open source software producers should focus on both product development and communication. Currently, most open source projects are mainly concerned with developing code using the most appealing technologies and introducing fancy features. On the contrary, open source software producers seem to lack good communication strategies. In this paper we describe the communication strategies adopted by three successful companies that are active in open source software development. The goal of the paper is to provide some hints that could help other open source software producers identify communication strategies that are effective in promoting their products on the market.

Estimating Software Development Effort Based on Phases

Software development effort estimation is a very important issue in software engineering and several models have been defined to this end. In this paper, we carry out an empirical study on the estimation of software development effort broken down by phase, so that estimation can be used along the software development lifecycle. More specifically, our goal is twofold. At any given point in the software development lifecycle, we estimate the effort needed for the next phase. Also, we estimate the effort for the remaining part of the software development process. Our empirical study is based on historical data from the ISBSG database. The results show a set of statistically significant correlations between: (1) the effort spent in one phase and the effort spent in the following one, (2) the effort spent in a phase and the remaining effort, (3) the cumulative effort up to the current phase and the remaining effort. However, the results also show that these estimation models come with different degrees of goodness of fit. Finally, including further information, such as the functional size, does not significantly improve estimation quality.

How developers perceive smells in source code: A replicated study

Abstract Context. In recent years, smells, also referred to as bad smells, have gained popularity among developers. However, it is still not clear how harmful they are perceived from the developers’ point of view. Many developers talk about them, but only few know what they really are, and even fewer really take care of them in their source code. Objective. The goal of this work is to understand the perceived criticality of code smells both in theory, when reading their description, and in practice. Method. We executed an empirical study as a differentiated external replication of two previous studies. The studies were conducted as surveys involving only highly experienced developers (63 in the first study and 41 in the second one). First the perceived criticality was analyzed by proposing the description of the smells, then different pieces of code infected by the smells were proposed, and finally their ability to identify the smells in the analyzed code was tested. Results. According to our knowledge, this is the largest study so far investigating the perception of code smells with professional software developers. The results show that developers are very concerned about code smells in theory, nearly always considering them as harmful or very harmful (17 out of 23 smells). However, when they were asked to analyze an infected piece of code, only few infected classes were considered harmful and even fewer were considered harmful because of the smell. Conclusions. The results confirm our initial hypotheses that code smells are perceived as more critical in theory but not as critical in practice.

Architectural Patterns for Microservices: A Systematic Mapping Study.

Microservices is an architectural style increasing in popularity. However, there is still a lack of understanding how to adopt a microservice-based architectural style. We aim at characterizing different microservice architectural style patterns and the principles that guide their definition. We conducted a systematic mapping study in order to identify reported usage of microservices and based on these use cases extract common patterns and principles. We present two key contributions. Firstly, we identified several agreed microservice architecture patterns that seem widely adopted and reported in the case studies identified. Secondly, we presented these as a catalogue in a common template format including a summary of the advantages, disadvantages, and lessons learned for each pattern from the case studies. We can conclude that different architecture patterns emerge for different migration, orchestration, storage and deployment settings for a set of agreed principles.

A Continuous Software Quality Monitoring Approach for Small and Medium Enterprises

Context: SMEs cannot always afford the effort required for software quality assurance, and therefore there is the need of easy and affordable practices to prevent issues in the software they develop. Object: In this paper we propose an approach to allow SMEs to access SQA practices, using an SQA approach based on a continuous issue and error monitoring and a recommendation system that will suggest quality practices, recommending a set of quality actions based on the issues that previously created errors, so as to help SMEs to maintain quality above a minimum threshold. Method: First, we aim to identify a set of SQA practices applicable in SMEs, based on the main constraints of SMEs and a set of tools and practices to fulfill a complete DevOps pipeline. Second, we aim to define a recommendation system to provide software quality feedback to micro-teams, suggesting which action(s) they should take to maintain a certain quality level and allowing them to remove the most severe issues with the lowest possible effort. Our approach will be validated by a set of local SMEs. Moreover, the tools developed will be published as Open Source.

Comparing Communication Effort within the Scrum, Scrum with Kanban, XP, and Banana Development Processes

[Context]: Communication plays an important role in any development process. However, communication overhead has been rarely compared among development processes. [Objective]: The goal of this work is to compare the communication overhead and the different channels applied in three agile processes (XP, Scrum, Scrum with Kanban) and in an unstructured process. [Method]: We designed an empirical study asking four teams to develop the same application with the four development processes, and we compare the communication overhead among them. [Results]: As expected, face-to-face communication is most frequently employed in the teams. Scrum with Kanban turned out to be the process that requires the least communication. Unexpectedly, despite requiring much more time to develop the same application, the unstructured process required comparable communication overhead (25% of the total development time) as the agile processes.

Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages

In the last years, cloud-native architectures have emerged as a target platform for the deployment of microservice architectures. The migration of existing monoliths into cloud-native applications is still in the early phase, and only few companies already started their migrations. Therefore, success and failure stories about different approaches are not available in the literature. This context connects also to the recently discussed DevOps context where development and continuous deployment are closely linked.