ABSTRACT Introduction Requirements engineering (RE) faces challenges due to the handling of increasingly complex software systems. These challenges can be addressed using generative artificial intelligence (GenAI). Given that GenAI‐based RE has not been systematically analyzed in detail, this review examines the related research, focusing on trends, methodologies, challenges, and future work directions. Methods A systematic methodology for paper selection, data extraction, and feature analysis is used to comprehensively review 238 articles published from 2019 to 2025 and available from major academic databases. Results Although generative pretrained transformer models dominate current applications (67.3% of studies), the research focus remains unevenly distributed across RE phases, with analysis (30.0%) and elicitation (22.1%) receiving the most attention and management (6.8%) remaining underexplored. Three core challenges—reproducibility (66.8%), hallucinations (63.4%), and interpretability (57.1%)—form a tightly interlinked triad affecting trust and consistency, and strong correlations ( co‐occurrence) indicate that these challenges must be addressed holistically. Industrial adoption remains nascent, with > 90% of studies corresponding to early‐stage development and only 1.3% reaching production‐level integration. Evaluation practices show maturity gaps, limited tool/dataset availability, and fragmented benchmarking approaches. Conclusions Despite the transformative potential of GenAI‐based RE, several barriers hinder its practical adoption. The strong correlations among core challenges demand specialized architectures targeting interdependencies rather than isolated solutions. The limited real‐world deployment reflects systemic bottlenecks in generalizability, data quality, and scalable evaluation methods. Successful adoption requires coordinated development across technical robustness, methodological maturity, and governance integration. A multiphase research roadmap emphasizing evaluation infrastructure strengthening, governance‐aware development, and industrial‐scale standardization is proposed.

With the rapid advancement of virtual reality (VR) technology, understanding developer discussions is essential for improving software quality and maintenance. This study is the first to systematically investigate how developer concerns across major VR platforms, namely SteamVR, Meta, and HTCVive, align with the ISO/IEC 25010 international software quality standard. We collected and analyzed 392,590 posts from 47,280 developers, using topic modeling and manual coding to map discussions to nine ISO/IEC 25010 quality characteristics. We further examined topic distributions, sentiment trends, and interaction patterns across platforms. Our findings show that developers are most challenged by interaction, compatibility, and functionality issues, emphasizing the need to enhance user experience, enable cross device integration, and maintain system stability. Discussion on performance has decreased, signaling a shift in priorities. Platform specific challenges also emerged, highlighting the need for tailored strategies for different VR ecosystems. Based on these insights, we suggest strategies that prioritize optimizing user interaction (e.g., intuitive controls, seamless navigation), strengthening cross platform compatibility (e.g., universal SDKs, shared asset pipelines), and implementing sustainable maintenance practices (e.g., clear codebases, regular updates) to foster a more robust VR software ecosystem.

Quantum computers leverage the principles of quantum mechanics to execute operations. They require quantum programs that define operations on quantum bits (qubits), the fundamental units of computation. Unlike traditional software development, the process of creating and debugging quantum programs requires specialized knowledge of quantum computation, making the development process more challenging.

Business-to-business software systems are inherently specialized and operationally intricate, which make them crucial to develop accurate personas that reflect real end-user requirements throughout the development lifecycle. As user needs continuously evolve over time, it becomes imperative to establish a data-driven framework capable of persistently updating these personas and promptly integrating those changes into the development process to maintain long-term value delivery. Conventional persona generation techniques typically depend on clustering approaches applied to qualitative and quantitative data—a process that is time-intensive, expensive, and requires considerable domain expertise. This study introduces an automated method for continuous persona generation, extracting user requirements from an ongoing stream of user data. The approach utilizes large language models to interpret qualitative inputs and dynamically generate knowledge graphs, enabling real-time insights into shifting user needs. A case study involving inquiry call logs from a customer support center was conducted to validate the method. Results demonstrated that the proposed approach outperformed a traditional clustering-based baseline in approximately 86% of the cases in a question–answering task aimed at evaluating the structuring and retrieval of user requirements. Furthermore, clear insights into user pain points and requiring improvements were provided, reinforcing the effectiveness and practical utility of continuous, data-driven persona generation.

With the increasing prevalence of software incorporating deep neural networks (DNNs), quality assurance for these software systems has become a crucial concern. To this end, various methods have been proposed to repair the misbehavior of DNNs by modifying their weights. However, these repair methods may not meet the developer’s needs for a given dataset and model. In this study, we build prediction models for repair outcomes (i.e., repairs and breaks) to help determine whether the repair method is likely to work. By using our prediction models, developers and operators of DNNs can decide whether or not to apply a repair method, and if so, which method to use. Our prediction models utilize four metrics as explanatory metrics that represent the confidence or ambiguity in the DNN predictions. We experimented with four repair methods and 10 datasets. The experimental results demonstrate that our prediction models successfully select a repair method that meets developers’ needs in 16 out of 24 cases, resulting in an average time saving of 16.29% compared to the naive method. Based on these results, our prediction models can reduce costs for developers and operators when deciding whether to employ repair methods for real-world applications of DNNs.

Quantum computers, which utilize the principles of quantum mechanics, are expected to be applied to a wide range of fields. With the advancement of quantum computer development, a lot of quantum software, which enables the operation of quantum computers, has been developed. It has a distinct nature (e.g., superposition and entanglement of qubits) compared to traditional software, leading to the unique challenges of its development. While prior studies have clarified and defined some unique challenges of quantum software, many remain unclear due to limited research. In this study, we conducted an empirical study of Self-Admitted Technical Debt (SATD) for quantum software. SATD is a type of technical debt, a problem in the code that the developer is aware of. Hence, we conjecture that analyzing SATDs can reveal the unique challenges developers face when developing quantum software. We manually coded 202 comments from the Python® files of the 61 open-source quantum software on GitHub®. The 202 comments correspond to a 95% confidence level with a 5% confidence interval, as in previous studies. The results showed that 88 comments (45.6% of all SATD comments) were quantum-specific SATDs (QSATDs), which require knowledge of quantum computation to repay. Furthermore, we propose a taxonomy for QSATDs. This taxonomy, which consists of four main categories and eight subcategories, classifies QSATDs in terms of quantum-specific aspects such as circuit implementation, backend, and algorithms. Our empirical results are beneficial for quantum software developers, helping them understand implementation areas that require attention. For researchers, our results promote further research, including the exploration of challenges in QSATD repayment.

