社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

コード内に出現する識別子情報に基づくコミット分類
山内健二†

楊嘉晨†

堀田 圭佑†

肥後芳樹†

楠本真二†

† 大阪大学大学院情報科学研究科〒 565–0871 大阪府吹田市山田丘 1–5
E-mail: †{y-kenji,jc-yang,k-hotta,higo,kusumoto}@ist.osaka-u.ac.jp
あらましソフトウェアの開発工程において，これまでに記述されたソースコードの内容や，それにより実現されたソフトウェアの挙動について整理や検討が必要な場面がある．このような整理や検討は，バージョン管理システムやタスク管理システムを利用し，各コミットにおけるソースコードへの変更内容を，タスクという開発作業の単位で把握することで実現できる．このときコミットをタスク単位で分類するためには，タスクとコミットの対応関係の特定が必要となる．この特定を行うための手段として，コミットコメントやコミットを行った開発者の名前を利用することが考えられる．しかし，コミットコメントの内容の不備や開発者とコミットとに多対多の関係などがあることで，対応関係の特定が困難な場合がある．そこで本論文では，各コミットにおけるソースコードの差分に出現する識別子情報を利用してタスク単位でのコミット分類を行い，タスク単位での変更内容の把握を支援する手法を提案する．また提案手法の評価として，いくつかのオープンソース・ソフトウェアに対して，提案手法によるコミットの分類を行い，本手法がどのようなタスクを分類するのに有効であるかを考察した．
キーワード

バージョン管理システム，タスク管理システム，クラスタリング

Classification of Commits by Analyzing Identifiers in Source CodeKenji YAMAUCHI† , Jiachen YANG† , Keisuke HOTTA† , Yoshiki HIGO† , and Shinji
KUSUMOTO†† Graduate School of Information Science and Technology, Osaka University
Yamadaoka 1–5, Suita-Shi, Osaka, 565–0871 Japan
E-mail: †{y-kenji,jc-yang,k-hotta,higo,kusumoto}@ist.osaka-u.ac.jp
Abstract In software development, there is a need to understand changes of source code and implemented software behavior. To grasp those information, we can use a link between commits and tasks, with version control
system and task management system. To detemine commit-to-task links, some studies have proposed approaches
using commit comments and developers’ names. However, it is diﬃcult for those approaches to detect such links
when there are obscure commmit comments or many-to-many relations between commits and developers’ names.
This paper proposes a technique to group commits into related tasks by using idetifier names in changes of soucecode on each commit. To validate our approach, we applied it on several open-source software projects and foundcommits that were ideally grouped into a task. Furthermore, we discuss what type of tasks can be detected by ourapproach.
Key words version control system, task control system, clustering

1. ま え が き

発工程で設定される目標ごとに実装内容を把握することで，効率的に行うことができる．本論文においては，このような開発ソフトウェアの開発工程において，これまでに記述された工程での目標について，それを達成する作業群を，それぞれタソースコードの内容や，それにより実現されたソフトウェアのスクと呼ぶ．タスク単位での実装内容の把握が有用な場面とし

挙動 (以下 実装内容 と呼ぶ) について整理や検討が必要な場面て，コードレビュー，リリースノートの作成，タスク管理シスがある．このような整理や検証は，機能の追加や変更など，開テムとの同期などが挙げられる．

—1—

&-()
<3!



2=
$




 $ 





<3 "#2=
$



    $






&-() &-()

:6+&*/

9740%
51







 $ 
$$ $.,'*.

1>;8

図 1: コミット分類の流れ

このようなタスク単位での実装内容の把握は，バージョン管理システム (Version Control System，VCS) を利用すること

2. 研 究 動 機で，より効率的に行うことができる．VCS からは，ソースファ

2. 1 タスク単位でのコミット分類

