Abstract Design Thinking techniques have been widely used in software requirements elicitation to understand the necessities of stakeholders and end‐users. However, there is a lack of evidence of their effectiveness when applied to guide the development process of a system targeting vulnerable populations. What are the implications of using Design Thinking techniques to elicit requirements in a community of former inmates—and what would be the benefits of and challenges in this deployment? In this paper, we report our experience of using Design Thinking for requirements elicitation of a mobile application customized for the former inmates of the Brazilian prison system and their families. We applied techniques such as Brainstorming, Stakeholder Mapping, Personas Creation, Rapid Ethnography, and Interviews to obtain relevant data and create several prototypes. These techniques contribute to the development of an uncommon application that aims to help the reintegration process of former inmates into society. Our results validate the initial hypothesis that such techniques, when applied to a sensitive context, assist product development that meets the end‐users' needs by creating a higher quality product. The main limitation of the research was the lack of access to low‐literacy end‐users and/or former inmates without previous experience using mobile devices.

Misuse of cryptographic (crypto) APIs is a noteworthy cause of security vulnerabilities. For this reason, static analyzers were recently proposed for detecting crypto API misuses. They differ in strengths and weaknesses, and they might miss bugs. Motivated by the inherent limitations of static analyzers, this article reports on a study of runtime verification (RV) as a dynamic-analysis-based alternative for crypto API misuse detection. RV monitors program runs against formal specifications; it was shown to be effective and efficient for amplifying the bug-finding ability of software tests. We focus on the popular JCA crypto API and write 22 RV specifications based on expert-validated rules in a static analyzer. We monitor these specifications while running tests in five benchmarks. Lastly, we compare the accuracy of our RV-based approach, RVSec, with those of three state-of-the-art crypto API misuses detectors: CogniCrypt, CryptoGuard, and CryLogger. Results show that RVSec has higher accuracy in four benchmarks and is on par with CryptoGuard in the fifth. Overall, RVSec achieves an average${\boldsymbol{F}}_{1}$measure of 95%, compared with 83%, 78%, and 86% for CogniCrypt, CryptoGuard, and CryLogger, respectively. We highlight the strengths and limitations of these tools and show that RV is effective for detecting crypto API misuses. We also discuss how static and dynamic analysis can complement each other for detecting crypto API misuses.

Context: In a seminal work, Ball et al. [1] investigate if the information available in version control systems could be used to predict defect density, arguing that practitioners and researchers could better understand errors "if [our] version control system could talk". In the meanwhile, several research works have reported that conflict merge resolution is a time consuming and error-prone task, while other contributions diverge about the correlation between co-change dependencies and defect density. Problem: The correlation between conflicting merge scenarios and bugs has not been addressed before, whilst the correlation between co-change dependencies and bug density has been only investigated using a small number of case studies-which can compromise the generalization of the results. Goal: To address this gap in the literature, this paper presents the results of a comprehensive study whose goal is to understand whether or not (a) conflicting merge scenarios and (b) co-change dependencies are good predictors for bug density. Method: We first build a curated dataset comprising the source code history of 29 popular Java Apache projects and leverage the SZZ algorithm to collect the sets of bug-fixing and bug-introducing commits. We then combine the SZZ results with the set of past conflicting merge scenarios and co-change dependencies of the projects. Finally, we use exploratory data analysis and machine learning models to understand the strength of the correlation between conflict resolution and co-change dependencies with defect density. Findings: (a) conflicting merge scenarios are not more prone to introduce bugs than regular commits, (b) there is a negligible to a small correlation between co-change dependencies and defect density-contradicting previous studies in the literature.

Maintaining complex software systems is a time-consuming and challenging task. Practitioners must have a general understanding of the system's decomposition and how the system's developers have implemented the software features (probably cutting across different modules). Re-engineering practices are imperative to tackle these challenges. Previous research has shown the benefits of using software module clustering (SMC) to aid developers during re-engineering tasks (e.g., revealing the architecture of the systems, identifying how the concerns are spread among the modules of the systems, recommending refactorings, and so on). Nonetheless, although the literature on software module clustering has substantially evolved in the last 20 years, there are just a few tools publicly available. Still, these available tools do not scale to large scenarios, in particular, when optimizing multi-objectives. In this paper we present the Draco Clustering Tool (DCT), a new software module clustering tool. DCT design decisions make multi-objective software clusterization feasible, even for software systems comprising up to 1,000 modules. We report an empirical study that compares DCT with other available multi-objective tool (HD-NSGA-II), and both DCT and HD-NSGA-II with mono-objective tools (BUNCH and HD-LNS). We evidence that DCT solves the scalability issue when clustering medium size projects in a multi-objective mode. In a more extreme case, DCT was able to cluster Druid (an analytics data store) 221 times faster than HD-NSGA-II.

Collaborative development approaches (e.g., pair programming, coding dojo, and hackathons) have gained increasing attention in recent years, mostly because they help to share knowledge during software development activities and might shorten development cycles and increase the quality of software products. Collaborative development approaches bring also the potential benefit to contribute to learning activities. For instance, novices might participate on collaborative development sessions in order to learn new development practices, tools, and techniques used in a software development project. Besides these potential benefits, little is known about the perception of students engaged in collaborative development efforts. Therefore, in this paper we investigate whether or not the engagement of students in collaborative development efforts contributes to the learning process of software development practices and techniques, as well as the perceived benefits and challenges related to collaborative software development activities. To this end, we first performed several of coding dojo sessions during a period of 18 months. These development sessions have been conducted within the context of a real software modernization effort, which aims to modernize two enterprise systems of the Brazilian Army. After that, we carried out a qualitative study where the participants (students, software developers, and software architects) answered a survey, in order to understand the learning benefits of using coding dojo in software development activities. The results so far are encouraging. Coding Dojos allowed professors and software architects to seamless share their experience in software development with the students. According to the answers, the methodology created a better environment for the team, allowing better discussions and ideas to be shared and implemented. This has helped the team members to solve problems easier than by themselves, bringing additional benefits, such as steep the learning curve in programming languages, usage of development tools, understanding the requirements, and code refactoring.