Faculty Profiles - IHARA Akinori

Published Papers - IHARA Akinori

Division display21 - 40 of about 75／ All the affair displays >>

Do review feedbacks influence to a contributor's time spent on oss projects?

Takuto Norikane, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

Proceedings - 2018 IEEE/ACIS 3rd International Conference on Big Data, Cloud Computing, Data Science and Engineering, BCD 2018 ( Institute of Electrical and Electronics Engineers Inc. ) 109 - 113 2018.11 [Refereed]

Open Source Software (OSS) does not work without contributions from the community. In particular, long-term contributors (LTCs) (e.g., committer), defined as contributors who spend at least one year on OSS projects, play a crucial role in a project success because they would have permission to add (commit) code changes to a project's version control system, and to become a mentor for a beginner in OSS projects. However, contributors often leave a project before becoming a LTC because most contributors are volunteers. If contributors are motivated in their work in OSS projects, they might not leave the projects. In this study, we examine the phenomena involved in becoming a LTC in terms of motivation to continue in OSS projects. In particular, our target motivation is to understand what is involved in long-term contribution with other expert contributors. We study classifier to identify a LTC who will contribute patch submissions for more than one year based on collaboration in terms of the code review process. In detail, we analyze what review feedbacks encourage a contributor to continue with OSS project. Using a Qt project dataset, we build a prediction model to identify a LTC. We find that not only contributor's activities, but also a reviewer feedbacks, useful in identifying LTCs.

DOI

How are IF-Conditional Statements Fixed Through Peer CodeReview?

Yuki Ueda, Akinori Ihara, Takashi Ishio, Toshiki Hirao, Kenichi Matsumoto （Part： Corresponding author )

IEICE Transactions on Information and Systems 101-D ( 11 ) 2720 - 2729 2018.11 [Refereed]

DOI

An empirical study of design discussions in code review

Farida El Zanaty, Toshiki Hirao, Shane McIntosh, Akinori Ihara, Kenichi Matsumoto

International Symposium on Empirical Software Engineering and Measurement ( IEEE Computer Society ) 2018.10

Background: Code review is a well-established software quality practice where developers critique each others' changes. A shift towards automated detection of low-level issues (e.g., integration with linters) has, in theory, freed reviewers up to focus on higher level issues, such as software design. Yet in practice, little is known about the extent to which design is discussed during code review. Aim: To bridge this gap, in this paper, we set out to study the frequency and nature of design discussions in code reviews. Method: We perform an empirical study on the code reviews of the OpenStack Nova (provisioning management) and Neutron (networking abstraction) projects. We manually classify 2,817 review comments from a randomly selected sample of 220 code reviews. We then train and evaluate classifiers to automatically label review comments as design related or not. Finally, we apply the classifiers to a larger sample of 2,506,308 review comments to study the characteristics of reviews that include design discussions. Results: Our manual analysis indicates that (1) design discussions are still quite rare, with only 9% and 14% of Nova and Neutron review comments being related to software design, respectively
and (2) design feedback is often constructive, with 73% of the design-related comments also providing suggestions to address the concerns. Furthermore, our classifiers achieve a precision of 59%-66% and a recall of 70%-78%, outperforming baselines like zeroR by 43 percentage points in terms of F1-score. Finally, code changes that have design-related feedback have a statistically significantly increased rate of abandonment (Pearson 2 test, DF=1, p &lt
0.001). Conclusion: Design-related discussion during code review is still rare. Since design discussion is a primary motivation for conducting code review, more may need to be done to encourage such discussions among contributors.

DOI

Extraction of library update history using source code reuse detection

Kanyakorn Jewmaidang, Takashi Ishio, Akinori Ihara, Kenichi Matsumoto, Pattara Leelaprute

IEICE Transactions on Information and Systems ( Institute of Electronics, Information and Communication, Engineers, IEICE ) E101D ( 3 ) 799 - 802 2018.06 [Refereed]

DOI

Extraction of Library Update History Using Source Code Reuse Detection(vol 101, pg 799, 2018)

Jewmaidang Kanyakorn, Ishio Takashi, Ihara Akinori, Matsumoto Kenichi

IEICE TRANSACTIONS ON INFORMATION AND SYSTEMS E101D ( 6 ) 1722 2018.06 [Refereed]

DOI

A Predicting Method of Issue-fixing Time Using Development Metrics in OSS Projects

伊原彰紀, 若元亮樹, 松本健一（Part： Lead author,　Corresponding author )

情報処理学会論文誌 59 ( 3 ) 834 - 844 2018 [Refereed]

Towards Smoother Library Migrations: A Look at Vulnerable Dependency Migrations at Function Level for npm JavaScript Packages.

