agile inspection workshop - ipacopy right ©永田敦2010 agile inspection...

Agile Inspection WorkshopCopy Right ©永田敦 2010

Agile Inspection Workshop

ソニー（株）永田敦

2010年9月17日

12010/9/17

JISA共催SECセミナー

プロセス改善ベストプラクティス」ワークショップ


自己紹介

• ソニー株式会社永田敦ソフトウェアテストプロセス改善

SQiP研究会第三分科会副主査

SQiPシンポジウム運営委員

派生開発推進委員会運営委員

2

情報処理学会会誌 2009 5月号特集「ソフトウェアレビュー/ソフトウェアインスペクションと欠陥予防の現在」

2010/9/17


アジェンダ

• インスペクションの目的，位置付け

• アジャイルインスペクションとは

• アジャイルインスペクションプロセス

• 体験してみよう

• アジャイルインスペクションのポイント

• もう一度やってみよう

• まとめ

32010/9/17


誤り，欠陥，故障

知識行為正しくない記述

望ましくない結果

業務知識分野知識各種標準など

文書化コード化試験・運用

文書コード

手戻りシステム障害

誤り（Ｅｒｒｏｒ）

欠陥（Defect) 故障（Ｆａｉｌｕｒｅ）

http://www.bcm.co.jp/index.html: 山本修一郎要求工学要求レビュより

42010/9/17


ドキュメントインスペクションの従来の目的

ドキュメントの欠陥を発見する

より多く

52010/9/17


コスト：インスペクション• 開発予算の１０～１５％

– 時間

• ？時間／回

• ？分／件

– 人：例

• リーダー１名

• モデレータ１名

• インスペクタ６名

• 提案者２名

– 工数

• インスペクション人数ｘ時間ｘ賃率

• 事前の仕様書の読み

インスペクション時間とコストはかかる

Tom Gilb : “ソフトウエアインスペクション ”より

62010/9/17


サンプリング・インスペクション• 課題：対象ドキュメントの欠陥を網羅的に抽出する

– 欠陥を完全にゼロにすることはできない

– ドメイン知識，技術力，経験，文書分析力

– 観点：開発設計者，テストエンジニア，営業，保守

⇒より上流で

ドキュメントを書く側の質を上げていく

⇒上流で欠陥を防ぎコストを下げる

レビュープロセスのコストを下げるレビュープロセスのコスト＝

レビューアの人数ｘレビューアの賃率ｘ時間

72010/9/17


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


アジャイルインスペクションの目的

高品質のドキュメントをはじめから生産すること

Extreme Inspection

92010/9/17


Agile Inspection Principle 1

The Prevent –

Do not Clean Principle– リビューの目的を、

欠陥を取り除き修正する

Engineer Your Review Process : Tom Gilb 2008

やり直して“元から”ドキュメントの品質を上げてもらう

102010/9/17


アジャイルインスペクションプロセス

インスペクション

ロギング

サンプリング

修正

次のフェーズEXIT

No EXIT

Agile InspectionIteration

ENTRY

112010/9/17


アジャイルインスペクションのプロセス1. インスペクタ（チェッカー）を決める

2. ルール（インスペクションの観点）を決める

3. 欠陥密度の閾値を決める

4. 実施時間を決める

5. ドキュメントをサンプリングする

6. インスペクタにルールなどの説明をする

7. サンプルをインスペクションする( 約10分から30分）

8. ログをとる

8. メトリクスを分析する

9. 欠陥密度が閾値より低い場合,次のプロセスに進む

10. 欠陥密度が閾値より高い場合,ドキュメントの質の

改善のために差し戻す

準備

実施

分析・判定

122010/9/17


誤り，欠陥，故障

知識行為正しくない記述

望ましくない結果

業務知識分野知識各種標準など

文書化コード化試験・運用

文書コード

手戻りシステム障害

誤り（Ｅｒｒｏｒ）

欠陥（Defect) 故障（Ｆａｉｌｕｒｅ）

http://www.bcm.co.jp/index.html: 山本修一郎要求工学要求レビュより

132010/9/17


ルール：曖昧 1

絶対ドラゴンズに勝ってほしい

142010/9/17



•子供が好きなおばさんが来た

•太郎は自転車で逃げた花子を追いかけた

•父は弟に自分の部屋で勉強させた

152010/9/17



多義文

162010/9/17



•「全部できなくても大丈夫」

•全部網羅しなくても合格とする

172010/9/17



ＡまたはＢでないとき

Ｃである

182010/9/17



「入力項目は生年月日と

氏名あるいはフリガナです」

「テストケースは全部できなかった」

192010/9/17


ルール：不明確 7

•データの輻輳に注意して…

•応答をいつまで待っても来なかったときは…

•できるだけ早く応答を返す

•「以上」「以下」

202010/9/17


ルール：矛盾 8

•できるだけ早く応答を返す

⇒ ２秒以内に…

→ 要件間の衝突（矛盾）

212010/9/17


ルール：不明確 9

•設定された閾値（表 3-3）で検出した個数が16個以下ならすべて追加。

• 16個以上なら異常状態として追加しな

い。

222010/9/17


ルール：設計 10

要求仕様書では欠陥となる

• ＡＴＭ

– 金の引き出しにおいて，引き出し口が開いてから１分以内に貨幣を取らないと引き出し口は閉じる

– タイムアウトの１分は内部のタイマーＩＣにより正確に測る

• ログインアカウント

– ユーザー名とパスワードを正しく入れたらアカウントにログインすることができる．

パラメータの指定だけでは設計問題ではないこともある232010/9/17


曖昧性，丌明確性，矛盾性を持った

ドキュメント（仕様書）の表現により

そのあとの設計，コーディングで

エラーを起こして

お客様に影響のある

故障を発生するリスクをもつ欠陥．

24

重要（Ｍａｊｏｒ）な欠陥

2010/9/17


インスペクション• Agile Inspection Workshop

やってみましょうどのくらい、欠陥があるか体験してみましょう

ルール対象要求仕様書

– あいまいでないこと

– 明解であること

– 矛盾のないこと

– 設計要素がないこと

• １ページ分１５分かけてチェックしましょう

252010/9/17


• Respect & Influence

– 敬意をもち影響を与える

• レビューは合意の技術

– 自分が欠陥と思っていることを理解してもらい

修正のモチベーションを持ってもらう

2010/9/17 27

ロギング


Agile Inspection Principle 2

•REVIEW EARLYリビューは早いうちに“できているところ”からやる。

Engineer Your Review Process : Tom Gilb 2008

インスペクションロギング

サンプリング

書き直し

次のフェーズEXIT

No EXIT

Agile InspectionIteration

ENTRY

282010/9/17


ポイント

• サンプリング

• 時間を決める

• Checking Rate 読む速さ

• Major Defect ：重大欠陥

• EXIT/Not EXIT ：閾値 → 目標

292010/9/17


ルール

–３つから７つぐらいのルール

–例

•曖昧ではないか？

•明確か？

•矛盾はないか？

•テスト可能か？

•設計要素がないか（要求仕様において）

302010/9/17


Agile Inspection 対象

• 適したドキュメントは上流ドキュメント

• 要求仕様書

• 基本設計書

• テスト設計書

312010/9/17


これから

• モチベーション

– プロセス改善

導入できるか？• Exit Criteria

• テーラリング

• ルール

– 標準

– 独自のルール

• メトリクス

– テーラリング

• 表現

– 書き方

• スキル

– トレーニング

322010/9/17


ご清聴

ありがとう

ございます

332010/9/17

agile inspection workshop - ipacopy right ©永田敦2010 agile inspection...

Documents