UMLで記述された設計仕様書を対象とした レビュー手法CBRとPBRの比較評価実験

Presentation on theme: "UMLで記述された設計仕様書を対象とした レビュー手法CBRとPBRの比較評価実験"— Presentation transcript:

1 UMLで記述された設計仕様書を対象とした レビュー手法CBRとPBRの比較評価実験
大阪大学大学院情報科学研究科 松川　文一　　Giedre Sabaliauskaite 楠本　真二　　井上　克郎

2 発表内容 研究の背景 実験に用いたレビュー手法について 研究の目的 評価実験 まとめと今後の課題
CBR（Checklist-based Reading） PBR（Perspective-based Reading） 研究の目的 評価実験 実験概要 データ分析 まとめと今後の課題 2019/2/21 オブジェクト指向シンポジウム2002

3 研究の背景 ソフトウェアレビュー レビューのプロセス[1]
ソフトウェアのプロダクトの内容について，作成者と他の開発者たちとの間で議論し，プロダクト内のバグを早期発見，修正することを目的とする レビューのプロセス[1] 始動 個人チェック グループチェック 完了 プロセス改善 Checklist-based Reading（CBR） Perspective-based Reading（PBR） [1] T. Gilb, D.Graham, 伊土 誠一, 富野 壽[監訳], “ソフトウェアインスペクション”, 共立出版, 1999. 2019/2/21 オブジェクト指向シンポジウム2002

4 CBR CBR（Checklist-based Reading）
いくつかのチェック項目を並べたリストを元に，それに対してyes/no形式で答えながらレビューを行う 項目は基本的にチェックを行う場所，バグ発見の指針となる問題点のリストからなる チェックリスト 　クラス図，アクティビティ図，シーケンス図，コンポーネント図に対して，以下の項目についてチェックしてください．チェックした際にバグを見つけた時には， 図上のバグの箇所に印をつけて，バグ調査表に記入してください．  クラス図 1. クラス図と要求仕様書の間に矛盾はありませんか？  yes  no 2. 必要なクラス，関連が全て定義されていますか？ 3. 冗長なクラスはありませんか？ 4. 全ての関連について多重度は定義されていますか？ 5. プログラムを書く上で十分な情報が記入されていますか？ 2019/2/21 オブジェクト指向シンポジウム2002

5 PBR PBR（Perspective-based Reading）
チェックリスト（ユーザ） 　あなたはこのソフトウェアのユーザであると思ってください．あなたの目標は，要求仕様書，ユースケース図，アクティビティ図，シーケンス図があなたの要求を満たしているかどうかをチェックすることです．具体的には，ユーザの立場で，アクティビティ図とシーケンス図にバグがないかどうかをチェックしてもらいます． 　チェックは，以下のStep1～Step5に従って行ってください．各Step では指定された設計図を用意して，チェック項目に従って確認してください．バグを発見した時には，図上のバグの箇所に印をつけて，バグ調査表に記入してください． PBR（Perspective-based　Reading） プロダクトに関わるいくつかの立場（ユーザ, 設計者，等）を設定し, それぞれの異なった視点からレビューを行う 各視点毎に作成されたシナリオを用いる シナリオにはレビュー順序，作業, チェック項目等が記されている シーケンス図と要求仕様書をチェックします． 要求仕様書から，あなたが必要と思われるオブジェクトをリストアップしてください．次にシーケンス図に表れているオブジェクトをリストアップしてください．2つのリストを比較して，以下の質問に答えてください． 要求仕様書から得られたオブジェクトが少なくとも一つのシーケンス図上にありますか？ シーケンス図とユースケース図をチェックします． ユースケース図の各ユースケースの横に，対応するシーケンス図の名前を書いてください．次に，以下の質問に答えなさい． Step4 4.1 Step5 2019/2/21 オブジェクト指向シンポジウム2002

6 CBRの特徴 CBR yes/no形式で答えるのでレビューは容易に行うことができ，バグ検出の効率も上げることができる
プロダクトの全体を網羅することができるが，レビューに費やす時間や負担は大きい チェック項目は過去のバグ情報に基づくことが多く，それまでにないタイプのバグは検出しにくい可能性がある 2019/2/21 オブジェクト指向シンポジウム2002

7 PBRの特徴 PBR 各視点でのレビュー対象がプロダクトの一部に限られるので，レビューにかかる時間や負担は少ない
特定の視点で特定の部分に集中してチェックを行うため，より微細なバグも検出できる 各視点それぞれでのチェックを総合した時に，その範囲がプロダクトの全体を網羅するように，各視点（役割）を正確に設定する必要がある 対象となるプロダクトを考慮したシナリオを作成する必要があるため，その作成にコストがかかる 2019/2/21 オブジェクト指向シンポジウム2002

