Language：English   Publishing type：Research paper (scientific journal)  

Just-In-Time (JIT) models identify fix-inducing code changes. JIT models are trained using techniques that assume that past fix-inducing changes are similar to future ones. However, this assumption may not hold, e.g., as system complexity tends to accrue, expertise may become more important as systems age. In this paper, we study JIT models as systems evolve. Through a longitudinal case study of 37,524 changes from the rapidly evolving Qt and OpenStack systems, we find that fluctuations in the properties of fix-inducing changes can impact the performance and interpretation of JIT models. More specifically: (a) the discriminatory power (AUC) and calibration (Brier) scores of JIT models drop considerably one year after being trained; (b) the role that code change properties (e.g., Size, Experience) play within JIT models fluctuates over time; and (c) those fluctuations yield over- and underestimates of the future impact of code change properties on the likelihood of inducing fixes. To avoid erroneous or misleading predictions, JIT models should be retrained using recently recorded data (within three months). Moreover, quality improvement plans should be informed by JIT models that are trained using six months (or more) of historical data, since they are more resilient to period-specific fluctuations in the importance of code change properties.

DOI： 10.1109/TSE.2017.2693980

Language：English   Publishing type：Research paper (scientific journal)  

Developers increasingly rely on text matching tools to analyze the relation between natural language words and APIs. However, semantic gaps, namely textual mismatches between words and APIs, negatively affect these tools. Previous studies have transformed words or APIs into low-dimensional vectors for matching; however, inaccurate results were obtained due to the failure of modeling words and APIs simultaneously. To resolve this problem, two main challenges are to be addressed: the acquisition of massive words and APIs for mining and the alignment of words and APIs for modeling. Therefore, this study proposes Word2API to effectively estimate relatedness of words and APIs. Word2API collects millions of commonly used words and APIs from code repositories to address the acquisition challenge. Then, a shuffling strategy is used to transform related words and APIs into tuples to address the alignment challenge. Using these tuples, Word2API models words and APIs simultaneously. Word2API outperforms baselines by 10%-49.6% of relatedness estimation in terms of precision and NDCG. Word2API is also effective on solving typical software tasks, e.g., query expansion and API documents linking. A simple system with Word2API-expanded queries recommends up to 21.4% more related APIs for developers. Meanwhile, Word2API improves comparison algorithms by 7.9%-17.4% in linking questions in Question&Answer communities to API documents.

DOI： 10.1109/TSE.2018.2876006

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (scientific journal)  

© 2015, Springer Science+Business Media New York. Unlike traditional defect prediction models that identify defect-prone modules, Just-In-Time (JIT) defect prediction models identify defect-inducing changes. As such, JIT defect models can provide earlier feedback for developers, while design decisions are still fresh in their minds. Unfortunately, similar to traditional defect models, JIT models require a large amount of training data, which is not available when projects are in initial development phases. To address this limitation in traditional defect prediction, prior work has proposed cross-project models, i.e., models learned from other 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 models in a cross-project context. Through an empirical study on 11 open source projects, we find that while JIT models rarely perform well in a cross-project context, their performance tends to improve when using approaches that: (1) select models trained using other projects that are similar to the testing project, (2) combine the data of several other projects to produce a larger pool of training data, and (3) combine the models of several other projects to produce an ensemble model. Our findings empirically confirm that JIT models learned using other projects are a viable solution for projects with limited historical data. However, JIT models tend to perform best in a cross-project context when the data used to learn them are carefully selected.

DOI： 10.1007/s10664-015-9400-x

Language：English   Publishing type：Research paper (international conference proceedings)  

Nowadays, a flexible, lightweight variant of the code review process (i.e., the practice of having other team members critique software changes) is adopted by open source and pro prietary software projects. While this flexibility is a blessing (e.g., enabling code reviews to span the globe), it does not mandate minimum review quality criteria like the formal code inspections of the past. Recent work shows that lax reviewing can impact the quality of open source systems. In this paper, we investigate the impact that code review- ing practices have on the quality of a proprietary system that is developed by Sony Mobile. We begin by replicating open source analyses of the relationship between software quality (as approximated by post-release defect-proneness) and: (1) code review coverage, i.e., the proportion of code changes that have been reviewed and (2) code review partic ipation, i.e., the degree of reviewer involvement in the code review process. We also perform a qualitative analysis, with a survey of 93 stakeholders, semi-structured interviews with 15 stakeholders, and a follow-up survey of 25 senior engineers. Our results indicate that while past measures of review coverage and participation do not share a relationship with defect-proneness at Sony Mobile, reviewing measures that are aware of the Sony Mobile development context are associated with defect-proneness. Our results have lead to improvements of the Sony Mobile code review process.

Language：English   Publishing type：Research paper (other academic)  

© 2016 ACM. Nowadays, a flexible, lightweight variant of the code review process (i.e., the practice of having other team members critique software changes) is adopted by open source and proprietary software projects. While this flexibility is a blessing (e.g., enabling code reviews to span the globe), it does not mandate minimum review quality criteria like the formal code inspections of the past. Recent work shows that lax reviewing can impact the quality of open source systems. In this paper, we investigate the impact that code reviewing practices have on the quality of a proprietary system that is developed by Sony Mobile. We begin by replicating open source analyses of the relationship between software quality (as approximated by post-release defect-proneness) and: (1) code review coverage, i.e., the proportion of code changes that have been reviewed and (2) code review participation, i.e., the degree of reviewer involvement in the code review process. We also perform a qualitative analysis, with a survey of 93 stakeholders, semi-structured interviews with 15 stakeholders, and a follow-up survey of 25 senior engineers. Our results indicate that while past measures of review coverage and participation do not share a relationship with defect-proneness at Sony Mobile, reviewing measures that are aware of the Sony Mobile development context are associated with defect-proneness. Our results have lead to improvements of the Sony Mobile code review process.

DOI： 10.1145/2889160.2889243

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Others   Publishing type：Research paper (scientific journal)  

DOI： 10.1007/s10664-023-10366-z

Language：Others   Publishing type：Research paper (scientific journal)  

DOI： 10.1007/s10664-023-10336-5

Language：Japanese  

Analyzing the Impact of Automatic Test Case Generation Considering Execution Paths on Automated Program Repair
For automated program repairs (APR), the cost of the patch generation process will be reduced if automatically-generated test suites can be used. Automatic test-case generation techniques often take classes as input. This study aims at identifying which classes should be given as input for the aforementioned technique. In this study, we investigate the relationship between the test suites that detected failures and the actual classes that had bugs fixed by developers. We observe the cases where test suites do not identify the classes fixed by developers as a cause of failures. We also find that these cases occur when the classes fixed by developers are on the traces generated by test suites' exercises. Based on this finding, we examine the impact of the automatically generated test-suites on the performance of APR. We demonstrate, taking into account all the classes exercised by the failed test cases, that the total number of generated patches decreases but the number of correct patches increases.

DOI： 10.11309/jssst.40.1_45

Language：Japanese  

A case study of automatic debugging problem generation using novice programmers' bug fix histories
The debugging support for beginner programmers has been an active research area in recent years. However, instead of directly supporting their debugging, training such programmers to be intermediate programmers by using exercises to debug programs is overlooked. In this training, it is important to prepare the programs including bugs that capture the tendency of beginner programmers. Therefore, we focused on Learning-Mutation, which learns the bugs using machine translation from buggy programs and fixed programs, and automatically induces bugs into programs. In this study, we applied Learning-Mutation to the programs written by beginner programmers at Kyushu University. By comparing the induced bugs by Learning-Mutation with the actual bugs by such programmers, we evaluated whether Learning-Mutation can be used to support the exercises by preparing the programs including bugs. As a result, the induced bugs are similar to the actual bugs, and the patterns of bugs that are forgetting semicolons and undeclaring variables or functions accounted for more than 36% when the number of tokens was small. On the other hand, as the number of tokens increased, the number of incorrect expressions increased. Furthermore, although there are bugs that are difficult to generate, beam search relieves this difficulty.

DOI： 10.11309/jssst.39.4_10

Language：Others   Publishing type：Research paper (other academic)  

DOI： 10.1109/icsme55016.2022.00057

Language：Others   Publishing type：Research paper (scientific journal)  

DOI： 10.1016/j.infsof.2022.106855

Language：Others   Publishing type：Research paper (other academic)  

DOI： 10.1145/3524610.3527882

Language：Japanese  

