UMLで記述された設計仕様書を対象とした レビュー手法CBRとPBRの比較評価実験 大阪大学大学院情報科学研究科 松川 文一 Giedre Sabaliauskaite 楠本 真二 井上 克郎 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 発表内容 研究の背景 実験に用いたレビュー手法について CBR（Checklist-based Reading） PBR（Perspective-based Reading） 研究の目的 評価実験 実験概要 データ分析 まとめと今後の課題 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 2 研究の背景 ソフトウェアレビュー ソフトウェアのプロダクトの内容について，作成者と他の開発者た ちとの間で議論し，プロダクト内のバグを早期発見，修正すること を目的とする レビューのプロセス[1] 1. 2. 3. 4. 5. 始動 個人チェック グループチェック 完了 プロセス改善 •Checklist-based Reading（CBR） •Perspective-based Reading（PBR） [1] T. Gilb, D.Graham, 伊土 誠一, 富野 壽[監訳], “ソフトウェアインスペクション”, 共立出版, 1999. 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 3 CBR CBR（Checklistbased Reading） いくつかのチェック項目を 並べたリストを元に，それ に対してyes/no形式で 答えながらレビューを行う 項目は基本的にチェック を行う場所，バグ発見の 指針となる問題点のリス トからなる 2015/10/1 チェックリスト クラス図，アクティビティ図，シーケンス図，コンポーネント 図に対して，以下の項目についてチェックしてください．チェッ クした際にバグを見つけた時には， 図上のバグの箇所に印 をつけて，バグ調査表に記入してください． クラス図 1. 2. 3. 4. 5. クラス図と要求仕様書 の間に矛盾はありませ んか？ 必要なクラス，関連が 全て定義されています か？ 冗長なクラ スはありま せんか？ yes no yes no yes no 全ての関連について多 重度は定義されていま すか？ プログラムを書く上で十 分な情報が記入されて いますか？ yes no yes no オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 4 PBR PBR（Perspectivebased Reading） プロダクトに関わるいくつかの 立場（ユーザ, 設計者，等） を設定し, それぞれの異なっ た視点からレビューを行う 各視点毎に作成されたシナ リオを用いる シナリオにはレビュー順序， 作業, チェック項目等が記さ れている チェックリスト（ユーザ） あなたはこのソフトウェアのユーザであると思ってください．あなたの目標は，要求仕 様書，ユースケース図，アクティビティ図，シーケンス図があなたの要求を満たしている かどうかをチェックすることです．具体的には，ユーザの立場で，アクティビティ図とシー ケンス図にバグがないかどうかをチェックしてもらいます． チェックは，以下のStep1～Step5に従って行ってください．各Step では指定された設 計図を用意して，チェック項目に従って確認してください．バグを発見した時には，図上 のバグの箇所に印をつけて，バグ調査表に記入してください． シーケンス図と要求仕様書をチェックします． Step4 要求仕様書から，あなたが必要と思われるオブジェクトをリ ストアップしてください．次にシーケンス図に表れているオブ ジェクトをリストアップしてください．2つのリストを比較して， 以下の質問に答えてください． 4.1 要求仕様書から得られたオブジェクトが少なくとも一 つのシーケンス図上にありますか？ シーケンス図とユースケース図をチェックします． Step5 ユースケース図の各ユースケースの横に，対応するシーケ ンス図の名前を書いてください．次に，以下の質問に答え なさい． 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 5 CBRの特徴 CBR yes/no形式で答えるのでレビューは容易に行うこ とができ，バグ検出の効率も上げることができる プロダクトの全体を網羅することができるが，レ ビューに費やす時間や負担は大きい チェック項目は過去のバグ情報に基づくことが多く， それまでにないタイプのバグは検出しにくい可能性 がある 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 6 PBRの特徴 PBR 各視点でのレビュー対象がプロダクトの一部に限ら れるので，レビューにかかる時間や負担は少ない 特定の視点で特定の部分に集中してチェックを行 うため，より微細なバグも検出できる 各視点それぞれでのチェックを総合した時に，その 範囲がプロダクトの全体を網羅するように，各視 点（役割）を正確に設定する必要がある 対象となるプロダクトを考慮したシナリオを作成す る必要があるため，その作成にコストがかかる 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 7 関連研究 レビュー手法の比較評価 UML（Unified Modeling Language）で記述さ れた設計仕様書に対するCBR, PBRの比較評 価実験[2] バグの平均検出率，バグ1個あたりの平均検出コ スト（分/バグ）でそれぞれPBRの方が有効であった 実験で用いられたUML図が2種類（クラス図, コラ ボレーション図）のみであったことなどから，より様々 なコンテキストにおいて比較評価を行う必要性が 指摘 [2]O. Laitenberger, C. Atkinson, M. Schlich, K. El Emam. “An experimental comparison of reading techniques for defect detection in UML design documents”, The Journal of Systems and Software, 53:183204, 2000. 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 8 研究の目的 UMLとレビューに関する予備知識を持った学生を対 象とし，より多くの種類のUML図で記述された仕様 書を用いてCBR, PBRの2つの手法でのレビュー実 験を行う バグ検出率，レビュー時間，バグ検出コストについて 両手法の比較評価を行う 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 9 実験概要 被験者 大阪大学情報科学科3年生59人 レビュー対象の仕様書 セミナ情報システム 医療情報システム 人数配分 PBR CBR ユーザ 設計者 プログラマ セミナ情報システム 7 6 6 11 医療情報システム 7 6 6 10 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 10 レビュー対象の仕様書 セミナ情報システム セミナ会社がセミナの企画からセミナの実施，資格の認定 までを行うことを支援するシステム セミナ会社の職員，受講者，講師間の関連，データの処 理及び流れ等について設計 医療情報システム 病院における，患者に対する段階的な処理や業務を支 援するシステム 医者をはじめとするさまざまな担当者や患者間における 関連及びデータ処理について設計 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 11 実験プロセス 入力 出力 CBR 要求仕様書 UML図 - ユースケース図 - クラス図（3） - アクティビティ図（4） - シーケンス図（5） - コンポーネント図（3） チェックリスト（CBR） シナリオ（PBR） UML図 - 検出したバグの該当 場所に印を付けたもの PBR（ユーザ） PBR（設計者） バグ報告書 - 検出バグについて該 当UML図, チェックリス トの項目, 検出時刻等 を記録 PBR（プログラマ） 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 12 ドキュメントについて 各システムのドキュメント数とその割当て ドキュメント数 セミナ情報 システム 医療情報 システム 割当て PBR CBR ユーザ 設計者 プログラマ 要求仕様書 1 1 ユースケース図 1 1 クラス図 1 1 アクティビティ図 8 7 シーケンス図 12 7 コンポーネント図 1 1 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 13 バグについて（1/3） 番号 図 分類 1 クラス図 構文的 クラス間の関連が無い 2 クラス図 意味的 冗長なクラスの存在 3 クラス図 構文的 クラス間の多重度の定義漏れ 4 アクティビティ図 意味的 要求仕様に矛盾した状態の存在 5 アクティビティ図 構文的 状態の名前漏れ 6 アクティビティ図 意味的 状態の順番の違い 7 アクティビティ図 意味的 冗長な状態の存在 2015/10/1 内容 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 14 バグについて（2/3） 8 シーケンス図 意味、関連 必要なオブジェクトが存在していない 9 シーケンス図 意味、関連 矛盾したメソッド呼び出し 10 シーケンス図 構文的 メッセージ名の漏れ 11 シーケンス図 意味的 必要なユースケースが実現されていない 12 シーケンス図 意味的 重複したメソッド呼び出し 13 コンポーネント図 他図との関連 14 コンポーネント図 意味的 必要なコンポーネントが存在しない 15 コンポーネント図 意味的 冗長なコンポーネントの存在 2015/10/1 必要なクラスが存在していない オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 15 バグについて（3/3） PBRにおいては各視点で用いるシナリオによって検出でき るバグ数が異なる 検出 内訳 できる クラス図 アクティビティ図 シーケンス図 コンポーネント図 バグ数 （バグ数3） （バグ数4） （バグ数5） （バグ数3） ユーザ 7 - 4 3 - 設計者 6 3 - 3 - プログラマ 9 3 - 3 3 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 16 バグの例（構文的バグ） 正 2015/10/1 誤 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 17 バグの例（意味的バグ） 問診 問診 診察の案内をした 診察の案内をした 正 受診待ち 受診待ち 誤 患者を呼び出した 問診. 患者を呼び出した 受診 2015/10/1 受診 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 18 バグの例（他の図との関連バグ） : 受講者 : 資格認定証 : 受講者 : 受講者 : 資格 : 資格認定証 : 受講者 資格認定証受取り（） 資格認定証受取り（） 認定内容参照( ) 認定内容参照( ) 資格名参照( ) 正 誤 資格名，受講者コード 資格名，受講者名 資格名 資格名，受講者コード 資格名，受講者名 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 19 収集データ バグ レビュー時間（min） 人数 検出 可能数 平均 発見数 max/min 平均 max/min PBR（ユーザ） 7 7 4.43 6/3 60.43 90 / 46 PBR(設計者） 6 6 5.00 6/4 65.50 80 / 51 PBR(プログラマ） 6 9 6.50 9/5 76.67 95 / 40 CBR 11 15 10.55 13 / 8 74.64 90 / 62 PBR(ユーザ） 7 7 4.43 6/3 48.29 70 / 25 PBR(設計者） 6 6 3.83 5/3 59.17 73 / 30 PBR(プログラマ） 6 9 6.33 7/5 63.30 77 / 44 CBR 10 15 10.50 12 / 8 70.10 94 / 60 セミナ情報システム 医療情報システム 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 20 バグ検出率（手法） CBR (%) PBR 80 70 60 50 全体 ユーザが検出可能なバグ 設計者が検出可能なバグ プログラマが検出可能なバグ 検出率 = （検出バグ数）/（検出可能バグ数） どの項目においても大きな差は見られなかった 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 21 バグ検出率（バグの種類別） バグの種類別 CBR PBR (%) 90 80 70 60 50 構文的バグ 意味的バグ 他図との関連バグ 構文的なバグについてはCBR, 意味的なバグや他の図との関連バグについてはPBR に高い検出率 CBRは広範にチェックする分, 表面的なバグは発見しやすい PBRは範囲が限られる分, より詳細にチェックできる 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 22 バグ検出率（UML図別） UML図別 CBR (%) PBR 90 80 70 60 50 クラス図 アクティビティ図 シーケンス図 コンポーネント図 クラス図についてはCBR, コンポーネント図においてはPBRに高い検出率 クラス図には構文的なバグが多い ⇒ CBRで検出しやすい コンポーネント図には意味的，他の図に関連したバグが多い ⇒ PBRで検出しやすい 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 23 個人データ比較 構文的なバグの検出にはCBR，意味的なバグや他 の図との関連によるバグの検出にはPBRに，それぞ れ有効性が認められた CBRはひとつの図それぞれに対して表面的に項目 に答えていく形式 PBRはシナリオの中で他の図との一貫性や関連を 確認する作業が含まれている 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 24 仮想的チームデータでの分析 被験者で仮想的にチームを作り，バグ検出数， レビュー時間，バグ検出コストについて比較 人数（基準A） CBR：3（人/チーム, 無作為に選ぶ） PBR：3（人/チーム, 各視点から無作為に1人ずつ選ぶ） 検出可能バグ数（基準B） CBR：1（人/チーム） PBR：3（人/チーム, 各視点から無作為に1人ずつ選ぶ） 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 25 チームのグループ化 1グループあたりのチーム数 基準A・・・CBR：3 PBR：6 グループでのバグ検出数、レビュー時間、バグ検出コ ストを算出，比較 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 26 チームのグループ化（図式化） PBR CBR（C1 .. C10） ユーザ 設計者 プログラマ C1 C2 C3 C4 C5 C6 U1 D1 I1 C7 C8 C9 U2 D2 I2 : : U6 D6 I6 （U1.. U7） （D1.. D6） : グループ1 （I1.. I6 ） C1 C2 C3 C4 C5 C6 U1 D1 I6 C7 C8 C10 U2 D2 I1 : : D6 I5 グループ2 : : 2015/10/1 ・ バグ検出数 ・ レビュー時間 ・ バグ検出コスト を比較 : U6 グループ1 グループ2 ： ： ： オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 27 データ算出方法 バグ検出数： 15個のバグについて重複するものを1 つとし，3人の検出数を算出（チームの Bug 1 Bug 2 Bug 3 ・・・ Bug 15 バグ検出数とする） C1 ○ × ○ ・・・ × C2 × × ○ ・・・ × レビュー時間：3人のレビュー時間のうちの最長時間 （チームのレビュー時間とする） C3 ○ ○ ○ ・・・ × Team ○ ○ ○ ・・・ × バグ検出コスト：（チームのレビュー時間）÷（チームの バグ検出数）をチームのバグ検出コ ストとする 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 28 チームデータ比較（1/2） 比較結果 バグ検出数 レビュー時間 バグ検出コスト 基準A CBR PBR CBR 基準B PBR PBR PBR 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 29 チームデータ比較（2/2） 文献[2]の実験ではPBRに有効性 仮想的チームデータでの比較では，どちらの手法が有効であ るかを結論付けることはできず バグ報告について この実験では想定していたバグについてのみ考慮したが，文献[2] の実験では，用意していた以外のバグが報告された場合に，それ が正しければ新たにバグとして追加，分析に反映 → PBRで多く検出していた可能性? 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 30 まとめと今後の課題 まとめ UMLで記述された設計仕様書を対象とし, 2つのレビュー手 法CBRとPBRを用いた評価実験を行った 個人データに関しては、構文的なバグ検出にはCBRに, 意 味的なバグ検出に関してはPBRに有効性が認められた 仮想的チームデータに関しては、どちらの手法が有効である かを決定付けることはできなかった 今後の課題 チームデータのより詳細な分析 仮想的ではなく，実際のチームレビューをした上での評価 準備作業でのコストについて考慮 更なる比較評価実験によるデータ収集 2015/10/1 オブジェクト指向シンポジウム2002 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Technology and Science, Osaka University 31
© Copyright 2024 ExpyDoc
