Context Most software companies strive to have high-performing teams and mitigate withdrawal behaviors like being present but unproductive. In this context, psychological safety and developers’ perceived impact are suggested as potential drivers of voice and silence behaviors. However, understanding these social aspects of software development entails the incorporation of social science theories. Objective This study aims to empirically explore the relationships among software professionals’ perceived impact, psychological safety, voice and silence behaviors, burnout particularly withdrawal and performance using a theoretical model. Method A survey questionnaire was conducted, resulting in 158 valid responses from software development teams. Then, we analyzed the responses using structural equation modeling (SEM) and a novel semi-confirmatory SEM. All variables were measured using pre-validated instruments. Results The findings supported the theoretical model, showing that psychological safety was more related to silence than voice, whereas perceived impact showed a stronger relationship with voice than with silence. Furthermore, silence contributed to higher burnout, whereas voice alleviated it. In contrast, silence showed a negative association with performance, whereas voice was positively associated with it. Conclusions This study examines the direct effects of perceived impact and psychological safety on voice and silence behaviors. Additionally, it examines the direct effects of these behaviors on burnout and task performance among software professionals. Consequently, the findings offer both theoretical and practical insights.

Abstract Blockchain technology has attracted significant attention in both academia and industry. Recently, the application of blockchain has been advocated in software engineering. The global software engineering paradigm exacerbates trust issues, as distributed and cross‐organizational teams need to share software artifacts. In such a context, there is a need for a decentralized yet reliable traceability knowledge base to keep track of what/how/when/by whom software artifacts were created or changed. This study presents a blockchain‐enabled framework for trustworthy and collaborative traceability management and identifies benefits, challenges, and potential improvements based on the feedback of software engineering experts. A qualitative approach was followed in this study through semistructured interviews with software engineering (SE) experts. Transcripts were analyzed by applying the content analysis technique. The results indicated the emergence of five categories, further grouped into three main categories: experts' perceptions, blockchain‐based software process improvement, and experts' recommendations. In addition, the findings suggested four archetypes of organizations that may be interested in blockchain technology: distributed organizations, organizations with contract‐based projects, organizations in regulated domains, and regulators who may push the use of this technology. Further efforts should be devoted to the integration of the proposal with tools used throughout the software development lifecycle and leveraging the potential of smart contracts in validating the implementation of requirements automatically.

Abstract Blockchain technology has emerged as a “disruptive innovation” that has received significant attention in academic and organizational settings. However, most of the existing research is focused on technical issues of blockchain systems, overlooking the organizational perspective. This study adopted a grounded theory to unveil the blockchain implementation process in organizations from the lens of blockchain experts. The results revealed three main categories: key activities, success factors, and challenges related to blockchain implementation in organizations, the latter being identified as the core category, along with 17 other concepts. Findings suggested that the majority of blockchain projects stop at the pilot stage and outlined organizational resistance to change as the core challenge. According to the experts, the following factors contribute to the organizational resistance to change: innovation–production gap, conservative management, and centralized mentality. The study aims to contribute to the existing blockchain literature by providing a holistic and domain‐agnostic view of the blockchain implementation process in organizational settings. This can potentially encourage the development and implementation of blockchain solutions and guide practitioners who are interested in leveraging the inherent benefits of this technology. In addition, the results are used to improve a blockchain‐enabled requirements traceability framework proposed in our previous paper.

Background: DevOps is currently one of the main trends in software development. Low-Code is also an emerging tendency that, combined with DevOps, may offer significant value to software businesses by improving the process. However, how DevOps practices and low-code are combined is little known. Aim: This study aims to understand the practitioner's perspectives on low-code trends. Method: Twelve interviews with IT professionals who deal with low-code in the context of DevOps were conducted. Then, a grounded theory approach was used to theme the interview quotes into emergent categories. Results: The main result of this exploratory study reveals that such an approach is the most common response to the skill shortages of software professionals. Conclusion: This study suggests the emergence of DevOps and low-code could significantly contribute to the development of quality products with low-cost and time.