近年のIT社会の発展によってIT人材の不足が深刻になり，プログラム自動生成を含むソフトウェア開発の自動化が求められている．多くの研究が行われているなかで，プログラム自動生成をより実用的なものとするために，自動生成の過程でソースコード検索器を使用している研究がある．その研究では，求めるソースコードに木構造が近いと推測される類似解答ソースコードを検索し，自動生成の雛形としている．この手法を用いることで，プログラミングコンテストAtCoderの解答ソースコードの自動生成において，検索を行わない場合と比較して自動生成できた件数が増加したと報告されている．本研究では，木編集距離を学習に用いたソースコード検索器に着目した．ソースコード検索器の性能に影響を与える要因を実証的に調査することで，プログラム自動生成の精度向上への知見を得ることを目指す．調査では，検索精度に影響を与える要因として，深層学習モデルの構造，ソースコードの入力形式，問題の複雑度の3つを対象とし，AtCoderの問題を使用して検索精度の比較を行った．調査の結果，類似解答ソースコード検索においてTransformerのエンコーダ部分の使用は有効であることが期待できること，AtCoderの問題に対して抽象構文木のベクトル表現の使用は有効であるとはいえないこと，問題の複雑度は検索精度に影響を与えることを示した．
Automatic program generation is an active research topic in software engineering. To make automatic program generation more practical, a prior study applies source code search to the method of automatic program generation. In that study, source codes whose tree structures may be close to the desired source code developers require are searched and used as a template for the method. They reported that the method with source code search increases the number of generated source codes compared to the method without source code search. In this study, we use source code search using the tree edit distance. By empirically investigating the factors that affect the performance of source code search, we aim to improve the accuracy of automatic program generation. We focused on three factors that affect the search accuracy: the structure of the deep learning model, the input format of the source code, and the complexity of the problem. We compared the search accuracy on the AtCoder problems. We found that the encoder part of Transformer is promising for source code search, the use of vectorized representation of abstract syntax trees is less effective for the AtCoder problems, and the complexity of the problem affects the search accuracy.

DOI： 10.20729/00217602

Language：Japanese  

Self-Admitted Technical Debt（SATD）とは，コード中に存在するバグや解消すべき課題のことであり，その中でも開発者が課題を認識したうえで，コードに埋め込んだものを指す．SATDの調査は，ソフトウェアの品質向上につながることから，SATDの追加や削除について様々な研究が行われている．他方，近年ソフトウェアのクラウド化にともない，コンテナ仮想化技術の1つであるDockerが注目されている．Dockerにおいても，従来のSATD研究で調査対象とされてきた一般的なプログラミング言語と同様に，SATDの存在が報告されている．しかし，DockerにおけるSATDの削除についての調査はまだ行われていない．SATD解決実態の把握により，SATD解決パターンの獲得や解決案の提示といった応用が期待できる．そこで本研究では，Docker Hubの人気上位250イメージを対象に，Dockerfileに含まれるSATDの削除の性質理解のための調査を行う．調査の結果，Dockerfile内のSATDのうち40.7%の負債が解決されており，存在期間は中央値が67日，平均値が166日であった．また，Dockerfile自体のレビューを求めるSATDや，外部システムに起因するSATDが多いことを明らかにした．外部システムに起因するSATDの早期解決を開発者に対して促すため，外部システムの変更を検知し，更新時に開発者に通知を行うツールを作成した．
Developers occasionally leave bugs and issues that need to be resolved in source codes on purpose because of several reasons such as lack of development effort. Self-Admitted Technical Debt (SATD) refers to such bugs and issues. As it is pivotal to reduce SATDs from source codes, researchers have been investigating the additions and deletions of SATDs so far. A prior study found SATDs on Docker, one of the container virtualization technologies attracting attention in recent years. Although Docker is an important technology because of the shift to cloud computing, no prior work studies the deletions of SATD on Docker. Hence, in this study, we aim at revealing the process of deletions for SATDs on Docker to support the development with Docker. We investigate the characteristics of the deletions of SATDs on Dockerfiles, a text file to build an image for a container, in the top 250 most popular repositories of Docker Hub. We found that about 40.7% of the SATDs in the Dockerfiles are resolved within 67 days on median and 166 days on average. We also found that many SATDs exist that request a review of the Dockerfile itself and SATDs caused by external systems. In order to encourage developers to resolve SATDs caused by external systems as fast as possible, we created a tool that detects changes in external systems and notifies developers when such changes resolve the cause of SATDs.

DOI： 10.20729/00217598

Language：Others   Publishing type：Research paper (scientific journal)  

DOI： 10.1007/s10664-021-10081-7

Language：Others   Publishing type：Research paper (scientific journal)  

DOI： 10.1016/j.infsof.2021.106623

Language：Others   Publishing type：Research paper (scientific journal)  

DOI： 10.1007/s10664-021-10060-y

Language：Others   Publishing type：Research paper (other academic)  

DOI： 10.1109/ICSME52107.2021.00022

Language：Others   Publishing type：Research paper (other academic)  

DOI： 10.1109/SCAM52516.2021.00025

Language：Others   Publishing type：Research paper (scientific journal)  

DOI： 10.1007/s10664-021-09970-8

Language：Others   Publishing type：Research paper (scientific journal)  

DOI： 10.1007/s10664-021-10004-6

Language：Others  

An Empirical Analysis of the Evolution of README Files

Language：Others   Publishing type：Research paper (other academic)  

DOI： 10.1109/SANER50967.2021.00034

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Others   Publishing type：Research paper (scientific journal)  

Classifier specific (CS) and classifier agnostic (CA) feature importance methods are widely used (often interchangeably) by prior studies to derive feature importance ranks from a defect classifier. However, different feature importance methods are likely to compute different feature importance ranks even for the same dataset and classifier. Hence such interchangeable use of feature importance methods can lead to conclusion instabilities unless there is a strong agreement among different methods. Therefore, in this paper, we evaluate the agreement between the feature importance ranks associated with the studied classifiers through a case study of 18 software projects and six commonly used classifiers. We find that: 1) The computed feature importance ranks by CA and CS methods do not always strongly agree with each other. 2) The computed feature importance ranks by the studied CA methods exhibit a strong agreement including the features reported at top-1 and top-3 ranks for a given dataset and classifier, while even the commonly used CS methods yield vastly different feature importance ranks. Such findings raise concerns about the stability of conclusions across replicated studies. We further observe that the commonly used defect datasets are rife with feature interactions and these feature interactions impact the computed feature importance ranks of the CS methods (not the CA methods). We demonstrate that removing these feature interactions, even with simple methods like CFS improves agreement between the computed feature importance ranks of CA and CS methods. In light of our findings, we provide guidelines for stakeholders and practitioners when performing model interpretation and directions for future research, e.g., future research is needed to investigate the impact of advanced feature interaction removal methods on computed feature importance ranks of different CS methods.

DOI： 10.1109/TSE.2021.3056941

Language：English   Publishing type：Research paper (scientific journal)  

Classifier specific (CS) and classifier agnostic (CA) feature importance methods are widely used (often interchangeably) by prior studies to derive feature importance ranks from a defect classifier. However, different feature importance methods are likely to compute different feature importance ranks even for the same dataset and classifier. Hence such interchangeable use of feature importance methods can lead to conclusion instabilities unless there is a strong agreement among different methods. Therefore, in this paper, we evaluate the agreement between the feature importance ranks associated with the studied classifiers through a case study of 18 software projects and six commonly used classifiers. We find that: 1) The computed feature importance ranks by CA and CS methods do not always strongly agree with each other. 2) The computed feature importance ranks by the studied CA methods exhibit a strong agreement including the features reported at top-1 and top-3 ranks for a given dataset and classifier, while even the commonly used CS methods yield vastly different feature importance ranks. Such findings raise concerns about the stability of conclusions across replicated studies. We further observe that the commonly used defect datasets are rife with feature interactions and these feature interactions impact the computed feature importance ranks of the CS methods (not the CA methods). We demonstrate that removing these feature interactions, even with simple methods like CFS improves agreement between the computed feature importance ranks of CA and CS methods. In light of our findings, we provide guidelines for stakeholders and practitioners when performing model interpretation and directions for future research, e.g., future research is needed to investigate the impact of advanced feature interaction removal methods on computed feature importance ranks of different CS methods.

DOI： 10.1109/TSE.2021.3056941

Language：English   Publishing type：Research paper (other academic)  

DOI： 10.1109/QRS51102.2020.00066

Language：English   Publishing type：Research paper (scientific journal)  

DOI： 10.1007/s10664-020-09817-8

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (scientific journal)  

© 2019, Springer Science+Business Media, LLC, part of Springer Nature. Defect prediction is an important task for preserving software quality. Most prior work on defect prediction uses software features, such as the number of lines of code, to predict whether a file or commit will be defective in the future. There are several reasons to keep the number of features that are used in a defect prediction model small. For example, using a small number of features avoids the problem of multicollinearity and the so-called ‘curse of dimensionality’. Feature selection and reduction techniques can help to reduce the number of features in a model. Feature selection techniques reduce the number of features in a model by selecting the most important ones, while feature reduction techniques reduce the number of features by creating new, combined features from the original features. Several recent studies have investigated the impact of feature selection techniques on defect prediction. However, there do not exist large-scale studies in which the impact of multiple feature reduction techniques on defect prediction is investigated. In this paper, we study the impact of eight feature reduction techniques on the performance and the variance in performance of five supervised learning and five unsupervised defect prediction models. In addition, we compare the impact of the studied feature reduction techniques with the impact of the two best-performing feature selection techniques (according to prior work). The following findings are the highlights of our study: (1) The studied correlation and consistency-based feature selection techniques result in the best-performing supervised defect prediction models, while feature reduction techniques using neural network-based techniques (restricted Boltzmann machine and autoencoder) result in the best-performing unsupervised defect prediction models. In both cases, the defect prediction models that use the selected/generated features perform better than those that use the original features (in terms of AUC and performance variance). (2) Neural network-based feature reduction techniques generate features that have a small variance across both supervised and unsupervised defect prediction models. Hence, we recommend that practitioners who do not wish to choose a best-performing defect prediction model for their data use a neural network-based feature reduction technique.

