Your SlideShare is downloading. ×
Xp祭り用odc入門
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Xp祭り用odc入門

997
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
997
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. XP祭り2012ODC入門 森 龍二 1
  • 2. 自己紹介• 属性 • 川崎の某SIer(エンプラ系) • 全社技術セクションにいます • 本業はレビュー(Quality Inspectionでググってください) • Twitter:@mori_ryuji• 出没場所 • 「実践アジャイルテスト」読書会 • テスト自動化研究会(STAR) • WACATE 2
  • 3. 講演のきっかけ •Janet Gregory 「実践アジャイルテスト座談会」(5/29)打ち上げ にて • 「XP祭りつーイベントがあって」 • (森)「こんなネタあるんすけど」→「ODC」 • 「ぜひやって!」 • (森) (゜Д゜)マジデ!! 3
  • 4. アジャイルとバグ票• 「実践アジャイルテスト」におけるバグ票の扱い • できるだけ書かない • 解決に時間がかかる時→アジャイルでは少ない • 市場流出バグ→これはアジャイルでも一緒のはず• 上司「おいどうなってんだ!」 • オレ「こんなこともあろうかと」→【ODC分析結果】サッ • かこいい!!(^_^)v 4
  • 5. 目次• ODCとは• ODC概要• 適用してみて• まとめ 5
  • 6. ODCとは 6
  • 7. ODCとは• Orthogonal Defect Classification• 直交(交差)欠陥分類• 定量的分析と定性的分析の両方の性質を併せ持つ技法 例 長所 短所 障害の性質そのものは 定量的 信頼度成長曲線 実施コスト低い よくわからない 定性的 原因分析手法 問題の根本的解決を図る 実施コストがかかる• 障害の性質とその数から次のアクションを考えるための技法 7
  • 8. ODC略歴• 90年代初頭にIBM Researchで開発• 以降プロジェクトに適用を重ねる• 2011年現在 v 5.11• 開発の中心人物はRam Chillarege氏 • www.chillarege.com 8
  • 9. 信頼度成長曲線1件のバグの重みは? 確かに収束方向にあるがこ んなフェーズの後半で改善プ ロセス回せない! 件数はわかるが、今出てい るバグの種類と対処法がこれ ではわからん! 9
  • 10. 原因分析手法 これも重み不明 何件ぐらい起こってるの? 現場・アプリを知る専門 家が必要いわゆるフィッシュボーン 10
  • 11. ODCのイメージバグの種類別に 分類 数えられる=集中し 傾向がわかれば早 ている箇所が明確 期に対処可能 11
  • 12. ODC概要 12
  • 13. 最初に• この章の内容はURLからの情報を翻 訳、まとめています。疑問点は原文を あたってください。 • http://www.research.ibm.com/softeng/ ODC/ODC.HTM• SQuBOKは少し情報が古いかも 13
  • 14. ODCの特徴• 8つの属性 • 互いに観点の異なる属性に基づく分類 • 属性とその取り得る値同士は重なりがない(直交)• 開発プロセス、技術に非依存• 幅広い検証対象 • 要件定義書、標準規約以外のすべての成果物 14
  • 15. 8つの属性一覧時期 属性 Attribute 概要 Defect Removal 欠陥除去作業 Activities 欠陥を発見したフェーズ検出 トリガー Trigger 欠陥を発見する観点Open インパクト Impact お客様に与える影響 ターゲット Target 修正対象の成果物 Defect 欠陥種類 修正した欠陥の種類修正 TypeClose 状態 Qualifier 欠陥種類の状態 履歴 Age いつ作りこまれたか ソース Source 成果物の出所 15
  • 16. 欠陥の分類時期• Opener Section • 欠陥検出時に確定する情報• Closer Section • 欠陥修正時に確定する情報 16
  • 17. Opener Sectionの属性• 欠陥除去活動(Defect Removal Activity) • 欠陥を検出した開発フェーズ • 活動ごとに対応するトリガーを変える• トリガー(Trigger) • 欠陥を顕在化させた状況、条件、検証の観点• 影響(Impact) • お客様に与える影響の種類(影響度ではない) 17
  • 18. Error Fault Failure Fault Error Bug FailureMistake Defect人間の頭の中 Errorを実装したもの Faultが実行され、のある状態 まだ実行されない 機能が達成されな い状態 ※SQuBOKガイドより 18
  • 19. トリガーとは Trigger Fault Failure・電源が抜けてた ・電源の抜けを探す・電池切れ ・リモコンの電池を替える テレビが点かない・基盤が壊れてた ・本体の故障を疑う レビュー・テスト観点 2011/12/7 Ram Chillarege氏講演より 19
  • 20. 欠陥除去活動とトリガー トリガーのセット レビュー用欠陥除去活動 トリガーのセット 機能テスト用 設計レビュー コードレビュー 機能テスト トリガーのセット システムテスト システムテスト用 20
  • 21. 設計レビュー・コードレビューのトリガー# トリガー Trigger 内容 Design 設計書やコードが前後の工程の成果物・開発標準と矛盾1 設計との整合性 Conformance を起こしている、要件が漏れている・曖昧である2 ロジックフロー Logic/Flow 言語知識から論理・データの流れに矛盾がある Backward3 後方互換性 過去のバージョンの機能が損なわれている Compatibility Lateral 検査対象のシステムとやりとりする他システム、サービ4 並行互換性 Compatibility ス、コンポーネントとの間に矛盾がある5 同時実行性 Concurrency 共有リソースをアクセスする仕組みがない Internal 内部ドキュメント(目次と内容、コメントとソースコー6 内部ドキュメント Documents ドなど)が不正、不整合、不完全である Language 言語固有のコーディング標準や効率的な実装方法に準拠7 言語依存性 Dependency していない レビュー対象の設計書やコードが対象外へ及ぼす影響が8 副作用 Side Effect ある9 特殊な状況 Rare Situations 想定外または言及されていないシステムの振る舞い 21
  • 22. レビューのトリガー 現バージョン 前バージョン 前工程の 前工程の 設計書 設計書 3:後方互換性 6:内部ドキュメント 1:設計整合性 レビュー 相互作用 対象 する仕様 レビュー 4:並行互換性 相互作用レビューワー 対象 する仕様 後工程の レビュー 設計書 対象外 1:設計整合性 8:副作用 レビュー2:ロジックフロー 後工程の 対象外 5:同時実行性 設計書 7:言語依存性 9:特殊な状況 22
  • 23. 単体テストのトリガートリガー Trigger 内容 いわゆるホワイトボックステストによって見つかる欠 陥。市場に出たバグを含まないが、顧客がビジネスパ Simple ートナーやベンダーでコードに明るい場合はここに分単純パス Path 類される。 (例)case文のdefaultを通そうと思ったがdefaultがそも そも存在していなかった ホワイトボックス・グレーボックステストで見つかる バグ。いくつかの分岐やテスト条件が組み合わさって Complex 起こった者。Simple Pathに含まれない通常の市場バグ複合パス Path はこれ。 (例)ある箇所で使うはずのメモリーを別の場所で解放 してしまった 23
  • 24. 機能テストのトリガートリガー Trigger 内容 ブラックボックステストで、一つの機能をパラメーカバレッジ Coverage タなしまたは単一のパラメータで呼び出した場合の 欠陥 ブラックボックステストで、一つの機能を入力やパ組み合わせ Variation ラメータの組み合わせで呼び出した場合の欠陥 ブラックボックステストで、複数の機能を一連の流連続処理 Sequence れに従って呼び出した場合の欠陥 ブラックボックステストで、コードの2つ以上の塊の間でやりとりを相互作用 Interaction したときの欠陥。一つの機能を独立に実行すると正常終了するが組み 合わせると失敗するときだけに使う 24
  • 25. システムテストのトリガー トリガー Trigger 内容 Workload/ システムをリソースの限界またはその前後の環境下で使負荷・ストレス Stress ったときの欠陥 Recovery/ 例外を発生させるコードやリカバリコードが正常に動作 回復・例外 Exception しない。失敗(Failure)そのものではなく回復力 Startup/ シャットダウンやシステムの失敗から回復した後に起 起動・再起動 Restart 動・再起動する時の欠陥 Hardwareハードウェア設定 特定のハードウェア設定下で正常動作しない Configuration Softwareソフトウェア設定 特定のソフトウェア設定下で正常動作しない Configuration 負荷テスト中、限界以下の負荷でシナリオテストを実行ブロックテスト Blocked Test できない。ただし顧客が報告するバグは含まない 25
  • 26. 影響(Impact) 影響 Impact 内容 設置性 Installability ソフトウェアを使える状態にするまでのしやすさ完全性/セキュリティ Integrity/Security システム、プログラム、データなどの悪意のある破壊・置き換え・公開 パフォーマンス Performance 顧客または顧客のエンドユーザが想定するソフトウェアの処理スピード 保守性 Maintenance ソフトウェアの保守しやすさ。予防保守と是正保守の両方を含む 有用性 Serviceability 失敗(Failure)の診断のしやすさ 移行性 Migration 新しいリリースへの移行しやすさ。例えば互換性が失われる場合など 文書化の度合い Documentation ソフトウェアの構造や意図する使い方がきちんと文書化されているか ユーザビリティ Usability ソフトウェアや文書が理解しやすく正しく目的を遂げられるか 標準適合性 Standards 関連する標準に適合しているか。業界標準、プロトコルなど 信頼性 Reliability ソフトウェアが意図しない中断をしないで目的を遂げられるか 要件適合性 Requirements 製品に対する顧客の要求が抜け漏れていたり、期待と違っているアクセシビリティ Accessibility 障害のある人が情報に継続的に情報にアクセス・利用できるか 可能性 Capability ソフトウェアが既知の要件を満たしながら意図した目的を果たすか 26
  • 27. ImpactとISO 9126 Installability Integrity/Security Performance Maintenance Serviceability MigrationDocumentation Usability Standards ReliabilityRequirements Accessibility 9126にマップできそう Capability →標準なのでこちらに準拠すべき? 27
  • 28. Closer Sectionの属性• 修正対象(Target) • 欠陥を修正した成果物• 欠陥種類(Defect Type) • 欠陥の種類(修正対象に依存)• 状態(Qualifier) • 「欠陥種類」が今どういう状態なのかを示す• 履歴(Age) • 欠陥のあった成果物がいつ作成されたか• ソース(Source) • 欠陥のあった成果物の出所(内製、派生開発、アウトソースなど) 28
  • 29. 修正対象修正対象 Target 内容要件定義書 Requirements 要件定義書を直した場合 設計書 Design (基本・詳細、外部・内部)設計書を直した場合 コード Code コードを直した場合ビルド/パッケー ビルドスクリプト、ライブラリ、変更管理・バー ジ Build/Package ジョン管理システムなどを直した場合ドキュメント Information ユーザーガイド、インストールマニュアル、オン Development ラインヘルプを直した場合 29
  • 30. 欠陥種類欠陥種類 Defect Type 内容 Assignment/ 変数の代入ミス・初期化漏れ代入/初期化 Initialization 複数の変数への代入ミスはアルゴリズムへ パラメータや条件文のデータミス。条件文はif文やfor/while 検証 Checking ループの出口判定を含むアルゴリズム/メ Algorithm/ 設計変更なしでアルゴリズムやデータ構造の変更だけで修 ソッド Method 正できる効率の悪いコード、または欠陥関数/クラス/オブ Function/Class/ 正式な設計変更が必要な欠陥。重要な機能、UI、インター ジェクト Object フェイス、グローバルデータ構造の変更タイミング/直列 Timing/ 共有リソースを直列化していない、直列化対象の間違い、 化 Serialization 直列化の技術を間違えたインターフェイス/O-O Interface/O-O モジュール・オブジェクト間などのコミュニケーションミス メッセージ Messages (動的やりとり?) プロシージャ間・データ構造・オブジェクトの関連ミス(静 関連 Relationship 的な関連?) 30
  • 31. トリガーと欠陥種類 トリガー Fault Failure 欠陥検出のよしあし 作り込み工程 欠陥種類要件定義 設計 実装 テスト 31
  • 32. 状態状態 Qualifier 内容 ある状態が「ない」ことによる欠陥漏れ Missing 例:代入文がない ある状態が「誤っている」ことによる欠陥誤り Incorrect 例:判断文の値が間違っていた ドキュメントやソースと関係がない何かによる欠陥無関係 Extraneous 例:設計書に現在の製品と関係がない章があり、削 除対象である 32
  • 33. 履歴履歴 Age 内容 現在のプロジェクトによる修正部分になく、標準ラ 本体 Base イブラリでもない潜在欠陥 新規 New 新規作成部分にある欠陥 古い機能を設計・実装し直した部分に混入された欠書き直し Rewritten 陥再修正 Refixed 欠陥を改修しようとした部分に持ち込まれた欠陥 33
  • 34. ソースソース Source 内容 Developed 組織の開発チームによって開発された部分にある欠 内製 In-House 陥 既存のライブラリを使った部分にある欠陥。ライブ Reused From再利用 ラリの使い方が誤っていたか、ライブラリ自身の欠 Library 陥アウトソース Outsourced ベンダー開発部分にある欠陥 異なる環境で有効だったソースを転用した部分にあ 転用 Ported る欠陥 34
  • 35. ODCでわかること 参考資料http://www.research.ibm.com/softeng/ODC/ODCEG.HTM 35
  • 36. バグの収束判定 「機能」に関するバグ信頼度成長曲線上で は収束していない。収束傾向に見えても... Period2までに把握し て対策を打てる 36
  • 37. 高コストの原因究明 T2中心にバグを発見して いるためコスト高 Triggerを見るとT1でつぶすT0:設計・コードレビュー べきバグがT2まで残っているT1:単体テスト・結合テスト ように見える。これが原因T2:システムテスト 37
  • 38. バグはどこにあるか? Ageの分布 Base(潜在バグ)が大半を占める。 前ページと合わせて考えると ・本体部分に多くの積み残しバグ ・一旦テストを中断して本体部分の 既存バグ改修を優先すべき 38
  • 39. 真の顧客満足とは?Impactの分布 製品Aは仕様バ グ(Capability)が ほとんど 製品Bは信頼性 (Reliablity)と仕様 バグがほぼ同数 究極の選択?! 39
  • 40. 設計・コードの完成度 Defect TypeとQualifierの関係 設計変更が必要なバグで、漏れ と誤りがほぼ半々アルゴリズムの誤りが多い 【診断】要件定義の漏れが多い【診断】詳細設計の完成度が か、要件をうまく設計に落としいまいち 込めていない 40
  • 41. 維持管理の戦略 システムテストのトリガー分布起動、復旧、設定に関するバグは比較的初期に収束する 性能問題はカットオーバー後1年 1年目 2年目 以上経って現れる 運用ポリシーの参考にする 41
  • 42. 適用してみて 42
  • 43. 実バグ票への適用• とある過去プロジェクトの詳細なバグ票について実施• 約550件のバグ票のうち分類可能は約350件• 「状態」は漏れと誤りがほぼ同数、無関係はごく少ない• 欠陥種類のトップ3 • アルゴリズム • 検証 • インターフェイス• 大人の事情で詳細はごめんなさいm(_ _)m 43
  • 44. 問題点1:分類自体の難しさ• 属性が多い• 属性のとりうる値はさらに多い• 欠陥除去活動とトリガーの間に妙な依存関係がある• どれに該当するか迷う• テストケース・テストデータの誤りをどう扱うか不 明 44
  • 45. 問題点2:バグ票とのマッピングID サマリ 入力 期待結果 出力 重要度 原因1 ∼バグ ボタン押下 Aと表示 Bと表示 高 修正対象(Target) 状態(Qualifier) 要件漏れ 要件定義書 漏れ 設計書の記載ミス 設計書 誤り コーディングミス コード 無関係 設計との不整合 トリガー(Trigger) 設計との整合性 . ロジックフロー . 後方互換性 . 横の一貫性 あらかじめ定義しておく 45
  • 46. 問題点3:バグ1件の定義 • 現実のバグ票では同じようなバグを何件にもカウントしていた り、逆に1件でカウントされていたりとばらばら • 野中先生のSQiP 2010併設チュートリアルより • 「成果物に含まれる問題の原因部分について1件と数える」 • 原因が成果物にある場合→原因1件につき1件 • 原因がプロセスにある場合→修正箇所ごとにカウント • ODC分析の前にバグ票のカウント方式について確認する必要が ある 46
  • 47. まとめ 47
  • 48. まとめ• ODCとは「直交(交差)欠陥分類」• 定性的分析と定量的分析の両方の長所をとった分析方法• 8つの属性を持ち、各属性の取り得る値は重ならない(直交)• 実適用した結果 • 分類自体の困難さ • バグ票とのマッピングが必要 • 欠陥1件の定義を決めてからカウントする• うまくいくと欠陥の収束状況やリリース判断、プロジェクトコ ストの見積もりなどできる 48
  • 49. 資料• 後日Slideshareに上げます• WACATE向け勉強会資料 • http://www.slideshare.net/mori_ryuji/odc• バグ票ワーストプラクティスに寄稿した論文 • http://www.slideshare.net/mori_ryuji/ odc-14036416 49
  • 50. 今後の予定• 手近にあるレビュー結果へのODC適用• 時系列データの取得 • 時間的変化からプロジェクトへの提言へ• BTS・ITSへのODCスキーム組み込み • 分析結果グラフの自動生成など• ODC普及活動 50
  • 51. 告知!• 「ソフトウェア病理学」読書会第1回 (9/25) • (株)エクサ 13F セミナールーム • 「ソフトウェア病理学」で検索。続きはWebで• 「ソフトウェア開発プロジェクトはなぜ失敗するのか」 • プロジェクトの中断・赤字・低品質 • 症状・治療法・予防• これらの話にご興味のある方はぜひ 会場 51
  • 52. ご清聴ありがとうございました 52