ODC分析の導入

Size: px

Start display at page:

Download "ODC分析の導入"

たつぞうあんさい
4 years ago
Views:

3 教育ガイドラインチームメンバーの構成プラント制御組込みソフト Web IT システム以下の様な議論がありました ODCを現場に導入するにはどうしたらよいか? そもそも効果は? ODC 分類ガイドが欲しい ODC 分析ガイドが欲しいテストを担当しているがテストチームからどんな報告ができるか? 導入するにはどんな苦労があるか? どんな準備が必要か? Copyright ODC 分析研究会 All Right Reserved 3

ODC はバグ分析の一手法である 1992 年 IBM ワトソン研究所の Ram Chillarege 氏により発表された信頼度成長曲線 SGRM (Software Reliability Growth Model) 収束を見る具体的対策ない Signature 直交欠陥分類 ODC (Orthogonal Defect Classification)

4 ODC はバグ分析の一手法である 1992 年 IBM ワトソン研究所の Ram Chillarege 氏により発表された信頼度成長曲線 SGRM (Software Reliability Growth Model) 収束を見る具体的対策ない Signature 直交欠陥分類 ODC (Orthogonal Defect Classification) 即状況把握できる習得導入が大変根本原因解析 RCA (Root Cause Analysis) 真因を特定する時間がかかる ODC は開発プロセスに着目しあるべき状態と現在の状態を比較しどのプロセスに問題があったのか目星をつけるタイムリーに対策を打つことができプロセス改善に役立つ Copyright ODC 分析研究会 All Right Reserved 4

5 ODC はバグを複数の属性で分類しフェーズごとや時系列でグラフ化しあるべき割合と比較することで現課題の目星をつけ対応策により改善する手法である欠陥タイプ (Type) とトリガー (Trigger) が代表的なODC 属性である検出時にトリガー属性を付与する修正時に欠陥タイプ属性を付与する検出時修正時トリガー (Trigger) インパクト (Impact) 欠陥タイプ (Defect type) タイプ修飾子 (Qualifier) 混入元 (Source) 混入時期 (Age) Copyright ODC 分析研究会 All Right Reserved 5

6 検出活動ごとに属性がありどの活動を行っていて検出したかで決定する設計レビュー / コードレビュー単体テスト機能テストシステムテスト設計との整合性単純パスカバレッジ負荷 / ストレスロジック / フロー複雑パス組合わせ回復 / 例外後方互換性テスト順序起動 / 再起動側方互換性相互作用ハードウェア構成内部ドキュメントソフトウェア構成同時処理テスト阻害言語依存副作用レアケース検出活動は完全なウォーターフォール型プロセスであれば順番でこれらの活動を進めるしかし反復プロセスや機能ごとで開発を進める場合は五月雨式に活動が進むので別活動のそれぞれの属性を同じ日に検出したバグに付与してもかまわないまたレビュー活動観点のチェックを機能テストあるいはシステムテストで実施した場合も設計レビュー / コードレビューの属性を機能テストやシステムテストで付与してもかまわない Copyright ODC 分析研究会 All Right Reserved 6

7 欠陥タイプ属性はどのように修正したかで属性を決定する欠陥タイプ (Defect type) タイプ修飾子 (Qualifier) 代入/初期化 (Assignment/Initialization) 誤り (Incorrect) チェック/条件 (Checking) 漏れ (Missing) アルゴリズム/メソッド (Algorithm/Method) 無関係 (Extraneous) タイミング/順序 (Timing/Serialization) インターフェイス/オブジェクト間通信 (Interface/O-O Messages) 関連付け (Relationship) 機能/クラス/オブジェクト (Function/Class/Object) Copyright ODC分析研究会 All Right Reserved 7

ODCはIBMで開発され ITT, AT&T, Motorolaなどで活用されている運用するには ODC導入計画の策定が必要分類フローを参考にしても実際の正解率は from 50% to 70% Quality Plan Source 分析を正しく行うには少なくとも正解率は 80% or more

8 ODCはIBMで開発され ITT, AT&T, Motorolaなどで活用されている運用するには ODC導入計画の策定が必要分類フローを参考にしても実際の正解率は from 50% to 70% Quality Plan Source 分析を正しく行うには少なくとも正解率は 80% or more 必要 Type ODC Trigger Age Impact ネット上の情報を参考に分類しグラフ化しても開発状況を読み解けない正しく分類しないと分析できないバグが多い場合 2000~6000件有識者で分類すると大変 Copyright ODC分析研究会 All Right Reserved 8