DOI： 10.1007/s10664-018-9679-5

Language：Others   Publishing type：Research paper (other academic)  

© 2019 IEEE. 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.

DOI： 10.1109/QRS.2019.00045

Language：English   Publishing type：Research paper (other academic)  

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.

DOI： 10.1109/QRS.2019.00045

Language：English   Publishing type：Research paper (scientific journal)  

Technical Debt is a metaphor used to express sub-optimal source code implementations that are introduced for short-term benefits that often need to be paid back later, at an increased cost. In recent years, various empirical studies have focused on investigating source code comments that indicate Technical Debt often referred to as Self-Admitted Technical Debt (SATD). Since the introduction of SATD as a concept, an increasing number of studies have examined various aspects pertaining to SATD. Therefore, in this paper we survey research work on SATD, analyzing the characteristics of current approaches and techniques for SATD detection, comprehension, and repayment. To motivate the submission of novel and improved work, we compile tools, resources, and data sets made available to replicate or extend current SATD research. To set the stage for future work, we identify open challenges in the study of SATD, areas that are missing investigation, and discuss potential future research avenues.

DOI： 10.1016/j.jss.2019.02.056

Language：English   Publishing type：Research paper (scientific journal)  

© 2019 Elsevier Inc. Technical Debt is a metaphor used to express sub-optimal source code implementations that are introduced for short-term benefits that often need to be paid back later, at an increased cost. In recent years, various empirical studies have focused on investigating source code comments that indicate Technical Debt often referred to as Self-Admitted Technical Debt (SATD). Since the introduction of SATD as a concept, an increasing number of studies have examined various aspects pertaining to SATD. Therefore, in this paper we survey research work on SATD, analyzing the characteristics of current approaches and techniques for SATD detection, comprehension, and repayment. To motivate the submission of novel and improved work, we compile tools, resources, and data sets made available to replicate or extend current SATD research. To set the stage for future work, we identify open challenges in the study of SATD, areas that are missing investigation, and discuss potential future research avenues.

DOI： 10.1016/j.jss.2019.02.056

Language：English   Publishing type：Research paper (other academic)  

© 2019 IEEE. The rise of Artificial intelligence (AI) has the potential to significantly transform the practice of project management. Project management has a large socio-technical element with many uncertainties arising from variability in human aspects, e.g. customers' needs, developers' performance and team dynamics. AI can assist project managers and team members by automating repetitive, high-volume tasks to enable project analytics for estimation and risk prediction, providing actionable recommendations, and even making decisions. AI is potentially a game changer for project management in helping to accelerate productivity and increase project success rates. In this paper, we propose a framework where AI technologies can be leveraged to offer support for managing agile projects, which have become increasingly popular in the industry.

DOI： 10.1109/ICSE-NIER.2019.00019

Language：English   Publishing type：Research paper (other academic)  

© 2019 IEEE. Energy consumption is a concern in the data-center and at the edge, on mobile devices such as smartphones. Software that consumes too much energy threatens the utility of the end-user's mobile device. Energy consumption is fundamentally a systemic kind of performance and hence it should be addressed at design time via a software architecture that supports it, rather than after release, via some form of refactoring. Unfortunately developers often lack knowledge of what kinds of designs and architectures can help address software energy consumption. In this paper we show that some simple design choices can have significant effects on energy consumption. In particular we examine the Model-View-Controller architectural pattern and demonstrate how converting to Model-View-Presenter with bundling can improve the energy performance of both benchmark systems and real world applications. We show the relationship between energy consumption and bundled and delayed view updates: bundling events in the presenter can often reduce energy consumption by 30%.

DOI： 10.1109/ICSE.2019.00114

Language：English   Publishing type：Research paper (other academic)  

© 2019 IEEE. Nowadays, many software systems are required to be updated and delivered in a short period of time. It is important for developers to make software embrace uncertainty, because user requirements or design decisions are not always completely determined. This paper introduces iArch-U, an Eclipse-based uncertainty-aware software development tool chain, for developers to properly describe, trace, and manage uncertainty crosscutting over UML modeling, Java programming, and testing phases. Integrating with Git, iArch-U can manage why/when/where uncertain concerns arise or are fixed to be certain in a project. In this tool demonstration, we show the world of uncertainty-aware software development using iArch-U. Our tool is open source software released from http://posl.github.io/iArch/.

DOI： 10.1109/ICSE-Companion.2019.00047

Language：English   Publishing type：Research paper (other academic)  

The rise of Artificial intelligence (AI) has the potential to significantly transform the practice of project management. Project management has a large socio-technical element with many uncertainties arising from variability in human aspects, e.g. customers' needs, developers' performance and team dynamics. AI can assist project managers and team members by automating repetitive, high-volume tasks to enable project analytics for estimation and risk prediction, providing actionable recommendations, and even making decisions. AI is potentially a game changer for project management in helping to accelerate productivity and increase project success rates. In this paper, we propose a framework where AI technologies can be leveraged to offer support for managing agile projects, which have become increasingly popular in the industry.

DOI： 10.1109/ICSE-NIER.2019.00019

Language：English   Publishing type：Research paper (other academic)  

© 2019 IEEE. Energy consumption is a concern in the data-center and at the edge, on mobile devices such as smartphones. Software that consumes too much energy threatens the utility of the end-user's mobile device. Energy consumption is fundamentally a systemic kind of performance and hence it should be addressed at design time via a software architecture that supports it, rather than after release, via some form of refactoring. Unfortunately developers often lack knowledge of what kinds of designs and architectures can help address software energy consumption. In this paper we show that some simple design choices can have significant effects on energy consumption. In particular we examine the Model-View-Controller architectural pattern and demonstrate how converting to Model-View-Presenter with bundling can improve the energy performance of both benchmark systems and real world applications. We show the relationship between energy consumption and bundled and delayed view updates: bundling events in the presenter can often reduce energy consumption by 30%.

DOI： 10.1109/ICSE.2019.00114

Language：English   Publishing type：Research paper (other academic)  

Nowadays, many software systems are required to be updated and delivered in a short period of time. It is important for developers to make software embrace uncertainty, because user requirements or design decisions are not always completely determined. This paper introduces iArch-U, an Eclipse-based uncertainty-aware software development tool chain, for developers to properly describe, trace, and manage uncertainty crosscutting over UML modeling, Java programming, and testing phases. Integrating with Git, iArch-U can manage why/when/where uncertain concerns arise or are fixed to be certain in a project. In this tool demonstration, we show the world of uncertainty-aware software development using iArch-U. Our tool is open source software released from http://posl.github.io/iArch/.

DOI： 10.1109/ICSE-Companion.2019.00047

Language：English   Publishing type：Research paper (other academic)  

Embracing uncertainty in software development is one of the crucial research topics in software engineering. In most projects, we have to deal with uncertain concerns by using informal ways such as documents, mailing lists, or issue tracking systems. This task is tedious and error-prone. Especially, uncertainty in programming is one of the challenging issues to be tackled, because it is difficult to verify the correctness of a program when there are uncertain user requirements, unfixed design choices, and alternative algorithms. This paper proposes iArch-U/MC, an uncertainty-aware model checker for verifying whether or not some important properties are guaranteed even if Known Unknowns remain in a program. Our tool is based on LTSA (Labelled Transition System Analyzer) and is implemented as an Eclipse plug-in.

Language：English   Publishing type：Research paper (scientific journal)  

Defect prediction is an important task for preserving software quality. Most prior work on defect prediction uses software features, such as the number of lines of code, to predict whether a file or commit will be defective in the future. There are several reasons to keep the number of features that are used in a defect prediction model small. For example, using a small number of features avoids the problem of multicollinearity and the so-called ‘curse of dimensionality’. Feature selection and reduction techniques can help to reduce the number of features in a model. Feature selection techniques reduce the number of features in a model by selecting the most important ones, while feature reduction techniques reduce the number of features by creating new, combined features from the original features. Several recent studies have investigated the impact of feature selection techniques on defect prediction. However, there do not exist large-scale studies in which the impact of multiple feature reduction techniques on defect prediction is investigated. In this paper, we study the impact of eight feature reduction techniques on the performance and the variance in performance of five supervised learning and five unsupervised defect prediction models. In addition, we compare the impact of the studied feature reduction techniques with the impact of the two best-performing feature selection techniques (according to prior work). The following findings are the highlights of our study: (1) The studied correlation and consistency-based feature selection techniques result in the best-performing supervised defect prediction models, while feature reduction techniques using neural network-based techniques (restricted Boltzmann machine and autoencoder) result in the best-performing unsupervised defect prediction models. In both cases, the defect prediction models that use the selected/generated features perform better than those that use the original features (in terms of AUC and performance variance). (2) Neural network-based feature reduction techniques generate features that have a small variance across both supervised and unsupervised defect prediction models. Hence, we recommend that practitioners who do not wish to choose a best-performing defect prediction model for their data use a neural network-based feature reduction technique.