GitHub Copilot is an AI-enabled tool that automates program synthesis. It has gained significant attention since its launch in 2021. Recent studies have extensively examined Copilot's capabilities in various programming tasks, as well as its security issues. However, little is known about the effect of different natural languages on code suggestion. Natural language is considered a social bias in the field of NLP, and this bias could impact the diversity of software engineering. To address this gap, we conducted an empirical study to investigate the effect of three popular natural languages (English, Japanese, and Chinese) on Copilot. We used 756 questions of varying difficulty levels from AtCoder contests for evaluation purposes. The results highlight that the capability varies across natural languages, with Chinese achieving the worst performance. Furthermore, regardless of the type of natural language, the performance decreases significantly as the difficulty of questions increases. Our work represents the initial step in comprehending the significance of natural languages in Copilot's capability and introduces promising opportunities for future endeavors.

Just-In-Time (JIT) defect prediction strives to model changes that induce future fixes so that they can be predicted or better understood to inform development practices. Prior work demonstrates that the majority of the predictive/explanatory power of JIT models derives from the size of a change (i.e., larger changes tend to be defect-prone); however, in practice, a misguided change to even a single line of code can lead to defects. While it is clearly the case that larger changes are more likely to alter the product behavior, even small changes are capable of doing this, and when they do, they pose a risk that teams should note. However, to the best of our knowledge, JIT defect prediction models are yet to incorporate features that characterize the change in product behavior when modelling risk. This paper is the first to explore the impact of behavioral code change on JIT prediction. Specifically, we propose seven dynamic features that capture the difference in product behavior before and after applying a change. These features are computed using trace logs that are collected during invocations of test suites. Using these logs, we identify which lines of code started/stopped being exercised after a change. We evaluate these features by conducting an empirical study of two large and thriving open-source projects. We observe that, compared to baseline models that use traditional features, adding our proposed set of behavior features leads to improvements of up to 5.9% of ROC-AVC, 44.8% of precision, and 14.1 % of PR-AUC. This paper not only demonstrates the importance of behavioral features for JIT defect prediction, but also lays the foundation for future work on behavioral features in other software engineering contexts, such as build outcome prediction and code reviewer recommendation.

With the prevalence of software systems adopting neural network models, the quality assurance of these systems has become crucial. Hence, various studies have proposed repairing methods for neural network models so far to improve the quality of the models. While these methods are evaluated by researchers, it is difficult to tell whether they succeed in all models and datasets (i.e., all developers’ environments). Because these methods require many resources, such as execution times, failing to repair neural networks would cost developers their resources. Hence, if developers can know whether repairing methods succeed before adopting them, they could avoid wasting their resources. This paper proposes prediction models that predict whether repairing methods succeed in repairing neural networks using a small resource. Our prediction models predict repairs and side-effects of repairing methods, respectively. We evaluated our prediction models on a state-of-the-art repairing method Arachne on three datasets, Fashion-MNIST, CIFAR-10, and GTSRB, and found our prediction models achieved high performance, an average ROC-AUC of 0.931 and an average f1score of 0.880 for the side-effects and an average ROC-AUC of 0.768 and an average f1-score of 0.725 for the repairs.

COVID-19 has transformed face-to-face software development into distributed development (e. g., remote work). While the company authors belong to studies microtask programming, an open source software (OSS) -like development, as a solution to employ distributed development, a prior study reports a challenge: online communication in microtask programming takes longer; such lengthy communication discourages developers and affects their completion of assigned tasks. OSS, however, is successfully developed using online communication, such as issues. Hence, we have a question: how does OSS address the online communication challenge? In this experience report, we answer this question based on an empirical study on OSS communication. We found that (1) OSS prefers burst communication similar to face-to-face development, and (2) attracting developers’ attention may be a possible solution. Based on the findings, we discuss the direction of future studies to achieve better online communication in microtask programming in the company. The main contributions of this report are (1) to empirically reveal the actual communication times in OSS and (2) to show how an empirical approach helps industrial collaborators.

Defect prediction models can predict defects in software projects, and many researchers study defect prediction models to assist debugging efforts in software development. In recent years, there has been growing interest in Cross Project Defect Prediction (CPDP), which predicts defects in a project using a defect prediction model learned from other projects’ data when there is insufficient data to construct a defect prediction model. Since CPDP uses other projects’ data, data privacy preservation is one of the most significant issues. However, prior CPDP studies still require data sharing among projects to train models, and do not fully consider protecting project confidentiality. To address this, we propose a CPDP model FLR employing federated learning, a distributed machine learning approach that does not require data sharing. We evaluate FLR, using 25 projects, to investigate its effectiveness and feature interpretation. Our key results show that first, FLR outperforms the existing privacy-preserving methods (i.e., LACE2). Meanwhile, the performance is relatively comparable to the conventional methods (e.g., supervised and unsupervised learning). Second, the results of the interpretation analysis show that scale-related features have a common effect on the prediction performance of the FLR. In addition, further insights demonstrate that parameters of federated learning (e.g., learning rates and the number of clients) also play a role in the performance. This study is served as a first step to confirm the feasibility of the employment of federated learning in CPDP to ensure privacy preservation and lays the groundwork for future research on applying other machine learning models to federated learning.