9 導入する際いきなりすべての属性を活用するなどと欲張らないことが大切テストに懸念がある場合はトリガー属性から設計実装など品質作込みに懸念がある場合は欠陥タイプ属性とはじめるなどスモールスタートがよい導入計画例 : 日程イベント内容第 1 週目キックオフ ODC 概要の説明自部門の製品課題の解決を目標とする第 2 週目過去バグ分析例説明会過去の同系列のバグ分析を行いODC 分析による課題があきらかになることを説明する次週からODCトレーニングを開始することを担当者に通知し過去バグのODC 分類を20 件程度依頼する第 3 週目第 1 回トレーニング指導者と過去のバグをODC 分類の答合せを行い異なる部分を説明し合う ODC 分類を20 件程度依頼する第 4 週目第 2 回トレーニング指導者と過去のバグをODC 分類の答合せを行い異なる部分を説明し合う ODC 分類を20 件程度依頼する第 5 週目第 3 回トレーニング指導者と過去のバグをODC 分類の答合せを行い異なる部分を説明し合う第 6 週目実際の製品への導入計画説明バグ管理システムのどの欄にODC 属性を記述するか決め ODC 属性付与の役割を定めるテスト中盤現状の説明と ODC 分析例の説明実際に活用し課題抽出および分析対策を実施する Copyright ODC 分析研究会 All Right Reserved 9

10 ODC の分類トレーニングは実際のバグを分類するのが一番の近道である以下の様に実際のバグをあらかじめ分類し見解が異なる部分をどうして自分はそう思ったかを議論する設計メンバーは実際の修正コードがどうなっているのかを説明の上で最終的には有識者の意見に集約するように行う A さん分類 B さん分類有識者分類番号タイトル原因対策欠陥タイプ不備形態欠陥タイプ不備形態欠陥タイプ不備形態 01 アイコンがグレーで Disable のように見える 02 スキャン中にキャンセルするとダイアログが表示される画像のみ非活性にしていた原稿台と紙読込みの判定がまちがっていたボタンと画像を非活性となるよう属性を修正チェック不正初期化不正初期化不正判別プログラムを修正したチェック漏れアルゴリズム不正チェック不正 03 両面印刷時にカウント表示が正しくない両面時ページカウントを +1 としてカウントしていた両面印刷時は印刷全体枚数が偶数場合 1/2 奇数の場合整数部を 1/2+1 と修正機能不正チェック不正アルゴリズム不正 04 大量印刷後に再び印刷するとメモリーリーク 2 回目の印刷時ハンドルがなくメモリ解放できていないハンドル情報がなくてもメモリ解放するように変更機能漏れ初期化不正アルゴリズム不正 05 印刷ジョブが多重の場合連続スキャンになってしまう 2 つのスレッドが同時に処理されている場合スキャン状況が不正になっていた多重処理の場合スキャン情報が排他するように修正タイミング不正アルゴリズム不正タイミング不正 Copyright ODC 分析研究会 All Right Reserved 10

11 欠陥タイプ ( Type) 説明 ( Description ) 代入 / 初期化 ( Assignment/Initialization ) チェック / 条件 ( Checking ) アルゴリズム / メソッド ( Algorithm/Method ) タイミング / 順序 ( Timing/Serialization ) インターフェイス / オブジェクト間通信 ( Interface/O-O Messages ) ( 変数定数への ) 値の代入の誤りまたは初期化の誤り (Incorrect) または欠如 (Missing) If 文などの条件判定文での引数データに対する判定の誤りまたは欠如 ( ただし引数やデータの取得に関数が用いられる場合はアルゴリズムとする ) アルゴリズムの誤りまたは欠如データアクセスの順番制御やリソースアクセスに対する排他制御スレッドの同期処理の誤りまたは欠如機能ブロック間コンポーネント間プロダクト間又はハードウェアとソフトウェアの間のコミュニケーションに関する誤りまたは欠如関連付け ( Relationship ) 機能 / クラス / オブジェクト ( Function/Class/Object ) プロシージャーデータ構造やオブジェクトの継承 () に関連する誤りまたは欠如要求仕様との不整合機能性ユーザインターフェイス又はグローバルデータ構造の誤りまたは欠如 Copyright ODC 分析研究会 All Right Reserved 11