イルに対して行われた変更の内容を，コミットという単位で取タスク単位での実装内容の把握を支援する手段の 1 つとし得できる．それぞれのコミットがどのタスクに関係しているのて，タスク単位でのコミット分類が挙げられる．コミットをタかを特定し，コミットをタスクごとに分類することで，タスクスク単位で分類することで，それぞれのタスクを実現するため単位での実装内容の把握が容易となる．これまでに，コミットにソースコードに対してどのような修正が加えられたのかを把コメントやコミットを行った開発者の名前を用いて，コミット握することができる．とタスクの対応関係を特定する手法が提案されている [1, 2]．しタスク単位でコミットを分類する場合，分類の基準の候補とかし，これらの手法には，適切なコミットコメントが記述されしてコミットコメント，コミットを行った人物の名前，ソースていない場合や，開発者とタスクが多対多で対応している場合

コードの差分情報という 3 つの情報が挙げられる．タスク管理に，コミットとタスクを適切に関連付けることができないといシステムを用いて開発されているプロジェクトの場合，各タスう課題がある．

クには一意なタスク ID が割り当てられている．従って，コミッコミットコメントや開発者の名前を用いる手法以外のコミットを行う際に，コミットコメントに該当するタスク ID を記述

トの分類手法には，ソースコードの差分情報を利用する方法がすることで，タスクとコミットの関連を把握することが可能にある．ソースコードの差分を用いることで，コミットコメントなる [1]．そのため，全てのコミットについて，コミットコメンの記述が不十分な場合や，開発者とタスクが多対多で対応してトでタスク ID を記述していれば，そこからコミットをタスクいる場合でも，コミットの分類を行うことができる．これまで単位で分類できる．しかしながら，コミットコメントに，タスにソースコードの差分を用いたコミットの分類手法が提案され

ク ID の記述が行われていない等の不備がある場合，コミットている [3] が，それらはタスク単位でのコミット分類を対象ととタスクの関連の把握が困難になる．

していない．また，ソースコード中の構文の構造のみを利用しまた，1 つのタスクに対して，1 人の開発者のみが割り当てているため，分類の結果にそのソースコードが書かれた目的なられているならば，コミットを行った人物の名前を分類基準とどを反映できないという課題がある．

して利用できる．しかし，開発者とタスクが多対多で割り当て

そこで，本論文では，ソースコードの差分に含まれる識別子情報に基づいてコミットの分類を行う手法を提案する．識別子られている場合には，開発者名を用いてタスク単位でコミットを分類することは難しい．

情報を用いることで，抽象構文木などの構文情報からは得るこ

ソースコードの差分情報を用いる方法は，各コミットでソーとのできない，そのソースコードが書かれた目的などの情報スコードに対してどのような修正が加えられたのか，というを得ることができる．それぞれのソースコードが書かれた目情報に基づき，コミットの分類を行う．ソースコードの差分情的は実装内容と強く関連するため，識別子情報を用いてコミッ報は各コミットに必ず含まれる情報であるため，コミットコメトの分類を行うことで，タスク単位でのコミット分類を実現す

ントや開発者名を用いる手法を適用できない状況でも，コミッることができると期待できる．オープンソース・ソフトウェア

トの分類を実現することができる．従って本論文では，ソース(Open Source Software，OSS) に対して提案手法を適用し，提コードの差分情報を用いてコミットの分類を行う手法を提案

案手法がタスク単位でのコミット分類を行うことができている

する．

かを評価した．その結果，コミットコメントや開発者名を用い

2. 2 関 連 研 究た場合は適切にコミットの分類ができない事例に対し，適切にこれまでに，コミットの分類を行う手法がいくつか提案されコミットの分類を行うことができたことを確認した．ている．Hindle ら，及び Hattori と Lanza はそれぞれコミッ
トコメントに対して自然言語処理を適用してコミットの分類を行うことで，各コミットがソフトウェアの挙動に与える影響を—2—

調査している [4, 5]．これらの手法はコミットコメントを用いる手法であるため，コミットコメントに不備がある場合，コミットの分類を行うことができない．
また，Dragan らは，ステレオタイプと呼ばれる典型的な設計種別を利用してコミットの分類を行っている [3]．しかしこの手法では，設計上の影響があった修正にしか対処できず，バ #"  ! !" # #
$
$
%.-*'&+)