Rodrigo Elizalde Zapata, Raula Gaikovina Kula, Bodin Chinthanet, Takashi Ishio, Kenichi Matsumoto, Akinori Ihara

Proceedings of the IEEE International Conference on Software Maintenance and Evolution (ICSME) 2018 ( IEEE Computer Society ) 559 - 563 2018 [Refereed]

DOI

An Empirical Study on README contents for JavaScript Packages.

Shohei Ikeda, Akinori Ihara, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Corresponding author )

IEICE Transactions on Information and Systems abs/1802.08391 2018 [Refereed]

An Politeness Analysis for Understanding Continuous Activities of Developers in OSS Communities

宮崎智己, 伊原彰紀, 大平雅雄, 東裕之輔, 山谷陽亮（Part： Corresponding author )

情報処理学会論文誌 59 ( 1 ) 2 - 11 2018 [Refereed]

The impact of IR-based classifier configuration on the performance and the effort of method-level bug localization

Chakkrit Tantithamthavorn, Surafel Lemma Abebe, Ahmed E. Hassan, Akinori Ihara, Kenichi Matsumoto

Information and Software Technology ( Elsevier B.V. ) 102 160 - 174 2018 [Refereed]

Context: IR-based bug localization is a classifier that assists developers in locating buggy source code entities (e.g., files and methods) based on the content of a bug report. Such IR-based classifiers have various parameters that can be configured differently (e.g., the choice of entity representation). Objective: In this paper, we investigate the impact of the choice of the IR-based classifier configuration on the top-k performance and the required effort to examine source code entities before locating a bug at the method level. Method: We execute a large space of classifier configuration, 3172 in total, on 5266 bug reports of two software systems, i.e., Eclipse and Mozilla. Results: We find that (1) the choice of classifier configuration impacts the top-k performance from 0.44% to 36% and the required effort from 4395 to 50,000 LOC
(2) classifier configurations with similar top-k performance might require different efforts
(3) VSM achieves both the best top-k performance and the least required effort for method-level bug localization
(4) the likelihood of randomly picking a configuration that performs within 20% of the best top-k classifier configuration is on average 5.4% and that of the least effort is on average 1%
(5) configurations related to the entity representation of the analyzed data have the most impact on both the top-k performance and the required effort
and (6) the most efficient classifier configuration obtained at the method-level can also be used at the file-level (and vice versa). Conclusion: Our results lead us to conclude that configuration has a large impact on both the top-k performance and the required effort for method-level bug localization, suggesting that the IR-based configuration settings should be carefully selected and the required effort metric should be included in future bug localization studies.

DOI

Maintaining third-party libraries through domain-specific category recommendations.

Daiki Katsuragawa, Akinori Ihara, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Corresponding author )

Proceedings of the 1st International Workshop on Software Health (SoHeal) 2018 ( ACM ) 2 - 9 2018 [Refereed]

An Analysis of Library Rollbacks: A Case Study of Java Libraries

Hirohiko Suwa, Akinori Ihara, Raula Gaikovina Kula, Daiki Fujibayashi, Kenichi Matsumoto

1st International Workshop on Software-driven Big Data Analytics 2017.12 [Refereed]

DOI

How is if statement fixed through code review? A case study of QT project

Yuki Ueda, Akinori Ihara, Toshiki Hirao, Takashi Ishio, Kenichi Matsumoto （Part： Corresponding author )

Proceedings - 2017 IEEE 28th International Symposium on Software Reliability Engineering Workshops, ISSREW 2017 ( Institute of Electrical and Electronics Engineers Inc. ) 207 - 213 2017.11 [Refereed]

Peer code review is key to ensuring the absence of software defects. To improve the review process, many code review tools provide OSS(Open Source Software) project CI(Continuous Integration) tests that automatically verify code quality issues such as a code convention issues. However, these tests do not cover project policy issues and a code readability issues. In this study, our main goal is to understand how a code owner fixes conditional statement issues based on reviewers feedback. We conduct an empirical study to understand if statement changes after review. Using 69,325 review requests in the Qt project, we analyze changes of the if conditional statements that (1) are requested to be reviewed, and (2) that are implemented after review. As a result, we find the most common symbolic changes are '(' and ')' (35%), '!' operator (20%) and '-&gt
' operator (12%). Also, '!' operator is frequently replaced with '(' and ')'.

DOI

Understanding key features of high-impact bug reports

Md. Rejaul Karim, Akinori Ihara, Xin Yang, Hajimu Iida, Kenichi Matsumoto （Part： Corresponding author )

