Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Copy Right ©永田 敦 2011 ルール  3つから7つぐらいのルール  例  曖昧ではないか?  明確か?  矛盾はないか?  テスト可能か?  設計要素がないか(要求仕様におい て) 2013/07/11 22

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Copy Right ©永田 敦 2011 重要(MAJOR)な欠陥 曖昧性,不明確性,矛盾性を持っ た ドキュメント(仕様書)の表現により そのあとの設計,コーディングで エラーを起こして埋め込まれた, お客様に影響のある 故障を発生するリスクをもつ欠陥. 2013/07/11 32

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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 ユニークな欠陥数/論理ページ 欠陥数の平均値/論理ページ 共通のメンバーにおけるユニークな欠陥密度と欠陥密度の関係  チェッカーの人選を初めから適切にすること  イテレーションではできるだけチェッカーを変えないこと

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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