,(private(int(logCounts;
!IS_LOGGED
log(messages);

図 3: ソースコード変更と構文単位の差分の例

グ修正，リファクタリングなどのタスクに対する分類に有効でない．
そこで本論文では，ソースコードの差分情報に含まれる識別子名を用いてコミットの分類を行う手法を提案する．識別子

フィールドかメソッドの宣言ならば，それらが含まれるクラスの識別子のみ抽出する．

名はそのソースコードが行う処理の内容と強く関連しており，

図 3 に 示 す 例 で あ れ ば ， 3. 1 節 で 説 明 し た 3 つ のかつ構文情報からは得ることのできない情報が含まれている．

構文単位の差分 “private int logCounts”，“!IS LOGGED”，

従って，識別子情報を用いることで，既存手法では対応できな“log(messages)” について，それぞれ識別子が抽出される．

い事例に対しても，タスク単位でのコミットの分類が実現でき

例えば，“private int logCounts” について考えると，差ると期待できる．

分自体に含まれる識別子 “logCounts” と，差分が含まれる

3. 提 案 手 法

クラスの名前である “Logger” が抽出される．同様に “!ISLOGGED”，“log(messages)” についても，それぞれ考え，最提案手法では，VCS のリポジトリを入力とし，そこに蓄積さ終的に “logCounts”，“Logger”，“IS LOGGED”，“Logger”，れたコミットをタスク単位で分類した結果を出力する．この時，“checkLog”，“log”，“messages”，“Logger”，“checkLog” とい

分類はコミット前後の，すなわちリビジョン間におけるソースう識別子群が得られる．

コードの差分に含まれる識別子の出現回数に基づいて行われる．
提案手法の処理の流れを図 1 に示す．この図に示すように，次に，特徴ベクトルを生成する．このステップは以下の 4 つのサブステップからなる．

提案手法によるコミットの分類は以下の 3 ステップからなる．

STEP-2A 識別子を英単語として意味のある単位で分割する．

STEP1 リポジトリから抽出した各コミットでのソースコー

STEP-2B STEP-3A で分割されたあとの単語をそれぞれ見ドに対する変更内容を，構文として意味のある単位 ( 以後 構文出し語化する．見出し語化した後の単語を 特徴語 と呼ぶ．

単位の差分 と呼ぶ ) で解釈した上で取得する．

STEP-2C STEP-3C で得られた特徴語それぞれについて，STEP2 STEP1 で得られた構文単位の差分それぞれについ出現回数を集計する．て，含まれる識別子を全て取得し，それぞれ英単語として意味

STEP-2D STEP-3D での集計結果を，特徴ベクトルへ変換のある単位に分割した上で，各単語の出現回数を元にした 特徴する．

ベクトル というベクトルの生成を行う．

以降，各サブステップごとに説明を行う．

STEP3 生成した特徴ベクトルをコミットの特徴量とみなし

3. 2. 1 (STEP-2A) 単語分割てクラスタリングのアルゴリズムを適用し，コミットの分類を行う．

STEP1 で抽出した識別子を，英単語として意味のある単位に分割する．この時，識別子それぞれがキャメルケースあるい以降の小節で，各手順についての詳細を述べる．

はスネークケースで記述されていることを前提とする．ここ3. 1 (STEP1) 構文単位の差分の抽出で，キャメルケースとは “getYourName” のような，単語の区本手法ではまず，各コミットについて，構文単位の差分を抽切りとなる英字を大文字に，他を小文字とする記述法で，ス出する．

ネークケースは “get your name” のような，単語の区切りにア各コミットにおいて，そのコミットで変更されたソースファンダースコア ( ) を用いる記述法である．また，各分割後の単イルを特定し，それぞれのソースファイルについて，Change語については，後述する特徴語の出現回数の集計処理を簡便にDistilling [6] と呼ばれる手法を用いることで，リビジョン間でするため小文字化する．例えば，“convertedName” と “MAXの構文単位の差分を求める．これらは，文や式としてまとまり

COUNTS” という識別子があった場合，それぞれ，“convertedのある形式で抜き出される．

name” と “max counts” という形で分割および小文字化される．

図 3 に示す例の場合，下線部の部分について字句的な変更が

3. 2. 2 (STEP-2B) 単語の見出し語化あったとして，その変更を含む，“private int logCounts”，次に，分割後のそれぞれの単語について，見出し語化を行“!IS LOGGED”，“log(messages)” という 3 つの構文単位の差う．見出し語化とは，動詞の活用や名詞の格変化で語尾の変化分が得られる．

がある単語について，基本形に変形することである．先ほどの3. 2 (STEP2) 識別子名の抽出と特徴ベクトルの生成

例の場合，“converted” と “counts” がそれぞれ “convert” と次に，それら構文単位の差分に含まれる識別子を抽出する．

“count” になる．以降，分割並びに見出し語化までの処理が行

この時，その差分に含まれる識別子と合わせて，その差分を含むメソッド名およびクラス名の抽出も行う．変更の対象がわれた単語を特徴語と呼ぶ．
図 2 に ，こ こ ま で の 流 れ の 具 体 例 を 示 す．こ の 例 で は ，—3— !*)/#+-#" (#!*)/#+-*.+ (#
,#)"* &'#+/#+!*)/#+-#") (#!*)/#+-0*.+) (#,#+/#+,$*+,#)"&)%
,#)"-*( &',#+/#+!*)/#+-#") (#!*)/#+-) (#,#+/#+,#)"&)%
,#)"( &',#+/#+24367851!*)/#+-) (#!*)/#+-) (#,#+/#+,#)"
,#)"( &',#+/#+

図 2: 識別子の英単語の見出し語化までの過程“convertedName”，“convertYourName”，“SERVERS FOR

ングのアルゴリズムには，Repeated Bisection 以外にもいくつSENDING”，“sendToMailServer” という 4 つの識別子群が取か存在する．しかし，それらは計算量が大きく，膨大なデータ得できたとして，特徴語群を抽出するまでを示している．得られを処理するには大きな計算時間を要する．Repeated Bisection

る特徴語群は，“convert”，“name”，“your”，“server”，“for”，は他のクラスタリング数の指定が不要なクラスタリングアルゴ“send”，“to”，“mail” である．

リズムに比べて高速である [7] ことから 1 つ目の条件と 2 つ目

3. 2. 3 (STEP-2C) 特徴語の出現回数集計
STEP-3B で特定した特徴語群について，それぞれの出現回数を集計する．この時，ストップワードについては集計を行わの条件を同時に満たす．

4. 評 価 実 験ない．ストップワードとは，自然言語処理における用語で，前本節では 3. 節 で述べた手法に対する評価実験について記

置詞や助動詞など，どのような文書でも現れやすいために文書述する．いくつかのリポジトリに対して提案手法を適用してコの特徴を示しにくい語群を意味する．これらの単語は，文書分ミット分類を行い，タスクに対応したクラスタが存在すること類において，分類の精度へ悪影響を与えるおそれがある．よっを確認する．て，本提案手法では，ストップワードを特徴語群から排除する．
図 2 の例であれば，特徴語群に関して，“convert” が 2 回，“name” が 2 回，“server” が 2 回，“send” が 2 回，“mail” が1 回という集計結果を得られることになる．

4. 1 提案手法による分類結果の確認
この実験では，4 つの OSS のリポジトリに対して提案手法を適用し，生成されるクラスタ数を確認する．

Java で記述され，Git で管理されている OSS のうち，これま3. 2. 4 (STEP-2D) 集計結果の特徴ベクトルへの変換

でに行われたコミット数が多い (5,000 以上) ものから 4 つを選最後に，集計結果を，特徴ベクトルへ変換する．

択して実験対象とし，提案手法によるコミットの分類を行った．

それぞれのコミットを，各特徴語の出現回数を各要素とす

表 1 に実験対象のプロジェクトのそれぞれについて，分類結るベクトル (以下 Bag-Of-Words(BOW) ベクトル と呼ぶ)

果におけるクラスタ数とともに分類結果を示す．また，図 4 に，へと変換し，これを正規化して特徴ベクトルとする．この時，分類結果における各クラスタに属しているコミット数の分布を

BOW ベクトルの次元数は，全てのコミットで出現した特徴語

箱ひげ図で示す．図 4 では，各プロジェクトについて，X 軸上の数と等しくなる．そのコミットで出現しない単語に対応する方に各クラスタに属しているコミット数の中央値を示す．どの要素の値は 0 となる．例えば，コミット A で特徴語 “a”，“b”

プロジェクトでも 6 か 7 となっている．

が 1 回ずつ，コミット B で特徴語 “b”，“c” が 2 回ずつ登場a ) 望ましい分類結果の例したとして，それぞれのコミットの BOW ベクトルを考える．

まず，分類結果がタスク単位でのコミットの分類を適切に行

この時，各要素がそれぞれ “a”，“b”，“c” の出現回数である

うことができたと考えられる例を示す．表 2 に，Lucene/Solr

BOW ベクトルが，コミット A，B でそれぞれ (1,1,0)，(0,2,2)についてコミット群を分類した結果におけるあるクラスタにつとして得られる．

いて，そのクラスタを構成する 4 つのコミットの情報を示す．

3. 3 (STEP3) クラスタリングアルゴリズムの適用

ここで，コミット ID が e4a64f5，5adc910，c5a985e のコミッ

最後に，3. 2. 4 節 で生成した特徴ベクトルを用いて，クラスタリングを行う．アルゴリズムには，以下に述べる 2 つの条件

表 1: 分類結果を考慮して，Repeated Bisection [7] を選択した．

•

分類後のクラスタ数の指定が不要である．本手法では事前にタスク数，すなわち分類後のクラスタ数を特定できない．

プロジェクト名

Lucene/Solr（注 1）

そのため，事前に分類後のクラスタ数を指定する必要があるク

Jenkins CIラスタリングは利用できない．

WildFly（注 3）
JRuby（注 4）•スケーラビリティが高い． 開発が長期にわたって行われコミット数（注 2）

分類対象となった

11,159

コミット数

クラスタ数

7,341

919

17,640

8,452

1,102

14,280

10,247

1,204

20,531

13,142

1,487ているプロジェクトは膨大なコミット数をリポジトリに蓄積している場合がある．したがって，本手法では，アルゴリズムにスケーラビリティが要求される．
分類後のクラスタ数を事前に指定する必要のないクラスタリ（注 1）：https://lucene.apache.org/solr/（注 2）：http://jenkins-ci.org/（注 3）：http://www.wildfly.org/（注 4）：http://jruby.org/—4—スクといえる．コミット ID が b3553d6 と 7d0bac1 のコミットで行われた変更内容を見ると，それぞれのコミットは異なるメソッドについての実装である．そのため，これらは異なるタスクについての実装であるといえる．
さらに，ID が a545a39 のコミットで行われた変更内容を確認すると，Launcher クラスの内部クラスについて，アクセスレベルの変更を行っている．これは，コミットコメントからも分かるように，該当の内部クラスについてシリアライズを行うためのものであるため，入出力関係の処理を実装している同じクラスタに分類された他の 2 つのコミットとは関連がない．
このように，表 3 に挙げたクラスタに含まれているコミットは，それぞれ異なる実装内容を実現している．そのため，このクラスタは，1 つのタスクのみに関連している，すなわちタス
図 4: 各クラスタのコミット数分布

トについては，それぞれのコミットコメントに記述されたタス
ク ID から，Lucene/Solr の開発において用いられているタス
ク管理システムで，SOLR-4275（注 5）というタスク ID を割り当てられたタスクと関連しているコミットであるとわかる．

ク単位として望ましく分類されているクラスタとはいえない．

5. 考

察

変更が多岐にわたるタスクというものを考え， 4. 節 で得られた結果から，このようなタスクの分類に対して手法が有効であるかを考察する．

また，コミット ID が a3e95d0 のコミットは差分の内容を確あるコミット群について，各コミットでの差分を個別に把握認すると，コミットコメントでも言及されているように Token-

するだけでは，それぞれのコミットで実現された実装内容の関Tokenizer クラスへ，オフセットの利用を目的として処理を記連を把握しにくいが，実際には 1 つのタスクを実現しているも述したことがわかる．さらに，その記述で生じたバグに対しのがある．このようなタスクのうちで，変更が多岐にわたるタて，コミット ID が c5a985e のコミットで修正を行ったことがスクというものを考え，提案手法でこれらのタスクがどの程度分かる．

検出可能かを評価する．

よって，TokenTokenizer クラスのオフセット機能の実装とまず，変更が多岐にわたるタスクの定義を述べる．実装上のいうタスクを考えた時，a3e95d0 のコミットはコミットコメン問題から，単一のファイルのみに対する編集で完結しないタス

トでタスク ID の記述がないが，他 3 つのコミット e4a64f5，クが存在する場合がある．このようなタスクが複数コミットで5adc910，c5a985e と同じタスクの作業であるといえる．

実現され，しかも各コミットで変更されるソースファイルが異まとめると，このクラスタは，1 つのタスクに関連したコミッなっている場合，主として変更されているファイルを一意に決トのみで構成されていると考えられる．

定しにくいために，実装内容の把握が困難であると考えられる．

b ) 望ましくない分類がなされた例

