Agile Inspection Workshop
0 likes93 views
アジャイル・インスペクションのワークショップ ソフトウェアドキュメントを、サンプリングして、レビューを行い、そのフィードバックをするというループをイテレーティブに行うレビュー手法。定量的に評価しながら、ドキュメントの書き手とドキュメントの品質をアジャイルに改善していく。
Agile Inspection Workshop
- 1. Copy Right ©永田 敦 2011 永田 敦 2013年7月11日 2013/07/11 1 Agile Inspection Workshop
- 2. Copy Right ©永田 敦 2011 INTRODUCTION ソニー株式会社 永田 敦 ソフトウェアテストプロセス改善 SQiP研究会 第三分科会 副主査 SQiPシンポジウム運営委員 派生開発推進委員会運営委員 JSTQB Advanced Level Manager 2 2013/07/11
- 3. Copy Right ©永田 敦 2011 レビューの目的 2013/07/11 3 ドキュメントの欠陥を発見する より多く
- 4. Copy Right ©永田 敦 2011 誤り，欠陥，故障 2013/07/11 4 知識 行為 正しくな い記述 望ましくない 結果 業務知識 分野知識 各種標準など 文書化 コード化 試験・運用 文書 コード 手戻り システム障害 誤り（Ｅｒｒｏｒ） 欠陥（Defect) 故障（Ｆａｉｌｕｒｅ） http://www.bcm.co.jp/index.html: 山本修一郎 要求工学 要求レビュ より
- 5. Copy Right ©永田 敦 2011 2013/07/11 5 どこまでやったら すべての欠陥を取り除いた と言えますか？
- 6. Copy Right ©永田 敦 2011 課題： 2013/07/11 6 対象ドキュメントの欠陥を 網羅的に抽出することが できているだろうか
- 7. Copy Right ©永田 敦 2011 課題： 2013/07/11 7 欠陥を完全に ゼロ にすることはできない 対象ドキュメントの欠陥を網羅的に 抽出することができているだろうか
- 8. Copy Right ©永田 敦 2011 課題： 2013/07/11 8 欠陥を完全にゼロにすることはできない ドメイン知識，技術力，経験，文書分析力 観点 ： 開発設計者，テストエンジニア，営業，保守 左右する要素 対象ドキュメントの欠陥を網羅的に抽出することができているだろうか
- 9. Copy Right ©永田 敦 2011 2013/07/11 9 ドキュメントの欠陥とは？
- 10. Copy Right ©永田 敦 2011 要求仕様書の品質 (IEEE 830-1998) 正当性 非曖昧性 完全性 一貫性 検証可能性 2013/07/11 10
- 11. Copy Right ©永田 敦 2011 課題： 2013/07/11 11 欠陥を完全にゼロにすることはできない 対象ドキュメントの欠陥を網羅的に 抽出することができているだろうか でも，致命的な，重要は欠陥は除きたい
- 12. Copy Right ©永田 敦 2011 2013/07/11 12 よし，レビューをやっていこう
- 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
- 14. Copy Right ©永田 敦 2011 2013/07/11 14 レビューの場合の欠陥予防 ？
- 15. Copy Right ©永田 敦 2011 JUSE, Tokyo 2008 Keynote 90 minutes with Consecutive Translation (45 minutes effectively) Tom Gilb kyoritsu-pub.co.jp Tom@Gilb.com • Gilb and Graham, Software Inspection (1993): • Japanese Edition Tom Gilb kyoritsu-pub.co.jp 15 AGILE INSPECTIONS: Reviews by sampling and measuring defects
- 16. Copy Right ©永田 敦 2011 インスペクションの目的 2013/07/11 16 高品質のドキュメントを はじめから生産すること
- 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 “初めからよいものを書いてもらうように” ドキュメントの書き方の品質を改善してもらう
- 18. Copy Right ©永田 敦 2011 アジャイルインスペクションプロセス 2013/07/11 18 インスペクション ロギング サンプリング 修正 次のフェーズ EXIT No EXIT Agile Inspection Iteration ENTRY
- 19. Copy Right ©永田 敦 2011 アジャイルインスペクションのプロセス 1. インスペクタ（チェッカー）を決める 2. ルール（インスペクションの観点）を決める 3. 欠陥密度の閾値を決める 4. 実施時間を決める 5. ドキュメントをサンプリングする 6. インスペクタにルールなどの説明をする 7. サンプルをインスペクションする( 約10分から30分） 8. ログをとる 8. メトリクスを分析する 9. 欠陥密度が閾値より低い場合,次のプロセスに進む 10. 欠陥密度が閾値より高い場合,ドキュメントの質の 改善のために差し戻す 2013/07/11 19 準 備 実 施 分 析 ・ 判 定
- 20. Copy Right ©永田 敦 2011 ケーススタディー：計画 Inspection ID Display1 Inspection Leader 永田 敦 Author XXXXXXX Date Inspection requested: Product ｘｘｘｘｘ 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
- 21. Copy Right ©永田 敦 2011 「箱の上端×四分位範囲×１．５」 の範囲で一番大きいデータ 75%点 (第3四分位点) 中央値 50%点 (第2四分位点) 25%点 (第1四分位点) 「箱の下端×四分位範囲×１．５」 の範囲で一番小さいデータ 欠陥密度の変化 2013/07/11 21
- 22. Copy Right ©永田 敦 2011 ルール ３つから７つぐらいのルール 例 曖昧ではないか？ 明確か？ 矛盾はないか？ テスト可能か？ 設計要素がないか（要求仕様におい て） 2013/07/11 22
- 23. Copy Right ©永田 敦 2011 ルール：曖昧 絶対ドラゴンズに 勝ってほしい 僕はウナギだ 2013/07/11 23
- 24. Copy Right ©永田 敦 2011 ルール：曖昧 子供が好きなおばさんが 来た 太郎は自転車で逃げた花 子を追いかけた 父は弟に自分の部屋で勉 強させた 2013/07/11 24
- 25. Copy Right ©永田 敦 2011 ルール：曖昧 多義文 2013/07/11 25
- 26. Copy Right ©永田 敦 2011 ルール：曖昧 全部網羅しなくても合 格とする テストケースは全部でき なかった 全部＋否定語 2013/07/11 26
- 27. Copy Right ©永田 敦 2011 ルール：曖昧 ＡまたはＢでないとき Ｃである 2013/07/11 27
- 28. Copy Right ©永田 敦 2011 ルール：曖昧 6 「入力項目は生年月日と 氏名あるいはカタカナで す」 2013/07/11 28
- 29. Copy Right ©永田 敦 2011 ルール：不明確 7 データの輻輳に注意して… 応答をいつまで待っても来 なかったときは… できるだけ早く応答を返す 「以上」「以下」「同じ」 2013/07/11 29
- 30. Copy Right ©永田 敦 2011 ルール：矛盾 設定された閾値（表 3-3）で検出し た個数が16個以下ならすべて追加。 16個以上なら異常状態として追加 しない。 2013/07/11 30
- 31. Copy Right ©永田 敦 2011 ルール：設計要素 要求仕様書では欠陥となる ＡＴＭ 金の引き出しにおいて，引き出し口が開いてから１分以内に貨幣 を取らないと引き出し口は閉じる タイムアウトの１分は内部のタイマーＩＣにより正確に測る ログインアカウント ユーザー名とパスワードを正しく入れたらアカウントにログインする ことができる． パラメータの指定だけでは設計問題ではないこともある 2013/07/11 31
- 32. Copy Right ©永田 敦 2011 重要（MAJOR）な欠陥 曖昧性，不明確性，矛盾性を持っ た ドキュメント（仕様書）の表現により そのあとの設計，コーディングで エラーを起こして埋め込まれた， お客様に影響のある 故障を発生するリスクをもつ欠陥． 2013/07/11 32
- 33. Copy Right ©永田 敦 2011 インスペクション Agile Inspection Workshop やってみましょう どのくらい、欠陥があるか 体験してみましょう ルール 対象 要求仕様書 あいまいでないこと 明解であること 矛盾のないこと 設計要素がないこと １ページ分１５分かけてチェックしましょう 2013/07/11 33
- 34. Copy Right ©永田 敦 2011 アジャイルインスペクションプロセス 2013/07/11 34 インスペクション ロギング サンプリング 修正 次のフェーズ EXIT No EXIT Agile Inspection Iteration ENTRY
- 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 ユニークな欠陥数／論理ページ 欠陥数の平均値／論理ページ 共通のメンバーにおけるユニークな欠陥密度と欠陥密度の関係 チェッカーの人選を初めから適切にすること イテレーションではできるだけチェッカーを変えないこと
- 36. Copy Right ©永田 敦 2011 ロギング 2013/07/11 36 指摘して， 書き手に直してもらえなかったこと ありませんか？
- 37. Copy Right ©永田 敦 2011 2013/07/11 37 ドキュメントを書く人の "質"を上げていく
- 38. Copy Right ©永田 敦 2011 2013/07/11 38 どうやったら， ドキュメントを書く人の "質"があがるのか？
- 39. Copy Right ©永田 敦 2011 2013/07/11 39 書き手は 欠陥と認めてますか？ 認識してますか？
- 40. Copy Right ©永田 敦 2011 2013/07/11 40 欠陥だという気付きを 与えていますか？
- 41. Copy Right ©永田 敦 2011 2013/07/11 41 どうやったら 欠陥だと気付いて もらえるでしょうか？
- 42. Copy Right ©永田 敦 2011 2013/07/11 42 フィードバックは コミュニケーション
- 43. Copy Right ©永田 敦 2011 2013/07/11 43 Respect & Influence
- 44. Copy Right ©永田 敦 2011 2013/07/11 44 それでは， フィードバックを 書いてみましょう
- 45. Copy Right ©永田 敦 2011 2013/07/11 45 曖昧性は， ステークホルダのスコープによって変わる ドメイン知識 暗黙知 現実世界の環境
- 46. Copy Right ©永田 敦 2011 欠陥密度の変化 2013/07/11 46 「箱の上端×四分位範囲×１．５」 の範囲で一番大きいデータ 75%点 (第3四分位点) 中央値 50%点 (第2四分位点) 25%点 (第1四分位点) 「箱の下端×四分位範囲×１．５」 の範囲で一番小さいデータ
- 47. Copy Right ©永田 敦 2011 AGILE INSPECTION POLICY REVIEW EARLY リビューは早いうちにできているところからやる。 2013/07/11 47 全部そろうまで 待つ Engineer Your Review Process : Tom Gilb 2008
- 48. Copy Right ©永田 敦 2011 インクリメンタル・レビュー 最初の１ページを書いたところから始める ドキュメントの作成スケジュールに従い，定期的， 計画的にアジャイルインスペクションを実施する イテレーティブな実施によりドキュメントの品質を 上げていく 書き手ごとに別のイテレーションを回す 2013/07/11 48
- 49. Copy Right ©永田 敦 2011 インクリメンタル・レビュー 2013/07/11 49 百ページのSRS バッチ的レビュー インクリメンタルなレビュー 初めの１ページからレビューを始めてしまう
- 50. Copy Right ©永田 敦 2011 まとめ レビューの目的 ドキュメントの品質を 改善してゆくことです． 2013/07/11 50
- 51. Copy Right ©永田 敦 2011 ご清聴ありがとうございます． 2013/07/11 51
- 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
- 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