DOI： 10.1007/s10664-018-9679-5

Language：English   Publishing type：Research paper (scientific journal)  

Researchers usually discretize a continuous dependent variable into two target classes by introducing an artificial discretization threshold (e.g., median). However, such discretization may introduce noise (i.e., discretization noise) due to ambiguous class loyalty of data points that are close to the artificial threshold. Previous studies do not provide a clear directive on the impact of discretization noise on the classifiers and how to handle such noise. In this paper, we propose a framework to help researchers and practitioners systematically estimate the impact of discretization noise on classifiers in terms of its impact on various performance measures and the interpretation of classifiers. Through a case study of 7 software engineering datasets, we find that: 1) discretization noise affects the different performance measures of a classifier differently for different datasets; 2) Though the interpretation of the classifiers are impacted by the discretization noise on the whole, the top 3 most important features are not affected by the discretization noise. Therefore, we suggest that practitioners and researchers use our framework to understand the impact of discretization noise on the performance of their built classifiers and estimate the exact amount of discretization noise to be discarded from the dataset to avoid the negative impact of such noise.

DOI： 10.1109/TSE.2019.2924371

Language：English   Publishing type：Research paper (scientific journal)  

Nowadays, open source software (OSS) systems are adopted by proprietary software projects. To reduce the risk of using problematic OSS systems (e.g., causing system crashes), it is important for proprietary software projects to assess OSS systems in advance. Therefore, OSS quality assessment models are studied to obtain information regarding the quality of OSS systems. Although the OSS quality assessment models are partially validated using a small number of case studies, to the best of our knowledge, there are few studies that empirically report how industrial projects actually use OSS quality assessment models in their own development process. In this study, we empirically evaluate the cost and effectiveness of OSS quality assessment models at Fujitsu Kyushu Network Technologies Limited (Fujitsu QNET). To conduct the empirical study, we collect datasets from (a) 120 OSS projects that Fujitsu QNET's projects actually used and (b) 10 problematic OSS projects that caused major problems in the projects. We find that (1) it takes average and median times of 51 and 49 minutes, respectively, to gather all assessment metrics per OSS project and (2) there is a possibility that we can filter problematic OSS systems by using the threshold derived from a pool of assessment metrics. Fujitsu QNET's developers agree that our results lead to improvements in Fujitsu QNET's OSS assessment process. We believe that our work significantly contributes to the empirical knowledge about applying OSS assessment techniques to industrial projects.

DOI： 10.1587/transinf.2018EDP7163

Language：English   Publishing type：Research paper (scientific journal)  

Nowadays, open source software (OSS) systems are adopted by proprietary software projects. To reduce the risk of using problematic OSS systems (e.g., causing system crashes), it is important for proprietary software projects to assess OSS systems in advance. Therefore, OSS quality assessment models are studied to obtain information regarding the quality of OSS systems. Although the OSS quality assessment models are partially validated using a small number of case studies, to the best of our knowledge, there are few studies that empirically report how industrial projects actually use OSS quality assessment models in their own development process. In this study, we empirically evaluate the cost and effectiveness of OSS quality assessment models at Fujitsu Kyushu Network Technologies Limited (Fujitsu QNET). To conduct the empirical study, we collect datasets from (a) 120 OSS projects that Fujitsu QNET's projects actually used and (b) 10 problematic OSS projects that caused major problems in the projects. We find that (1) it takes average and median times of 51 and 49 minutes, respectively, to gather all assessment metrics per OSS project and (2) there is a possibility that we can filter problematic OSS systems by using the threshold derived from a pool of assessment metrics. Fujitsu QNET's developers agree that our results lead to improvements in Fujitsu QNET's OSS assessment process. We believe that our work significantly contributes to the empirical knowledge about applying OSS assessment techniques to industrial projects.

DOI： 10.1587/transinf.2018EDP7163

Language：English   Publishing type：Research paper (other academic)  

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. Aim: Unfortunately for developers, manual assignment of FLs to 1000s of test cases is a time consuming task, leading to inaccurately labeled test cases, which will render the dashboard useless. We created an automated system that suggests tags/labels to the developers for their test cases rather than manual labeling. Method: We use machine learning models to predict and label the functionality tested by 10,000 test cases developed at the company. Results: Through the quantitative experiments, our models achieved acceptable F-1 performance of 0.3 to 0.88. Also through the qualitative studies with expert teams, we showed that the hierarchy and path of tests was a good predictor of a feature's label. Conclusions: We find that this method can reduce tedious manual effort that software developers spent classifying test cases, while providing more accurate classification results.

DOI： 10.1145/3239235.3268927

Language：English   Publishing type：Research paper (scientific journal)  

Association rule mining discovers relationships among variables in a data set, representing them as rules. These are expected to often have predictive abilities, that is, to be able to predict future events, but commonly used rule interestingness measures, such as support and confidence, do not directly assess their predictive power. This paper proposes a cross-validation -based metric that quantifies the predictive power of such rules for characterizing software defects. The results of evaluation this metric experimentally using four open-source data sets (Mylyn, NetBeans, Apache Ant and jEdit) show that it can improve rule prioritization performance over conventional metrics (support, confidence and odds ratio) by 72.8% for Mylyn, 15.0% for NetBeans, 10.5% for Apache Ant and 0 for jEdit in terms of SumNormPre(100) precision criterion. This suggests that the proposed metric can provide better rule prioritization performance than conventional metrics and can at least provide similar performance even in the worst case.

DOI： 10.1587/transinf.2018EDP7020

Language：English   Publishing type：Research paper (scientific journal)  

Association rule mining discovers relationships among variables in a data set, representing them as rules. These are expected to often have predictive abilities, that is, to be able to predict future events, but commonly used rule interestingness measures, such as support and confidence, do not directly assess their predictive power. This paper proposes a cross-validation -based metric that quantifies the predictive power of such rules for characterizing software defects. The results of evaluation this metric experimentally using four open-source data sets (Mylyn, NetBeans, Apache Ant and jEdit) show that it can improve rule prioritization performance over conventional metrics (support, confidence and odds ratio) by 72.8% for Mylyn, 15.0% for NetBeans, 10.5% for Apache Ant and 0 for jEdit in terms of SumNormPre(100) precision criterion. This suggests that the proposed metric can provide better rule prioritization performance than conventional metrics and can at least provide similar performance even in the worst case.

DOI： 10.1587/transinf.2018EDP7020

Language：English   Publishing type：Research paper (other academic)  

Software developers can have a reputation for frequently working long and irregular hours which are widely considered to inhibit mental capacity and negatively affect work quality. This paper analyzes the working habits of software developers and the effects these habits have on efficiency based on a large amount of data extracted from the actions of developers in the IDE (Integrated Development Environment), Visual Studio. We use events that recorded the times at which all developer actions were performed along with the numbers of successful and failed build and test events. Due to the high level of detail of the events provided by KaVE project's tool, we were able to analyze the data in a way that previous studies have not been able to. We structure our study along three dimensions: (1) days of the week, (2) time of the day, and (3) continuous work. Our findings will help software developers and team leaders to appropriatly allocate working times and to maximize work quality.

DOI： 10.1145/3196398.3196458

Language：Others   Publishing type：Research paper (other academic)  

© 2018 Authors. 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 selected from the GitHub repositories.

DOI： 10.1145/3183440.3194966

Language：Others   Publishing type：Research paper (other academic)  

© 2018 ACM. Software developers can have a reputation for frequently working long and irregular hours which are widely considered to inhibit mental capacity and negatively affect work quality. This paper analyzes the working habits of software developers and the effects these habits have on efficiency based on a large amount of data extracted from the actions of developers in the IDE (Integrated Development Environment), Visual Studio. We use events that recorded the times at which all developer actions were performed along with the numbers of successful and failed build and test events. Due to the high level of detail of the events provided by KaVE project's tool, we were able to analyze the data in a way that previous studies have not been able to. We structure our study along three dimensions: (1) days of the week, (2) time of the day, and (3) continuous work. Our findings will help software developers and team leaders to appropriatly allocate working times and to maximize work quality.

DOI： 10.1145/3196398.3196458

Language：English   Publishing type：Research paper (scientific journal)  