そこで，クラスタ内のコミットで編集対象となったファイル次に，コミットの分類が適切に行われなかった例を示す．表

すべてについて，編集対象となったコミット数を考える．この3 に，Jenkins CI に提案手法を適用して得られたあるクラスタで，そのクラスタを構成する 3 つのコミットの情報を示す．
ま ず，IOUtils ク ラ ス に 対 す る 変 更 を 行って い る ID が

表 3: 望ましくない分類の例 (Jenkins CI)
コミット ID

修正されたソースコードコミットコメント

b3553d6

IOUtils.java

added a convenience

クラスであるため，機能が独立した静的なメソッドのみで構成

7d0bac1

IOUtils.java

dohされている．そのため，それぞれのメソッドの実装は異なるタ

a545a39

Launcher.java

for serialization work

b3553d6 と 7d0bac1 のコミットについて述べる．IOUtils ク
ラスはソフトウェア内での入出力処理に関するユーティリティ

methodthese interfaces need
to be public

表 2: 望ましい分類結果の例 (Lucene/Solr)
コミット ID

修正されたソースファイル

コミットコメントに記述されたタスク ID

e4a64f5

TestTrie.java

SOLR-4275

5adc910

TestTrie.java

SOLR-4275

c5a985e

TrieTokenizerFactory.java SOLR-4275