Proceedings - 8th IEEE International Workshop on Empirical Software Engineering in Practice, IWESEP 2017 ( Institute of Electrical and Electronics Engineers Inc. ) 53 - 58 2017.05 [Refereed]

Nowadays, software projects are receiving bug reports on a daily basis. Developers cannot treat all the bugs in the same priority since some bugs can significantly affect software development process and the quality of products. Previous studies defined these bugs as High Impact Bug (HIB) and they found that HIB should be fixed quicker than other bugs in software development. However, fixing a HIB sometimes become complicated because the low-quality bug reports can be delay the bug fixing. In this study, we investigate what information is essential when reporting a HIB report. As a case study, we manually examine the HIB reports and perform both qualitative and quantitative analysis in Apache Camel project. Our main findings include: (1) we find four types of features are the most requested information from developers when they fix HIB, (2) the requested additional information significantly influences bug fixing time.

DOI

Which review feedback did long-term contributors get on OSS projects?

Takuto Norikane, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

SANER 2017 - 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering ( Institute of Electrical and Electronics Engineers Inc. ) 571 - 572 2017.03 [Refereed]

Open Source Software (OSS) cannot exist without contributions from the community. In particular, long-term contributors (LTCs) (e.g., committer), defined as contributors who spend at least one year on OSS projects, play crucial role in a project success because they would have permission to add (commit) code changes to a project's version control system, and to become a mentor for a beginner in OSS projects. However, contributors often leave a project before becoming a LTC because most contributors are volunteers. If contributors are motivated in their work in OSS projects, they might not leave the projects. In this study, we examine the phenomena involved in becoming a LTC in terms of motivation to continue in OSS projects. In particular, our target motivation is to understand what is involved in long-term contribution with other expert contributors. We study classifier to identify a LTC who will contribute patch submissions for more than one year based on collaboration in terms of the code review process. In detail, we analyze what review feedbacks encourage a contributor to continue with OSS project. Using a Qt project dataset, we understand review feedback which affected contribution period of the developer.

DOI

Does the release cycle of a library project influence when it is adopted by a client project?

Daiki Fujibayashi, Akinori Ihara, Hirohiko Suwa, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Corresponding author )

SANER 2017 - 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering ( Institute of Electrical and Electronics Engineers Inc. ) 569 - 570 2017.03 [Refereed]

DOI

Toward Identifying a Re-opened Bug Based on Reviewers Disagreement―Case Study of OpenStack Project

林宏徳, 伊原彰紀, 松本健一（Part： Corresponding author )

情報処理学会論文誌 ( 情報処理学会 ) 58 ( 3 ) 721 - 725 2017.03 [Refereed]

Understanding when to adopt a library: A case study on ASF projects

Akinori Ihara, Daiki Fujibayashi, Hirohiko Suwa, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Lead author,　Corresponding author )

Proceedings of the International Conference on Open Source Systems (OSS) ( Springer New York LLC ) 496 128 - 138 2017 [Refereed]

Software libraries are widely used by both industrial and open source client projects. Ideally, a client user of a library should adopt the latest version that the library project releases. However, sometimes the latest version is not better than a previous version. This is because the latest version may include additional developer effort to test and integrate all changed features. In this study, our main goal is to better understand the relationship between adoption of library versions and its release cycle. Specifically, we conducted an empirical study of release cycles for 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. Our findings show that software projects are quicker to update earlier rapid-release libraries compared to library projects with a longer release cycle. Moreover, results suggest that software projects are more likely to adopt the latest version of a rapid-release library compared to libraries with a longer release cycles.

DOI

Project IŜ3: Incentive-based intelligent intervention for smart and sustainable society

Yutaka Arakawa, Keiichi Yasumoto, Kenichi Matsumoto, Hideaki Hata, Hirohiko Suwa, Akinori Ihara, Manato Fujimoto

Proceedings - 2016 5th IIAI International Congress on Advanced Applied Informatics, IIAI-AAI 2016 215 - 218 2016.08 [Refereed]

© 2016 IEEE. Project IS^3 is the leading-edge project in Nara Institute of Science and Technology, a national graduate school in Japan, started from February 2016. This project aims to utilize a human's behavior change for solving the social problems and maintaining our society sustainably. In order to cause the behavior change intentionally, various information technologies are required. In this paper, we explain the concept and goal of our project and figure out what we will do in this project.

DOI

Toward selecting a reliable version of OSS library based on bug-fixing curve

Keisuke Fujino, Akinori Ihara, Kiyoshi Honda, Hironori Washizaki, Kenichi Matsumoto （Part： Corresponding author )

23rd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2016) 2016.03 [Refereed]

　 PREV - NEXT 　

<IHARA Akinori>

Published Papers - IHARA Akinori