© 2017 IEEE. Just-In-Time (JIT) models identify fix-inducing code changes. JIT models are trained using techniques that assume that past fix-inducing changes are similar to future ones. However, this assumption may not hold, e.g., as system complexity tends to accrue, expertise may become more important as systems age. In this paper, we study JIT models as systems evolve. Through a longitudinal case study of 37,524 changes from the rapidly evolving Qt and OpenStack systems, we find that fluctuations in the properties of fix-inducing changes can impact the performance and interpretation of JIT models. More specifically: (a) the discriminatory power (AUC) and calibration (Brier) scores of JIT models drop considerably one year after being trained; (b) the role that code change properties (e.g., Size, Experience) play within JIT models fluctuates over time; and (c) those fluctuations yield over- and underestimates of the future impact of code change properties on the likelihood of inducing fixes. To avoid erroneous or misleading predictions, JIT models should be retrained using recently recorded data (within three months). Moreover, quality improvement plans should be informed by JIT models that are trained using six months (or more) of historical data, since they are more resilient to period-specific fluctuations in the importance of code change properties.

DOI： 10.1109/TSE.2017.2693980

Language：Others   Publishing type：Research paper (other academic)  

© 2018 Authors. 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 selected from the GitHub repositories.

DOI： 10.1145/3183440.3194966

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (other academic)  

© 2017 IEEE. 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.

DOI： 10.1109/MiSE.2017.7

Language：English   Publishing type：Research paper (other academic)  

© 2017 IEEE. It is common practice to discretize continuous defect counts into defective and non-defective classes and use them as a target variable when building defect classifiers (discretized classifiers). However, this discretization of continuous defect counts leads to information loss that might affect the performance and interpretation of defect classifiers. Another possible approach to build defect classifiers is through the use of regression models then discretizing the predicted defect counts into defective and non-defective classes (regression-based classifiers). In this paper, we compare the performance and interpretation of defect classifiers that are built using both approaches (i.e., discretized classifiers and regression-based classifiers) across six commonly used machine learning classifiers (i.e., linear/logistic regression, random forest, KNN, SVM, CART, and neural networks) and 17 datasets. We find that: i) Random forest based classifiers outperform other classifiers (best AUC) for both classifier building approaches, ii) In contrast to common practice, building a defect classifier using discretized defect counts (i.e., discretized classifiers) does not always lead to better performance. Hence we suggest that future defect classification studies should consider building regression-based classifiers (in particular when the defective ratio of the modeled dataset is low). Moreover, we suggest that both approaches for building defect classifiers should be explored, so the best-performing classifier can be used when determining the most influential features.

DOI： 10.1109/MSR.2017.4

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (other academic)  

© 2017 IEEE. A/B testing is the experiment strategy, which is often used on web or mobile application development. In A/B testing, a developer has to implement multiple variations of application, assign each variation to a subset of the entire user population randomly, and analyze log data to decide which variation should be used as a final product. Therefore, it is challenging to keep the application code clean in A/B testing, because defining variations of software or assigning user to each variation needs the modification of code. In fact there are some existing tools to approach this problem. Considering such a context of A/B testing research, we propose the solution based on the interface Archface-U and AOP (Aspect Oriented Programming) which aims to minimize the complication of code in A/B testing.

DOI： 10.1109/ICSTW.2017.72

Language：Others   Publishing type：Research paper (scientific journal)  

© 2016, Springer Science+Business Media New York The original version of this article unfortunately contained a mistake. The name of the third author was incorrectly displayed as BYasukata Kamei^. The correct information is as shown above.

DOI： 10.1007/s10664-016-9455-3

Language：English   Publishing type：Research paper (other academic)  

© 2017 IEEE. A/B testing is the experiment strategy, which is often used on web or mobile application development. In A/B testing, a developer has to implement multiple variations of application, assign each variation to a subset of the entire user population randomly, and analyze log data to decide which variation should be used as a final product. Therefore, it is challenging to keep the application code clean in A/B testing, because defining variations of software or assigning user to each variation needs the modification of code. In fact there are some existing tools to approach this problem. Considering such a context of A/B testing research, we propose the solution based on the interface Archface-U and AOP (Aspect Oriented Programming) which aims to minimize the complication of code in A/B testing.

DOI： 10.1109/ICSTW.2017.72

Language：Others   Publishing type：Research paper (scientific journal)  

© 2016, Springer Science+Business Media New York The original version of this article unfortunately contained a mistake. The name of the third author was incorrectly displayed as BYasukata Kamei^. The correct information is as shown above.

DOI： 10.1007/s10664-016-9455-3

Language：English   Publishing type：Research paper (scientific journal)  

© 2017 The Institute of Electronics, Information and Communication Engineers. To identify problems in a software development process, we have been developing an automated measurement tool called TaskPit, which monitors software development tasks such as programming, testing and documentation based on the execution history of software applications. This paper introduces the system requirements, design and implementation of TaskPit; then, presents two real-world case studies applying TaskPit to actual software development. In the first case study, we applied TaskPit to 12 software developers in a certain software development division. As a result, several concerns (to be improved) have been revealed such as (a) a project leader spent too much time on development tasks while he was supposed to be a manager rather than a developer, (b) several developers rarely used e-mails despite the company's instruction to use e-mail as much as possible to leave communication records during development, and (c) several developers wrote too long e-mails to their customers. In the second case study, we have recorded the planned, actual, and self reported time of development tasks. As a result, we found that (d) there were unplanned tasks in more than half of days, and (e) the declared time became closer day by day to the actual time measured by TaskPit. These findings suggest that TaskPit is useful not only for a project manager who is responsible for process monitoring and improvement but also for a developer who wants to improve by him/herself.

DOI： 10.1587/transinf.2016EDP7222

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (other academic)  

© 2016 IEEE. 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.

DOI： 10.1109/ICSME.2016.83

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

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.

Language：English   Publishing type：Research paper (other academic)  

© 2016 IEEE. 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.

DOI： 10.1109/QRS.2016.33

Language：English   Publishing type：Research paper (scientific journal)  

© 2015, Springer Science+Business Media New York. Software code review, i.e., the practice of having other team members critique changes to a software system, is a well-established best practice in both open source and proprietary software domains. Prior work has shown that formal code inspections tend to improve the quality of delivered software. However, the formal code inspection process mandates strict review criteria (e.g., in-person meetings and reviewer checklists) to ensure a base level of review quality, while the modern, lightweight code reviewing process does not. Although recent work explores the modern code review process, little is known about the relationship between modern code review practices and long-term software quality. Hence, in this paper, we study the relationship between post-release defects (a popular proxy for long-term software quality) and: (1) code review coverage, i.e., the proportion of changes that have been code reviewed, (2) code review participation, i.e., the degree of reviewer involvement in the code review process, and (3) code reviewer expertise, i.e., the level of domain-specific expertise of the code reviewers. Through a case study of the Qt, VTK, and ITK projects, we find that code review coverage, participation, and expertise share a significant link with software quality. Hence, our results empirically confirm the intuition that poorly-reviewed code has a negative impact on software quality in large systems using modern reviewing tools.

DOI： 10.1007/s10664-015-9381-9

Language：English   Publishing type：Research paper (international conference proceedings)  

Context: The quality of mobile applications has a vital impact on their user’s experience, ratings and ultimately overall success. Given the high competition in the mobile application market, i.e., many mobile applications perform the same or similar functionality, users of mobile apps tend to be less tolerant to quality issues.
Goal: Therefore, identifying these crashing releases early on so that they can be avoided will help mobile app developers keep their user base and ensure the overall success of their apps.
Method: To help mobile developers, we use machine learning techniques to effectively predict mobile app releases that are more likely to cause crashes, i.e., crashing releases. To perform our prediction, we mine and use a number of factors about the mobile releases, that are grouped into six unique dimensions: complexity, time, code, diffusion, commit, and text, and use a Naive Bayes classified to perform our prediction.
Results: We perform an empirical study on 10 open source mobile applications containing a total of 2,638 releases from the F-Droid repository. On average, our approach can achieve F1 and AUC scores that improve over a baseline (random) predictor by 50% and 28%, respectively. We also find that factors related to text extracted from the commit logs prior to a release are the best predictors of crashing releases and have the largest effect.
Conclusions: Ourproposedapproachcouldhelptoidentifycrash releases for mobile apps.

Language：English   Publishing type：Research paper (other academic)  

© 2016 ACM. 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. Aim: In this paper, we set out to understand the impact that the revision granularity has on co-change analyses. Method: We conduct an empirical study of 14 open source systems that are developed by the Apache Software Foundation. To understand the impact that the revision granularity may have on co-change activity, we study work items, i.e., logical groups of revisions that address a single issue. Results: We find that work item grouping has the potential to impact co-change activity, since 29% of work items consist of 2 or more revisions in 7 of the 14 studied systems. Deeper quantitative analysis shows that, in 7 of the 14 studied systems: (1) 11% of largest work items are entirely composed of small revisions, and would be missed by traditional approaches to filter or analyze large changes, (2) 83% of revisions that co-change under a single work item cannot be grouped using the typical configuration of the sliding time window technique and (3) 48% of work items that involve multiple developers cannot be grouped at the revision-level. Conclusions: Since the work item granularity is the natural means that practitioners use to separate development tasks, future software evolution studies, especially co-change analyses, should be conducted at the work item level.

