Faculty Profiles - IHARA Akinori

Published Papers - IHARA Akinori

Division display61 - 75 of about 75／ All the affair displays >>

What type of thread can get feedback in oss user mailing list?

Akinori Ihara, Yuji Tsuda, Ken-Ichi Matsumoto

2013 5th International Workshop on Social Software Engineering, SSE 2013 - Proceedings 25 - 28 2013 [Refereed]

High quality Open Source Software (OSS) has been used in many commercial software developments. In order to provide technical support to end users, OSS projects manage a user mailing list. It is for discussion about bugs and new functions of OSS with end users. However, according to a survey of Japanese companies that use OSS to build their commercial software, the biggest problem is the lack of adequate technical support. In this study, we investigate what type of thread can get feedback in user mailing list. As a result of a case study using Apache and Python project data, a thread is posted by a deep experienced user would be received a useful answer. In addition, we found threads written about internal system information of the OSS is more likely to be replied. Copyright 2013 ACM.

DOI

Mining A Change History to Quickly Identify Bug Locations : A Case Study of the Eclipse Project

Chakkrit Tantithamthavorn, Rattamont Teekavanich, Akinori Ihara, Ken-ichi Matsumoto

2013 IEEE INTERNATIONAL SYMPOSIUM ON SOFTWARE RELIABILITY ENGINEERING WORKSHOPS (ISSREW) ( IEEE ) 108 - 113 2013 [Refereed]

In this study, we proposed an approach to mine a change history to improve the bug localization performance. The key idea is that a recently fixed file may be fixed in the near future. We used a combination of textual feature and mining the change history to recommend source code files that are likely to be fixed for a given bug report. First, we adopted the Vector Space Model (VSM) to find relevant source code files that are textually similar to the bug report. Second, we analyzed the change history to identify previously fixed files. We then estimated the fault proneness of these files. Finally, we combined the two scores, from textual similarity and fault proneness, for every source code file. We then recommend developers examine source code files with higher scores. We evaluated our approach based on 1,212 bug reports from the Eclipse Platform and Eclipse JDT. The experimental results show that our proposed approach can improve the bug localization performance and effectively identify buggy files.

An Algorithm for Gradual Patch Acceptance Detection in Open Source Software Repository Mining

Passakorn Phannachitta, Akinori Ihara, Pijak Jirapiwong, Masao Ohira, Kenichi Matsumoto

IEICE Transactions on Information and Systems E95-A ( 9 ) 1478 - 1489 2012.09 [Refereed]

Good or Bad Committers? - A Case Study of Committer's Activities on the Eclipse's Bug Fixing Process

Anakorn jongyindee, Masao Ohira, Akinori Ihara, Kenichi Matsumoto

IEICE Transactions on Information and Systems E95-D ( 9 ) 2202 - 2210 2012.09 [Refereed]

OSS開発における不具合修正プロセスの現状と課題:不具合修正時間の短縮化へ向けた分析

伊原彰紀, 大平雅雄, 松本健一

情報社会学会誌 6 ( 2 ) 1 - 12 2012 [Refereed]

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

IHARA Akinori, KAMEI Yasutaka, OHIRA Masao, MATSUMOTO Ken-ichi, UBAYASHI Naoyasu

電子情報通信学会論文誌 ( 一般社団法人電子情報通信学会 ) J95-D ( 2 ) 237 - 249 2012 [Refereed]

Locating source code to be fixed based on initial bug reports - A case study on the eclipse project

Phiradet Bangcharoensap, Akinori Ihara, Yasutaka Kamei, Ken-Ichi Matsumoto

Proceedings - 2012 4th International Workshop on Empirical Software Engineering in Practice, IWESEP 2012 10 - 15 2012 [Refereed]

In most software development, a Bug Tracking System is used to improve software quality. Based on bug reports managed by the bug tracking system, triagers who assign a bug to fixers and fixers need to pinpoint buggy files that should be fixed. However if triagers do not know the details of the buggy file, it is difficult to select an appropriate fixer. If fixers can identify the buggy files, they can fix the bug in a short time. In this paper, we propose a method to quickly locate the buggy file in a source code repository using 3 approaches, text mining, code mining, and change history mining to rank files that may be causing bugs. (1) The text mining approach ranks files based on the textual similarity between a bug report and source code. (2) The code mining approach ranks files based on prediction of the fault-prone module using source code product metrics. (3) The change history mining approach ranks files based on prediction of the fault-prone module using change process metrics. Using Eclipse platform project data, our proposed model gains around 20% in TOP1 prediction. This result means that the buggy files are ranked first in 20% of bug reports. Furthermore, bug reports that consist of a short description and many specific words easily identify and locate the buggy file. © 2012 IEEE.

DOI

グローバル環境下におけるOSS開発者の情報交換に対する時差の影響

亀井靖高, 大平雅雄, 伊原彰紀, 小山貴和子, 松本真佑, 松本健一, 鵜林尚靖

情報社会学会誌 6 ( 2 ) 17 - 32 2012

グローバル環境下におけるOSS開発者の情報交換に対する時差の影響

亀井靖高, 大平雅雄, 伊原彰紀, 小山貴和子, 本真佑, 松本健一, 鵜林尚靖

情報社会学会学会誌 6 ( 2 ) 13 - 30 2011.11 [Refereed]

An analysis of gradual patch application: A better explanation of patch acceptance

Passakorn Phannachitta, Pijak Jirapiwongy, Akinori Ihara, Masao Ohira, Ken-Ichi Matsumoto

