Agile Inspection Workshop - IPACopy Right ©永田敦2010 Agile Inspection...
Transcript of Agile Inspection Workshop - IPACopy Right ©永田敦2010 Agile Inspection...
Agile Inspection WorkshopCopy Right ©永田 敦 2010
Agile Inspection Workshop
ソニー(株) 永田 敦
2010年9月17日
12010/9/17
JISA共催SECセミナー
プロセス改善ベストプラクティス」ワークショップ
Agile Inspection WorkshopCopy Right ©永田 敦 2010
自己紹介
• ソニー株式会社 永田 敦ソフトウェアテストプロセス改善
SQiP研究会 第三分科会副主査
SQiPシンポジウム運営委員
派生開発推進委員会運営委員
2
情報処理学会会誌 2009 5月号特集「ソフトウェアレビュー/ソフトウェアインスペクションと欠陥予防の現在」
2010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
アジェンダ
• インスペクションの目的,位置付け
• アジャイルインスペクションとは
• アジャイルインスペクションプロセス
• 体験してみよう
• アジャイルインスペクションのポイント
• もう一度やってみよう
• まとめ
32010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
誤り,欠陥,故障
知識 行為正しくない記述
望ましくない結果
業務知識分野知識各種標準など
文書化コード化試験・運用
文書コード
手戻りシステム障害
誤り(Error)
欠陥(Defect) 故障(Failure)
http://www.bcm.co.jp/index.html: 山本修一郎 要求工学 要求レビュ より
42010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ドキュメントインスペクションの従来の目的
ドキュメントの欠陥を発見する
より多く
52010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
コスト:インスペクション• 開発予算の10~15%
– 時間
• ?時間/回
• ?分/件
– 人 : 例
• リーダー 1名
• モデレータ 1名
• インスペクタ 6名
• 提案者 2名
– 工数
• インスペクション 人数 x 時間 x 賃率
• 事前の仕様書の読み
インスペクション 時間とコストはかかる
Tom Gilb : “ソフトウエアインスペクション ”より
62010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
サンプリング・インスペクション• 課題: 対象ドキュメントの欠陥を網羅的に抽出する
– 欠陥を完全にゼロにすることはできない
– ドメイン知識,技術力,経験,文書分析力
– 観点 : 開発設計者,テストエンジニア,営業,保守
⇒より上流で
ドキュメントを書く側の質を上げていく
⇒上流で欠陥を防ぎコストを下げる
レビュープロセスのコストを下げるレビュープロセスのコスト =
レビューアの人数 x レビューアの賃率 x 時間
72010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
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 EditionTom Gilb
kyoritsu-pub.co.jp
AGILE INSPECTIONS:Reviews by
sampling and measuring defects
8
Agile Inspection WorkshopCopy Right ©永田 敦 2010
アジャイルインスペクションの目的
高品質のドキュメントをはじめから生産すること
Extreme Inspection
92010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
Agile Inspection Principle 1
The Prevent –
Do not Clean Principle– リビューの目的を、
欠陥を取り除き修正する
Engineer Your Review Process : Tom Gilb 2008
やり直して“元から”ドキュメントの品質を上げてもらう
102010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
アジャイルインスペクションプロセス
インスペクション
ロギング
サンプリング
修正
次のフェーズEXIT
No EXIT
Agile InspectionIteration
ENTRY
112010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
アジャイルインスペクションのプロセス1. インスペクタ(チェッカー)を決める
2. ルール(インスペクションの観点)を決める
3. 欠陥密度の閾値を決める
4. 実施時間を決める
5. ドキュメントをサンプリングする
6. インスペクタにルールなどの説明をする
7. サンプルをインスペクションする( 約10分から30分)
8. ログをとる
8. メトリクスを分析する
9. 欠陥密度が閾値より低い場合,次のプロセスに進む
10. 欠陥密度が閾値より高い場合,ドキュメントの質の
改善のために差し戻す
準備
実施
分析・判定
122010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
誤り,欠陥,故障
知識 行為正しくない記述
望ましくない結果
業務知識分野知識各種標準など
文書化コード化試験・運用
文書コード
手戻りシステム障害
誤り(Error)
欠陥(Defect) 故障(Failure)
http://www.bcm.co.jp/index.html: 山本修一郎 要求工学 要求レビュ より
132010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:曖昧 1
絶対ドラゴンズに勝ってほしい
142010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:曖昧 2
•子供が好きなおばさんが来た
•太郎は自転車で逃げた花子を追いかけた
•父は弟に自分の部屋で勉強させた
152010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:曖昧 3
多義文
162010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:曖昧 4
•「全部できなくても大丈夫」
•全部網羅しなくても合格とする
172010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:曖昧 5
AまたはBでないとき
Cである
182010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:曖昧 6
「入力項目は生年月日と
氏名あるいはフリガナです」
「テストケースは全部できなかった」
192010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:不明確 7
•データの輻輳に注意して…
•応答をいつまで待っても来なかったときは…
•できるだけ早く応答を返す
•「以上」「以下」
202010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:矛盾 8
•できるだけ早く応答を返す
⇒ 2秒以内に…
→ 要件間の衝突(矛盾)
212010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:不明確 9
•設定された閾値(表 3-3)で検出した個数が16個以下ならすべて追加。
• 16個以上なら異常状態として追加しな
い。
222010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール:設計 10
要求仕様書では欠陥となる
• ATM
– 金の引き出しにおいて,引き出し口が開いてから1分以内に貨幣を取らないと引き出し口は閉じる
– タイムアウトの1分は内部のタイマーICにより正確に測る
• ログインアカウント
– ユーザー名とパスワードを正しく入れたらアカウントにログインすることができる.
パラメータの指定だけでは設計問題ではないこともある232010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
曖昧性,丌明確性,矛盾性を持った
ドキュメント(仕様書)の表現により
そのあとの設計,コーディングで
エラーを起こして
お客様に影響のある
故障を発生するリスクをもつ欠陥.
24
重要(Major)な欠陥
2010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
インスペクション• Agile Inspection Workshop
やってみましょうどのくらい、欠陥があるか 体験してみましょう
ルール 対象 要求仕様書
– あいまいでないこと
– 明解であること
– 矛盾のないこと
– 設計要素がないこと
• 1ページ分15分かけてチェックしましょう
252010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010 26
湯沸かしポット
2010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
• Respect & Influence
– 敬意をもち影響を与える
• レビューは合意の技術
– 自分が欠陥と思っていることを理解してもらい
修正のモチベーションを持ってもらう
2010/9/17 27
ロギング
Agile Inspection WorkshopCopy Right ©永田 敦 2010
Agile Inspection Principle 2
•REVIEW EARLYリビューは早いうちに“できているところ”からやる。
Engineer Your Review Process : Tom Gilb 2008
インスペクションロギング
サンプリング
書き直し
次のフェーズEXIT
No EXIT
Agile InspectionIteration
ENTRY
282010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ポイント
• サンプリング
• 時間を決める
• Checking Rate 読む速さ
• Major Defect : 重大欠陥
• EXIT/Not EXIT : 閾値 → 目標
292010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ルール
–3つから7つぐらいのルール
–例
•曖昧ではないか?
•明確か?
•矛盾はないか?
•テスト可能か?
•設計要素がないか(要求仕様において)
302010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
Agile Inspection 対象
• 適したドキュメントは上流ドキュメント
• 要求仕様書
• 基本設計書
• テスト設計書
312010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
これから
• モチベーション
– プロセス改善
導入できるか?• Exit Criteria
• テーラリング
• ルール
– 標準
– 独自のルール
• メトリクス
– テーラリング
• 表現
– 書き方
• スキル
– トレーニング
322010/9/17
Agile Inspection WorkshopCopy Right ©永田 敦 2010
ご清聴
ありがとう
ございます
332010/9/17