ソースコード更新履歴を利用した変更危険度計測システムの試作大阪大学基礎工学部情報科学科井上研究室村尾憲治ソフトウェア開発 • 開発の大規模化・複雑化 • 開発の多人数化開発の管理が重要版管理システムが広く利用されている 2 版管理システム • ソフトウェアの開発履歴を保存・提供するシステム開発者開発者 – 開発者はソースコードの作業用コピーを得る（チェックアウト） • 開発者は作業用コピーを更新 – ソースコードの更新内容を版管理システムに反映（チェックイン） – 全ての更新の内容は版管理システムに蓄積される版管理システムには過去の開発過程の情報が保存されている版管理システムチェックアウトチェックイン更新作業用コピー開発者 3 ソフトウェア開発の問題点開発の複雑化・多人数化変更すると問題が発生する危険性のある箇所の判断が難しい開発者この箇所は変更してもいいのだろうか？変更すると • 仕様に反する可能性 • 開発を混乱させてしまう可能性  適確な判断にはソフトウェアの十分な理解が必要しかし，十分な理解は困難で時間がかかる 4 研究の目的変更すると問題が発生する危険性のある箇所を知りたい • メトリクスを定義「変更危険度」＝変更すると問題が発生する可能性の大きさ（粒度：行） • 変更の難しい箇所を判断 – その箇所への変更を避ける – 他の開発者に相談 • 変更危険度を計測するシステムを作成 5 変更危険度の大きい箇所 • 過去に変更が行われたが，後に変更前の状態に戻された箇所 – 変更を行っても以前と同じように戻される可能性 • 現在頻繁に更新されている箇所 – 迂闊に変更を加えると開発を混乱させる可能性過去の開発過程から知ることができる版管理システムに蓄積されている 6 提案する手法（概要） • 過去の更新過程から変更危険度を計測 → 版管理システムから入手できる情報を利用 • 更新パターンを分析「更新パターン」＝過去の更新過程にみられる「どのように更新されてきたか」という情報 • 変更危険度は複数の更新パターン毎に計測 – 対象：最新ソースコードの各行 7 提案する手法（図）版管理システム更新ソースコードの過去の更新内容（変更された行，更新日時など）更新更新更新更新パターンの検出変更危険度の計測更新更新更新パターン毎の変更危険度更新の過程を再現最新のソースコード 8 更新パターンの検出 • 今回対象とする更新パターン – 一度更新された部分が，後になって戻されている • 更新したがうまくいかなかった可能性 • 検出箇所・・・更新後の内容が以前にも存在した箇所 • 値・・・戻されている行数 – 変更されている量が多い • 大規模な修正がなされた可能性 • 検出箇所・・・更新が行われた箇所 • 値・・・変更された行数 – 頻繁に更新されている • 開発途中である可能性 • 検出箇所・・・更新が行われた箇所 • 値・・・更新された回数 9 変更危険度の計測 • 更新パターンの検出結果を統合 – 更新パターン毎に変更危険度を計測 – 検出した値に時間的な重み付けを行う • 古い情報ほど重要度を下げる – 最近の更新の方が影響が強い – ソースコードの改善による変更危険度の低下を表現時間的な重み w αx 0 α 1 ， x ：経過時間 10 計測の手順 1. 各開発時点の時間的な重み wi を決定 2. 各開発時点において，変更危険度を求める行に対応する範囲を調べる 3. 対応する範囲で検出された値 vi を取得 4. 各開発時点の vi  wi の値を合計する時間的な重み： w2 時間的な重み： w1 時間的な重み： w0 ( 1) w2 検出した値：v2 検出した値：v1 検出した値：v0  w1  w0 変更危険度   (vi  wi ) i 0 過去のソースコード最新のソースコード 11 変更危険度計測システムの実装 • 提案手法を実装するシステムを試作した – 開発言語・・Java – 総行数・・約6000行 – 出力結果の閲覧はウェブブラウザを利用 – 表示する変更危険度の値に色付け • 更新パターン別に値の大きさに応じた色低 ← ソースコード内の最小値変更危険度の値 → 高ソースコード内の最大値 12 出力例 13 評価実験 • 実験対象 – CREBASS • CVSリポジトリ閲覧・検索システム • 開発言語・・Java • 実験目的 – 変更危険度の出力結果を見ることで，変更すると問題が発生する危険性のある箇所を知ることができることを確認 14 評価方法 • 3種いずれかの変更危険度の値が大きい箇所について開発者にアンケート – データベース作成の機能を実装する8つのソースコードから26箇所（コメント部などは除いた） – アンケート内容 • • • • • 過去にバグを発生したことがあったかアルゴリズムが複雑であるか他のモジュールに影響を及ぼしやすいか実装方法を何度も変更したか上記以外の問題が過去に存在したか – アンケートのいずれかの項目に該当 → 変更により問題が発生する危険性あり 15 アンケート結果箇所数過去にバグが発生 6 アルゴリズムが複雑 0 他のモジュールに影響 0 実装方法を何度も変更 12 上記以外の問題 1 小計 19 該当なし内訳 CR(A) CR(F) CR(U), CR(A), CR(F) CR(F) 1 5 1 3 上記以外の問題・・・仕様の変更 6 1 1 2 7 合計 26 1 全て 8 1 7 1 1 7 1 7 2 15 適合率： 0.73 16 考察 • 適合率 0.73 – 本手法は概ね有効 • 該当なしの箇所 – 設計やアルゴリズムの変更に伴い最近更新 • 実質一人で開発しているため，危険とは思わなかった – 多人数の開発では危険である可能性 • 対象とした箇所以外にも危険な箇所は存在 – 本手法では抽出できていない • 新たな更新パターンの考案が必要 17 まとめと今後の課題 • 版管理システムに保存されたソースコードの更新履歴を利用し，変更危険度を計測する手法を提案 • 手法を実装するシステムを試作し，実際のソフトウェアに適用 – 手法の有効性を確認 • 今後の課題 – 構文解析の導入 – 新しい更新パターンの考案 – 多人数で開発されているソフトウェアに対する評価実験 18