Artificial Intelligence (AI) technologies have become increasingly central to software development, enhancing efficiency with tools such as intelligent code assistants and driving innovations in products like chatbots, recommendation engines, and predictive analytics. Despite these advancements, the inherent complexity of AI-integrated software projects often leads to the accumulation of technical debt (TD), which can compromise the reliability and sustainability of systems in the long term. Managing TD effectively in these projects can be achieved by adapting international standards. Although these standards are not designed for TD management, they can be systematically applied to detect and address TD by aligning with AI system lifecycle processes. The aim of this study is to demonstrate how AI-related TD correlates with various AI lifecycle processes, thereby enabling systematic detection and management of TD in AI-integrated software projects. To achieve this, we studied 73 unique cases of TD, each reflecting either an instance or a root cause of data-related TD. These cases were subsequently mapped to the processes and activities outlined in the ISO/IEC 5338 AI Systems Lifecycle Processes standard. Subsequently, the accuracy of these mappings was validated bidirectionally by a large language model and two domain experts. Our findings revealed that data-related TD categories are associated with a diverse range of processes such as design definition, quality management and human resource management and tend to accumulate more significantly in certain areas within the AI lifecycle. This study not only serves as a proof of concept for developing a management approach for AI-related TD, but also enhances the body of knowledge on managing TD in AI projects by detailing how TD interacts with and impacts various AI lifecycle processes.

Agile development methods aim to balance up-front and just-in-time work, prioritize adaptive and exploratory approaches, and spend time and effort on essential activities in a project's lifespan. One of the key strategies in agile development is to defer making decisions as late as possible. Software architecture development (SAD) requires creating high-level software infrastructure that reflects a solution for quality requirements such as reliability and maintainability. SAD requires performing up-front work and having established software requirements. Given these characteristics, Agile and SAD may be perceived as two conflicting worlds. In this study, we present the results of a Multivocal Literature Review (MLR) aimed at understanding the challenges of developing software architecture in agile software development projects and the solutions proposed for these challenges. The MLR included 13 grey literature and 40 formally published research sources. The challenges and solutions are discussed across eight categories.

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Abstract Medical device software development organizations are bound by regulatory requirements and constraints to ensure that developed medical devices will not harm patients. Medical devices have to be treated as complete systems and be evaluated in this manner. Instead of manufacturers having to ensure compliance to various regulatory standards individually, the authors previously developed a medical device software process assessment framework called MDevSPICE®that integrates the regulatory requirements from all the relevant medical device software standards. The MDevSPICE®was developed in a manner that suits plan‐driven software development. To improve the usability of MDevSPICE®in agile settings, we extended the assessment approach. The hybrid assessment approach described here combines the MDevSPICE®‐based process assessment method with steps for prioritization of improvement needs through value stream mapping and enabling process improvement through the use of KATA technique. This approach integrates agile methods into the medical device software development process while adhering to the requirements of the regulatory standards. This paper describes the implementation of the approach within 4 organizations that develop software in line with medical device regulations.

Agile software development approaches have emerged to overcome the inherent challenges of the traditional software development methodologies. With that in mind, they offer a set of simple yet effective practices based on the values and supporting principles of the Agile Manifesto. Today, more and more organizations are practicing Agile but transitioning to Agile is not as straightforward as it might seem. The benefits afforded by the agile values, principles and practices are not fully obtained and adapters struggle to become more mature; i.e. increase their Agility. For, adapters to address this problem, agility assessments have been designed to be aware of the situation of their transition and make sure that they are heading in the right direction. However, these assessments still require significant amount of time and effort to apply. To overcome this problem, we have developed a web-based agility assessment tool which is a part of an integrated agility assessment approach. The approach consists of a structured and comprehensive agility assessment model (AgilityMod), an exemplar agility assessment process and a web based agility assessment tool (AssessAgility). This research focuses on the final component of the approach: AssessAgility tool and presents a multiple case study that was conducted to evaluate tool's capabilities in terms of providing guidance, automation and reducing the effort spent on the assessments.

Data repositories play critical role in software management practices. Construction of the estimation models, benchmark of software performance indicators, identification of the process improvement opportunities, and quality assessment are major utilization areas of software repositories. This paper presents the observed difficulties in utilization of external and multi-organizational software benchmark repositories for effort estimation model construction for a software organization in finance domain. ISBSG, Albrecht, China, Desharnais, Finnish, Maxwell and Kemerer repositories' data were utilized in this study. The approach was the utilization of these repositories and organization's own repository to estimate the software development effort and evaluate whether external and multi-organizational data be used for effort estimation.