TEF/StudyMeeting/20081010

TEF/StudyMeeting

TEF勉強会 2008年10月10日 †

勉強会本編 †

• 【講師】永田さん
  
• 【幹事】増田さん
  
  

勉強会メモ †

========================================
Agile Inspection Workshop（TEF勉強会）
========================================
【講師】永田　敦（ソニー）
　・活動：２００８年ＪａＳＳＴ東京で論文を発表しベストスピーカー賞受賞
　・著書：ソフトウェアテストの基礎（共同翻訳）
【全体の流れ】
　◆経緯・イントロ(19:10 〜 )
　◆目的・方法
　◆体験（Agile Inspection 実施）
　　□休憩(19:55 〜 20:05)
　◆コスト・効果・これから
　◆Q&A(20:40〜21:00)

――――――――――――――――――――
【記述方法】
　Q: 質問
　A: 回答
　C: コメント

========================================
ワークショップ開始
========================================
◆経緯・イントロ
―――――――――――――――――――――――――
◇経緯
　ソフトウェア品質シンポジウム2008 SQIP(Software Quality Profession)の番外編で、
　実施したチュートリアルの内容をおすそ分けです。

　レビュー／ウォークスルーとの違い等についてお話します。
　目的は、TEFを経由して日本全体に広めてたいと思っています。
　本日使うツール（Excel）も皆さんに持って帰っていただきます。
　（広める活動、ツールの提供については、トム・ギルブの了承済み）

　★その代わりに、お願い！！
　　持ち帰って実施した、結果をフィードバックしてください。

―――――――――――――――――――――――――
◇イントロ
−ドキュメントレビューとは？
　C:静的テスト技法のひとつと考えています。
−テストベースを読まなければ
−ドキュメント
　C:組込み系は、昔は実機を触っていた
　C:テストベースがなかった
　　→実記ができてからでは遅い！
　　→テストベースを読まなければ！！

―――――――――――――――――――――――――
◆目的・方法
―――――――――――――――――――――――――
◇目的
−テスト設計する
−ドキュメントの品質を測る
−ドキュメントの欠陥を発見する
　★レビューは、一番効率の良いデバック（テスト）方法では？！

C:「トムギルブ氏の言葉」
　すべてのドキュメントをレビューしてから、ドキュメントが間違って
　いるから直してくださいではなく、ドキュメントの質自体を計測して
　一定の基準になっていないものは返却する。
　一定の基準を満たしているものは、次の段階へ進む（Exit）

◇方法
−サンプリング
　・1ページだけをインスペクションして品質を推定
　・アジャイル　インスペクション
　→担当者ごとで違いが出る
−局所レビュー
　・観点を持って狙いをつけてレビューする
−全レビュー
　・ドキュメントレビュー

―――――――――――――――――――――――――
◆体験（Agile Inspection 実施）
―――――――――――――――――――――――――
◇サンプリング
[ウェブで公開されているものを資料として利用]
[某市のウェブサイト委託書]
−ルール：
　・あいまいでないこと（一意的であること）
　・明確であること（クリアであること）
　・矛盾のないこと
　・設計要素がないこと
　　→要求定義書なので、設計要素を入れない
　　　[例]：パスワードを入力する→[要求]セキュアであること
　　　　　　パスワードということは、実装が決まってくる
　　　　　　要求を満たすためには、指紋認証もありでしょう！
−メジャーなものを抽出：
　・マイナーなものは、今日はカウントしない（てにをは、表現等）
−時間：
　・1ページ15分かけてチェックしましょう
−その他：
　・発見数を5の倍数で声を出す（5個、10個、15個！、20個！！）
C:ゲーム感覚で言わせているらしい

◇ルール（14のルールを列挙）
−ソフトウェアインスペクションの付録にたくさん掲載されています。
　詳しくは、Tom Gilb 氏の著書をご参照ください。
　「ソフトウェアインスペクション」

―――――――――――――――――――――――――
□休憩
―――――――――――――――――――――――――
−Fault Desity KDSI のグラフを参照、1ページ毎のチェック時間と
　バグ検出率の関係？グラフを参照

C:じっくりやってよい結果を得られる場合もある
　早ければよいわけではない

C:チームを組んでやってみるとドメイン知識も含めてばらつきがでて
　面白い

C:今回は、公にしている要求定義書でも、いろいろ出てきますね

C:要求仕様の段階で、インプリメント（実装内容）を入れたくなって
　しまうが、要求仕様には設計側の実装内容は記入しない方が良い
　→本来の目的を忘れてしまう

―――――――――――――――――――――――――
◆コスト・効果・これから
―――――――――――――――――――――――――
◇Agile Inspection 実施結果
　目安：1ページ3000文字（400ワード）
　
[サンプルページ P7]
　ワード／メジャー／設計
　�273／25／2
　�200／14／4
　�300／14／4
　�160／11／0
　�320／10／2