a3e95d0

TrieTokenizerFactory.java 記述なし

表 4: 各プロジェクトでの，多岐にわたるクラスタの割合
プロジェクト名 クラスタ数

変更が多岐にわたるクラスタ数

割合 (パーセント)

Lucene/Solr919

321

34.9%

Jenkins CI

1,102234

21.2%

WildFly

1,204457

38.0%

JRuby

1,487

264

24.0%

（注 5）：http://issues.apache.org/jira/browse/SOLR-4275—5—コミット数が占めるクラスタ内の全コミット数に対する割合 (編に有効であるかを，変更が多岐にわたるタスクというものを定集割合 と呼ぶ) が，0.5 を超えるファイルが存在しないクラス義して考察した．

タを，変更が多岐にわたるタスクに対応するクラスタとみなす．

今後の課題は，以下の通りである．

変更が多岐にわたるタスクの例として，4. 節 で望ましい分類•

結果の例として挙げたクラスタが対応するタスクを考える．この抽出

分類精度向上のための，識別子からのより正確な特徴語

タスクでは，4 つのコミットにより，TrieTokenizerFactory.java•と TestTrie.java にまたがって編集が行われている．これらソー謝辞

複数のタスクに関連したコミットに対応した分類
本論文は，日本学術振興会科学研究費補助金基盤