If deep learning models in safety–critical systems misbehave, serious accidents may occur. Previous studies have proposed approaches to overcome such misbehavior by detecting and modifying the responsible faulty parts in deep learning models. For example, fault localization has been applied to deep neural networks to detect neurons that cause misbehavior. However, such approaches are not applicable to deep learning models that have internal states, which change dynamically based on the input data samples (e.g., recurrent neural networks (RNNs)). Hence, we propose a new fault localization approach to be applied to RNNs. We propose probabilistic automaton-based fault localization (PAFL). PAFL enables developers to detect faulty parts even in RNNs by computing suspiciousness scores with fault localization using n-grams. We convert RNNs into probabilistic finite automata (PFAs) and localize faulty sequences of state transitions on PFAs. To consider various sequences and to detect faulty ones more precisely, we use n-grams inspired by natural language processing. Additionally, we distinguish data samples related to the misbehavior to evaluate PAFL. We also propose a novel suspiciousness score, average n-gram suspiciousness (ANS) score, based on n-grams to distinguish data samples. We evaluate PAFL and ANS scores on eight publicly available datasets on three RNN variants: simple recurrent neural network, gated recurrent units, and long short-term memory. The experiment demonstrates that ANS scores identify faulty parts of RNNs when n is greater than one. Moreover, PAFL is statistically significantly better and has large effect sizes compared to state-of-the-art fault localization in terms of distinguishing data samples related to the misbehavior. Specifically, PAFL is better in 66.74% of the experimental settings. The results demonstrate that PAFL can be used to detect faulty parts in RNNs. Hence, in future studies, PAFL can be used as a baseline for fault localization in RNNs.

Debugging erroneous programs requires a great deal of human effort. To reduce human effort, automating debugging processes has been actively studied so far. One of such automation is automated program repair techniques for syntactic errors in programs. Researchers intend to support novice programmers such as students with these techniques because fixing syntactic errors is a difficult task for novice programmers. However, there exist few datasets that consist of programs written by novice programmers in universities and can be used to evaluate these techniques. Also, it is difficult to prepare such datasets from scratch. Indeed, prior studies usually utilized the Indian Institute of Technology Kanpur (IITK) dataset only. This limitation restricts the findings and implications in prior studies as a case study in the university. In this study, we intend to clarify which findings and implications in prior studies remain the same and which ones change in another university by a case study. We prepare three datasets that consist of over 21k programs collected from an introductory programming course in different divisions at our university. We compare the state-of-the-art automated program repair techniques, DeepFix, RLAssist, and Dr Repair, in these datasets. We found that (1) the best technique remains the same in all the datasets, (2) these techniques fix 8.3 % to 54.5 % syntactic errors in our datasets, which are 6.7 % to 32.4 % lower than those in the IITK dataset, (3) the error types that are fixed by them change in different datasets. Hence, the main finding in the IITK dataset remains the same; however, each technique fixes different errors.

Background: Prior studies lack the perspective of using developer's skills to augment the performance of automated program repair (APR). APR has a phase referred to as fault localization (FL), which automatically finds the faulty statement that causes faults. To achieve a well-performed FL phase, we study developers' FL skills, which allow developers to find faulty statements. We suppose that such FL skills can add additional information to fault localization to augment the accuracy of fault localization and reduce the execution cost of APR. Aims: We aim at revealing a criterion that distinguishes whether using the FL skill reduces the execution cost of the state-of-the-art APR, TBar, depending on the accuracy of the FL skill. Method: We conduct a simulation case study in the Defects4J dataset, which is the most popular dataset. We compare the numbers of candidate patches generated by TBar using the FL skill or using spectrum-based fault localization (SBFL). Results: Our case study revealed that, if developers localized the faulty statements before inspecting 40 % of the statements in the target program, the execution cost of TBar reduces for over half of the studied faults. The 40 % value is a requirement for developers using the FL skill to augment the performance of APR. Conclusion: If developers can localize the faulty statement before inspecting 40 % of the statements, integrating the FL skill with SBFL makes TBar faster compared to when SBFL is used.

Issue reports are a pivotal interface between developers and users for receiving information about bugs in their products. In practice, issue reports often have incorrect information or insufficient information to enable bugs to be reproduced, and this has the effect of delaying the entire bug-fixing process. To facilitate their bug-reproduction work, GitHub has provided a new feature that allows users to share videos (e.g., mp4 files.) Using such videos, reports can be made to developers about the details of bugs by recording the symptoms, reproduction steps, and other important aspects of bug information.

Microtask programming [4] is a solution to promote distributed development in industry. The key idea of microtask programming is to reduce face-to-face communication across developers by splitting the development task of software into independent microtasks. Such microtasks can be completed by crowd workers who work remotely and at their preferable time such as early morning. Dedicated developers who have the responsibility for the progress of development split the task into microtasks, and distribute them to crowd workers. Hence, microtask programming has these two actors. Our research team reported that microtask programming has potential benefits such as the fluidity of project assignments in industrial companies [4]. However, we suppose it still has challenges. In addition, it is still unclear what are future research direction to support both actors in microtask programming, though our research team has conducted three studies for microtask programming so far [2--4].

Refactoring as a process is aimed at improving the quality of a software system while preserving its external behavior. In practice, refactoring comes in the form of many specific and diverse refactoring operations, which have different scopes and thus a different potential impact on both the production and the test code. We present a large-scale quantitative study complemented by a qualitative analysis involving 615,196 test cases to understand how and to what extent different refactoring operations impact a system's test suites. Our findings show that while the vast majority of refactoring operations do not or very seldom induce test breaks, some specific refactoring types (e.g., “RENAME Attribute” and “RENAME Class”) have a higher chance of breaking test suites. Meanwhile, “ADD Parameter” and “CHANGE Return Type” refactoring operations often require additional lines of changes to fix the test suite they break. While some modern IDEs provide features to automatically apply these two types of refactoring operations, they are not always able to avoid test breaks, thus demanding extra human efforts.