DOI： 10.1145/2961111.2962607

Language：English   Publishing type：Research paper (other academic)  

© 2016 ACM. Context: The quality of mobile applications has a vital impact on their user's experience, ratings and ultimately overall success. Given the high competition in the mobile application market, i.e., many mobile applications perform the same or similar functionality, users of mobile apps tend to be less tolerant to quality issues. Goal: Therefore, identifying these crashing releases early on so that they can be avoided will help mobile app developers keep their user base and ensure the overall success of their apps. Method: To help mobile developers, we use machine learning techniques to effectively predict mobile app releases that are more likely to cause crashes, i.e., crashing releases. To perform our prediction, we mine and use a number of factors about the mobile releases, that are grouped into six unique dimensions: complexity, time, code, diffusion, commit, and text, and use a Naive Bayes classified to perform our prediction. Results: We perform an empirical study on 10 open source mobile applications containing a total of 2,638 releases from the F-Droid repository. On average, our approach can achieve F1 and AUC scores that improve over a baseline (random) predictor by 50% and 28%, respectively. We also find that factors related to text extracted from the commit logs prior to a release are the best predictors of crashing releases and have the largest effect. Conclusions: Our proposed approach could help to identify crash releases for mobile apps.

DOI： 10.1145/2961111.2962606

Language：English   Publishing type：Research paper (international conference proceedings)  

Aim: In this paper, we set out to understand the impact that the revision granularity has on co-change analyses. Method: We conduct an empirical study of 14 open source systems that are developed by the Apache Software Foundation. To understand the impact that the revision granularity may have on co-change activity, we study work items, i.e., logical groups of revisions that address a single issue. Results: We find that work item grouping has the poten- tial to impact co-change activity, since 29% of work items consist of 2 or more revisions in 7 of the 14 studied systems. Deeper quantitative analysis shows that, in 7 of the 14 studied systems: (1) 11% of largest work items are entirely composed of small revisions, and would be missed by traditional approaches to filter or analyze large changes, (2) 83% of revisions that co-change under a single work item cannot be grouped using the typical configuration of the sliding time window technique and (3) 48% of work items that involve multiple developers cannot be grouped at the revision-level. Conclusions: Since the work item granularity is the natural means that practitioners use to separate development tasks, future software evolution studies, especially co-change analyses, should be conducted at the work item level.

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (other academic)  

© 2016 IEEE. 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.

DOI： 10.1109/COMPSAC.2016.144

Language：English   Publishing type：Research paper (other academic)  

© 2016 IEEE. Association rule mining discovers patterns of co-occurrences of attributes as association rules in a data set. The derived association rules are expected to be recurrent, that is, the patterns recur in future in other data sets. This paper defines the recurrence of a rule, and aims to find a criteria to distinguish between high recurrent rules and low recurrent ones using a data set for software defect prediction. An experiment with the Eclipse Mylyn defect data set showed that rules of lower than 30 transactions showed low recurrence. We also found that the lower bound of transactions to select high recurrence rules is dependent on the required precision of defect prediction.

DOI： 10.1109/ICIS.2016.7550867

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (other academic)  

© 2016 IEEE. We have investigated through several experiments the differences in the fault-prone module prediction accuracy caused by the differences in the constituent code clone metrics of the prediction model. In the previous studies, they use one or more code clone metrics as independent variables to build an accurate prediction model. While they often use the clone detection method proposed by Kamiya et al. to calculate these metrics, the effect of the detection method on the prediction accuracy is not clear. In the experiment, we built prediction models using a dataset collected from an open source software project. The result suggests that the prediction accuracy is improved, when clone metrics derived from the various clone detection tool are used.

DOI： 10.1109/SANER.2016.65

Language：English   Publishing type：Research paper (other academic)  

© 2016 IEEE. We have investigated through several experiments the differences in the fault-prone module prediction accuracy caused by the differences in the constituent code clone metrics of the prediction model. In the previous studies, they use one or more code clone metrics as independent variables to build an accurate prediction model. While they often use the clone detection method proposed by Kamiya et al. to calculate these metrics, the effect of the detection method on the prediction accuracy is not clear. In the experiment, we built prediction models using a dataset collected from an open source software project. The result suggests that the prediction accuracy is improved, when clone metrics derived from the various clone detection tool are used.

DOI： 10.1109/SANER.2016.65

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Others   Publishing type：Research paper (scientific journal)  

© 2015, Springer Science+Business Media New York. As software systems continue to play an important role in our daily lives, their quality is of paramount importance. Therefore, a plethora of prior research has focused on predicting components of software that are defect-prone. One aspect of this research focuses on predicting software changes that are fix-inducing. Although the prior research on fix-inducing changes has many advantages in terms of highly accurate results, it has one main drawback: It gives the same level of impact to all fix-inducing changes. We argue that treating all fix-inducing changes the same is not ideal, since a small typo in a change is easier to address by a developer than a thread synchronization issue. Therefore, in this paper, we study high impact fix-inducing changes (HIFCs). Since the impact of a change can be measured in different ways, we first propose a measure of impact of the fix-inducing changes, which takes into account the implementation work that needs to be done by developers in later (fixing) changes. Our measure of impact for a fix-inducing change uses the amount of churn, the number of files and the number of subsystems modified by developers during an associated fix of the fix-inducing change. We perform our study using six large open source projects to build specialized models that identify HIFCs, determine the best indicators of HIFCs and examine the benefits of prioritizing HIFCs. Using change factors, we are able to predict 56 % to 77 % of HIFCs with an average false alarm (misclassification) rate of 16 %. We find that the lines of code added, the number of developers who worked on a change, and the number of prior modifications on the files modified during a change are the best indicators of HIFCs. Lastly, we observe that a specialized model for HIFCs can provide inspection effort savings of 4 % over the state-of-the-art models. We believe our results would help practitioners prioritize their efforts towards the most impactful fix-inducing changes and save inspection effort.

DOI： 10.1007/s10664-015-9370-z

Language：Others   Publishing type：Research paper (other academic)  

© 2016 ACM. Analogy-based effort estimation (ABE) is a commonly used software development effort estimation method. The processes of ABE are based on a reuse of effort values from similar past projects, where the appropriate numbers of past projects (k values) to be reused is one of the long-standing debates in ABE research studies. To date, many approaches to find this k value have been continually proposed. One important reason for this inconclusive debate is that different studies appear to produce different conclusions of the k value to be appropriate. Therefore, in this study, we revisit 8 common approaches to the k value being most appropriate in general situations. With a more robust and comprehensive evaluation methodology using 5 robust error measures subject to the Wilcoxon rank-sum statistical test, we found that conflicting results in the previous studies were not mainly due to the use of different methodologies nor different datasets, but the performance of the different approaches are actually varied widely.

DOI： 10.1145/2851613.2851974

Language：English  

Language：Others   Publishing type：Research paper (scientific journal)  

© 2016 Information Processing Society of Japan. Open Source Software (OSS) is vital to both end users and enterprises. As OSS systems are becoming a type of infrastructure, long-term OSS projects are desired. For the survival of OSS projects, the projects need to not only retain existing developers, but also attract new developers to grow. To better understand how projects retain and attract contributors, our preliminary study aimed to measure the personnel attraction and retention of OSS projects using a pair of population migration metrics, called Magnet (personnel attraction) and Sticky (retention) metrics. Because the preliminary study analyzed only 90 projects and the 90 projects are not representative of GitHub, this paper extend the preliminary study to better understand the generalizability of the results by analyzing 16,552 projects of GitHub. Furthermore, we also add a pilot study to investigate the typical duration between releases to find more appropriate release duration. The study results show that (1) approximately 23% of developers remain in the same projects that the developers contribute to, (2) the larger projects are likely to attract and retain more developers, (3) 53% of terminal projects eventually decay to a state of fewer than ten developers and (4) 55% of attractive projects remain in an attractive category.

DOI： 10.2197/ipsjjip.24.339

Language：Others   Publishing type：Research paper (scientific journal)  

© 1984-2012 IEEE. Nine rising stars in software engineering describe how software engineering research will evolve, highlighting emerging opportunities and groundbreaking solutions. They predict the rise of end-user programming, the monitoring of developers through neuroimaging and biometrics sensors, analysis of data from unstructured documents, the mining of mobile marketplaces, and changes to how we create and release software.

DOI： 10.1109/MS.2016.55

Language：English  

Language：English   Publishing type：Research paper (scientific journal)  

Language：Others   Publishing type：Research paper (scientific journal)  

© 1984-2012 IEEE. Nine rising stars in software engineering describe how software engineering research will evolve, highlighting emerging opportunities and groundbreaking solutions. They predict the rise of end-user programming, the monitoring of developers through neuroimaging and biometrics sensors, analysis of data from unstructured documents, the mining of mobile marketplaces, and changes to how we create and release software.

