Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile Inspection Workshop

Agile Inspection Workshop

アジャイル・インスペクションのワークショップ
ソフトウェアドキュメントを、サンプリングして、レビューを行い、そのフィードバックをするというループをイテレーティブに行うレビュー手法。定量的に評価しながら、ドキュメントの書き手とドキュメントの品質をアジャイルに改善していく。

Atsushi Nagata

May 27, 2022
Tweet

More Decks by Atsushi Nagata

Other Decks in Technology

Transcript

  1. Copy Right ©永田 敦 2011
    永田 敦 2013年7月11日
    2013/07/11
    1
    Agile Inspection Workshop

    View Slide

  2. Copy Right ©永田 敦 2011
    INTRODUCTION
     ソニー株式会社 永田 敦
    ソフトウェアテストプロセス改善
    SQiP研究会 第三分科会 副主査
    SQiPシンポジウム運営委員
    派生開発推進委員会運営委員
    JSTQB Advanced Level Manager
    2
    2013/07/11

    View Slide

  3. Copy Right ©永田 敦 2011
    レビューの目的
    2013/07/11
    3
    ドキュメントの欠陥を発見する
    より多く

    View Slide

  4. Copy Right ©永田 敦 2011
    誤り,欠陥,故障
    2013/07/11
    4
    知識 行為
    正しくな
    い記述
    望ましくない
    結果
    業務知識
    分野知識
    各種標準など
    文書化
    コード化
    試験・運用
    文書
    コード
    手戻り
    システム障害
    誤り(Error)
    欠陥(Defect) 故障(Failure)
    http://www.bcm.co.jp/index.html: 山本修一郎 要求工学 要求レビュ より

    View Slide

  5. Copy Right ©永田 敦 2011
    2013/07/11
    5
    どこまでやったら
    すべての欠陥を取り除いた
    と言えますか?

    View Slide

  6. Copy Right ©永田 敦 2011
    課題:
    2013/07/11
    6
    対象ドキュメントの欠陥を
    網羅的に抽出することが
    できているだろうか

    View Slide

  7. Copy Right ©永田 敦 2011
    課題:
    2013/07/11
    7
    欠陥を完全に
    ゼロ
    にすることはできない
    対象ドキュメントの欠陥を網羅的に
    抽出することができているだろうか

    View Slide

  8. Copy Right ©永田 敦 2011
    課題:
    2013/07/11
    8
    欠陥を完全にゼロにすることはできない
    ドメイン知識,技術力,経験,文書分析力
    観点 : 開発設計者,テストエンジニア,営業,保守
    左右する要素
    対象ドキュメントの欠陥を網羅的に抽出することができているだろうか

    View Slide

  9. Copy Right ©永田 敦 2011
    2013/07/11
    9
    ドキュメントの欠陥とは?

    View Slide

  10. Copy Right ©永田 敦 2011
    要求仕様書の品質
    (IEEE 830-1998)
    正当性
    非曖昧性
    完全性
    一貫性
    検証可能性
    2013/07/11
    10

    View Slide

  11. Copy Right ©永田 敦 2011
    課題:
    2013/07/11
    11
    欠陥を完全にゼロにすることはできない
    対象ドキュメントの欠陥を網羅的に
    抽出することができているだろうか
    でも,致命的な,重要は欠陥は除きたい

    View Slide

  12. Copy Right ©永田 敦 2011
    2013/07/11
    12
    よし,レビューをやっていこう

    View Slide

  13. Copy Right ©永田 敦 2011
    FAULT DENSITY VERSUS CHECKING RATE:
    RAYTHEON 95
    Over 1,000 Statements
    Checked per hour
    by a single checker
    Defects
    Found/Kdsi
    Real Optimum
    Checking Rate
    Too-quick reviews
    and inspections will
    not find the defects
    early, thus creating
    lots of work for
    testers later.
    13
    2013/07/11

    View Slide

  14. Copy Right ©永田 敦 2011
    2013/07/11
    14
    レビューの場合の欠陥予防 ?

    View Slide

  15. Copy Right ©永田 敦 2011
     JUSE, Tokyo 2008
     Keynote 90 minutes with
    Consecutive
     Translation (45 minutes effectively)
     Tom Gilb
     kyoritsu-pub.co.jp [email protected]
    • Gilb and Graham, Software Inspection (1993):
    • Japanese Edition
    Tom Gilb
    kyoritsu-pub.co.jp
    15
    AGILE INSPECTIONS:
    Reviews by
    sampling and measuring defects

    View Slide

  16. Copy Right ©永田 敦 2011
    インスペクションの目的
    2013/07/11
    16
    高品質のドキュメントを
    はじめから生産すること

    View Slide

  17. Copy Right ©永田 敦 2011
    AGILE INSPECTION PRINCIPLE 1
    The Prevent –
    Do not Clean Principle
     リビューの目的を、
    欠陥を取り除き修正する
    2013/07/11
    17
    Engineer Your Review Process : Tom Gilb 2008
    “初めからよいものを書いてもらうように”
    ドキュメントの書き方の品質を改善してもらう

    View Slide

  18. Copy Right ©永田 敦 2011
    アジャイルインスペクションプロセス
    2013/07/11
    18
    インスペクション
    ロギング
    サンプリング
    修正
    次のフェーズ
    EXIT
    No EXIT
    Agile Inspection
    Iteration
    ENTRY

    View Slide

  19. Copy Right ©永田 敦 2011
    アジャイルインスペクションのプロセス
    1. インスペクタ(チェッカー)を決める
    2. ルール(インスペクションの観点)を決める
    3. 欠陥密度の閾値を決める
    4. 実施時間を決める
    5. ドキュメントをサンプリングする
    6. インスペクタにルールなどの説明をする
    7. サンプルをインスペクションする( 約10分から30分)
    8. ログをとる
    8. メトリクスを分析する
    9. 欠陥密度が閾値より低い場合,次のプロセスに進む
    10. 欠陥密度が閾値より高い場合,ドキュメントの質の
    改善のために差し戻す
    2013/07/11
    19









    View Slide

  20. Copy Right ©永田 敦 2011
    ケーススタディー:計画
    Inspection ID Display1 Inspection Leader 永田 敦
    Author XXXXXXX Date Inspection requested:
    Product xxxxx No.Pages 11 Status
    Entry Criteria with Apply
    Current Entry Status No Exit
    Entry Criteria with Apply 10Unique defects/LP
    Documents
    ドキュメント ソフトウェア要求仕様書 ページ数 11ページ
    イテレーション 時間 人数 プロファイル サンプリング
    1st 1時間 8 設計,設計内評価 2種類
    2nd 1時間 13 設計,設計内評価,SQA 2種類
    3rd 1時間 9 設計,設計内評価,SQA 2種類
    ルール イテレーションの内訳
    非曖昧性 ガイド 20分
    明確性 チェッキング 20分
    非矛盾性 ロギング 20分
    設計表現なし
    その他
    2013/07/11
    20

    View Slide

  21. Copy Right ©永田 敦 2011
    「箱の上端×四分位範囲×1.5」
    の範囲で一番大きいデータ
    75%点 (第3四分位点)
    中央値 50%点 (第2四分位点)
    25%点 (第1四分位点)
    「箱の下端×四分位範囲×1.5」
    の範囲で一番小さいデータ
    欠陥密度の変化
    2013/07/11
    21

    View Slide

  22. Copy Right ©永田 敦 2011
    ルール
     3つから7つぐらいのルール
     例

    曖昧ではないか?

    明確か?

    矛盾はないか?

    テスト可能か?

    設計要素がないか(要求仕様におい
    て)
    2013/07/11
    22

    View Slide

  23. Copy Right ©永田 敦 2011
    ルール:曖昧
    絶対ドラゴンズに
    勝ってほしい
    僕はウナギだ
    2013/07/11
    23

    View Slide

  24. Copy Right ©永田 敦 2011
    ルール:曖昧
    子供が好きなおばさんが
    来た
    太郎は自転車で逃げた花
    子を追いかけた
    父は弟に自分の部屋で勉
    強させた
    2013/07/11
    24

    View Slide

  25. Copy Right ©永田 敦 2011
    ルール:曖昧
    多義文
    2013/07/11
    25

    View Slide

  26. Copy Right ©永田 敦 2011
    ルール:曖昧
    全部網羅しなくても合
    格とする
    テストケースは全部でき
    なかった
    全部+否定語
    2013/07/11
    26

    View Slide

  27. Copy Right ©永田 敦 2011
    ルール:曖昧
    AまたはBでないとき
    Cである
    2013/07/11
    27

    View Slide

  28. Copy Right ©永田 敦 2011
    ルール:曖昧 6
    「入力項目は生年月日と
    氏名あるいはカタカナで
    す」
    2013/07/11
    28

    View Slide

  29. Copy Right ©永田 敦 2011
    ルール:不明確 7
    データの輻輳に注意して…
    応答をいつまで待っても来
    なかったときは…
    できるだけ早く応答を返す
    「以上」「以下」「同じ」
    2013/07/11
    29

    View Slide

  30. Copy Right ©永田 敦 2011
    ルール:矛盾
    設定された閾値(表 3-3)で検出し
    た個数が16個以下ならすべて追加。
    16個以上なら異常状態として追加
    しない。
    2013/07/11
    30

    View Slide

  31. Copy Right ©永田 敦 2011
    ルール:設計要素
    要求仕様書では欠陥となる
     ATM
     金の引き出しにおいて,引き出し口が開いてから1分以内に貨幣
    を取らないと引き出し口は閉じる
     タイムアウトの1分は内部のタイマーICにより正確に測る
     ログインアカウント
     ユーザー名とパスワードを正しく入れたらアカウントにログインする
    ことができる.
    パラメータの指定だけでは設計問題ではないこともある
    2013/07/11
    31

    View Slide

  32. Copy Right ©永田 敦 2011
    重要(MAJOR)な欠陥
    曖昧性,不明確性,矛盾性を持っ

    ドキュメント(仕様書)の表現により
    そのあとの設計,コーディングで
    エラーを起こして埋め込まれた,
    お客様に影響のある
    故障を発生するリスクをもつ欠陥.
    2013/07/11
    32

    View Slide

  33. Copy Right ©永田 敦 2011
    インスペクション
     Agile Inspection Workshop
    やってみましょう
    どのくらい、欠陥があるか 体験してみましょう
     ルール 対象 要求仕様書
     あいまいでないこと
     明解であること
     矛盾のないこと
     設計要素がないこと
     1ページ分15分かけてチェックしましょう
    2013/07/11
    33

    View Slide

  34. Copy Right ©永田 敦 2011
    アジャイルインスペクションプロセス
    2013/07/11
    34
    インスペクション
    ロギング
    サンプリング
    修正
    次のフェーズ
    EXIT
    No EXIT
    Agile Inspection
    Iteration
    ENTRY

    View Slide

  35. Copy Right ©永田 敦 2011
    チェッカーのメンバーと欠陥密度との関係(2)
    2013/07/11
    35
    y = 3.0035x
    R² = 0.9836
    0
    5
    10
    15
    20
    25
    0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0
    ユニークな欠陥数/論理ページ
    欠陥数の平均値/論理ページ
    共通のメンバーにおけるユニークな欠陥密度と欠陥密度の関係
     チェッカーの人選を初めから適切にすること
     イテレーションではできるだけチェッカーを変えないこと

    View Slide

  36. Copy Right ©永田 敦 2011
    ロギング
    2013/07/11
    36
    指摘して,
    書き手に直してもらえなかったこと
    ありませんか?

    View Slide

  37. Copy Right ©永田 敦 2011
    2013/07/11
    37
    ドキュメントを書く人の
    "質"を上げていく

    View Slide

  38. Copy Right ©永田 敦 2011
    2013/07/11
    38
    どうやったら,
    ドキュメントを書く人の
    "質"があがるのか?

    View Slide

  39. Copy Right ©永田 敦 2011
    2013/07/11
    39
    書き手は
    欠陥と認めてますか?
    認識してますか?

    View Slide

  40. Copy Right ©永田 敦 2011
    2013/07/11
    40
    欠陥だという気付きを
    与えていますか?

    View Slide

  41. Copy Right ©永田 敦 2011
    2013/07/11
    41
    どうやったら
    欠陥だと気付いて
    もらえるでしょうか?

    View Slide

  42. Copy Right ©永田 敦 2011
    2013/07/11
    42
    フィードバックは
    コミュニケーション

    View Slide

  43. Copy Right ©永田 敦 2011
    2013/07/11
    43
    Respect & Influence

    View Slide

  44. Copy Right ©永田 敦 2011
    2013/07/11
    44
    それでは,
    フィードバックを
    書いてみましょう

    View Slide

  45. Copy Right ©永田 敦 2011
    2013/07/11
    45
    曖昧性は,
    ステークホルダのスコープによって変わる
    ドメイン知識
    暗黙知
    現実世界の環境

    View Slide

  46. Copy Right ©永田 敦 2011
    欠陥密度の変化
    2013/07/11
    46
    「箱の上端×四分位範囲×1.5」
    の範囲で一番大きいデータ
    75%点 (第3四分位点)
    中央値 50%点 (第2四分位点)
    25%点 (第1四分位点)
    「箱の下端×四分位範囲×1.5」
    の範囲で一番小さいデータ

    View Slide

  47. Copy Right ©永田 敦 2011
    AGILE INSPECTION POLICY
    REVIEW EARLY
     リビューは早いうちにできているところからやる。
    2013/07/11
    47
    全部そろうまで
    待つ
    Engineer Your Review Process : Tom Gilb 2008

    View Slide

  48. Copy Right ©永田 敦 2011
    インクリメンタル・レビュー
     最初の1ページを書いたところから始める
     ドキュメントの作成スケジュールに従い,定期的,
    計画的にアジャイルインスペクションを実施する
     イテレーティブな実施によりドキュメントの品質を
    上げていく
     書き手ごとに別のイテレーションを回す
    2013/07/11
    48

    View Slide

  49. Copy Right ©永田 敦 2011
    インクリメンタル・レビュー
    2013/07/11
    49
    百ページのSRS
    バッチ的レビュー
    インクリメンタルなレビュー
    初めの1ページからレビューを始めてしまう

    View Slide

  50. Copy Right ©永田 敦 2011
    まとめ
     レビューの目的
     ドキュメントの品質を
    改善してゆくことです.
    2013/07/11
    50

    View Slide

  51. Copy Right ©永田 敦 2011
    ご清聴ありがとうございます.
    2013/07/11
    51

    View Slide

  52. Copy Right ©永田 敦 2011
    FORMAL INSPECTION
     IBM Faganが発案
     5つのrole

    Moderator

    Author

    Reader

    Recorder

    Inspector
     6つのプロセス

    Planning

    Overview meeting

    Preparation

    Inspection meeting

    Rework

    Follow-up
    2013/07/11
    52

    View Slide

  53. Copy Right ©永田 敦 2011
    INSPECTION PROCES
    2013/07/11
    53
    Step Description
    Planning Confirms material to be inspected meets entry criteria. Arranges
    the availability of appropriate participants. Schedules a meeting
    place and time.
    Overview Educates group of participants in what is to be inspected. Assigns
    inspection roles to participants.
    Preparation Participants separately learn the material and find potential
    defects
    Inspection
    Meeting
    Identified defects are agreed on by the group and classified
    Rework The author corrects all defects
    Follow-up The moderator or the entire team verifies that all fixes are
    effective and that no additional defects have been introduced

    View Slide