Refactoring, the process of improving the internal code structure of a software system without altering its external behavior, is widely applied during software development. Understanding how developers refactor source code can help gain better understanding of the software development process and the relationship between various versions of a system. Refactoring detection tools have been developed for many popular programming languages, such as Java (e.g., REFACTORINGMINER and REF-FINDER) but, quite surprisingly, this is not the case for Python, a widely used programming language.Inspired by REFACTORING MINER, we present PYREF, a tool that automatically detects method-level refactoring operations in Python projects. We evaluated PYREF against a manually built oracle and compared it with a PYTHON-ADAPTED REFACTOR-INGMINER, which converts Python program to Java and detects refactoring operations with REFACTORING MINER. Our results indicate that PYREF can achieve satisfactory precision and detect more refactorings than the current state-of-the-art.

Software quality assurance efforts often focus on identifying defective code. To find likely defective code early, change-level defect prediction - aka. Just-In-Time (JIT) defect prediction - has been proposed. JIT defect prediction models identify likely defective changes and they are trained using machine learning techniques with the assumption that historical changes are similar to future ones. Most existing JIT defect prediction approaches make use of manually engineered features. Unlike those approaches, in this paper, we propose an end-to-end deep learning framework, named DeepJIT, that automatically extracts features from commit messages and code changes and use them to identify defects. Experiments on two popular software projects (i.e., QT and OPENSTACK) on three evaluation settings (i.e., cross-validation, short-period, and long-period) show that the best variant of DeepJIT (DeepJIT-Combined), compared with the best performing state-of-the-art approach, achieves improvements of 10.36-11.02% for the project QT and 9.51-13.69% for the project OPENSTACK in terms of the Area Under the Curve (AUC).

Recently, many developers begin to notice that uncertainty is a crucial problem in software development. Unfortunately, no one knows how often uncertainty appears or what kinds of uncertainty exist in actual projects, because there are no empirical studies on uncertainty. To deal with this problem, we conduct a large-scale empirical study analyzing commit messages and revision histories of 1,444 OSS projects randomly selected from the GitHub repositories. The main findings are as follows: 1) Uncertainty exists in the ratio of 1.44% (average); 2) Uncertain program behavior, uncertain variable/value/name, and uncertain program defects are major kinds of uncertainty; and 3) Sometimes developers tend to take an action for not resolving but escaping or ignoring uncertainty. Uncertainty exists everywhere in a certain percentage and developers cannot ignore the existence of uncertainty.

Background: An Android smartphone is an ecosystem of applications, drivers, operating system components, and assets. The volume of the software is large and the number of test cases needed to cover the functionality of an Android system is substantial. Enormous effort has been already taken to properly quantify "what features and apps were tested and verified?". This insight is provided by dashboards that summarize test coverage and results per feature. One method to achieve this is to manually tag or label test cases with the topic or function they cover, much like function points. At the studied Android smartphone vendor, tests are labelled with manually defined tags, so-called "feature labels (FLs)", and the FLs serve to categorize 100s to 1000s test cases into 10 to 50 groups.

Uncertainty can appear in all aspects of software development: uncertainty in requirements analysis, design decisions, implementation and testing. If uncertainty can be dealt with modularly, we can add or delete uncertain concerns to/from models, code and tests whenever these concerns arise or are fixed to certain concerns. To deal with this problem, we developed iArch-U, an IDE (Integrated Development Environment) for managing uncertainty modularly in all phases in software development. In this paper, we introduce an overview of iArch-U. The iArch-U IDE is open source software and can be downloaded from GitHub.

To prioritize software quality assurance efforts, faultprediction models have been proposed to distinguish faulty modules from clean modules. The performances of such models are often biased due to the skewness or class imbalance of the datasets considered. To improve the prediction performance of these models, sampling techniques have been employed to rebalance the distribution of fault-prone and non-fault-prone modules. The effect of these techniques have been evaluated in terms of accuracy/geometric mean/F1-measure in previous studies, however, these measures do not consider the effort needed to fixfaults. To empirically investigate the effect of sampling techniqueson the performance of software fault prediction models in a morerealistic setting, this study employs Norm(Popt), an effort-awaremeasure that considers the testing effort. We performed two setsof experiments aimed at (1) assessing the effects of samplingtechniques on effort-aware models and finding the appropriateclass distribution for training datasets (2) investigating the roleof balanced training and testing datasets on performance ofpredictive models. Of the four sampling techniques applied, the over-sampling techniques outperformed the under-samplingtechniques with Random Over-sampling performing best withrespect to the Norm (Popt) evaluation measure. Also, performanceof all the prediction models improved when sampling techniqueswere applied between the rates of (20-30)% on the trainingdatasets implying that a strictly balanced dataset (50% faultymodules and 50% clean modules) does not result in the bestperformance for effort-aware models. Our results also indicatethat performances of effort-aware models are significantly dependenton the proportions of the two types of the classes in thetesting dataset. Models trained on moderately balanced datasetsare more likely to withstand fluctuations in performance as theclass distribution in the testing data varies.

Background: Substantial research in the software evolution field aims to recover knowledge about development from the project history that is archived in repositories, such as a Version Control System (VCS). However, the data that is archived in these repositories can be analyzed at different levels of granularity. Although software evolution is a well-studied phenomenon at the revision-level, revisions may be too fine-grained to accurately represent development tasks.

