1 / 29

開発履歴データのリアルタイム収集・分析システム EPM の拡張について ～ SRGM を用いた予測グラフの実現および既存解析システムとの連携 ～

開発履歴データのリアルタイム収集・分析システム EPM の拡張について ～ SRGM を用いた予測グラフの実現および既存解析システムとの連携 ～. 横森励士 † 市井誠 † 新海平 ‡ 井上克郎 † † 　大阪大学　大学院情報科学研究科 ‡ ( 株 ) 日立システムアンドサービス. 研究の背景. 現在のソフトウェア開発環境では，ソフトウェアの生産性に関する問題が顕在化しつつある 開発期間の短縮圧力 大規模化したプロジェクトに対しての人海戦術の限界 ソフトウェアの信頼性が犠牲になっていることが多い 多数のバグを含んだソフトの流通 一度ダウンすると多大な社会的損失.

wyoming-meyer
Download Presentation

開発履歴データのリアルタイム収集・分析システム EPM の拡張について ～ SRGM を用いた予測グラフの実現および既存解析システムとの連携 ～

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 開発履歴データのリアルタイム収集・分析システムEPMの拡張について～ SRGMを用いた予測グラフの実現および既存解析システムとの連携 ～ 横森励士†市井誠†新海平‡ 井上克郎† †　大阪大学　大学院情報科学研究科 ‡ (株) 日立システムアンドサービス

  2. 研究の背景 • 現在のソフトウェア開発環境では，ソフトウェアの生産性に関する問題が顕在化しつつある • 開発期間の短縮圧力 • 大規模化したプロジェクトに対しての人海戦術の限界 • ソフトウェアの信頼性が犠牲になっていることが多い • 多数のバグを含んだソフトの流通 • 一度ダウンすると多大な社会的損失

  3. 研究の背景 • ソフトウェアの生産性，信頼性を向上させるためには，常にモニタリングを行い，問題を早期に発見し，早期に治療することが重要 • まずい状態を放置することは状況をさらに悪化させる • モニタリングを行う際には，ソフトウェア開発に関するデータの収集・計測・分析が必須の課題 • GQMなど，ソフトウェア計測に関する諸技術は多数提案されているが…… • 手法をよく理解して，実践するには，十分な経験が必要 • 実際のところ，改善に結びつけることはとても難しい

  4. EASEプロジェクト • 我々の研究チームではソフトウェア開発の分野における実証的手法（エンピリカルアプローチ）の実践を目指し，EASEプロジェクトを推進している • 定量的なデータ収集，分析，グラフ表示システムEPM データ収集 データの分析 プロセス改善の サイクルの確立を 目指す 開発現場へのフィードバック 分析結果に基づく モデルの提案

  5. EPM • リアルタイムでのプロジェクト管理を目的とした開発データの自動収集・分析システム • 以下の3種類の開発支援システムから収集 • 構成管理ツール（CVS） • メーリングリスト管理ツール（Mailman, Majordomo, FML） • 障害管理ツール（GNATS, Bugzilla） • オープンソース開発では昔からよく利用されている • 実際の開発においても，同種のシステムが利用されていることが多い

  6. EPMのアーキテクチャ Analyzer 開発者 管理者 個別分析，関連分析 Java PostgreSQL (Repository) importer Java 標準化エンピリカルデータ(XML形式) Rubyスクリプト translator 開発者 管理者 構成管理履歴 メール履歴 不具合履歴 CVS, Mailman, GNATS, (WinCVS, ShareSourceTM)<Option> Majordomo, FML, Bugzilla 既存ツール

  7. EPMによるデータ分析 • 単一システムからのデータを元に分析 • ソースコード規模（CVS） • 障害解決時間累積・未解決障害件数/平均障害滞留時間（GNATS（Bugzilla)） • ・・・ • 複数システムからのデータを元に分析 • 更新/参照数やメール投稿数（CVS⇔Mailmanなど） • 障害報告/メール投稿数（CVS⇔GNATS⇔ Mailman） • 更新と障害件数（CVS⇔GNATS） • ・・・ • 複数プロジェクト間の比較 • 分析結果をグラフに同時に出力 • 入力クエリーのカスタマイズ機能

  8. EPMのインタフェース：設定画面

  9. EPM出力例（その１）：ソースコードの規模推移とチェックインEPM出力例（その１）：ソースコードの規模推移とチェックイン

  10. EPM出力例（その２）：累積メール投稿数，　　　　チェックイン，障害発生/障害解決時期EPM出力例（その２）：累積メール投稿数，　　　　チェックイン，障害発生/障害解決時期

  11. EPM出力例（その３）：複数プロジェクト間の比較EPM出力例（その３）：複数プロジェクト間の比較

  12. 現在のEPMの課題 • 予測機能の充実化 • 現在のEPM では情報を取得し集計して表示するだけ • 開発者は，自力で類似プロジェクトを探索し表示し，類似プロジェクトの情報をもとに推測するくらいしかない • 開発者が現状を判断できるように，もう少し深く分析した情報を提示したい • 実際にEPMを利用してもらうための動機付けとして • 「予測機能の充実」 • 「類似プロジェクトの検出を支援する機能」が必要 • 既存の解析システムとの連携 • 現在のEPMはログ情報から比較的簡単に導出できるメトリクスを提示 • 一方，我々の研究チームではソースコード(などの生成物）に対する様々な分析手法（ツール）を提案している • SPARS • CC-finder • など • EPM上でも，これらのツールを有効に活用したい • EPM と有効に結びつける仕組みを提案することが重要である

  13. 研究の目的 • 実利用を考慮したEPMの機能の拡張 • 予測機能の充実化 • SRGM を用いた潜在フォールト数予測グラフの作成機能の実現 • SRGMプラグイン • 既存の解析システムとの連携 • 既存の解析システムとの連携手法を考察 • CCFinder • SPARS-J • ユースケースポイント計測支援システム

  14. 研究の目的 • 実利用を考慮したEPMの機能の拡張 • 予測機能の充実化 • SRGM を用いた潜在フォールト数予測グラフの作成機能の実現 • SRGMプラグイン • 既存の解析システムとの連携 • 既存の解析システムとの連携手法を考察 • CCfinder • SPARS-J • ユースケースポイント計測支援システム

  15. SRGM を用いた予測グラフ作成機能の実現 • SRGMとは • Software Reliability Growth Model（ソフトウェア信頼度成長モデル） • その時点までに発見された欠陥数を元に，欠陥数がどう収束するかを推定するための手法

  16. SRGM を用いた予測グラフ作成機能の実現 • いままで，多くのモデルが提案されているが… • 指数型ＳＲＧＭ • 修正指数型ＳＲＧＭ • Ｓ字型ＳＲＧＭ • テスト労力依存型ＳＲＧＭ • など • 実際企業などでＳＲＧＭが利用される場合には，決め打ちで一種類だけのモデルしか使われない場合が多い • 実情とあわなかったり • 開発者側が順応し，対策を立ててしまうことも 　　　　　　　いくつかのモデルを簡単に適用でき，比較できるような 　仕組みをＥＰＭ上で実現したい

  17. SRGMプラグイン • 実現の手順： • ＥＰＭで収集しているバグ情報追跡システムの履歴情報を用いる • 計測期間中の各日のバグ発見数を計算 • 複数（現在は４つの）のモデルそれぞれでパラメータ推定を行う • 指数型ＳＲＧＭ • 修正指数型ＳＲＧＭ • Ｓ字型ＳＲＧＭ • 習熟Ｓ字型ＳＲＧＭ • それぞれのモデルに検定を行う • コルモゴロフ・スミルノフ検定法 • 検定に合致したモデルに対し，その結果をグラフ化する • 潜在バグ数（とその予想域），総発見バグ数の推移予想 • 利点: • データを人手で加工する手間がなく，グラフ化までを自動化できる • 複数のＳＲＧＭを気軽に利用できる • 現場でGNATSなどの障害管理ツールを導入するためのきっかけに

  18. SRGMプラグイン SRGM プラグイン データベース （フォールト情報 管理システム） 指数型 修正指数型 遅延S字型 習熟S字型 パラメータの推定 検定 適合 適合 不適合 不適合

  19. 現状の課題（SRGMプラグイン） • 実際の開発データに基づいた評価 • 現在EPMのバージョン0.91を実際の開発で利用してもらっている • EPMの次バージョンリリース後に実際の開発データをもとに評価 • 機能の洗練 • 検定方法の工夫 • 現在はコルモゴロフースミルノフ適合度検定法だけを利用 • モデルとの適合度を測定し，グラフをより見やすいものに加工 • テスト工数（労力）を考慮したSRGMモデルの導入 • 一般的に，テスト工数を考慮すると予測結果がより正確になる • テスト労力関数にもいろいろなモデルが存在 • Reyleigh curve, Logistic curve, Log-Logistic curve • 自動化には，プロジェクト管理システムとの連携が必要

  20. 研究の目的 • 実利用を考慮したEPMの機能の拡張 • 予測機能の充実化 • SRGM を用いた潜在フォールト数予測グラフの作成機能の実現 • SRGMプラグイン • 既存の解析システムとの連携 • 既存の解析システムとの連携手法を考察 • CCFnder • SPARS-J • ユースケースポイント計測支援システム

  21. 既存の解析システムとの連携 • 現在のEPMでは，CVSから基本的なメトリクスを抽出するだけ • LOC，更新（参照）回数… • 適用対象を限定しないため • CVSに登録されているプロダクトからはもっと情報が抽出できるはず • より詳しい解析を行うために既存のツールを利用したい • 既存のソースコード解析システムとの連携手法を考察 • CCFinder • SPARS-J • ユースケースポイント計測支援システム

  22. CCFinder • コードクローンの検出，分析システム • コードクローンとはソースコード中の全く同じあるいは類似したコードの断片を指す • ソースコードにコードクローンが大量に存在すると，保守が困難に • CCFinderの特徴 • スケーラブル • 100万行単位のソースコードに対して実用的に適用できる． • 複数のプログラミング言語に対応 • C/C++, Java, COBOL, Fortranなどに対応 • コードクローンの抽出だけでなく，コードクローンに関するいくつかのメトリクスを測定可能 • コードクローンカバレッジ：ソースコード中の行の中で，コードクローンの集合に含まれる行の割合 Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue, ”CCFinder: A Multi-Linguistic Token-based Code Clone Detection System for Large Scale Source Code,” IEEE Trans. Software Engineering, Vol. 28, No. 7, pp. 654–670,2002.

  23. CCFinderの利用に関する考察 • CCFinderを用いてコードクローンを検出したり，メトリクスを用いることで，プロジェクトの現状が把握できないだろうか？ • CVS内の各バージョンのソースコードに対して • 差分⇔本体間や，本体内，差分内でコードクローンを抽出し，それぞれの場合のコードクローンカバレッジを計算 • コードクローンが混入された変更の推定 • コードクローンを多く含んだ修正は警告する • バージョン経過による，本体内のコードクローンカバレッジの推移を計算 • リファクタリングのタイミングをはかる • 差分内，差分と本体間のコードクローンを計算 • コードクローンが混入された箇所の調査 • 変更し忘れと思われるコードクローンがあればそれを指摘 • 修正パターンをコードクローンから抽出し，変更を分類

  24. SPARS-J • ソフトウェアプロダクトの収集・解析・検索システム • ソフトウェア部品を解析し，利用関係などの様々な情報をもとに，検索結果に有益な情報を付加する • 単純な検索システムとしてだけでなく，組織内のソースコード管理にも有効に利用できる • SPARS-Jの特徴 • スケーラブル • 10万ファイル単位のソースコードに対して実用的に運用可能 • 高速な検索が可能 • Javaに対応 • Javaソースコード，XMLドキュメント，JSPなどを検索可能 • 順位付け手法 • キーワードとの適合性 • 部品の被利用度（Component Rank） 横森励士, 梅森文彰, 西秀雄, 山本哲男, 松下誠, 楠本真二, 井上克郎: ”Java ソフトウェア部品検索システムSPARS-J”, 電子情報通信学会論文誌D-I, VolJ87-D-I, No.12, pp1060–1068, 2004.

  25. SPARS-Jの利用に関する考察 • SPARS-JはEPMと同様な運用形態 • サーバにデータベースを構築し，利用者はデータベースにアクセス • 夜中に走らせておけば，常に最新状態で利用可能 • 開発言語がJavaであれば，EPMと同時に運用すると効果的 • EPM導入時にソースコード管理環境も容易に構築できる • Component Rankの推移を開発の安定度を測定するために使えないだろうか？ • 開発の初期は常に新しい部品が追加され，利用関係はどんどん変化していく • 時間の経過とともに収束していくはず • CVS内の各バージョンに対して， Component Rankを計算しその推移をはかる

  26. ユースケースポイント測定システム • ソフトウェアの開発において見積もりをすばやく正確に行うことは重要 • 早い段階で見積もりができれば，計画も立てやすい • 要求定義の段階において工数の規模見積もりを行う手法としてユースケース図から規模見積もりを行う手法が提案されている • ユースケースポイント法 • ユースケースポイント法に基づいてユースケースポイント計測の自動化を支援するシステムを開発した • アクタやユースケースに対する重み付けを支援する • 重み付けをするために必要な情報が不足している場合でも，過去の情報を参考にして重み付けを行うことができる 松川文一, 楠本真二, 井上克郎, 英繁雄, 前川祐介: ”ユースケースポイント計測支援ツールの実装とその適用”, 情報処理学会研究報告(2004-SE-144), Vol. 2004, No.30, pp.91–98, 2004.

  27. ユースケースポイント測定システムに関する考察ユースケースポイント測定システムに関する考察 • EPMと連携することで，EPMに設計情報を用いた工数の予測機能を追加できる． • ユースケース図をCVSで管理する必要あり • 変更があった場合も，過去に登録された情報をもとに自動的に再計算 • 再計算に必要な手間を最低限に • 必要な情報が不足していても，CVSリポジトリから取得 • プロジェクトの計画の変更に対して，柔軟に対応できるようになる．

  28. 既存解析システムとの連携 Analyzer 開発者 管理者 個別分析，関連分析 Java 加工・登録 既存システム PostgreSQL (Repository) 不具合履歴 解析情報 importer Java 標準化エンピリカルデータ(XML形式) Rubyスクリプト translator 解析ツール 開発者 管理者 構成管理履歴 メール履歴 不具合履歴 実行 CVS, Mailman, GNATS, (WinCVS, ShareSourceTM)<Option> Majordomo, FML, Bugzilla 既存ツール

  29. まとめ • まとめ • SRGM を用いた潜在フォールト数予測グラフの作成機能をEPM上で実現した • 既存の解析システムとの連携手法を考察した • CCFinder • SPARS-J • ユースケースポイント計測支援システム • 今後の課題 • 実際の開発データに基づいた評価 • 実際の利用をもとにした，機能の洗練 • 既存の解析システムとの連携の実現

More Related