DOI： 10.1109/MS.2016.55

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (other academic)  

© 2015 ACM. It is often observed that the majority of the development work of an Open Source Software (OSS) project is contributed by a core team, i.e., a small subset of the pool of active developers. In fact, recent work has found that core development teams follow the Pareto principle-roughly 80% of the code contributions are produced by 20% of the active developers. However, those findings are based on samples of between one and nine studied systems. In this paper, we revisit prior studies about core developers using 2,496 projects hosted on GitHub. We find that even when we vary the heuristic for detecting core developers, and when we control for system size, team size, and project age: (1) the Pareto principle does not seem to apply for 40%-87% of GitHub projects; and (2) more than 88% of GitHub projects have fewer than 16 core developers. Moreover, we find that when we control for the quantity of contributions, bug fixing accounts for a similar proportion of the contributions of both core (18%-20%) and non-core developers (21%-22%). Our findings suggest that the Pareto principle is not compatible with the core teams of many GitHub projects. In fact, several of the studied GitHub projects are susceptible to the bus factor, where the impact of a core developer leaving would be quite harmful.

DOI： 10.1145/2804360.2804366

Language：English   Publishing type：Research paper (other academic)  

© 2015 IEEE. 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.

DOI： 10.1109/ICSE.2015.266

Language：English   Publishing type：Research paper (other academic)  

© 2015 ACM. It is nearly 50 years since Dijkstra argued that goto obscures the ow of control in program execution and urged programmers to abandon the goto statement. While past research has shown that goto is still in use, little is known about whether goto is used in the unrestricted manner that Dijkstra feared, and if it is harmful' enough to be a part of a post-release bug. We, therefore, conduct a two part empirical study - (1) qualitatively analyze a statistically representative sample of 384 files from a population of almost 250K C programming language files collected from over 11K GitHub repositories and find that developers use goto in C files for error handling (80:21 ± 5%) and cleaning up resources at the end of a procedure (40:36 ± 5%); and (2) quantitatively analyze the commit history from the release branches of six OSS projects and find that no goto statement was re- moved/modified in the post-release phase of four of the six projects. We conclude that developers limit themselves to using goto appropriately in most cases, and not in an un- restricted manner like Dijkstra feared, thus suggesting that goto does not appear to be harmful in practice.

DOI： 10.1145/2786805.2786834

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Japanese  

A Bug Triaging Method for Reducing the Time to Fix Bugs in Large-scale Open Source Software Development
This paper proposes a bug triaging method to reduce the time to fix bugs in large-scale open source software development. Our method considers the upper limit of tasks which can be fixed by a developer in a certain period. In this paper, we conduct a case study of applying our method to Mozilla Firefox and Eclipse Platform projects and show the following findings: (1) using our method mitigates the situation where the majority of bug-fixing tasks are assigned to particular developers, (2) our method can reduce up to 50%-83% of time to fix bugs compared with the manual bug triaging method and up to 34%-38% compared with the existing method, and (3) the two factors, Preference (adequate for fixing a bug) and Limit (limits of developers' working hours), used in our method have an dispersion effect on the task assignment.

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Others   Publishing type：Research paper (other academic)  

Copyright 2014 ACM. In most software development projects, design models tend to contain uncertainty, because all of the design concerns cannot be captured at the early development phase. It is preferable to be able to check consistency or traceability among design models and programs even if they contain uncertain concerns. To deal with this problem, we propose the notion of uncertainty-aware Archface, an interface mechanism exposing a set of architectural points that should be shared between design and code. We can explicitly describe uncertainty in design models or programs by specifying uncertain architectural points.

DOI： 10.1145/2666358.2666579

Language：Others   Publishing type：Research paper (other academic)  

Copyright © 2014 ACM. This paper proposes an abstraction-aware reverse engineering method in which a developer just makes a mark on an important code region as if he or she draws a quick sketch on the program list. A support tool called iArch slices a program from marked program points and generates an abstract design model faithful to the intention of the developer. The developer can modify the design model and re-generate the code again while preserving the abstraction level and the traceability. Archface, an interface mechanism between design and code, plays an important role in abstraction-aware traceability check. If the developer wants to obtain a more concrete design model from the code, he or she only has to make additional marks on the program list. We can gradually transition to model-driven development style.

DOI： 10.1145/2666581.2666595

Language：English   Publishing type：Research paper (other academic)  

© 2014 IEEE. There exists two types of developers in Open Source Software (OSS) projects: 1) Committers who have permission to commit edited source code to the Version Control System (VCS), 2) Developers who contribute source code but cannot commit to the VCS directly. In order to develop and evolve high quality OSS, projects are always in search of new committers. OSS projects often promote strong developers to become committers. When existing committers find strong developers, they propose their promotion to a committer role. Delaying the committer-promotion might lead to strong developers departing from an OSS project and the project losing them. However early committer-promotion comes with its own slew of risks as well (e.g., the promotion of inexperienced developers). Hence, committer-promotion decisions are critical for the quality and successful evolution of OSS projects. In this paper, we examine the committer-promotion phenomena for two OSS projects (Eclipse and Firefox). We find that the amount of activities by future committers was higher than the amount of activities by developers who did not become committers). We also find that some developers are promoted to a committer role very rapidly (within a few month) while some of developers take over one year to become a committer. Finally, we develop a committer-identification model to assist OSS projects identifying future committers.

DOI： 10.1109/QSIC.2014.30

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Japanese  

On Measuring the Difficulty of Program Comprehension based on Cerebral Blood Flow
In this research, we aim to quantify the difficulty of program comprehension during source code reading. We use Near Infra-Red Spectroscopy(NIRS) to measure the activation of brain. As a result of an experiment with 10 subjects, 8 of them showed a strong activation in the brain during reading of strongly obfuscated programs that are extremely difficult to comprehend. We also normalized the data for each participant and aggregated them for statistical testing. As a result of t-test, significant difference (p < 0.001) was seen in the mean of the brain blood flow between obfuscated and non-obfuscated programs.

DOI： 10.11309/jssst.31.3_270

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Others   Publishing type：Research paper (scientific journal)  

To date, various techniques for predicting fault-prone modules have been proposed; however, test strategies, which assign a certain amount of test effort to each module, have been rarely studied. This paper proposes a simulation model of software testing that can evaluate various test strategies. The simulation model estimates the number of discoverable faults with respect to the given test resources, the test strategy, complexity metrics of a set of modules to be tested, and the fault prediction results. Based on a case study of simulation applying fault prediction to two open source software (Eclipse and Mylyn), we show the relationship between the available test effort and the effective test strategy.

Language：Others   Publishing type：Research paper (other academic)  

Copyright 2014 ACM. Software code review, i.e., the practice of having third-party team members critique changes to a software system, is a well-established best practice in both open source and proprietary software domains. Prior work has shown that the formal code inspections of the past tend to improve the quality of software delivered by students and small teams. However, the formal code inspection process mandates strict review criteria (e.g., in-person meetings and reviewer checklists) to ensure a base level of review quality, while the modern, lightweight code reviewing process does not. Although recent work explores the modern code review process qualitatively, little research quantitatively explores the relationship between properties of the modern code review process and software quality. Hence, in this paper, we study the relationship between software quality and: (1) code review coverage, i.e., the proportion of changes that have been code reviewed, and (2) code review participation, i.e., the degree of reviewer involvement in the code review process. Through a case study of the Qt, VTK, and ITK projects, we find that both code review coverage and participation share a significant link with software quality. Low code review coverage and participation are estimated to produce components with up to two and five additional post-release defects respectively. Our results empirically confirm the intuition that poorly reviewed code has a negative impact on software quality in large systems using modern reviewing tools.

DOI： 10.1145/2597073.2597076

Language：Others   Publishing type：Research paper (scientific journal)  

To date, various techniques for predicting fault-prone modules have been proposed; however, test strategies, which assign a certain amount of test effort to each module, have been rarely studied. This paper proposes a simulation model of software testing that can evaluate various test strategies. The simulation model estimates the number of discoverable faults with respect to the given test resources, the test strategy, complexity metrics of a set of modules to be tested, and the fault prediction results. Based on a case study of simulation applying fault prediction to two open source software (Eclipse and Mylyn), we show the relationship between the available test effort and the effective test strategy.

Language：Others   Publishing type：Research paper (other academic)  

Copyright 2014 ACM. 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.

DOI： 10.1145/2597073.2597116

Language：Others   Publishing type：Research paper (other academic)  

Copyright 2014 ACM. 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.

DOI： 10.1145/2597073.2597075

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (scientific journal)  