Software development is a cyclic process of integrating new features while introducing and fixing defects. During development, commits that modify source code files are uploaded to version control systems. Occasionally, these commits need to be reverted, i.e., the code changes need to be completely backed out of the software project. While one can often speculate about the purpose of reverted commits (e.g., the commit may have caused integration or build problems), little empirical evidence exists to substantiate such claims. The goal of this paper is to better understand why commits are reverted in large software systems. To that end, we quantitatively and qualitatively study two proprietary and four open source projects to measure: (1) the proportion of commits that are reverted, (2) the amount of time that commits that are eventually reverted linger within a codebase, and (3) the most frequent reasons why commits are reverted. Our results show that 1%-5% of the commits in the studied systems are reverted. Those commits that are eventually reverted linger within the studied codebases for 1-35 days (median). Furthermore, we identify 13 common reasons for reverting commits, and observe that the frequency of reverted commits of each reason varies broadly from project to project. A complementary qualitative analysis suggests that many reverted commits could have been avoided with better team communication and change awareness. Our findings made Sony Mobile's stakeholders aware that internally reverted commits can be reduced by paying more attention to their own changes. On the other hand, externally reverted commits could be minimized only if external stakeholders are involved to improve inter-company communication or requirements elicitation.

To prioritize quality assurance efforts, various fault prediction models have been proposed. However, the best performing fault prediction model is unknown due to three major drawbacks: (1) comparison of few fault prediction models considering small number of data sets, (2) use of evaluation measures that ignore testing efforts and (3) use of n-fold cross-validation instead of the more practical cross-release validation. To address these concerns, we conducted cross-release evaluation of 11 fault density prediction models using data sets collected from 2 releases of 25 open source software projects with an effort-aware performance measure known as Norm(Popt). Our result shows that, whilst M5 and K* had the best performances, they were greatly influenced by the percentage of faulty modules present and size of data set. Using Norm(Popt) produced an overall average performance of more than 50% across all the selected models clearly indicating the importance of considering testing efforts in building fault-prone prediction models.

Practical guidelines on what code has better quality are in great demand. For example, it is reasonable to expect the most complex code to be buggy. Structuring code into reasonably sized files and classes also appears to be prudent. Many attempts to determine (or declare) risk thresholds for various code metrics have been made. In this paper we want to examine the applicability of such thresholds. Hence, we replicate a recently published technique for calculating metric thresholds to determine high-risk files based on code size (LOC and number of methods), and complexity (cyclomatic complexity and module interface coupling) using a very large set of open and closed source projects written primarily in Java. We relate the threshold-derived risk to (a) the probability that a file would have a defect, and (b) the defect density of the files in the high-risk group. We find that the probability of a file having a defect is higher in the very high-risk group with a few exceptions. This is particularly pronounced when using size thresholds. Surprisingly, the defect density was uniformly lower in the very high-risk group of files. Our results suggest that, as expected, less code is associated with fewer defects. However, the same amount of code in large and complex files was associated with fewer defects than when located in smaller and less complex files. Hence we conclude that risk thresholds for size and complexity metrics have to be used with caution if at all. Our findings have immediate practical implications: the redistribution of Java code into smaller and less complex files may be counterproductive.

Uncertainty can appear in all aspects of software development: uncertainty in requirements analysis, design decisions, implementation, and testing. As the research on uncertainty is so young, there are many issues to be tackled. Modularity for Uncertainty is one of them. If uncertainty can be dealt with modularly, we can add or delete uncertain concerns to/from models, code, and tests whenever these concerns arise or are fixed to certain concerns. To deal with this challenging issue, we propose a modularization mechanism for uncertainty. Agile methods embrace change to accept changeable user requirements. On the other hand, our approach embraces uncertainty to support exploratory development. This paper sets out a focused research agenda for uncertainty in terms of the new modularity vision.

Uncertainty in programming is one of the challenging issues to be tackled, because it is error-prone for many programmers to temporally avoid uncertain concerns only using simple language constructs such as comments and conditional statements. This paper proposes ucJava, a new Java programming environment for conquering uncertainty. Our environment provides a modular programming style for uncertainty and supports test-driven development taking uncertainty into consideration.

DSL (Domain-Specific Language) is one of the important approaches for software abstraction. In the past decades, DSLs have been provided by expert engineers familiar with domain knowledge and programming language processors. It is not easy for ordinary programmers to construct DSLs for their own purposes. To deal with this problem, we propose a language workbench called Argyle that can automatically generate a DSL by only specifying a set of functions needed to the DSL and an execution platform supported by the DSL. Argyle is based on software product lines and consists of the following two steps: 1) development of the core assets for constructing a family of DSLs and 2) DSL configuration using these core assets. To demonstrate the effectiveness of our approach, we developed a prototype DSL for supporting MSR (Mining Software Repositories), the most active research field in software engineering.

This paper rethinks both modularity and compilation in the light of abstraction between design and implementation. We propose a new compilation approach called abstraction-aware verifying compiler, in which abstraction is the target of compilation. Both a design model and its code are inputted as the first-class software modules to the compiler.

Abstraction has been an important issue in software engineering. However, it is not easy to design an architec- ture reflecting the intention of developers and implement the result of a design as a program while preserving an adequate abstraction level. To deal with this problem, we provide iArch, an IDE (Integrated Development Environment) for supporting abstraction-aware traceability between design and code. The iArch IDE is based on Archface, an architectural interface mechanism exposing a set of architectural points that should be shared between design and code. An abstraction level is determined by selecting architectural points.

Prior research suggests that predicting defect-inducing changes, i.e., Just-In-Time (JIT) defect prediction is a more practical alternative to traditional defect prediction techniques, providing immediate feedback while design decisions are still fresh in the minds of developers. Unfortunately, similar to traditional defect prediction models, JIT models require a large amount of training data, which is not available when projects are in initial development phases. To address this flaw in traditional defect prediction, prior work has proposed cross-project models, i.e., models learned from older projects with sufficient history. However, cross-project models have not yet been explored in the context of JIT prediction. Therefore, in this study, we empirically evaluate the performance of JIT cross-project models. Through a case study on 11 open source projects, we find that in a JIT cross-project context: (1) high performance within-project models rarely perform well; (2) models trained on projects that have similar correlations between predictor and dependent variables often perform well; and (3) ensemble learning techniques that leverage historical data from several other projects (e.g., voting experts) often perform well. Our findings empirically confirm that JIT cross-project models learned using other projects are a viable solution for projects with little historical data. However, JIT cross-project models perform best when the data used to learn them is carefully selected.

