昨日、
SRA技術セミナー
開発者視点でのビッグデータの活用
〜ソフトウェア開発を成功に導く魅力的な開発ログデータの利用に向けて〜
に行ってきた！その内容をメモメモ
■イントロダクション
利用者視点からのログデータの活用
ビッグデータ
・国 JST（２０１３年 きつれがわ先生など）
特徴
大量なデータ
不均一
密なところと疎なところ
分析することをもともと想定せず集まったデータ
データマイニング
データ→関係／パターンを見つける
→国がやっているところ
では、どうするか？
→切り離すと効果は？
ソフトウェア開発ログデータ
マシン上で行うアクティビティの多くは
そのログを＜フリー＞に記録して貯めておくことができる
効果
全体の傾向の提示
過去のパターンに基づいた予測
開発者の視点
経緯を思い出す
リフレクションする
必要な情報を探す手立てにする
動機付けになる
■ソフトウェアリポジトリマイニングでできること、できないこと
大平先生（和歌山大）
オープンソースソフトウェア工学研究室
→OSS開発を「見える化」するための技術の開発
ソフトウェアリポジトリマイニング
・開発ログデータをソフトウェア開発に有用な知見を導き出す
SI(ソフトウェアインテリジェンス）
→BIにちなんで
MSR（ワーキングコンファレンス オン マイニング ソフトウェア リポジトリ）
ICSE併設の会議
２００４年からつづくリポジトリマイニング専門の国際会議
ソーシャルマイニングも
ソースコード、メールデータも
MSRのキーワード
ソフトウェア（コード）解析
統計解析
データマイニング
テキストマイニング
ソーシャルネットワーク分析
これまでのSW開発支援技術との違い
・伝統的アプローチ
CASEツール：モデルはツールを作った人が持っている
・MSR的アプローチ
前提：開発ログデータに創意工夫
開発者がプロダクティブ
ソフトウェアリポジトリ
・SWの製造／試験／保守運用工程において用いられる
開発ツールの使用履歴を記録・保存しておくための
データベース
バージョン管理システム：コードリポジトリ
・ソースコードの変更履歴を管理するためのシステム
・Git,CVS,Subversionなど
どんな情報（メトリクス）が取得可能か
プロダクトメトリクス（ソースコード）
プロセスメトリクス（コミットログ）
不具合管理システム：バグリポジトリ
BTS（バグトラッキングシステム）
わりと、ばぐじら対象
状態遷移（どんなフローで解決？）
議論内容→テキストマイニング
メーリングリストアーカイブ
ヘッダ→タイムゾーン
最近：クラッシュレポート
テストケース管理
ソースコードレビューの記録
できること
・製造（プログラミング）支援
・ソフトウェア部品検索エンジン(SPARSなど）
・使用頻度に基づくOSSライブラリの安定バージョン
・コードクローン検出
・テスト／デバッグ支援
バグモジュール予測
バグの原因箇所の特定
同時変更されるコードの特定など
・保守支援
不具合箇所の特定（バグ・ローカライゼーション）
バグトリアージ（最も適した開発者を推薦する）
Reopen Bugの予測（直したが、再発する予測）
不具合修正時間の予測
・ライセンス管理
OSSのライセンス違反を自動的に検出する
→製品が存在する
・組織構造／コミュニケーションの分析
・OSSユーザー支援
品質／成熟度評価
MSRが設立されて１０年
・最近：たくさんのデータ
初期：
・メトリクス計測の自動化
・開発プロジェクトの可視化
EPM
中期：
・異種リポジトリ間の関連付け
CVS／SVN→Bugzilla
・潜在的な組織構造の分析
SW開発のソーシャルな側面に注目
最近のトレンド：
・対象リポジトリの大規模化、多様化
・クロスプロジェクト予測
・SWエコシステムの分析
・非構造データの活用と構造データとの関連付け
・バグ トリアージ
・バグ ローカライゼーション
そのままでは使ってもらえない
現場にどう生かすか：
→ユースフル＆アクショナブル
マイクロソフトのリポジトリマイニング
リポジトリマイニングでできないこと
・トップダウンアプローチが苦手
・VS GQM（Goal Question Metrics)法
SW開発現場への導入に当たっての課題
・SE Data（リポジトリデータ）の処理に必要となる
膨大な統計解析／データマイニングの知識
MSR研究者の課題
・SETask（現場の支援ニーズ）の理解不足
・実データでの検証不足
False-Positive/False-Negativeへの十分な対応
現在進行中の主なプロジェクト
・IPA EPM-Xにリポジトリマイニングプラグイン
・バグトリアージ／整数計画法（ナップザック問題）
・遅延相関分析
＜＜質問＞＞
・企業は？
マイクロソフト、IBM,あばや、インド企業
日本は？NTTデータ、日立、富士通が割りと
チュートリアルすると、企業１〜２割
・バグトリアージの効果は？
運用までがすくない（未知数）インド企業で使ってみた
・要求・設計のマイニングは？
REの去年のベストペーパー／自然言語のマイニング
プロセス改善は？まだ行っていない
・バグのモジュール予測
テスト工数を割り当て：情報処理学会で出てる
ソース書き換え：実践例はない
・最近、バグがどれくらいインパクトというのを見ている
判別分析で予測
ソーシャルマイニング：熟練者と初心者の傾向分析
・はじめるまでのコストが高そう
効果の出る規模・業種とかある？
ある程度のデータがそろっていないと、なにもできない
・企業でバグモジュールの予測
プロジェクトで比較すると、傾向が違う
→個々に特化した判別モデルを作る
→組織に違いがあるのでないか？
→最近興味を持っているのがそこ、はずれ値をみる
・マイニングで面白い発見ある？
→意外な発見いっぱいある
依頼するまでに時間をかけると、はやくバグ終息する
→そのまえに戦略を立てているから
■SRAのソフトウェアリポジトリマイニング実践事例
SRA
SIとして開発
プロジェクトの規模、プラットフォームさまざま
→プロセスの統一、開発ツールの統一が困難
品質向上
・開発ツール
テスティング自動化：オートテスティング系
静的解析
Fortify→脆弱性
CodeDepot→コード検索
・開発プロセス
標準化（CMM,VSE→SQETを利用した作業項目、成果物のチェック）
オフショア発注のガイドライン
・品質の管理
品質メトリクスの収集と評価
SILVRとは
・チーム開発における課題
さまざまな業務、規模、環境で共通の課題
導入目的
・チーム開発での共通課題の解決
・プロジェクト間の共有
学習の効率化
・定量データの収集と評価
・開発者は収集されていることを意識しない
→開発マネージャー／品質担当者
構成
バージョン管理 ：subversion
課題管理・Wiki ：trac
メーリングリスト ：mailman
ファイル共有 ：webDAV
継続的インテグレーション：jenkins
継続的インスペクション ：Sonar
脆弱性 ：Fortify
ソースコード検索 ：CodeDepot
運用
・新規プロジェクト作成
・アクセス制御
・SSLによるリモート接続
・自動バックアップ
あゆみ
・２００８年：初期バージョン
・２０１２年：メトリクスの可視化
利用例：
品質指標に相関の近い指標が見たい
jenkinsも使うようになっている
チケット管理はちゃんと使わないと
ダッシュボード
ユーザーごとのメトリクス
SRA技術セミナー
開発者視点でのビッグデータの活用
〜ソフトウェア開発を成功に導く魅力的な開発ログデータの利用に向けて〜
に行ってきた！その内容をメモメモ
■イントロダクション
利用者視点からのログデータの活用
ビッグデータ
・国 JST（２０１３年 きつれがわ先生など）
特徴
大量なデータ
不均一
密なところと疎なところ
分析することをもともと想定せず集まったデータ
データマイニング
データ→関係／パターンを見つける
→国がやっているところ
では、どうするか？
→切り離すと効果は？
ソフトウェア開発ログデータ
マシン上で行うアクティビティの多くは
そのログを＜フリー＞に記録して貯めておくことができる
効果
全体の傾向の提示
過去のパターンに基づいた予測
開発者の視点
経緯を思い出す
リフレクションする
必要な情報を探す手立てにする
動機付けになる
■ソフトウェアリポジトリマイニングでできること、できないこと
大平先生（和歌山大）
オープンソースソフトウェア工学研究室
→OSS開発を「見える化」するための技術の開発
ソフトウェアリポジトリマイニング
・開発ログデータをソフトウェア開発に有用な知見を導き出す
SI(ソフトウェアインテリジェンス）
→BIにちなんで
MSR（ワーキングコンファレンス オン マイニング ソフトウェア リポジトリ）
ICSE併設の会議
２００４年からつづくリポジトリマイニング専門の国際会議
ソーシャルマイニングも
ソースコード、メールデータも
MSRのキーワード
ソフトウェア（コード）解析
統計解析
データマイニング
テキストマイニング
ソーシャルネットワーク分析
これまでのSW開発支援技術との違い
・伝統的アプローチ
CASEツール：モデルはツールを作った人が持っている
・MSR的アプローチ
前提：開発ログデータに創意工夫
開発者がプロダクティブ
ソフトウェアリポジトリ
・SWの製造／試験／保守運用工程において用いられる
開発ツールの使用履歴を記録・保存しておくための
データベース
バージョン管理システム：コードリポジトリ
・ソースコードの変更履歴を管理するためのシステム
・Git,CVS,Subversionなど
どんな情報（メトリクス）が取得可能か
プロダクトメトリクス（ソースコード）
プロセスメトリクス（コミットログ）
不具合管理システム：バグリポジトリ
BTS（バグトラッキングシステム）
わりと、ばぐじら対象
状態遷移（どんなフローで解決？）
議論内容→テキストマイニング
メーリングリストアーカイブ
ヘッダ→タイムゾーン
最近：クラッシュレポート
テストケース管理
ソースコードレビューの記録
できること
・製造（プログラミング）支援
・ソフトウェア部品検索エンジン(SPARSなど）
・使用頻度に基づくOSSライブラリの安定バージョン
・コードクローン検出
・テスト／デバッグ支援
バグモジュール予測
バグの原因箇所の特定
同時変更されるコードの特定など
・保守支援
不具合箇所の特定（バグ・ローカライゼーション）
バグトリアージ（最も適した開発者を推薦する）
Reopen Bugの予測（直したが、再発する予測）
不具合修正時間の予測
・ライセンス管理
OSSのライセンス違反を自動的に検出する
→製品が存在する
・組織構造／コミュニケーションの分析
・OSSユーザー支援
品質／成熟度評価
MSRが設立されて１０年
・最近：たくさんのデータ
初期：
・メトリクス計測の自動化
・開発プロジェクトの可視化
EPM
中期：
・異種リポジトリ間の関連付け
CVS／SVN→Bugzilla
・潜在的な組織構造の分析
SW開発のソーシャルな側面に注目
最近のトレンド：
・対象リポジトリの大規模化、多様化
・クロスプロジェクト予測
・SWエコシステムの分析
・非構造データの活用と構造データとの関連付け
・バグ トリアージ
・バグ ローカライゼーション
そのままでは使ってもらえない
現場にどう生かすか：
→ユースフル＆アクショナブル
マイクロソフトのリポジトリマイニング
リポジトリマイニングでできないこと
・トップダウンアプローチが苦手
・VS GQM（Goal Question Metrics)法
SW開発現場への導入に当たっての課題
・SE Data（リポジトリデータ）の処理に必要となる
膨大な統計解析／データマイニングの知識
MSR研究者の課題
・SETask（現場の支援ニーズ）の理解不足
・実データでの検証不足
False-Positive/False-Negativeへの十分な対応
現在進行中の主なプロジェクト
・IPA EPM-Xにリポジトリマイニングプラグイン
・バグトリアージ／整数計画法（ナップザック問題）
・遅延相関分析
＜＜質問＞＞
・企業は？
マイクロソフト、IBM,あばや、インド企業
日本は？NTTデータ、日立、富士通が割りと
チュートリアルすると、企業１〜２割
・バグトリアージの効果は？
運用までがすくない（未知数）インド企業で使ってみた
・要求・設計のマイニングは？
REの去年のベストペーパー／自然言語のマイニング
プロセス改善は？まだ行っていない
・バグのモジュール予測
テスト工数を割り当て：情報処理学会で出てる
ソース書き換え：実践例はない
・最近、バグがどれくらいインパクトというのを見ている
判別分析で予測
ソーシャルマイニング：熟練者と初心者の傾向分析
・はじめるまでのコストが高そう
効果の出る規模・業種とかある？
ある程度のデータがそろっていないと、なにもできない
・企業でバグモジュールの予測
プロジェクトで比較すると、傾向が違う
→個々に特化した判別モデルを作る
→組織に違いがあるのでないか？
→最近興味を持っているのがそこ、はずれ値をみる
・マイニングで面白い発見ある？
→意外な発見いっぱいある
依頼するまでに時間をかけると、はやくバグ終息する
→そのまえに戦略を立てているから
■SRAのソフトウェアリポジトリマイニング実践事例
SRA
SIとして開発
プロジェクトの規模、プラットフォームさまざま
→プロセスの統一、開発ツールの統一が困難
品質向上
・開発ツール
テスティング自動化：オートテスティング系
静的解析
Fortify→脆弱性
CodeDepot→コード検索
・開発プロセス
標準化（CMM,VSE→SQETを利用した作業項目、成果物のチェック）
オフショア発注のガイドライン
・品質の管理
品質メトリクスの収集と評価
SILVRとは
・チーム開発における課題
さまざまな業務、規模、環境で共通の課題
導入目的
・チーム開発での共通課題の解決
・プロジェクト間の共有
学習の効率化
・定量データの収集と評価
・開発者は収集されていることを意識しない
→開発マネージャー／品質担当者
構成
バージョン管理 ：subversion
課題管理・Wiki ：trac
メーリングリスト ：mailman
ファイル共有 ：webDAV
継続的インテグレーション：jenkins
継続的インスペクション ：Sonar
脆弱性 ：Fortify
ソースコード検索 ：CodeDepot
運用
・新規プロジェクト作成
・アクセス制御
・SSLによるリモート接続
・自動バックアップ
あゆみ
・２００８年：初期バージョン
・２０１２年：メトリクスの可視化
利用例：
品質指標に相関の近い指標が見たい
jenkinsも使うようになっている
チケット管理はちゃんと使わないと
ダッシュボード
ユーザーごとのメトリクス