8 関連研究 レビュー手法の比較評価 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: , 2000. 2019/2/21 オブジェクト指向シンポジウム2002

9 研究の目的 UMLとレビューに関する予備知識を持った学生を対象とし，より多くの種類のUML図で記述された仕様書を用いてCBR, PBRの2つの手法でのレビュー実験を行う バグ検出率，レビュー時間，バグ検出コストについて両手法の比較評価を行う 2019/2/21 オブジェクト指向シンポジウム2002

10 実験概要 被験者 レビュー対象の仕様書 人数配分 大阪大学情報科学科3年生59人 セミナ情報システム 医療情報システム 7 6 11 10
PBR CBR ユーザ 設計者 プログラマ セミナ情報システム 7 6 11 医療情報システム 10 2019/2/21 オブジェクト指向シンポジウム2002

11 レビュー対象の仕様書 セミナ情報システム 医療情報システム
セミナ会社がセミナの企画からセミナの実施，資格の認定までを行うことを支援するシステム セミナ会社の職員，受講者，講師間の関連，データの処理及び流れ等について設計 医療情報システム 病院における，患者に対する段階的な処理や業務を支援するシステム 医者をはじめとするさまざまな担当者や患者間における関連及びデータ処理について設計 2019/2/21 オブジェクト指向シンポジウム2002

12 実験プロセス 入力 要求仕様書 UML図 チェックリスト（CBR） シナリオ（PBR） 出力 UML図 バグ報告書
- ユースケース図 - クラス図（3） - アクティビティ図（4） - シーケンス図（5） - コンポーネント図（3） チェックリスト（CBR） シナリオ（PBR） 出力 UML図 - 検出したバグの該当場所に印を付けたもの バグ報告書 - 検出バグについて該当UML図, チェックリストの項目, 検出時刻等を記録 CBR PBR（ユーザ） PBR（ユーザ） PBR（設計者） PBR（プログラマ） 2019/2/21 オブジェクト指向シンポジウム2002

13 ドキュメントについて 各システムのドキュメント数とその割当て ドキュメント数 割当て 1  8 7 12 セミナ情報システム
医療情報システム CBR PBR ユーザ 設計者 プログラマ 要求仕様書 1  ユースケース図 クラス図 アクティビティ図 8 7 シーケンス図 12 コンポーネント図 2019/2/21 オブジェクト指向シンポジウム2002

14 バグについて（1/3） 番号 図 分類 内容 1 クラス図 構文的 クラス間の関連が無い 2 意味的 冗長なクラスの存在 3
クラス間の多重度の定義漏れ 4 アクティビティ図 要求仕様に矛盾した状態の存在 5 状態の名前漏れ 6 状態の順番の違い 7 冗長な状態の存在 2019/2/21 オブジェクト指向シンポジウム2002

15 バグについて（2/3） 8 シーケンス図 意味、関連 必要なオブジェクトが存在していない 9 矛盾したメソッド呼び出し 10 構文的
メッセージ名の漏れ 11 意味的 必要なユースケースが実現されていない 12 重複したメソッド呼び出し 13 コンポーネント図 他図との関連 必要なクラスが存在していない 14 必要なコンポーネントが存在しない 15 冗長なコンポーネントの存在 2019/2/21 オブジェクト指向シンポジウム2002

16 バグについて（3/3） PBRにおいては各視点で用いるシナリオによって検出できるバグ数が異なる 内訳 7 - 4 3 6 9 検出 できる
クラス図 （バグ数3） アクティビティ図 （バグ数4） シーケンス図 （バグ数5） コンポーネント図 ユーザ 7 - 4 3 設計者 6 プログラマ 9 2019/2/21 オブジェクト指向シンポジウム2002

17 バグの例（構文的バグ） 正 誤 2019/2/21 オブジェクト指向シンポジウム2002

18 バグの例（意味的バグ） 誤 正 2019/2/21 オブジェクト指向シンポジウム2002

19 バグの例（他の図との関連バグ） 誤 正 2019/2/21 オブジェクト指向シンポジウム2002

