シナリオを用いたレビュー手法PBRの追証実験 - UMLで記述された設計仕様書を対象として - 松川 文一 井上研究室
背景 ソフトウェアの生産性と品質の向上, 低コスト開発への要求の高まり ソフトウェアレビュー ソフトウェアのプロダクトの内容について, 作成者と他の開発者たちとの間で議論し, プロダクト内のバグを早期発見することを目的とする. これまでに多くの手法が提案されている. Checklist-based Reading(CBR) Scenario-based Reading(SBR) - Perspective-based Reading(PBR) etc… 2019/4/26 特別研究報告会
CBRとPBR（1/2） CBR（Checklist-based Reading） チェックリスト クラス図，状態図，シーケンス図，コンポーネント図に対して，以下の項目についてチェックしてください．チェックした際にバグを見つけた時には， 図上のバグの箇所に印をつけて，バグ調査表に記入してください． CBR（Checklist-based Reading） いくつかのチェック項目を並べたリストを元に, それに対してyes/no形式で答えながらレビューを行う yes/no形式で答えるのでレビューは容易に行うことができる反面,プロダクトの全体を網羅する必要があり, レビューに費やす時間や負担は大きくなってしまう クラス図 1. クラス図と要求仕様書の間に矛盾はありませんか？ yes no 2. 必要なクラス，関連が全て定義されていますか？ 3. 冗長なクラスはありませんか？ 4. 全ての関連について多重度は定義されていますか？ 5. プログラムを書く上で十分な情報が記入されていますか？ 2019/4/26 特別研究報告会
CBRとPBR（2/2） PBR（Perspective-based Reading） チェックリスト（ユーザ） あなたはこのソフトウェアのユーザであると思ってください．あなたの目標は，要求仕様書，ユースケース図，状態図，シーケンス図があなたの要求を満たしているかどうかをチェックすることです．具体的には，ユーザの立場で，状態図とシーケンス図にバグがないかどうかをチェックしてもらいます． チェックは，以下のStep1～Step5に従って行ってください．各Step では指定された設計図を用意して，チェック項目に従って確認してください．バグを発見した時には，図上のバグの箇所に印をつけて，バグ調査表に記入してください． PBR（Perspective-based Reading） プロダクトに関わるいくつかの立場（ユーザ, 設計者, プログラマ等）を設定し, それぞれの異なった視点からレビューを行う 各役割毎に, レビューの順序, 方法, チェック項目等が記されたシナリオを用いる 各役割でのレビュー対象がプロダクトの一部に限られるので, レビューにかかる時間や負担は少ない シーケンス図と要求仕様書をチェックします． 要求仕様書から，あなたが必要と思われるオブジェクトをリストアップしてください．次にシーケンス図に表れているオブジェクトをリストアップしてください．2つのリストを比較して，以下の質問に答えてください． 要求仕様書から得られたオブジェクトが少なくとも一つのシーケンス図上にありますか？ シーケンス図とユースケース図をチェックします． ユースケース図の各ユースケースの横に，対応するシーケンス図の名前を書いてください．次に，以下の質問に答えなさい． Step4 4.1 Step5 2019/4/26 特別研究報告会
関連研究 レビュー手法の比較評価 オブジェクト指向設計で用いられる開発言語UML(Unified Modeling Language)で記述された設計仕様書に対する2つのレビュー手法(CBR, PBR)の比較評価実験[1] 実験で用いられたUML図は2種類（クラス図, コラボレーション図）であったため, 様々なコンテキストに対して比較評価を行う必要がある. [1]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:183-204, 2000. 2019/4/26 特別研究報告会
目的 より多くの種類のUML図に対してCBR, PBRの2つの手法での比較評価実験を行う 2019/4/26 特別研究報告会
評価実験（1/2） 被験者 レビュー対象システム 情報科学科3年生59人 セミナ情報システム 医療情報システム 7 6 11 10 PBR CBR ユーザ 設計者 プログラマ セミナ情報システム 7 6 11 医療情報システム 10 2019/4/26 特別研究報告会
評価実験（2/2） 入力 要求仕様書 UML図 チェックリスト（シナリオ） 出力 UML図 バグ報告書 - ユースケース図 - クラス図（バグ数3） - ステートチャート図 （バグ数4） - シーケンス図（バグ数5） - コンポーネント図 （バグ数3） チェックリスト（シナリオ） 出力 UML図 - 検出したバグの該当場所に印を付けたもの バグ報告書 - 検出バグについて該当UML図, チェックリストの項目, 検出時刻等を記録 CBR PBR（ユーザ） PBR（ユーザ） PBR（設計者） PBR（プログラマ） 2019/4/26 特別研究報告会
収集データ 人数 バグ 時間 ( 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/4/26 特別研究報告会
バグ検出率 検出率 = （検出バグ数）/（検出可能バグ数） どの項目においても大きな差は見られなかった (%) 2019/4/26 特別研究報告会
バグ検出率（バグの種類別） CBRは広くチェックする分, 表面的なバグは発見しやすい PBRは範囲が限られる分, より深くチェックできる (%) 構文的なバグについてはCBR, 意味的なバグや他の図との関連バグについてはPBRに高い検出率 CBRは広くチェックする分, 表面的なバグは発見しやすい PBRは範囲が限られる分, より深くチェックできる 2019/4/26 特別研究報告会
バグ検出率（UML図別） クラス図には構文的なバグが多い ⇒ CBRで検出しやすい (%) クラス図についてはCBR, その他の図においてはPBRに高い検出率 クラス図には構文的なバグが多い ⇒ CBRで検出しやすい コンポーネント図には他の図に関連したバグが多い ⇒ PBRで検出しやすい 2019/4/26 特別研究報告会
チーム間の比較 一般的にレビューは複数の人数（チーム）で行う 被験者で仮想的にチームを作り, バグ検出数について比較を行った 検出可能バグ数 CBR - 1（人/チーム） PBR - 3（人/チーム, 各役割から無作為に一人ずつ選ぶ） ⇒PBRに有効性 人数 CBR - 3（人/チーム, 無作為に選ぶ） ⇒CBRに有効性 2019/4/26 特別研究報告会
まとめと今後の課題 まとめ 今後の課題 UMLで記述された設計仕様書を対象とし, 2つのレビュー手法CBRとPBRを用いた評価実験を行った チーム間でのより詳細な比較分析 更なる追証実験によるデータ収集 2019/4/26 特別研究報告会
2019/4/26 特別研究報告会
バグについて（1） 番号 図 内容 1 クラス図 クラス間の関連が無い 2 冗長なクラスの存在 3 クラス間の多重度の定義漏れ 4 状態図 要求仕様に矛盾した状態の存在 5 状態の名前漏れ 6 状態の順番の違い 7 冗長な状態の存在 2019/4/26 特別研究報告会
バグについて（2） 8 シーケンス図 必要なオブジェクトが存在していない 9 矛盾したメソッド呼び出し 10 メッセージ名の漏れ 11 必要なユースケースが実現されていない 12 重複したメソッド呼び出し 13 コンポーネント図 必要なクラスが存在していない 14 必要なコンポーネントが存在しない 15 冗長なコンポーネントの存在 2019/4/26 特別研究報告会
チームの組み合わせについて PBR CBR 7P6 × 6! × 6! U1 D1 I1 U2 D2 I2 C1 : : : C2 ユーザ 設計者 プログラマ (U1.. U7) (D1.. D6) (I1.. I6) PBR CBR U1 D1 I1 U2 D2 I2 : : : U6 D6 I6 グループ1 C1 C2 : C10 U1 D1 I6 U2 D2 I1 : : : U6 D6 I5 母平均の差の検定 グループ2 ： 総比較回数 7P6 × 6! × 6! = 3,628,000 グループ1 2019/4/26 特別研究報告会