TEF/StudyMeeting/20081010
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
|
ログイン
]
開始行:
[[TEF/StudyMeeting]]
* TEF勉強会 2008年10月10日 [#rd8226e5]
~
** 勉強会本編 [#r82ebd8b]
- 【講師】永田さん~
- 【幹事】増田さん~
~
** 勉強会メモ [#x8bb5a87]
~
========================================~
Agile Inspection Workshop(TEF勉強会)~
========================================~
【講師】永田 敦(ソニー)~
・活動:2008年JaSST東京で論文を発表しベストス...
・著書:ソフトウェアテストの基礎(共同翻訳)~
【全体の流れ】~
◆経緯・イントロ(19:10 〜 )~
◆目的・方法~
◆体験(Agile Inspection 実施)~
□休憩(19:55 〜 20:05)~
◆コスト・効果・これから~
◆Q&A(20:40〜21:00)~
~
――――――――――――――――――――~
【記述方法】~
Q: 質問~
A: 回答~
C: コメント~
~
========================================~
ワークショップ開始~
========================================~
◆経緯・イントロ~
―――――――――――――――――――――――――~
◇経緯~
ソフトウェア品質シンポジウム2008 SQIP(Software Quality ...
実施したチュートリアルの内容をおすそ分けです。~
~
レビュー/ウォークスルーとの違い等についてお話します。~
目的は、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:これほど、効果を発揮する方法はほかにはないのでは?!~
要求仕様で品質を向上させる。~
~
―――――――――――――――――――――――――~
◇局所レビュー~
−狙いどころ:対象箇所~
・3つのH(秋山氏の言葉)~
はじめて~
変化~
久しぶり~
・流用の落とし穴~
−危ないところを狙い撃ちする~
・テストできないところ(タイミング、高付加)~
・テスト実施前にAgile Inspectionは、実施可能~
・派生開発が多い(一部新機能、久しぶりに変更)~
・流用部品でも、チップが新しく・早くなったために問題が...
~
~
―――――――――――――――――――――――――~
◇どこまでやるのか?~
※無限大に時間があるわけではない~
−タイムボックス~
・時間規定~
・1テーマ30分(形骸化するので注意)~
・2時間/開催~
−何回やれるか?~
・テーマに対する優先順位~
重要度~
戦略~
変化規模~
設計者の気持ち~
・準備が大切~
テーマ選定~
目的・目標・方法~
~
※H社等では、効果を理解しているので重要視している~
~
―――――――――――――――――――――――――~
◇コスト~
[アジャイルインスペクション]~
・対象: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:それは、適宜各人・各組織で効果を測定してルールを決め...
最初は、基本的なルールを元に実施しては?~
組織毎のローカルルールもあると思いますので、~
~
設計的な要素をどこまで入れるかが悩みどころ~
~
本当は「何がしたいドキュメントなのか?」を考える必要...
~
―――――――――――――――――――――――――~
終了行:
[[TEF/StudyMeeting]]
* TEF勉強会 2008年10月10日 [#rd8226e5]
~
** 勉強会本編 [#r82ebd8b]
- 【講師】永田さん~
- 【幹事】増田さん~
~
** 勉強会メモ [#x8bb5a87]
~
========================================~
Agile Inspection Workshop(TEF勉強会)~
========================================~
【講師】永田 敦(ソニー)~
・活動:2008年JaSST東京で論文を発表しベストス...
・著書:ソフトウェアテストの基礎(共同翻訳)~
【全体の流れ】~
◆経緯・イントロ(19:10 〜 )~
◆目的・方法~
◆体験(Agile Inspection 実施)~
□休憩(19:55 〜 20:05)~
◆コスト・効果・これから~
◆Q&A(20:40〜21:00)~
~
――――――――――――――――――――~
【記述方法】~
Q: 質問~
A: 回答~
C: コメント~
~
========================================~
ワークショップ開始~
========================================~
◆経緯・イントロ~
―――――――――――――――――――――――――~
◇経緯~
ソフトウェア品質シンポジウム2008 SQIP(Software Quality ...
実施したチュートリアルの内容をおすそ分けです。~
~
レビュー/ウォークスルーとの違い等についてお話します。~
目的は、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:これほど、効果を発揮する方法はほかにはないのでは?!~
要求仕様で品質を向上させる。~
~
―――――――――――――――――――――――――~
◇局所レビュー~
−狙いどころ:対象箇所~
・3つのH(秋山氏の言葉)~
はじめて~
変化~
久しぶり~
・流用の落とし穴~
−危ないところを狙い撃ちする~
・テストできないところ(タイミング、高付加)~
・テスト実施前にAgile Inspectionは、実施可能~
・派生開発が多い(一部新機能、久しぶりに変更)~
・流用部品でも、チップが新しく・早くなったために問題が...
~
~
―――――――――――――――――――――――――~
◇どこまでやるのか?~
※無限大に時間があるわけではない~
−タイムボックス~
・時間規定~
・1テーマ30分(形骸化するので注意)~
・2時間/開催~
−何回やれるか?~
・テーマに対する優先順位~
重要度~
戦略~
変化規模~
設計者の気持ち~
・準備が大切~
テーマ選定~
目的・目標・方法~
~
※H社等では、効果を理解しているので重要視している~
~
―――――――――――――――――――――――――~
◇コスト~
[アジャイルインスペクション]~
・対象: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:それは、適宜各人・各組織で効果を測定してルールを決め...
最初は、基本的なルールを元に実施しては?~
組織毎のローカルルールもあると思いますので、~
~
設計的な要素をどこまで入れるかが悩みどころ~
~
本当は「何がしたいドキュメントなのか?」を考える必要...
~
―――――――――――――――――――――――――~
ページ名: