Local vs. Global Models for Effort Estimation and Defect Prediction

Preview:

DESCRIPTION

Proceeding of the 26th IEEE/ACM International Conference On Automated Software Engineering (ASE 2011), pp. 343 - 351. Local vs. Global Models for Effort Estimation and Defect Prediction. Tim Menzies , Andrew Butcher, Andrian Marcus, Thomas Zimmerman, David Cok. 担当:戸田 航史 ( NAIST ・松本研). - PowerPoint PPT Presentation

Citation preview

Local vs. Global Models for Effort Estimation and Defect Prediction

Tim Menzies, Andrew Butcher, Andrian Marcus, Thomas Zimmerman, David Cok

担当:戸田 航史( NAIST ・松本研)

Proceeding of the 26th IEEE/ACM International Conference On Automated Software Engineering (ASE 2011), pp. 343 - 351

概要• 我々がデータマイニングによって得られた結果を現場に持って行くと,いつも「で,プロジェクトをマシにする上で,このデータはどう使えばいいの?」と尋ねられる.• 本稿で提案するのは,その質問に対する解答を導く手段である.

Which: Contrast Set Learning

1. 特定のメトリクスを含むプロジェクトだけを集めたサブセットを作成し,サブセットから Score (データ改善指標値)を算出する2. 全てのメトリクス(組み合わせを含む)の中で,最も Score が高かったメトリクスに沿うようにプロジェクトを改善すれば良い

Which の具体例• 例: Score 最高値が「プログラマの能力=平均的」ならば,プロジェクトに参加するプログラマの能力を調整すれば良い– 例えばプロジェクトの工数を削りたい場合に,調整すべきメトリクスの指針を立てやすくなる– Score 式中の工数,欠陥率は例であり,改善したい項目を代入することで,そのための施策を立てることができる

• ここまで「 for effort estimation and defect prediction 」の話

Score=サブセットの工数 or 欠陥率の中央値元データの工数 or 欠陥率の中央値 ×サブセットのプロジェクト数

元データのプロジェクト数

ここまでのまとめ• でも全データセットを利用すると,結果があまりにもおおざっぱになりすぎる• クラスタリングによってプロジェクトの個別性を考慮しよう– ここから「 Local vs. Global Models 」の話– というか Which 自体は別の論文で提案された手法なのでこのままでは新規性が無い

Where: Clustering

• FASTMAP によって説明変数を 2 次元にまで集約し,各軸の中央値によって分割を繰り返す– 制限が無ければ分割するたびにクラスタは 4n

個になる

Where の具体例

• 改善対象のプロジェクトの所属するクラスタのデータを用いて Which を実行することでよりよい分析が可能となる

Fig. 3 より

Capacity Planning for Event-based System using Automated Performance Predictions

1Christoph Rathfelder 2Samuel Kounev 3David Evans

1FZI Research Center for Information Technology2Karlsruhe Institute of Technology

3University of Cambridge

Proceeding of the 26th IEEE/ACM International Conference On Automated Software Engineering (ASE 2011), pp. 352-361

担当:山内寛己 @ (株)アクセス( NAIST ・松本研 OB )

概要• 背景:スケーラブルな分散システムを構築するため,イベント駆動型通信が使われるようになってきた.• システム全体の挙動や性能を見積もるための Capacity

Planning が困難になってきている• 貢献(論文の流れ):• イベント駆動型通信に対応した拡張 Palladio Component

Model(PCM) による自動性能予測モデルを提案・開発.• 実際に使われているイベント駆動型システムをケーススタディとして,提案手法による性能予測と実測との比較・評価.

Palladio Component Model (PCM) の拡張(イベント駆動型対応)と自動化1. コンポーネントベースのソフトウェアアーキテクチャモデルを記述し,そこから性能予測モデルに変換

2. イベント駆動型通信に対応する自動変換するためのメタモデルを構築

3. 入力パラメータの組み合わせを自動生成し,性能予測モデルにて,シミュレーションの実行

S.Becker et al. "Model-Based Performance Prediction with the Palladio Component Model“, Proc. of the 6th international workshop on Software and performance(WOSP'07)

Component Model

Composition Model

Deployment Model

Usage Model

Fig.2 Automated Model-to-Model Transformation

Fig.3 Automated Performance Prediction Process

Fig. Palladio Component Model (Modified)