For Open Source Software (OSS) projects, retaining existing contributors and attracting new ones is a major concern. In this paper, we expand and adapt a pair of population migration metrics to analyze migration trends in a collection of open source projects. Namely, we study: (1) project stickiness, i.e., its tendency to retain existing contributors and (2) project magnetism, i.e., its tendency to attract new contributors. Using quadrant plots, we classify projects as attractive (highly magnetic and sticky), stagnant (highly sticky, weakly magnetic), fluctuating (highly magnetic, weakly sticky), or terminal (weakly magnetic and sticky). Through analysis of the MSR challenge dataset, we find that: (1) quadrant plots can effectively identify at-risk projects, (2) stickiness is often motivated by professional activity and (3) transitions among quadrants as a project ages often coincides with interesting events in the evolution history of a project.

We propose a new modularity vision to integrate design modeling with programming. A system consists of not only program code but also design models. However, design models such as UML diagrams have been treated as not modules but complementary documents. This paper provides a novel idea that treats a design model as a first-class software module termed design module. A system cannot be complied without design modules. A developer has to create and modify not only program modules but also design modules. To realize design modules, we introduce Archface, an architectural interface mechanism. Archface exposes architectural points shared between design and code. Archface plays a role as a design interface for a design module and as a program interface for a program module. Arch-face type system automatically checks the consistency between design and code. Our approach can integrate research on design modeling with research on programming in terms of modularity. Additional costs are not needed to introduce design modules, because Archface descriptions can be generated from a model editor and Archface is just an extension of the notion of program interfaces. That is, we can substitute Archface for traditional program interfaces.

Many research projects on software estimation use software size as a major explanatory variable. However, practitioners sometimes use the ratio of effort for early phase activities such as planning and requirement analysis, to the effort for the whole development phase of the software in order to estimate effort. In this paper, we focus on effort estimation based on the effort for early phase activities. The goal of the research is to examine the relationship of early phase effort and software size with software development effort. To achieve the goal, we built effort estimation models using early phase effort as an explanatory variable, and compared the estimation accuracies of these models to the effort estimation models based on software size. In addition, we built estimation models using both early phase effort and software size. In our experiment, we used ISBSG dataset, which was collected from software development companies, and regarded planning phase effort and requirement analysis effort as early phase effort. The result of the experiment showed that when both software size and sum of planning and requirement analysis phase effort were used as explanatory variables, the estimation accuracy was most improved (Average Balanced Relative Error was improved to 75.4% from 148.4%). Based on the result, we recommend that both early phase effort and software size be used as explanatory variables, because that combination showed the high accuracy, and did not have multicollinearity issues.

Defect prediction models are a well-known technique for identifying defect-prone files or packages such that practitioners can allocate their quality assurance efforts (e.g., testing and code reviews). However, once the critical files or packages have been identified, developers still need to spend considerable time drilling down to the functions or even code snippets that should be reviewed or tested. This makes the approach too time consuming and impractical for large software systems. Instead, we consider defect prediction models that focus on identifying defect-prone (“risky”) software changes instead of files or packages. We refer to this type of quality assurance activity as “Just-In-Time Quality Assurance,” because developers can review and test these risky changes while they are still fresh in their minds (i.e., at check-in time). To build a change risk model, we use a wide range of factors based on the characteristics of a software change, such as the number of added lines, and developer experience. A large-scale study of six open source and five commercial projects from multiple domains shows that our models can predict whether or not a change will lead to a defect with an average accuracy of 68 percent and an average recall of 64 percent. Furthermore, when considering the effort needed to review changes, we find that using only 20 percent of the effort it would take to inspect all changes, we can identify 35 percent of all defect-inducing changes. Our findings indicate that “Just-In-Time Quality Assurance” may provide an effort-reducing way to focus on the most risky changes and thus reduce the costs of developing high-quality software.

The Mining Software Repositories (MSR) field integrates and analyzes data stored in repositories such as source control and bug repositories to support practitioners. Given the abundance of repository data, scaling up MSR analyses has become a major challenge. Recently, researchers have experimented with conventional techniques like a supercomputer or cloud computing, but these are either too expensive or too hard to configure. This paper proposes to scale up MSR analysis using “general-purpose computing on graphics processing units” (GPGPU) on off-the-shelf video cards. In a representative MSR case study to measure co-change on version history of the Eclipse project, we find that the GPU approach is up to a factor of 43.9 faster than a CPU-only approach.

It is not easy to design software architecture reflecting the intention of developers and implement the result of design as a program while preserving the architectural correctness and adequate abstraction level. Archface, an architectural interface mechanism, plays a role as an ADL at the design phase and as a programming interface at the implementation phase. Design and code can co-evolve with Archface at the center of the development process. This paper proposes a verifiable architectural interface that can check the traceability between design and code. For this checking, we use an SMT (Satisfiability Modulo Theories) solver, a tool for deciding the satisfiability of logical formulas. Adopting our approach, we can construct MDD tools supporting adequate abstraction level when they generate code, recover a design model from code, and check the traceability between a design model and its code.

Context-awareness plays an important role in developing flexible and adaptive systems. However, it is not easy to design and implement such a context-aware system, because its system configuration can be dynamically changed. This paper proposes UML4COP, a UML-based design method for COP (Context-Oriented Programming). UML4COP is a DSML(Domain-Specific Modeling Language) for designing context-aware systems. In UML4COP, each context is modeled separately and a system design model at a certain period of time is composed by merging associated contexts.