[サンプルページ P8]
　�280／12／8
　�250／13／2
　�300／20／2
　�220／17／10
　�280／30／7

―――――――――――――――――――――――――
◇ツール（Excel）
−300ワード（1ページ?）毎の数量を正規化
　Agile Inspectionで見つかるのは1/3と仮定
　→見つかったポイントを3倍して、潜在的な相場バグ数と仮定
　→2/3は、意図に即して、正しく読まれる（実装される）
　→1/3は、バグを作りこむ
−このまま設計した場合の、後戻り作業工数（時間）

★判断基準は、（各組織）マネージャが判断
　→1ページあたりのバグ数が、一定数以下であること

C:実際の要求仕様書はどれぐらいになりますか？
C:何十、何百ページになる場合がほとんど

★アジャイルのポイント
　数ページをチェックすることにより、全体欠陥密度が推測できる
　それを持ってチェックポイントとする
　→ドキュメント作成者に指摘事項伝えて、ドキュメントを修正される
　　これをきっかけに、ドキュメント全体の質が向上する

―――――――――――――――――――――――――
◇結果
−たった1ページで
　いくつかのメジャーデフェクトが見つかったでしょうか？

◇RAYTHEON（米国軍事系の会社）の例
−計測グラフを参照
C:最初は、43%はRework（リグレッション・デバック）工数！
　→5年後には、5%になっていた

C:これほど、効果を発揮する方法はほかにはないのでは？！
　要求仕様で品質を向上させる。

―――――――――――――――――――――――――
◇局所レビュー
−狙いどころ：対象箇所
　・３つのH（秋山氏の言葉）
　　はじめて
　　変化
　　久しぶり
　・流用の落とし穴
−危ないところを狙い撃ちする
　・テストできないところ（タイミング、高付加）
　・テスト実施前にAgile Inspectionは、実施可能
　・派生開発が多い（一部新機能、久しぶりに変更）
　・流用部品でも、チップが新しく・早くなったために問題が発生する場合有り


―――――――――――――――――――――――――
◇どこまでやるのか？
　※無限大に時間があるわけではない
−タイムボックス
　・時間規定
　・1テーマ30分（形骸化するので注意）
　・2時間／開催
−何回やれるか？
　・テーマに対する優先順位
　　重要度
　　戦略
　　変化規模
　　設計者の気持ち
　・準備が大切
　　テーマ選定
　　目的・目標・方法

　※H社等では、効果を理解しているので重要視している

―――――――――――――――――――――――――
◇コスト
[アジャイルインスペクション]
　・対象：1ページから実施可能、時間も限定できる（フルルール、1時間）
　・人　：1人で実施可能
　・工数：少ない

[インスペクション]
　・対象：ドキュメント全体
　・人　：関係者多数
　・工数：ほどほど（開発予算の10〜15％）

◇効果：修正コスト
　2億5000万規模で
　→2000万（ドキュメント修正）＋コード修正・テスト作業

◇KPI
　ドキュメント1ページあたりのメジャー欠陥数
　ドキュメント全体の欠陥数
　等々

―――――――――――――――――――――――――
◇今後
　みんなで持ち帰ってやってみましょう！
　そして・・・
　データをください→Tom Gilbに報告します！！

◇その他
　※COMPETITIVE（トムギルブの本）
　　→PLANGAGE（プランゲージ：計画言語？）
　　　誰でもやれるやり方

―――――――――――――――――――――――――
◆Q&A
―――――――――――――――――――――――――
Q1：終わったプロジェクトでもOKですか？
A1：よいと思います。
　　いろいろ見比べてみるのが良いと思います

Q2:ドキュメントレビューして全部欠陥、
　　アジャイルインスペクションでも修正依頼のアプローチ
A2：開発者に他部署のドキュメントをアジャイルインスペクションを
　　やってみると、納得しやすい
　　それを踏まえたうえで、指摘したドキュメントを持っていくと
　　理解してもらえる

Q3：修正する人にも、そういった観点を持ってもらうきっかけにする
　　と言うことでしょうか？

A3：そうです。
　　ルールを提示すると、設計者という観点から第三者的な観点に
　　切り替わるので、いろいろな問題点が出てくる
　　自分が作ったドキュメントを自分で見てもわからない
　　アジャイルインスペクションをつかって気づきの機会とする

Q4：ルールが変われば、ほかのドキュメントでも使えるのでは？
A4：YES！
　　トムギルブの書籍に掲載されているルールセットを使えばいろいろな
　　ドキュメントに使える
　　ソフトウェア開発では、意外と

Q5：このルールセットのコンセンサスは、どうすればよいのでしょう？
A5：それは、適宜各人・各組織で効果を測定してルールを決めていけばよいと思います。
　　最初は、基本的なルールを元に実施しては？
　　組織毎のローカルルールもあると思いますので、

　　設計的な要素をどこまで入れるかが悩みどころ

　　本当は「何がしたいドキュメントなのか？」を考える必要がありそう。

―――――――――――――――――――――――――