2025年9月27日
今週の活動
1. Diffusion（拡散）カテゴリー
| 特徴量 |
説明 |
期待される効果 |
| NS |
変更されたサブシステムの数 |
大きいほど欠陥発生リスク↑ |
| NF |
変更されたファイルの数 |
大きいほど欠陥発生リスク↑ |
| Entropy |
ファイル間のコード変更の分散度 |
大きいほど欠陥発生リスク↑ |
2. Size（大きさ）カテゴリー
| 特徴量 |
説明 |
期待される効果 |
| LA/LT |
追加行数 / 変更前の総行数 |
大きいほど欠陥発生リスク↑ |
| LD/LT |
削除行数 / 変更前の総行数 |
大きいほど欠陥発生リスク↑ |
| LT/NF |
変更前の総行数 / ファイル数 |
大きいほど欠陥発生リスク↑ |
3. Purpose（目的）カテゴリー
| 特徴量 |
説明 |
期待される効果 |
| FIX |
欠陥修正か否か（ブール値） |
TRUEなら欠陥発生リスク↑ |
4. History（履歴）カテゴリー
| 特徴量 |
説明 |
期待される効果 |
| NDEV |
変更ファイルを変更した開発者数 |
大きいほど欠陥発生リスク↑ |
| AGE |
前回変更からの平均時間間隔 |
小さいほど欠陥発生リスク↑ |
| NUC/NF |
ユニークな変更回数 / ファイル数 |
大きいほど欠陥発生リスク↑ |
5. Experience（経験）カテゴリー
| 特徴量 |
説明 |
期待される効果 |
| EXP |
開発者の全体的な経験値 |
大きいほど欠陥発生リスク↓ |
| SEXP |
サブシステムでの開発者の経験値 |
大きいほど欠陥発生リスク↓ |
カテゴリー別の特徴数分布
| カテゴリー |
特徴数 |
| Diffusion |
3 |
| Size |
3 |
| Purpose |
1 |
| History |
3 |
| Experience |
2 |
| 合計 |
12 |
- NS
- なぜNSが大きいと欠陥発生リスクが高いのか？
- システム間の依存関係が複雑化するから
- 統合テストが困難になるから
- NF
- なぜNFが大きいと欠陥発生リスクが高いのか？
- 複数ファイル間の整合性を保つ必要があるため
- より多くのテストケースが必要になるため
- Entropy
- なぜEntropyが大きいと欠陥発生リスクが高いのか？
- LA/LT
- なぜLA/LTが大きいと欠陥発生リスクが高いのか？
- ファイルサイズに対して大きな追加があれば、大規模な機能追加やリファクタリングを示唆するため
- なぜLAをそのまま使わないのか？
- LD/LT
- なぜLD/LTが大きいと欠陥発生リスクが高いのか？
- ファイルサイズに対して大きな削除があれば、大規模な機能削除やリファクタリングを示唆するため
- なぜLDをそのまま使わないのか？
- LT/NF
- なぜLT/NFが大きいと欠陥発生リスクが高いのか？
- 1ファイル当たりのサイズが大きければ、粒度が荒くコードが複雑であることを示唆するため
- なぜLTをそのまま使わないのか？
- LTをそのまま使うとコードが適切に分散されていても値が過度に大きくなってしまうため
- FIX
- なぜFIX=TRUEだと欠陥発生リスクが高いのか？
- 新たな欠陥が発生しやすい場所で変更が行われたことを示唆するため
- NDEV
- なぜNDEVが大きいと欠陥発生リスクが高いのか？
- 多くの開発者が関与していると明確なコードオーナーがいない状態になり、変更の一貫性が低下するため
- AGE
- なぜAGEが小さいと欠陥発生リスクが高いのか？
- AGEが小さい（コードが頻繁に変更される）場合は、その変更要件が曖昧である可能性があるため
- NUC/NF
- なぜNUC/NFが大きいと欠陥発生リスクが高いのか？
- NUC/NFが大きければ多くの変更履歴を追跡する必要があり、コンテキストの理解が困難になるため
- なぜNUCをそのまま使わないのか？
- 多くのファイル変更があれば変更回数も多いと考えられる
- NUCをそのまま使うと変更回数が適切な範囲内であったとしても、値が過度に大きくなってしまうため
- EXP
- なぜEXPが大きいと欠陥発生リスクが低いのか？
- 経験が豊富な開発者はコードベース全体を理解しているため
- SEXP
- なぜSEXPが大きいと欠陥発生リスクが低いのか？
- サブシステムに詳しければ、そのコードの構造を理解しているため
得られた成果
- FIXの問題点
- 特定のコミットが欠陥修正であるかどうかを知るためのフラグであり、「どのメソッド/クラスが欠陥を誘発しやすいか」という具体的な情報を提供しないため予測性能向上にあまり寄与しない
- 例えメソッドやクラスの識別子を特徴量として追加したとしても、欠陥を誘発しやすいメソッドやクラスが変更あるいは移動されれば欠陥履歴を追跡できなくなる
- AGEの問題点
- 商用プロジェクトでは開発頻度が安定しているため予測性能向上に貢献するが、OSSプロジェクトはボランティアベースでコードが管理されているため、不定期にメンテナンスが行われ、特徴量として効果的ではない
- NDEVの問題点
- 商用プロジェクトではチームでの共同作業やペアプログラミングが行われることがあり、1つの変更に複数の開発者が関与することが比較的多いが、OSSプロジェクトでは1つの変更は基本的に1人の開発者（コントリビューターやコアメンテナー）が担当するため、特徴量として効果的ではない
- NUC/NFの問題点
- rebaseによって複数のコミットが1つにまとめられることがあるが、意図的にコミット数（変更回数）が減らされた場合は、その開発者は注意深くコードを観察している可能性が高いため欠陥発生リスクが減少するはず
- しかし、NUC/NFを指標として用いると逆に欠陥発生リスクが増加
- EXP/SEXPの問題点
- これらの指標は「コードベースに対する過去の変更回数」で開発者の経験を測定しているが、学習効率は個人差が大きく、変更回数すなわち学習量が多くても学習の質が低い開発者もいることを考慮していない
- NSの問題点
- Entropyの問題点
- 適切なモジュール分割をしたことで変更が複数のファイルに分散した場合であっても、欠陥発生リスクが高いと判断されてしまう
直面した課題
来週の計画