In this paper, we present a replicated study to predict fault-prone modules with code clone metrics to follow Baba's experiment. We empirically evaluated the performance of fault prediction models with clone metrics using 3 datasets from the Eclipse project and compared it to fault prediction without clone metrics. Contrary to the original Baba's experiment, we could not significantly support the effect of clone metrics, i.e., the result showed that F1-measure of fault prediction was not improved by adding clone metrics to the prediction model. To explain this result, this paper analyzed the relationship between clone metrics and fault density. The result suggested that clone metrics were effective in fault prediction for large modules but not for small modules.

To verify behavioral specification of compound Web services, this paper introduces to apply model checking to Web services flows described by BPEL. Model checking is a formal method to formalize the behavior of designed system as an automaton and to analyze automatically whether or not the automaton satisfies the specification. This paper introduces translation pattern to convert a BPEL process to Promela code (Process or Protocol Meta Language), which is a verification modeling language in SPIN model checker. The result of our case study using a parking navigation service shows that our translation pattern can automatically verify the specification except Exception handling pattern and Event handling pattern.

Many embedded systems not only affect their context through actuators but also are affected by the context through sensors. It is important to provide a context-dependent development method for constructing safe and reliable embedded systems. However, most of the current requirements analysis methods do not explicitly provide a systematic way for deciding the boundary of the context that should be taken into account because it is essentially difficult to decide which context element should be included as the targets of requirements analysis. If a developer explores the context boundary in an ad-hoc manner, he or she will be faced with the frame problem because there are unlimited context elements in the real world where the target system exists. To deal with this problem, this paper proposes a context-dependent requirements analysis method called CAMEmb (Context Analysis Method for Embedded systems) in which only the value-context elements are extracted as the associated context elements. Applying the guide words provided by CAMEmb, we can explore only a sequence of context elements directly or indirectly affecting the data value observed or controlled by the system sensors and actuators. Other context elements not affecting the system observation and control are not taken into account because these context elements do not affect the system behavior. Using CAMEmb and lightweight formal tools, we can explore the context boundary that guarantees the expected system behavior. We developed CAMEmbModeler, a support tool consisting of a CAMEmb-based modeling editor and a model compiler that transforms system and context models into the design model reflecting the context boundary.

This paper proposes Archface, an interface mechanism for bridging the gap between architectural design and its implementation. Archface, which encapsulates design essence based on the component-and-connector architecture, is not only an ADL (Architecture Description Language) but also a programming-level interface. Archface is effective for software evolution because traceability between design and its implementation can be realized by enforcing architectural constraints on program implementation, and this traceability is bidirectional. In Archface, a component exposes program points such as method call/execution and a connector defines how to coordinate exposed program points. A collaborative architecture consisting of components can be encapsulated into a group of interfaces and separated from implementation, because dynamic program points representing control flow can be specified in the interfaces. We can characterize the notion of Archface with the phrase "predicate coordination," in which program points are exposed by a predicate and coordinated by a trait-based connector.

Aspect-oriented programming (AOP) is a technique for modularizing crosscutting concerns (CCCs). A variety of CCCs can be found in typical Web applications. Most CCCs are scattered over Web-specific events such as page requests. AOWP, a PHP-based AOP framework, provides Web-specific aspect instantiations for dealing with session management and pointcut & advice mechanisms for capturing Web-specific events. CCCs in Web applications can be clearly modularized by introducing AOWP.

We propose a new domain-specific aspect-oriented programming (AOP) mechanism for Web application development. A variety of crosscutting concerns such as access control and performance tuning are found in typical Web applications, but it is not easy to concisely modularize the concerns as aspects in current AOP languages because they do not provide pointcut mechanisms for directly handling events in the Web controller layer. To deal with this problem, we propose a Web-specific AOP mechanism called AOWP and a PHP-based AOWP framework. Using this framework, a programmer can easily address Web-specific crosscutting concerns triggered by Web-specific events, including page requests, page transitions, and session management events.

This paper proposes a context-dependent requirements analysis method called CAMEmb (Context Analysis Method for Embedded systems) consisting of UML-based context modeling and formal verification support. In CAMEmb, a context model is constructed from initial system requirements by using a UML Profile for Context Analysis. This context model clarifies the relations among hardware components and contexts. After that, the context model is verified in order to check whether a target system behaves correctly under the expected contexts.

Refactoring is a method for improving a program's structure without changing its external behavior. Refactoring is a promising approach to assist reliable and safe software evolution. However, in aspect-oriented programming (AOP), it is not necessarily easy for a programmer to understand the overall behavior of a woven program because the weaving modifies the behavior. Unexpected bugs can be embedded in a program if the programmer does not modify the program carefully. In order to deal with this problem, we propose the notion of RbC (refactoring by contract), a technique to verify refactoring based on contracts. Contracts in RbC consist of preconditions, postconditions, and invariants. A precondition states under which conditions refactoring can be applied. A postcondition states what condition should be verified after refactoring has been accomplished, and an invariant states what conditions refactoring should preserve. After introducing RbC, we check whether refactoring preserves behavior and whether it actually improves internal structure. A contract is described in COW (contract writing language), a language for describing a predicate based on first-order logic. COW provides a set of primitive predicates that represent program structure and behavior. Adopting our approach, software evolution in AOP becomes reliable and safe.

AspectM, a UML-based aspect-oriented modeling (AOM) language, provides not only basic modeling constructs but also an extension mechanism called metamodel access protocol (MMAP) that allows a modeler to extend the AspectM metamodel. MMAP enables a modeler to construct domain-specific AOM languages at relatively low cost. In this paper, we show the overview of an AspectM support tool consisting of a reflective model editor and a verifying model weaver.

