研究の経過 |
近年,互いに連携し共同開発を行うことを想定して,開発者が自分の担当する部分のソースコードを進捗にあわせて CVS などの構成管理ツールに登録し,全体の管理者は登録されたソースコードを LOC などのメトリクスを用いて進捗を判断しているケースが増えている。本研究では,構成管理ツールに登録されているソースコードについて,利用関係の時間の経過による変化と収束に着目し,登録されている各バージョンに対してコンポーネントランクを計算し,各部品におけるコンポーネントランク(順位と評価値)の変動の度合いによって,開発経過を推測する手法を提案した。提案手法に基づいて変動度を計算するツールを作成し,12 のオープンソースプロジェクトに適用した。この研究成果に基づき,2006年 12 月にインド・バンガロールで開催された APSEC2006 で研究発表を行った. |
提案手法の手順 |
1. CVS リポジトリの更新履歴から更新日の一覧を取得する. |
2. 更新日のソースコードを取得し,コンポーネントランク計算用の評価値を求める. |
3. 2. の結果を部品ごとにまとめ,部品ごとの時間による順位の推移を求める. |
4. 3. の結果から平均変動率などを計算する. |
評価実験 |
12 のオープンソースプロジェクトに対して適用したところ,以下の傾向が確認できた. |
・ |
前半は順位の変動が大きいが,後半になるにつれて,順位の変動が起こりにくくなる. |
・ |
リファクタリングやコードの再構築後は,利用関係の変化がおこりにくい。 |
・ |
平均変動度が相対的に高い変更は,次のような変更であることが多かった。 |
|
1. 大規模な機能追加 |
|
2. コア部分に対する変更を含んだ機能追加 |
|
3. コードの再構築やリファクタリングなどの修正 |
・ |
開発の中期以降,2. および3.の変更が平均変動度の高い変動として出現しやすい。 |
今後の課題 |
今までの研究において,部品の利用関係が変化しやすい更新がある程度分類できることがわかった。今後は,各変更タイプ別に各部品の順位の変動を詳細に追跡していき,それぞれの変更タイプにおける変動の要因を追跡していくことを考えている。 |
・ |
各変更タイプの更新を詳細に分析し,実際の個々の部品の順位がどのように変動するのかを確認し,タイプごとに順位変動のメカニズムに違いが出るかを調査する。 |
・ |
リファクタリングなどにおいて,変更内容をタイプ分けしたときに,タイプごとにどのような違いがあるのかを調査する。 |