12 単純なコーディングミス? 値の代入初期化の修正? 代入 / 初期化 (Assignment/Initialization) if, switch, for, do while 文の条件の修正? チェック / 条件 ( Checking ) 詳細設計ミスあるいはレビュー漏れによるミスロジックの修正? あるいは初期化と条件を両方修正? アルゴリズム / メソッド (Algorithm/Methods) データアクセスの順番制御やリソースアクセスに対する排他制御スレッドの同期処理の修正? タイミング / 順序 ( Timing/Serialization ) 基本設計ミスあるいはレビュー漏れによる再基本設計と再コーディングで修正機能ブロック / コンポネント / プロダクト / ハードウェア / ソフトウェア間のコミュニケーションに関する修正? インターフェイス / オブジェクト間通信 ( Interface/O-O Messages ) H/W 起因の問題? ソフトウェア対象外あるいは H/W 起因の問題? プロシージャーデータ構造やオブジェクトの継承に関連する修正? 関連付け ( Relationship ) 対象外要件 / 基本機能 / クラスに関わる修正? ユーザーに多大な影響を与える修正? 機能 / クラス / オブジェクト ( Function/Class/Object ) Copyright ODC 分析研究会 All Right Reserved 12

13 ウォーターフォール型の場合大きく捉えると基本設計から詳細設計の不備またはレビューの不備により起きる複雑なバグはインターフェイスタイミングとして分類される詳細設計から実装にかけての不備によるバグは単純なバグとして初期化チェックに分類される複雑基本設計開発 V 字基本設計ではモジュール間のインターフェイスや I/O のタイミングを考慮し設計する単純複雑単純詳細設計詳細設計ではプログラムのフロー設定値や条件分岐を設計する単純な障害複雑な障害機能 (Function) は 10% 以下であるべき実装これらがテストで時間的にどう出てくるのかを見てシステムの安定度を判断する Copyright ODC 分析研究会 All Right Reserved 13

14 テスト全体を大きな流れで考えると大通り (Basic), 小路地 (Detail), トリッキー / 意地悪 (Deep), 最終的には収束を迎える. 大通り (Basic) テストでは単純なバグがでる小路地 (Detail) テストでは複雑なバグのうち Interface が中心に出るトリッキ -/ 意地悪 (Deep) テストでは複雑なバグのうち Timing が出る最終的には数的には減少するが Algorithm が残るというパターンを基本として理解すると捉えやすい漏れ (Missing) は 20~30% に減少して収まる Copyright ODC 分析研究会 All Right Reserved 14

15 大規模開発の一例として複合機能コピー機のよい結果例を示す実際には単体テストでのバグ管理がされていることが稀なので初期化が 38% を占めるグラフは珍しい機能が 15% を占めているが単体テストなので問題ではない機能が 3% である 10% 以上の場合は赤信号と考え問題点を分析する初期化が 5% で理想形である単体テストが完全な例は少ない 10 から 20% であれば単体テスト不備の分析が必要タイミングインターフェースが 10% 出ている全結合テストが適切に実施できている機能は 2% で安定している負荷や例外などの Deep なテストが実施できておりタイミングインターフェイスが 16 から 17% を占めている初期化やチェックも機能テストより若干増えているシステムテストを時系列でみるとタイミングインターフェイスも終盤は収束傾向がみられるべきである Copyright ODC 分析研究会 All Right Reserved 15

派生開発では追加機能分のテストケース追加は必要だが一連のテストケース群は再利用できる従ってトリガー属性の分布もある程度固定される

:40% テスト順序 :11% 相互作用 :10% 同系統の製品のトリガー分布を蓄積しそれらと比較することでより詳細な分析カバレッジ :41%

相互作用 :12% 相互作用 :10% である製品系列で傾向を分析カバレッジ :48% 組合わせ :28% テスト順序 :2% カバレッジ :45%

16 派生開発では追加機能分のテストケース追加は必要だが一連のテストケース群は再利用できる従ってトリガー属性の分布もある程度固定されるテストケースでトリガーが決まるカバレッジ :41% 組合わせ :38% テスト順序 :9% 相互作用 :12% カバレッジ :39% 組合わせ :40% テスト順序 :11% 相互作用 :10% 同系統の製品のトリガー分布を蓄積しそれらと比較することでより詳細な分析カバレッジ :41% 組合わせ :38% テスト順序 :9% カバレッジ :39% 組合わせ :40% テスト順序 :11% 予測が可能をすると精度が高いトリガー分析が可能相互作用 :12% 相互作用 :10% である製品系列で傾向を分析カバレッジ :48% 組合わせ :28% テスト順序 :2% カバレッジ :45% 組合わせ :30% テスト順序 :5% 予測が可能相互作用 :22% 相互作用 :20% Copyright ODC 分析研究会 All Right Reserved 16

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション 5 月 Java 基礎 1 タイトル Java 基礎 2 日間概要目的サーバサイドのプログラミング言語で最もシェアの高い Java SE の基本を習得します当研修ではひとつの技術ごとに実用的なアプリケーションを作成するため効果的な学習ができます Java SE の多くの API の中で仕事でよく利用するものを中心に効率よく学びます実際の業務で最も利用される開発環境である Eclipse