Abstract Over the last 3 decades, researchers have attempted to shed light into the requirements traceability problem by introducing tracing tools, techniques, and methods with the vision of achieving ubiquitous traceability. Despite the technological advances, requirements traceability remains problematic for researchers and practitioners. This study aims to identify and investigate the main challenges in implementing (semi‐)automated requirements traceability, as reported in the recent literature. A systematic literature review was carried out based on the guidelines for systematic literature reviews in software engineering, proposed by Kitchenham. We retrieved 4530 studies by searching five major bibliographic databases and selected 70 primary studies. These studies were analysed and classified according to the challenges they present and/or address. Twenty‐one challenges were identified and were classified into five categories. Findings reveal that the most frequent challenges are technological challenges, in particular, low accuracy of traceability recovery methods. Findings also suggest that future research efforts should be devoted to the human facet of tracing, to explore traceability practices in organisational settings, and to develop traceability approaches that support agile and DevOps practices. Finally, it is recommended that researchers leverage blockchain technology as a suitable technical solution to ensure the trustworthiness of traceability information in interorganisational software projects.

Background: Medical device development projects must follow proper directives and regulations to be able to market and sell the end-product in their respective territories. The regulations describe requirements that seem to be opposite to efficient software development and short time-to-market. As agile approaches, like DevOps, are becoming more and more popular in software industry, a discrepancy between these modern methods and traditional regulated development has been reported. Although examples of successful adoption in this context exist, the research is sparse. Aims: The objective of this study is twofold: to review the current state of DevOps adoption in regulated medical device environment; and to propose a checklist based on that review for introducing DevOps in that context. Method: A multivocal literature review is performed and evidence is synthesized from sources published between 2015 to March of 2020 to capture the opinions of experts and community in this field. Results: Our findings reveal that adoption of DevOps in a regulated medical device environment such as ISO 13485 has its challenges, but potential benefits may outweigh those in areas such as regulatory, compliance, security, organizational and technical. Conclusion: DevOps for regulated medical device environments is a highly appealing approach as compared to traditional methods and could be particularly suited for regulated medical development. However, an organization must properly anchor a transition to DevOps in top-level management and be supportive in the initial phase utilizing professional coaching and space for iterative learning; as such an initiative is a complex organizational and technical task.

Abstract Blockchain is considered as a major emerging technology that is having an ever‐increasing spread both in industrial and academic contexts. As the usage of blockchain keeps increasing, a fourth generation of blockchain platforms is being proposed. Thus, applications of blockchain have evolved towards wider scopes than cryptocurrency and asset management. In this context, it is important for practitioners to have deep understanding of various blockchain assessment initiatives. Therefore, this work discusses blockchain assessment initiatives from a technology evolution viewpoint. Furthermore, a mapping was conducted to identify factors that impact blockchain initiatives, synthesize available evidence, and identify gaps between relevant approaches available in the literature. As a result, nine selected works were analyzed based on applicability, research approach, assessment process, blockchain adoption process, and blockchain waves. The findings can help practitioners to understand the main assessment factors that undermine blockchain implementations.

Abstract The Web Content Accessibility Guidelines was developed by World Wide Web Consortium with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments. Given that there is a large percentage of very small entities that develop software who also utilize the ISO/IEC software process standard, the purpose of this study is the development of software design patterns for users with visual disabilities. As a result, four accessibility design patterns are defined: Authentication adapter, Blindness adapter, Dichromatic color vision adapter, and Blurry vision adapter. These patterns will help to improve the design of the web applications built using them while being compliant with the ISO/IEC 29110 standard. The use of design patterns also enables the transfer of design experience to programming practices and improves the software documentation. To validate the set of patterns, an online course for Spanish speakers was developed, and the evaluation was carried out using simulators, automated tools, experts, and users. Simulators and automated tools showed no accessibility errors and experts evaluated 10 heuristics principles and did not identify any severity issues. Taken together, our results provide positive evidence that users with visual disabilities could benefit from the proposed features.

This study presents the results of a web accessibility evaluation performed on a sample of six software products developed by small software enterprises of two countries. According to the International Standard Organization (ISO), an enterprise, organization, department or project with up to 25 people is considered small. All the products evaluated presented accessibility issues, mainly lack of HTML labels, alternative texts, and color contrast errors. These results showed there is a need in small software enterprises of an engineering development process that, taking into account their constraints of staff and budget, includes activities for improving the accessibility of their software. We present the current state of an ongoing work to define such process based on ISO/IEC 29110 that includes accessibility-related task in each of the following activities: initiation, analysis, design, construction, integration and test, and delivery.