Requirements changes sometimes cause a project to fail. A lot of projects now follow incremental development processes so that new requirements and requirements changes can be incorporated as soon as possible.These processes are called integrated requirements processes which integrate requirements processes with other development processes. We have investigated the requirements processes of a project from beginning to end, both quantitatively and qualitatively. Our focus is to clarify the types of requirements based on the components contained within a certain portion of the software architecture. Each type reveals its typical requirements processes through its rationale. The case studied is a system to manage the orders and services of a restaurant. In this paper, we introduce the case and describe the types of requirements processes. Then we discuss the reasons why we could not elicit all the requirements in the early development processes.

ccJava, a new kind of class-based AOP language, provides the weaving-interface mechanism in which the weaving can be realized by the component-and-connector architecture. The interface description constructs in ccJava can be considered a kind of architecture description language that takes into account the weaving. This paper provides a lightweight verification approach using Alloy, a structural modeling language based on relational logic. Using Alloy, we can verify whether the weaving based on the component-and-connector architecture satisfies some kinds of properties--whether advice-types are specified correctly,whether a pointcut selects join points correctly, and so on. By enforcing the architecture verified by Alloy to the class implementation, we can construct a reliable system.

In order to improve the quality of embedded software, this paper proposes an enhancement to the ESIM (embedded systems improving method) by combining an IFD (information flow diagram) with an Analysis Matrix to analyze unexpected obstacles in the software. These obstacles are difficult to predict in the software specification. Recently, embedded systems have become larger and more complicated. Theoretically therefore, the development cycle of these systems should be longer. On the contrary, in practice the cycle has been shortened. This trend in industry has resulted in the oversight of unexpected obstacles, and consequently affected the quality of embedded software. In order to prevent the oversight of unexpected obstacles, we have already proposed two methods for requirements analysis: the ESIM using an Analysis Matrix and a method that uses an IFD. In order to improve the efficiency of unexpected obstacle analysis at reasonable cost, we now enhance the ESIM by combining an IFD with an Analysis Matrix. The enhancement is studied from the following three viewpoints. First, a conceptual model comprising both the Analysis Matrix and IFD is defined. Then, a requirements analysis procedure is proposed, that uses both the Analysis Matrix and IFD, and assigns each specific role to either an expert or non-expert engineer. Finally, to confirm the effectiveness of this enhancement, we carry out a description experiment using an IFD.

AspectM, an aspect-oriented modeling language, provides not only basic modeling constructs but also an extension mechanism called metamodel access protocol (MMAP) that allows a modeler to modify the metamodel. MMAP consists of metamodel extension points, extension operations, and primitive predicates for defining pointcut designators. In this paper, a reflective model editor for supporting MMAP is proposed. A new modeling construct can be introduced by extending the metamodel. This mechanism, a kind of edit-time structural reflection, enables a modeler to represent domain-specific crosscutting concerns.

Aspect-oriented programming (AOP) separates crosscutting concerns from primary concerns. These concerns are woven together by a weaver. Although AOP provides an effective module mechanism, it is not necessarily easy for a programmer to understand the overall behavior of a woven program. To deal with this problem, we propose a new kind of information hiding mechanism called a weaving-interface that encapsulates weaving in class-based AOP in which all kinds of concerns are described according to classes. Weaving-interfaces are completely separated from concerns described in terms of classes. A programmer who designs how to compose concerns does not have to know the details of class definitions, but has only to be aware of weaving-interfaces. A programmer who designs each concern does not have to know how the concern is composed, but has only to be aware of weaving-interfaces. Adopting the weaving-interface mechanism, AO weaving can be realized by the component-and-connector software architecture. This weaving-interface mechanism is effective for software modularity, evolution, and reuse

This paper describes an analysis method with failure scenario matrix for specifying unexpected obstacles in order to improve the quality of embedded systems. Although embedded software has become increasingly large in scale and complexity, companies are requiring the software to be developed within shorter periods of time. Therefore, the quality of the software is bound to suffer. This problem is one of the most serious concerns in a coming age of ubiquitous embedded systems. In order to improve the quality, it is very important to specify the forbidden behavior of embedded systems. The forbidden behavior of unexpected obstacles is analyzed by using a matrix and scenarios. This paper provides a detailed description of the analysis method used, in particular the cause, phenomenon, and goal in the scenario, relating them to each other by using a matrix.

To achieve the goal of realizing object adaptation to environments, a new role-based model Epsilon and a language EpsilonJ is proposed. In Epsilon, an environment is defined as a field of collaboration between roles and an object adapts to the environment assuming one of the roles. Objects can freely enter or leave environments and belong to multiple environments at a time so that dynamic adaptation or evolution of objects is realized. Environments and roles are the first class constructs at runtime as well as at model description time so that separation of concerns is not only materialized as a static structure but also observed as behaviors. Environments encapsulating collaboration are independent reuse components to be deployed separately from objects. In this paper, the Epsilon model and the language are explained with some examples. The effectiveness of the model is illustrated by a case study on the problem of integrated systems. Implementation of the language is also reported.

We present a parameterized interpreter for modeling aspect-oriented mechanisms. The interpreter takes several parameters to cover different AOP mechanisms found in AspectJ, Hyper/J, and Demeter. The interpreter helps our understanding of the AOP mechanisms in two ways. First, its core part represents the common mechanical structure shared by different AOP mechanisms. Second, by reconstructing the existing AOP mechanisms and using parameters to configure the interpreter, we can illustrate the differences and similarities of those mechanisms clearly. This will also be helpful in rapid-prototyping a new AOP mechanism or a reflective AOP system that supports different mechanisms.

A framework in which a group of objects collaborating with each other evolve their functions dynamically is presented in this paper. We call the framework evolutional cooperative computation and present an environment-adaptive computation model for its foundation. Then, a programming language Epsilon/0, which supports the computation model and has the reflection mechanism, is presented. In this paper, the concept of environments that give objects collaboration fields is introduced. An object evolves itself and changes relations among other objects by adapting itself to environments or seceding from environments.