Context Effort-aware models, e.g., effort-aware bug prediction models aim to help practitioners identify and prioritize buggy software locations according to the effort involved with fixing the bugs. Since the effort of current bugs is not yet known and the effort of past bugs is typically not explicitly recorded, effort-aware bug prediction models are forced to use approximations, such as the number of lines of code (LOC) of the predicted files. Objective Although the choice of these approximations is critical for the performance of the prediction models, there is no empirical evidence on whether LOC is actually a good approximation. Therefore, in this paper, we investigate the question: is LOC a good measure of effort for use in effort-aware models? Method We perform an empirical study on four open source projects, for which we obtain explicitly-recorded effort data, and compare the use of LOC to various complexity, size and churn metrics as measures of effort. Results We find that using a combination of complexity, size and churn metrics are a better measure of effort than using LOC alone. Furthermore, we examine the impact of our findings on previous effort-aware bug prediction work and find that using LOC as a measure for effort does not significantly affect the list of files being flagged, however, using LOC under-estimates the amount of effort required compared to our best effort predictor by approximately 66%. Conclusion Studies using effort-aware models should not assume that LOC is a good measure of effort. For the case of effort-aware bug prediction, using LOC provides results that are similar to combining complexity, churn, size and LOC as a proxy for effort when prioritizing the most risky files. However, we find that for the purpose of effort-estimation, using LOC may under-estimate the amount of effort required. © 2013 Elsevier B.V. All rights reserved.

DOI： 10.1016/j.infsof.2013.06.002

Language：English   Publishing type：Research paper (scientific journal)  

Bug fixing accounts for a large amount of the software maintenance resources. Generally, bugs are reported, fixed, verified and closed. However, in some cases bugs have to be re-opened. Re-opened bugs increase maintenance costs, degrade the overall user-perceived quality of the software and lead to unnecessary rework by busy practitioners. In this paper, we study and predict re-opened bugs through a case study on three large open source projects - namely Eclipse, Apache and OpenOffice. We structure our study along four dimensions: (1) the work habits dimension (e.g., the weekday on which the bug was initially closed), (2) the bug report dimension (e.g., the component in which the bug was found) (3) the bug fix dimension (e.g., the amount of time it took to perform the initial fix) and (4) the team dimension (e.g., the experience of the bug fixer). We build decision trees using the aforementioned factors that aim to predict re-opened bugs. We perform top node analysis to determine which factors are the most important indicators of whether or not a bug will be re-opened. Our study shows that the comment text and last status of the bug when it is initially closed are the most important factors related to whether or not a bug will be re-opened. Using a combination of these dimensions, we can build explainable prediction models that can achieve a precision between 52.1-78.6 % and a recall in the range of 70.5-94.1 % when predicting whether a bug will be re-opened. We find that the factors that best indicate which bugs might be re-opened vary based on the project. The comment text is the most important factor for the Eclipse and OpenOffice projects, while the last status is the most important one for Apache. These factors should be closely examined in order to reduce maintenance cost due to re-opened bugs. © 2012 Springer Science+Business Media, LLC.

DOI： 10.1007/s10664-012-9228-6

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：Japanese  

Experimental Evaluation of Eleven Fault-Density Models

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (other academic)  

AspectM, an 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 modify the metamodel. MMAP consists of metamodel extension points, extension operations, and primitive predicates for navigating the metamodel. Although the notion of MMAP is useful, it needs tool support. This paper proposes a method for implementing a MMAP based AspectM support tool. It consists of model editor, model weaver, and model verifier. We introduce the notion of edit-time structural reflection and extensible model weaving. Using these mechanisms, a modeler can easily construct domain-specific languages (DSLs). We show a case study using the AspectM support tool and discuss the effectiveness of the extension mechanism provided by MMAP. As a case study, we show a UML based DSL for describing the external contexts of embedded systems. Copyright © 2012 The Institute of Electronics, Information and Communication Engineers.

DOI： 10.1587/transinf.E95.D.942

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Japanese  

Fault-prone Module Prediction Across Software Development Projects : Lessons Learned from 18 Projects

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：Japanese  

A Candidate Committer Prediction Based on Developer Activities in Open Source Software Projects

Language：Japanese  

dcNavi: A Concern-oriented Recommendation System for Debugging Support
Programmers tend to spend a lot of time debugging code. They check the erroneous phenomena, navigate the code, search the past bug fixes, and modify the code. If a sequence of these debug activities can be automated, programmers can use their time for more creative tasks. To deal with this problem, we propose dcNavi (Debug Concern Navigator), a concern-oriented recommendation system for debugging. The dcNavi provides appropriate hints to programmers according to their debug concerns by mining a repository containing not only program information but also test results and program modification history. In this paper, we evaluate the effectiveness of our approach in terms of the reusability of past bug fixes by using nine open source repositories created in the Eclipse plug-in projects.

Language：Japanese   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (scientific journal)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：English   Publishing type：Research paper (international conference proceedings)  

Language：Japanese  

Analyzing Software Reliability Based on Developer Metrics

Language：Japanese  

Analyzing Software Reliability Based on Developer Metrics

Language：Japanese  

A Replicated Experiment to Fault-Prone Module Detection with Clone Metrics

Language：Japanese  

A Replicated Experiment to Fault-Prone Module Detection with Clone Metrics

Language：Japanese  

A Code Review Technique to Reduce Fix Assurance Test Size
In testing phases of software development projects, detected defects are fixed by modifying artifact including source code. Most of the detected defects require both test cases to confirm that the modification is correct and the modification does not cause new defects. In this paper, we propose a code reading technique in order to reduce size of such testing. The proposed method preferentially detects defects that potentially require larger size of testing by giving information that helps reviewer to estimate size of testing. In an evaluation experiment, the proposed technique reduces size of testing 2.1 times compared with test case based reading and 1.9 times compared with ad-hoc reading among 18 subjects including 6 commercial software developers.

Language：Japanese  

Modeling of Test Effort Allocation and Software Reliability in Fault-prone Module Detection
Various fault-prone detection models have been proposed to improve software reliability. However, while improvement of prediction accuracy was discussed, there was few discussion about how the models shuld be used in the field, i.e. how test effort should be allocated. Thus, improvement of software reliability by fault-prone module detection was not clear. In this paper, we proposed TEAR (Test Effort Allocation and software Reliability) model that represents the relationship among fault-prone detection, test effort allocation and software reliability. The result of simulations based on TEAR model showed that greater test effort should be allocated for fault-prone modules when prediction accuracy was high and/or when the number of faulty modules were small. On the other hand, fault-prone module detection should not be use when prediction accuracy was small or the number of faulty modules were large.

Language：Japanese  

Modeling of Test Effort Allocation and Software Reliability in Fault-prone Module Detection
Various fault-prone detection models have been proposed to improve software reliability. However, while improvement of prediction accuracy was discussed, there was few discussion about how the models shuld be used in the field, i.e. how test effort should be allocated. Thus, improvement of software reliability by fault-prone module detection was not clear. In this paper, we proposed TEAR (Test Effort Allocation and software Reliability) model that represents the relationship among fault-prone detection, test effort allocation and software reliability. The result of simulations based on TEAR model showed that greater test effort should be allocated for fault-prone modules when prediction accuracy was high and/or when the number of faulty modules were small. On the other hand, fault-prone module detection should not be use when prediction accuracy was small or the number of faulty modules were large.

Language：Japanese  

The Effect of Collaborative Filtering on Software Component Recommendation
To clarify the effect of collaborative filtering (CF) on recommending highgenerality / low-generality software components, we experimentally verified two hypotheses; (1) the recommendation accuracy of CF for high-generality components is better than that of conventional methods (random algorithm and user average algorithm) and (2) the recommendation accuracy of CF for lowgenerality components is better than that of the conventional methods. We evaluated recommendation accuracy of CF with a dataset containing 29 open source software development projects (including 2,558 used components). As a result, the hypothesis (2) was supported, and the recommendation accuracy of CF showed better performance than the conventional methods and the median of NDPM was improved from 0.55 to 0.33 for low-generality components.

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Korea, Republic of  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Language：Japanese   Presentation type：Oral presentation (general)  

Country：Japan  

Type：Academic society, research group, etc. 

Type：Peer review 

Number of peer-reviewed articles in foreign language journals：26

Number of peer-reviewed articles in Japanese journals：4

Proceedings of International Conference Number of peer-reviewed papers：45

Proceedings of domestic conference Number of peer-reviewed papers：4

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Academic society, research group, etc. 

Type：Competition, symposium, etc. 

Type：Peer review 

Number of peer-reviewed articles in foreign language journals：6

Number of peer-reviewed articles in Japanese journals：2

Proceedings of International Conference Number of peer-reviewed papers：45

Proceedings of domestic conference Number of peer-reviewed papers：4

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Academic society, research group, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Academic society, research group, etc. 

Type：Peer review 

Number of peer-reviewed articles in foreign language journals：14

Number of peer-reviewed articles in Japanese journals：2

Proceedings of International Conference Number of peer-reviewed papers：42

Proceedings of domestic conference Number of peer-reviewed papers：4

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Academic society, research group, etc. 

Type：Peer review 

Number of peer-reviewed articles in foreign language journals：8

Number of peer-reviewed articles in Japanese journals：5

Proceedings of International Conference Number of peer-reviewed papers：45

Proceedings of domestic conference Number of peer-reviewed papers：4

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc. 

Type：Competition, symposium, etc.