ケーススタディ• 対象システム:ケンブリッジ市内イベント駆動型の交通モニタシステムの一部である SBUSミドルウェアと交通モニタリングアプリ

– SBUSミドルウェアコンポーネントベース. P2P 型イベント型通信(ストリームデータ(センサ情報),非同期イベント,同期メッセージ(RPC) )を取り扱える.

– 交通モニタリングアプリ異なる 8種類のコンポーネント(下図)で構成

Fig.4 Overview of Case Study Components

Cam: カメラLPR: ナンバプレート認識Speeding: スピード検出Toll: 高速料金収集ACIS : バス位置提供Location: 位置情報SCOOT: 信号機状態 Bus Proximity: バス接近検出

ケーススタディのシナリオと評価• シナリオ

– ベースシナリオ– 負荷の増加(コンポーネントの配置変更)– 機能追加(コンポーネントの追加)– ハードウェアのアップグレード

• 予測値100,000枚の画像処理を最後の約 3 分実行時の負荷– 実システム 5時間実行(またはそれ以上)に相当

• 評価– カメラ 1台あたりの画像更新レート [1/s] に対する

• CPU 利用率 [%]• LPR コンポーネントの処理時間 [s]

– 実システムの実測値との絶対誤差にて評価

評価結果とまとめ• 評価結果

– CPU 利用率,処理時間ともにほとんどのケースにおいて,誤差 20%以内だった.CPU 利用率の予測に関しては,予測誤差 25% を超えることはなかった.

• モデリングおよび予測のコスト– モデリング:イベント駆動型の拡張により,モデル変換が最大 80%省力化した.論文中のすべてのケースをモデリングするのに 30 分かからなかった.– 予測(シミュレーション):シミュレーションの実行は完全自動化されている.評価するには,シミュレーションのケースに相当する実システムの計測をすればよい.

100,000 ものシミュレーションイベントを MacBook Pro* で 3 分ほど.

*Corei7 CPU, 8GB RAM

Ecological inference in empirical software engineering

Daryl Posnett, Vladimir Filkov, Premkumar Devanbu

University of California, Davis

担当:角田 雅照( NAIST ・松本研)

Proceeding of the 26th IEEE/ACM International Conference On Automated Software Engineering (ASE 2011), pp. 362 - 371

Ecological inference

• ソフトウェアプロジェクト,プロダクトは階層的である.• ある階層で得られた知見が,下位の階層でも成り立つという推論( Ecological inference )は正しいのか ?– 疫学などでは,階層間(都道府県と個人間など)で成り立たないことがある (ecological fallacy) と指摘されている.

パッケージ

モジュールA

モジュールB

ファイル J ファイル K ファイル L ファイル M

知見 人数が多いとバグが多い成り立つ ?

Ecological inference の要因仮説検定

予測精度

知見

データ収集 結果の偏り

データ数

集計対象集計グループに偏りがある.- 集計グループに相関があると,分析結果に擬似相関が出る.

上位の測定値ほど,データ数が少なくなり,統計的な効果が下位に比べて小さくなる.- 説明変数として採用されなくなる.

バグありモジュールが,バグ無しモジュールに比べて少ない.

パッケージ

モジュールA モジュールB

ファイルJ ファイルK ファイルL ファイルM

予測モデルの精度• Apache プロジェクトのデータを収集,パッケージレベル,ファイルレベルのバグ予測をした.–パッケージレベルはファイルからの集計値を使う.単純な予測精度

(AUC) では差がない工数を減らす効果(ファイルレベルでの作業を考慮した評価)で比較すると,差がある.

上位レベルだけを見ている場合,過大評価をしてしまう場合がある.

仮説検定• 予測モデルの説明変数(行数など)が有意であれば,予測に役立つとする.• 検定結果がパッケージレベルとファイルレベル(下位)と一致しない場合について調べた.• モデルの説明変数の約半分が下位レベルで有意ありに変化,または有意なしに変化した.上位レベルで得られた知見が,下位レベルでも成り立つとは限らない.

まとめ• 論文の貢献点– 実証的ソフトウェア工学 (ESE) に Ecological

inference のコンセプトを導入した.– ESE における Ecological inference の要因を提示した.– 実験により,予測精度や仮説検定において, Ecological inference が成立しない場合を示した.

Recommended