20 収集データ 人数 バグ レビュー時間（min） 検出 可能数 平均 発見数 max/min セミナ情報システム PBR（ユーザ） 7
4.43 6 / 3 60.43 90 / 46 PBR(設計者） 6 5.00 6 / 4 65.50 80 / 51 PBR(プログラマ） 9 6.50 9 / 5 76.67 95 / 40 CBR 11 15 10.55 13 / 8 74.64 90 / 62 医療情報システム PBR(ユーザ） 48.29 70 / 25 3.83 5 / 3 59.17 73 / 30 6.33 7 / 5 63.30 77 / 44 10 10.50 12 / 8 70.10 94 / 60 2019/2/21 オブジェクト指向シンポジウム2002

21 バグ検出率（手法） 検出率 = （検出バグ数）/（検出可能バグ数） どの項目においても大きな差は見られなかった (%) 2019/2/21
オブジェクト指向シンポジウム2002

22 バグ検出率（バグの種類別） 構文的なバグについてはCBR, 意味的なバグや他の図との関連バグについてはPBRに高い検出率
(%) 構文的なバグについてはCBR, 意味的なバグや他の図との関連バグについてはPBRに高い検出率 　CBRは広範にチェックする分, 表面的なバグは発見しやすい 　PBRは範囲が限られる分, より詳細にチェックできる 2019/2/21 オブジェクト指向シンポジウム2002

23 バグ検出率（UML図別） クラス図についてはCBR, コンポーネント図においてはPBRに高い検出率
(%) クラス図についてはCBR, コンポーネント図においてはPBRに高い検出率 　クラス図には構文的なバグが多い　⇒　CBRで検出しやすい 　コンポーネント図には意味的，他の図に関連したバグが多い　⇒　PBRで検出しやすい 2019/2/21 オブジェクト指向シンポジウム2002

24 個人データ比較 構文的なバグの検出にはCBR，意味的なバグや他の図との関連によるバグの検出にはPBRに，それぞれ有効性が認められた
2019/2/21 オブジェクト指向シンポジウム2002

25 仮想的チームデータでの分析 被験者で仮想的にチームを作り，バグ検出数，レビュー時間，バグ検出コストについて比較 人数（基準A）
CBR：3（人/チーム, 無作為に選ぶ） PBR：3（人/チーム, 各視点から無作為に1人ずつ選ぶ） 検出可能バグ数（基準B） CBR：1（人/チーム） 2019/2/21 オブジェクト指向シンポジウム2002

26 チームのグループ化 1グループあたりのチーム数 グループでのバグ検出数、レビュー時間、バグ検出コストを算出，比較 基準A・・・CBR：3
PBR：6 グループでのバグ検出数、レビュー時間、バグ検出コストを算出，比較 2019/2/21 オブジェクト指向シンポジウム2002

27 チームのグループ化（図式化） PBR CBR（C1 .. C10） C1 C2 C3 C4 C5 C6 C7 C8 C9 U1 D1 I1
ユーザ　　 設計者　　プログラマ （U1.. U7） （D1.. D6） （I1.. I6 ） C1 C2 C3 C4 C5 C6 C7 C8 C9 U1 D1 I1 U2 D2 I2 : : : U6 D6 I6 グループ1 グループ1 C1 C2 C3 C4 C5 C6 C7 C8 C10 U1 D1 I6 U2 D2 I1 : : : U6 D6 I5 グループ2 ： ・ バグ検出数 ・ レビュー時間 ・ バグ検出コスト を比較 グループ2 : 2019/2/21 オブジェクト指向シンポジウム2002

28 データ算出方法 バグ検出数： 15個のバグについて重複するものを1 つとし，3人の検出数を算出（チームの バグ検出数とする）
バグ検出数： 15個のバグについて重複するものを つとし，3人の検出数を算出（チームの バグ検出数とする） レビュー時間：3人のレビュー時間のうちの最長時間 （チームのレビュー時間とする） バグ検出コスト：（チームのレビュー時間）÷（チームの バグ検出数）をチームのバグ検出コ ストとする Bug 1 Bug 2 Bug 3 ・・・ Bug 15 C1 ○ × C2 C3 Team 2019/2/21 オブジェクト指向シンポジウム2002

29 チームデータ比較（1/2） 比較結果 基準A CBR PBR 基準B バグ検出数 レビュー時間 バグ検出コスト 2019/2/21
オブジェクト指向シンポジウム2002

30 チームデータ比較（2/2） 文献[2]の実験ではPBRに有効性
仮想的チームデータでの比較では，どちらの手法が有効であるかを結論付けることはできず バグ報告について この実験では想定していたバグについてのみ考慮したが，文献[2] の実験では，用意していた以外のバグが報告された場合に，それ が正しければ新たにバグとして追加，分析に反映 →　PBRで多く検出していた可能性? 2019/2/21 オブジェクト指向シンポジウム2002

31 まとめと今後の課題 まとめ 今後の課題 UMLで記述された設計仕様書を対象とし, 2つのレビュー手法CBRとPBRを用いた評価実験を行った
仮想的チームデータに関しては、どちらの手法が有効であるかを決定付けることはできなかった 今後の課題 チームデータのより詳細な分析 仮想的ではなく，実際のチームレビューをした上での評価 準備作業でのコストについて考慮 更なる比較評価実験によるデータ収集 2019/2/21 オブジェクト指向シンポジウム2002