スファイルの編集割合はそれぞれ 0.5 であるから，このタスク研究 (S)(課題番号：25220003)，挑戦的萌芽研究 (課題番号：

は変更が多岐にわたるタスクである．

24650011)，及び文部科学省科学研究費補助金若手研究 (A)(課

最後に，編集割合を利用し，変更が多岐にわたるクラスタを特定し，これらが各実験対象のプロジェクトについてどの程度存在しているかを測定する．結果は表 4 である．表から，実験対象となったプロジェクトについては，どれも 20%以上変更の多岐にわたるクラスタ，そしてそれらに対応するタスクが存在することが分かる．
以上から，変更が多岐にわたるタスクが，一定の割合でプロジェクト内で存在することがいえる．そして，提案手法はこれらのタスクを自動で検出できるという点で有用性があるといえる．

6. 結果の妥当性
本論文における手法や考察の妥当性について，以下で説明する点に留意する必要がある．

6. 1 提案手法の妥当性
まず，提案手法はソースコード中に出現する識別子が実装内容を反映していることを仮定している．このため，識別子に対する命名に不備がある場合，望ましい分類が得られない．
また，1 つのコミットでは 1 つのタスクの内容しか実装していないことも仮定している．そのため，複数の独立したタスクが 1 つのコミットに混在しているコミットが多い場合は，本手法で正しく分類できない場合がある．

6. 2 考察の妥当性

題番号：24680002) の支援を受けて行われた．
文