Proceedings - Joint Conference of the 21st International Workshop on Software Measurement, IWSM 2011 and the 6th International Conference on Software Process and Product Measurement, MENSURA 2011 ( IEEE Computer Society ) 106 - 115 2011 [Refereed]

Patch submission has been known as one of the most important activities to sustain the open source software (OSS). The patch archive can be analyzed to procure many benefit cognizance for supporting the OSS project works. The recent models and methods that analyze the patches acceptance are quite rack of comprehensive
hence, complex activities such as a committer portioning the submitted patch out and accept are still excluded from the analysis. Therefore, the results derived from those methods would be inadequate to conclude the actual patch acceptance. In this research, we introduce an algorithm for analyzing patch acceptance including the partial and gradually accepted conditions. Validating our algorithm, we present our methods for indicating the partial and gradual application of the submitted patch between either mailing list and SVN or Bugzilla and CVS which are the commonly deployed patchactivities related system. We studied on two well known OSS projects
Apache HTTP and Eclipse Platform. We obtained a fascinating conclusion that larger patches have more confident to be accepted than the smaller contradicted to other analysis that came from the recent methods. © 2011 IEEE.

DOI

Good or bad committers? A case study of committers' cautiousness and the consequences on the bug fixing process in the eclipse project

Anakorn Jongyindee, Masao Ohira, Akinori Ihara, Ken-Ichi Matsumoto

There are many roles to play in the bug fixing process in open source software development. A developer called "Committer", who has a permission to submit a patch into software repository, plays a major role in this process and hold a key to the successfulness of the project. In this work, we have observed each committer activities from the Eclipse-Platform bug tracking system and version archives. Despite the importance of committer's activities, we suspected that sometimes committers can make mistakes, which have negative consequences to the bug fixing process. Our research focus on studying the consequences of each committer's activities to this process. We collected each committer's historical data and evaluated each of them by comparing the more cautiousness to less cautiousness committers. Then we looked deeper into each committer's characteristics to see the reasons why some committers tend to make mistakes more than the others. From our results, we would like to make a humbly suggestion to the OSS's committers to be aware of their importance to the projects and be cautious before doing their jobs. © 2011 IEEE.

DOI

Predicting re-opened bugs: A case study on the Eclipse project

Emad Shihab, Akinori Ihara, Yasutaka Kamei, Walid M. Ibrahim, Masao Ohira, Bram Adams, Ahmed E. Hassan, Ken-Ichi Matsumoto

Proceedings - Working Conference on Reverse Engineering, WCRE ( IEEE Computer Society ) 249 - 258 2010 [Refereed]

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 the Eclipse project. We structure our study along 4 dimensions: 1) the work habits dimension (e.g., the weekday on which the bug was initially closed on), 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). Our case study on the Eclipse Platform 3.0 project shows that the comment and description text, the time it took to fix the bug, and the component the bug was found in are the most important factors in determining whether a bug will be re-opened. Based on these dimensions we create decision trees that predict whether a bug will be re-opened after its closure. Using a combination of our dimensions, we can build explainable prediction models that can achieve 62.9% precision and 84.5% recall when predicting whether a bug will be re-opened. © 2010 IEEE.

DOI

A Time-Lag Analysis Toward Improving the Efficiency of Communications among OSS Developers

Masao Ohira, Kiwako Koyama, Akinori Ihara, Shinsuke Matsumoto, Yasutaka Kamei, Ken-ichi Matsumoto

In Proceedings of The 3rd International Workshop on Knowledge Collaboration in Software Development (KCSD2009) 49 - 62 2009.11 [Refereed]

An Analysis Method for Improving a Bug Modification Process in Open Source Software Development

Akinori Ihara, Masao Ohira, Ken-ichi Matsumoto

IWPSE-EVOL 09: ERCIM WORKSHOP ON SOFTWARE EVOLUTION (EVOL) AND INTERNATIONAL WORKSHOP ON PRINCIPLES OF SOFTWARE EVOLUTION (IWPSE) ( ASSOC COMPUTING MACHINERY ) 135 - 143 2009 [Refereed]

As open source software products have evolved over time to satisfy a variety of demands from increasing users, they have become large and complex in general. Open source developers often face with challenges in fixing a considerable amount of bugs which are reported into a bug tracking system on a daily basis. As a result, he mean time to resolve bugs has been protracted in these days. In order to reduce the mean time to resolve bugs, managers/leaders of open source projects need to identify and understand the bottleneck of a bug modification process in their own projects. In this paper, we propose an analysis method which represents a bug modification process using a bug tracking system as a state transition diagram and then calculates the amount of time required to transit between states. We have conducted a case study using Firefox and Apache project data to confirm the usefulness of the analysis method. From the results of the case study, we have found that the method helped to reveal that both of the projects took a lot of time to verify results of bug modifications by developers.

DOI

A Time-Lag Analysis for Improving Communication among OSS Developers.

Masao Ohira, Kiwako Koyama, Akinori Ihara, Shinsuke Matsumoto, Yasutaka Kamei, Ken-ichi Matsumoto

New Frontiers in Artificial Intelligence, JSAI-isAI 2009 Workshops, LENLS, JURISIN, KCSD, LLLL, Tokyo, Japan, November 19-20, 2009, Revised Selected Papers ( Springer ) 135 - 146 2009 [Refereed]

DOI

　 PREV -NEXT　

<IHARA Akinori>

Published Papers - IHARA Akinori