献[1] A. Murgia, G. Concas, M. Marchesi, and R. Tonelli. Amachine learning approach for text categorization of fixingissue commits on cvs. In Proceedings of the 2010 ACMIEEE International Symposium on Empirical Software Engineering and Measurement, pp. 6:1–6:10, 2010.
[2] Adrian Bachmann, Christian Bird, Foyzur Rahman,Premkumar Devanbu, and Abraham Bernstein. The missing links: Bugs and bug-fix commits. In Proceedings ofthe Eighteenth ACM SIGSOFT International Symposium
on Foundations of Software Engineering, pp. 97–106.
[3] N. Dragan, M.L. Collard, M. Hammad, and J.I. Maletic.
Using stereotypes to help characterize commits. In Proceedings of the 2011 27th IEEE International Conference on
Software Maintenance, pp. 520–523, 2011.
[4] A. Hindle, D.M. German, M.W. Godfrey, and R.C. Holt.
Automatic classication of large changes into maintenancecategories. In Proceedings of the 2009 IEEE 17th International Conference on Program Comprehension, pp. 30–39,
2009.
[5] L.P. Hattori and M. Lanza. On the nature of commits. InProceedings of the 23rd IEEE/ACM International Conference on Automated Software Engineering 2008., pp. 63–71,
2008.
[6] B. Fluri, M. Wuersch, M. PInzger, and H. Gall. Change distilling: Tree diﬀerencing for fine-grained source code change
extraction. IEEE Transactions on Software Engineering,pp. 725–743, 2007.
[7] G. Karypis. CLUTO - a clustering toolkit. Technical report,
Digitical Technology Center, 2003.

今回，分散の変更の分散が激しいタスクというものを考え，これがプロジェクト内で行われたタスク全体に占める割合を考えて手法の有効性を考察した．しかし，この考察において，変更の分散が激しいタスクとして検出されたクラスタそれぞれが，実際にどの程度 1 つのタスクとしてみなせるかを評価できていない．
そのため，検出された変更の分散が激しいクラスタそれぞれが，どの程度タスク単位の分類として正しいかを定量的に評価する必要がある．

7. あ と が き
本論文ではソフトウェア開発において，タスク単位での実装内容の把握が有用であることを踏まえ，これを支援するために，バージョン管理システムのリポジトリに蓄積されたコミットをタスク単位で分類する手法を提案し，実際にいくつかのオープンソース・ソフトウェアを対象として分類を行った．
その結果，タスク単位での分類として望ましい結果が存在することを確認した．また，提案手法がどのようなタスクの分類—6—