Comments
Description
Transcript
ODC分析による欠陥除去と 品質成熟度の可視化
SEC高信頼化技術適用事例 ODC分析による欠陥除去と 品質成熟度の可視化 ～医療機器の安全性・高品質を担保するために～ ２０１４年７月２９日 オリンパスソフトウェアテクノロジー株式会社 山崎 隆 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. ODC: Orthogonal Defect Classification （直交欠陥分類） Agenda 2 １ 背景 ２ ODC分析とは ３ ODC属性について ４ ODC分析の進め方 ５ ODC分析導入にあたって ６ 今後の発展性について ７ まとめ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 Agenda 3 １ 背景 ２ ODC分析とは ３ ODC属性について ４ ODC分析の進め方 ５ ODC分析導入にあたって ６ 今後の発展性について ７ まとめ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 オリンパスの医療事業 4 52 内視鏡システム EVIS EXERA III / EVIS LUCERA SPECTRUM 小腸用カプセル内視鏡 外科用エネルギーデバイス ※実際のカプセルにはロゴが入っていません。 THUNDERBEAT 世界初、バイポーラ高周波・ 超音波の統合エネルギー デバイス 内視鏡外科手術統合システム ENDOALPHA 内視鏡洗浄消毒装置 OER Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 医療機器に求められることとは 5 52 生命の安全にかかわる医療機器は、求められる安全性・品質のレベルが格段 に高くなっています。 医療機器の開発において重要なことは、手技を理解してリスクマネジメントを行 い、リスクの高い事象に対しては、設計上しっかり対処することです。 使用する人の意思通りに動くことは当然として、トラブル時を含めたあらゆる ユースケースを想定し、万が一にも正しく動かなくなってしまった場合でも、患者 様や、医療従事者への損害を限りなく少なくするため、きめ細やかな仕様を設 定し、その仕様を確実に検証し、品質を高めることが求められています。 製品の安全性をソフトウェア開発の観点から規制する動きが世界中で活発化し ておりソフトウェア開発に対する法規制への対応も必須となっています。 安全性 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 高品質 ODC分析の対象領域 6 52 ソフトウェアの検証領域における分析手法であり、その分析対象は、要求分析/ 定義から検証業務に至るソフトウェア開発全体に及びます。 （ハードウェアも含めたシステム全体） ユーザーニーズ 妥当性検証 システム/サブシステム 要求分析/定義 システム/サブシステム テスト システム/サブシステム 基本設計 システム/サブシステム 結合・結合テスト サブシステム/ コンポーネント開発 ソフトウェア 要求分析/定義 ソフトウェア 基本設計 ＯＤＣ分析の 実施領域 ＯＤＣの 分析対象 ソフトウェア 詳細設計 ソフトウェア システムテスト ソフトウェア 結合テスト ソフトウェア ユニットテスト 検証領域 ソフトウェア実装 （コンポーネントとしてのソフトウェア） Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 品質可視化の手法群での位置づけ 7 52 ODC分析は障害発生状況と原因分析のための手法です。 情報の蓄積と活用 障害原因の分析 障害件数の把握 ①品質管理図 ②ODC分析 残存障害の予測 ③信頼度成長曲線 ④品質メトリクス 障害密度 単体 障害発生状況と原因の分析 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 結合 システム 出荷 Agenda 8 １ 背景 ２ ODC分析とは ３ ODC属性について ４ ODC分析の進め方 ５ ODC分析導入にあたって ６ 今後の発展性について ７ まとめ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 ODC分析とは 9 52 概要： Orthogonal Defect Classification（直交欠陥分類、以下ＯＤＣ）に よる分析は、1992年 IBM Watson研究所により提唱された障害の 定量的分析手法。排他的（Orthogonal）な複数の属性を用いて分 析することにより、障害を多次元のソフトウェア空間領域上に位置 づけることできる。 具体的にODC分析では検出された障害に直交した複数の属性を付 与し、多角的な視点から分析を行う。独自で重複・冗長性のない属 性を定義し、その属性のみに注目しながら分類することにより効率 的に分析を行うことができることを特徴とする。 ODC分析により得 られる結果は、偏在する障害領域を特定するだけではなく、それが 作り込まれた開発工程をも特定することが可能となる特徴を有する。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. ODC分析の位置づけ ■ 10 52 ODC分析の特徴 障害分析の代表的な手法には、「統計的手法」と、「要因分析的手法」がある。 「ODC分析」は、両者の中間に位置する分析手法。 2 要因分析的2 手法 3 統計的 手法 過去のデータとの比較、 成熟度曲線モデル を用いる手法。 ODC 不具合の 詳細を調査する手法 是正処置に直結しない Orthogonal Defect Classification （直交欠陥分類） 多くの労力・コストが必要 容易に現状を理解することはできるが、 原因の分析や発生工程の特定ができない。 個々の不具合の意味論を 捕らえ、その分布をもとに 製品の経過、成熟度を考察する 効率よく原因・傾向が分析できる Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 障害の発生原因や工程はわかるが、 障害件数に比例して、実施が困難となる。 ODC分析とは 11 52 例えるならこういうこと・・・ 統計的手法 ODC分析 現在の総数は ○件・・・。 この1週間で○ 件増加。 要因分析的手法 あらかじめ障害 内容に応じてタ グをつけたよ。 タグの数を集計 してみたよ。 全体を眺める タグだけを見る 特別な手間を掛けずに品質 を捉えることができるが、中 身を知らないので問題点の 特定などはできない。そのた め是正処置に繋がりにくい。 手間を掛けずに障害傾向を 捉えることができる。複数の 観点で多角的に分析すること で問題点の特定もできる。 障害を多方面からみると、線の交わる 箇所に真の問題が潜んでいたりする！ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 障害１の原因は○○で重要度は 2 ○、作りこみ工程と障害機能の関 2 連が高いため品質向上のために 3 は・・・ 障害２の場合は・・・ 全てを調べる 障害 障害の発生原因や発生工程 など、何もかも把握できるが、 とにかく手間が掛かる・・・。 ODC分析の考え方 12 52 ODC分析では発見された不具合に属性を付与し、多角的な視点から分析を行う。 独自で重複・冗長でない属性定義（＝直交した属性定義）を用いることで、効率よい分析を 行うことができる。 属性の例 【検出工程】 【修正タイプ】 出荷後 ＳＷシステム試験 結合試験 単体試験 ソフトウェア空間（多くの障害を含む） 機能 インターフェイス タイミング アルゴリズム 代入・初期化 この辺に潜むのは サソリ級の障害 この辺りに潜むのは ミジンコ級の障害 利点１：不具合分析の観点充実と効率化 付与した属性の分析により、不具合の発見や修正内容に関する特徴・傾向がわかる。 ・個々の不具合を調査する前にODC分析を行うことで、問題箇所の推定ができる。 ・不具合の発見や修正内容に関する特徴・傾向から、ソフトウェアの成熟度を推定できる。 利点２：不具合分析によるプロセスの改善 ソフトウェア開発プロセスの面から不具合を分析することができる。 ・個々の不具合に対する対策を立てるためではなく、ソフトウェア開発プロセスのどの工程に問題が あったのか特定し、プロセス改善のために分析を行う。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. ODC分析で解ること 13 実例１ 52 「発生トリガー」による試験成熟度の評価 ①全体として障害は収 束傾向にあるといえる。 ②しかし、検出された障害の ７割近くがいまだに単純な操 作によるものであり、試験が 成熟している （＝やりつく し 2 た）とは言えない。 2 3 ③さらに、まったく検出されて いない障害があり、これらは 実運用開始後（＝出荷後）に 検出される可能性が高い。 試験の成熟度が評価でき、潜在障害の有無を推測できる。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. ODC分析で解ること 14 実例2 52 「障害タイプ」による実装成熟度の評価 結合試験 SWシステム試験 ①結合試験からSWシステム試験へと移行 しているにもかかわらず、障害の出現傾向 に大きな変化が無いことから、開発または 試験が狙い通り進んでいないと考えられる。 2 2 ②特にSWシステム試験終盤に 3 なって、「機能・クラス」など影響 範囲の大きい修正が続いており、 二次障害が懸念される。 ③さらにケアレスミスが全期 を通してほぼ一定の割合で 発生している。実装が成熟し ているとは考えにくい。 実装の成熟度が評価でき、潜在障害の有無を推測できる。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 導入のメリット・デメリット 15 メリット １．品質が客観的にわかる 傾向を様々な角度から分析でき、成熟度をはじめとする傾向分析が可能である。 2 2 「障害タイプ」と「障害実装タイプ」から、どの工程で不具合を埋め込んだか容易に 3 ２．開発工程の問題点がわかる 推測できる。これら情報が無いと障害処理票から詳細を読み取り、不具合の埋め 込み工程を推測しなければならない。 ３．要因分析的手法よりコストがかからない ODC分析は分析用に付けたタグに基づき分析するので、詳細を見ない分だけ、要 因分析手法より低コスト（簡単）である。 デメリット（課題） 分析用タグの分だけ入力する手間がかかる また入力方法について基本的な知識が必要。慣れるまでは大変である。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 Agenda 16 １ 背景 ２ ODC分析とは ３ ODC属性について ４ ODC分析の進め方 ５ ODC分析導入にあたって ６ 今後の発展性について ７ まとめ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 ODC属性について ■ 17 52 ODC属性とは？ ODC分析を実施するには、あらかじめインシデントをいくつかの観点で分類する必要がある。 その各観点を、ODC分析では「ODC属性」と呼び、全部で５つ＊の属性を採用している。 ＊実際には８つ定義されているが、そのうちの５つを適用している。 ODC属性 検出工程 障害タイプ 発生トリガー 障害実装タイプ 修正ソース種別 ■ ODC属性は様々なプロジェクトの障害実績から統計的 に設定されているため、あらゆるプロジェクトに対して 適用することが可能。共通の属性を使うことで、プロ ジェクト間の品質分析ができるようになる。 発見者により決定する属性 修正者により決定する属性 障害情報とODC分析 ただし、ODC分析ではODC属性だけを分析するとは限らない。実際の分析では、一般的な 障害情報である「ランク」や「発生日」、あるいは障害管理DBに登録する「ステータス」など も、ODC分析の材料として併用している。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. ODC属性について ■ 18 ODC属性の分類 今回対象としたODCの共通属性 （1） 検出工程 （Defect Removal Activities） （2） 発生トリガー （Triggers） （3） 障害タイプ （Defect Type） （4） 障害実装タイプ （Qualifier） （5） 修正ソース種別 （Age） 個別対応としたODC属性 （６） 影響範囲 （Impact） （７） 発生箇所 （Target） （８） 発生源 （Source） Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 全ての プロジェクトで 共通に 使用する ＯＤＣ属性 プロジェクト毎に 個別に 設定する ＯＤＣ属性 52 属性① 「検出工程」 ■ 19 「検出工程」 内容 用途・目的 発見者が登録 障害を検出した工程を識別する。 検出時期から、問題の深刻度、テストの成熟度を推測する。 選択肢 意味 備考 結合試験 結合試験中に検出された障害。 小 SWシステム試験 SWシステム試験中に検出された障害。 出荷試験 出荷試験中に検出された障害。 出荷後 ユーザーに納入後に検出された障害。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 深 刻 度 大 検出工程は、いつ障害 が検出されたかを示す。 同ランクの障害なら、よ り下流で検出される方 がプロダクトとしては深 刻といえる。 52 属性② 「発生トリガー」 ■ 20 1/4 「発生トリガー」 内容 用途・目的 発見者が登録 障害を検出するに至ったきっかけを識別する。 手順の複雑度から、テストの成熟度を推測する。 選択肢 意味 基本操作（標準設定） 備考 小 基本操作（オプション等の変更あり） 操作順序に依存 複数機能の相互作用 負荷・ストレス 次ページ参照。 手 順 の 複 雑 度 回復・例外 起動・再起動 構成 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 大 発生トリガーは、試験 手順の複雑度を示す 指標となる。 よ り 複雑な試験が 行 われているほど、試験 は成熟している（しっ かり試験されている） といえる。 52 属性② 「発生トリガー」 21 2/4 選択肢の意味 選択肢 意味 基本操作 （標準設定） パラメーター、オプションなどは全く変更せず、単一機能のみを 実行した時。 2 パラメーター、オプションなどを変更し、単一機能のみを実行し 2 た時。 3 基本操作 （オプション等の変更あり） 操作順序に依存 複数の機能を特定の順番で実行したとき（各機能を別々に行え ば正常動作する場合）、 もしくは単一機能を何回も実行した時。 複数機能の相互作用 複数の機能が同時に動作しているとき。もしくはその後。 負荷・ストレス 各リソース （メモリーなど）の限界値付近でテストした時。 回復・例外 リカバリー/例外処理のテストケースを実行した後。 起動・再起動 シャットダウン、スリープ、ネットワーク遮断、電源遮断などから 通常状態に戻した後。 構成 あるソフトウェアをダウンロード/インストールした後。もしくは、 あるハードウェアを接続した後。 次ページ「フローチャート」も参照 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 属性② 「発生トリガー」 スタート 不具合の再現 手順をイメージ する H/WあるいはS/W構成を変更した ことによって不具合が見つかったか？ 例外処理後の起動あるいは 再起動で不具合が見つかったか？ 意図的にシステムレベルの例外処理を 試すための試験で不具合が見つかったか？ 意図的にシステムレベルの限界値付近を試すための試験、 システムに対してストレスを与える試験で不具合が見つかったか？ Yes 複数の機能を同時に実行 したことによって不具合が見つかったか？ No 複数機能を特定の順番で実行 したことによって不具合が見つかったか？ １つの機能のみの試験で 不具合が見つかったか？ やり直し 22 3/4：選択肢の選び方 同じ手順の繰り返しによって 不具合が見つかったか？ 入力値・パラメータの変更 によって見つかったか？ もっとも近いものを選び直してください。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 構成 HW/SW Configuration 起動・再起動 Startup/Restart 回復・例外 Recovery/Exception 負荷・ストレス Workload/ Stress 2 2 3 試験の「狙い目」に着目 手順の複雑さに着目 （次ページも参照） 複数機能の相互作用 Interaction 操作順序に依存 Sequencing 基本操作（オプション等の変更あり） Variation 基本操作（標準設定） Basic, Coverage 52 属性② 「発生トリガー」 23 4/4 52 発生トリガーにおける手順の複雑さ （オプション等の変更あり） 操作順序に 依存 複数機能の 相互作用 パラメータ、オプション などを変更し、単一機 能のみを実行したとき に不具合が見つかっ た。 複数の機能を特定の 順番で実行したとき、 もしくは単一機能を何 回も実行したときに不 具合が見つかった。 複数の機能が同時に 2 動作しているとき。もし 2 くはその後に不具合が 見つかった。 3 基本操作 基本操作 （標準設定） オプションなどは全く 変更せず、単一機能 のみを実行したときに 不具合が見つかった。 既定状態 入力値変更 × × × × × Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 属性③ 「障害タイプ」 ■ 24 1/2 「障害タイプ」 内容 用途・目的 修正者が登録 修正内容に基づき、障害の種類を分類する。 他の情報と組み合わせて障害の深刻度、影響範囲を推測する。 選択肢 意味 値の代入/初期化 備考 小 値のチェック アルゴリズム 共有リソースのアクセス制御 次ページ参照。 インタフェース/メッセージ 他 へ の 影 響 度 関連付け 大 機能/クラス GUI Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 次ページ参照。 障害タイプは、その障害 が他に与える影響を考え る上での指標となる。 開発終盤で影響度の大 きい障害が多発する場 合は注意が必要である。 52 属性③ 「障害タイプ」 25 2/2 選択肢 意味 値の代入 /初期化 値の代入、初期化の修正が必要な障害。（ただ 値の初期化ミス／クラス生成時にコンスト し、複数のステートメントの修正が必要な場合は、 ラクター呼び出し忘れ、呼び出し結果が正 「アルゴリズム」を選択する。） しくない・・・ 値のチェック 条件式におけるデータチェックの修正が必要な 障害。（ただし、複数行の修正が必要な場合は、 「アルゴリズム」を選択する。） IF文、switch文の値チェックミス・処理忘れ ／メソッド引数のチェック部のミス・処理忘 れ・・・ アルゴリズム メソッド内、関数内のロジックの修正が必要な障 害。 IF文内の処理のロジックミス／リスト構造 のサーチロジックのミス／ローカルデータ 複数行 （単一モジュール） 構造のミス・・・ 共有リソース のアクセス制 御 共有リソースのアクセス制御部分の修正が必要 な障害。 排他処理ミス／共有メモリ上のデータ更新 処理の順番ミス・・・ インタフェース /メッセージ モジュール、デバイスドライバー、関数、コンポー ネント、オブジェクト間の、パラメータやデータ受 け渡しなどにかかわる修正が必要な障害。 インターフェースは数値へのポインターを 指定しているが、コードそのものは文字へ のポインターと扱っていた場合など。 関連付け クラス内のメソッド、データ間の問題、インスタン ス化および継承に関する修正が必要な障害。 クラスメソッドがオーバーライドされていて 動作が予想と違っていた、インスタンス可 数が間違って制限されていた場合など。 機能/クラス 設計変更を必要とし、機能実現性や（ユーザー、 ハードウェアなどに対する）外部インターフェー ス、グローバルデータの構造に影響する障害。 クラス不足、データサイズが要求に満たな い、などの機能実現性に影響する設計変 更が必要な場合。 リソースデータのみ修正が必要な障害。ソース コードの修正は不要。 GUIリソースの修正など。 GUI Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 具体例 52 修正・影響範囲 小 単一行 2 2 3 影 響 範 囲 複数個所 設計 全体 大 属性④ 「障害実装タイプ」 ■ 26 「障害実装タイプ」 内容 用途・目的 修正者が登録 障害の実装パターンを３種類で分類する。 障害の混入時期とあわせてプロセス上の問題箇所を推測する。 選択肢 意味 備考 誤実装 誤って実装。 多くの障害は「誤実装」を原因とする。 実装し忘れ。 もし開発終盤になって「実装し忘れ」が検出 された場合、プロセスに問題があると推測 できる。 余計な実装が障害の原因となった 場合。 「余分」が障害の原因となることは少ないが、 発生した場合は原因を調べる必要がある。 未実装 余分 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 属性⑤ 「修正ソース種別」 ■ 27 「修正ソース種別」 内容 用途・目的 修正者が登録 コードを修正した場合、そのコードの種類を識別する。 潜在障害の有無およびその影響範囲検証プロセスの精度を推測する。 選択肢 意味 新規 今回の開発で新規に作成したコー 一般的な問題。 ドで問題が発生。 既存 以前の開発から流用したコードで すでに出荷済みのソフトウェアにも、潜 障害が発生。 在的障害があることを示す。 改造/変更 二次障害 備考 以前の開発から流用したコードを改 良した箇所で障害が発生。 大量に検出された場合、影響範囲の確 障害を修正した箇所で別の障害が 認不足などが考えられる。 発生した。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 Agenda 28 １ 背景 ２ ODC分析とは ３ ODC属性について ４ ODC分析の進め方 ５ ODC分析導入にあたって ６ 今後の発展性について ７ まとめ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 ＯＤＣ分析の流れ 29 ＯＤＣ分析のステップ Step1：全体像の確認 障害ランクの推移 発生トリガーの推移 品質の可視化 障害タイプの推移 発生トリガーの分布（発生箇所別） 障害タイプの分布（発生箇所別） 成 熟 度 の 検 証 網 羅 率 の 検 証 まず障害数と障害ランクから品質の全体像を捉える。こ こでは品質を、「良いと言える」、「悪いと言える」、の2段 程度で考える。 Step2：潜在障害の推測 品質は顕在障害数だけではなく、潜在障害も考慮して判 断する必要がある。そのため潜在障害の有無を、「成熟 度」と「網羅率」の2つの観点から確認する。 必要に応じて「修正ソース種別と障害タイプの関係」、 「発生トリガーと障害タイプの関係」も参照する.。 結果の裏づけ （中間評価） Step1と2の結果より、品質を判断する。 障害タイプと障害実装タイプの関係 Step3：プロセスの検証 （品質管理図などによる障害修正状況の確認） さらに、障害対応プロセスの健全さを検証し、中間評価 の裏づけとする。必要に応じて、品質管理図等により障 害修正・確認が滞りなく実施されているか確認する。 Step4：完成度の検証 解決状況の推移 （最終評価） Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 最後に解決状況の推移を確認し、修正されるべき障害が 修正されていることを確認する。 Step3と4の結果より、品質を判断する。 52 分析事例 「発生トリガーの推移」 目的 30 52 障害検出の「きっかけ」の変化に着目し、試験の成熟度を確認する。 あるべき姿 単純系の障害収束に伴い、 複雑系障害が試験後半で検 出されている。 問題事例 最終的に満遍なく発生トリ ガーが検出されている。 2 2 単純系の障害が主体。より 複雑な試験を行うことにより 3 さらに障害が検出されると考 えられる。 単純系の障害が早い 段階で収束している。 出現傾向にバラツキがあり。まだ試験 されていない手順があると考えられる。 ポ イ ン ト ・ より単純な障害（簡単に見つかる障害）は試験前半で出尽くし、後半はより複雑な傷害（見つけにくい障害） が検出されていることで、試験が成熟していることを確認する。 ・ 発生トリガーの偏りがなく、満遍なく障害が検出されていることも重要。 ・ 成熟の度合いは、同一製品の前バージョンの同一時期と比較するのが効果的。該当製品が無い場合は、 同一規模の他製品、あるいは現在のフェーズがSWシステム試験であれば、結合試験の状況と比較してみ るのも有効。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 分析事例 「発生トリガーの推移（工程別）」 目的 31 52 試験フェーズごとの傾向の変化に着目し、試験の成熟度を確認する。 あるべき姿 結合試験 問題事例 SWシステム試験 2 2 3 傾向に変化が見られない。フェーズが進行した が、試験が成熟したとは考えにくい。 障害が収束傾向にあり、か つより複雑なトリガーで構 成されている。 単純系の障害は結合試験 で出し尽くしているため、 SWシステム試験では検出 されない。 ポ イ ン ト ・前フェーズの試験と比較して、状況の変化（改善具合など）を確認したい場合に有効。 ・ 前フェーズと比較して状況が改善されていることを確認。 ・ その他の着目すべき点は、前頁の「ポイント」を参照のこと。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 障害総数は減少しているが、相変わらず基本 障害の占める割合が大きい。成熟していない。 分析事例 「発生トリガーの分布（工程別）」 目的 32 52 工程ごとの発生トリガーの傾向に着目し、然るべき時期に障害が検出されていることを確認する。 あるべき姿 問題事例 結合試験でシステム全 体に関わる障害が検出 されている。試験が戦略 的に実施されていない可 能性がある。 2 2 3 結合試験では「基本操作」 系を中心に、単機能に着目 した障害検出されている。 SWシステム試験にな り、「負荷・ストレス」な どの非機能用件、「回 復・例外」などの異常 系処理、「起動･再起 動」や「構成」などシス テム全体に関わる試 験が実施されている。 必要に応じて単体試験、受 入試験も評価対象とする。 ポ イ ン ト ・ 発生トリガーの分布より、各フェーズで目的とされている試験が実施されていることを確認する。 ・ 具体的には結合試験では、より単純な障害（簡単に見つかる障害）が検出され、SWシステム試験ではより 複雑な障害が主に検出されていることを確認する。グラフがこの傾向を示さない場合、試験が戦略的に実 施されていない可能性を疑う。 ・ このグラフは「発生トリガーの推移」の最終日と同じ結果となります。発信すべきメッセージに合わせてグラ フを使い分けると良い。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. SWシステム試験では、結合試験と比 較してより複雑な障害を検出している が、相変わらず基本的な障害が多い。 結合試験の実施が不完全と考えられる。 分析事例 「発生トリガーの分布（発生箇所別）」 目的 33 52 機能ごとの障害発生量から試験の網羅度を推測し、発生トリガーよりその成熟度を確認する。 あるべき姿 問題事例 障害が検出されていない機能があ る。試験モレがあると考えられる。 発生トリガーの見方については、 「発生トリガーの推移」を参照のこと 2 2 3 発生トリガーの出現傾向に偏りが ある。原因を確認する必要がある。 全機能から満遍なく障害を検出 しており、試験が網羅的である。 ポ イ ン ト ・ モジュール毎に、各フェーズで目的とされている試験が実施されていることを確認する。 ・ 同時期、同規模で開発されたモジュールであれば、同程度の障害傾向が出現すると考えられるため、他と 比較して偏りのあるモジュールでは注意が必要です。ただし、障害数の過多はモジュールの規模により異 なるため、障害密度、試験密度などのメトリクスとあわせて確認すべき。 ・ このグラフは、「発生トリガーの推移」をモジュールごとに詳細化したもの。発信すべきメッセージにあわせ てグラフを使い分けると良い。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 障害のほとんどが「その他」に分類 されており、分析にならない。機能 の分類方法を見直す必要がある。 分析事例 「障害タイプの推移」 目的 34 52 障害内容の変化に着目し、設計及び実装の成熟度を確認する。 あるべき姿 問題事例 「機能/クラス」など設計に起因する より深刻な障害（修正影響範囲の 大きい障害）が少なく、極端な増加 傾向も見られない。 2 2 3 全体に占める軽微なミスが多い。コーディング 規約などの点検を行う必要がある。 「値の代入/初期化」、「値の チェック」など、実装の未熟さ を表す問題が、早期に収束し ている。 ポ イ ン ト ・ 障害内容の変化から、ソフトウェアの設計／実装が成熟していることを確認する。 ・ 実装の基本的なミスである「値の代入」、「値のチェック」が時間の経過とともに減少していることを確認し、実装の成熟 度を判断する。また、アーキテクチャ設計の問題に相当する「機能/クラス」など、より深刻な障害（影響範囲の大きい 障害）の増加傾向より、設計の成熟度を検討する。 ・ 成熟の度合いは、同一製品の前バージョンの同一時期と比較するのが効果的です。該当製品が無い場合は、同一規 模の他製品、あるいは現在のフェーズがSWシステム試験であれば、結合試験の状況と比較してみるのも有効。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 設計に起因する障害が終盤まで発生している。 今後も大規模な修正が必要となるため、デグ レード、仕様の不整合が生じる可能性がある。 特定の障害タイプに偏りがある場合は設計プロ セスのいずれかに問題があると考えられるので 原因を調査する。 分析事例 「障害タイプの推移（工程別）」 目的 52 試験フェーズごとの傾向の変化に着目し、設計及び実装の成熟度を確認する。 あるべき姿 結合試験 問題事例 SWシステム試験 2 2 傾向に変化が見られない。フェーズが進行した 3 障害が収束傾向にあり、特 に影響度の大きな障害が 減少している。 が、試験が成熟したとは考えにくい。 単純な障害は結合試験 で解決されているため、 SWシステム試験では検 出されない。 ポ イ ン ト 35 ・ このグラフは、前グラフの代わりに用いることができます。特に前フェーズの試験と比較し て、状況の変化（改善具合など）を確認したい場合に有効。 ・ 前フェーズと比較して状況が改善されていることを確認する。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 障害総数は減少しているが、相変わらず基本 障害の占める割合が大きい。成熟していない。 分析事例 「障害タイプの分布（工程別）」 目的 36 52 工程ごとの障害タイプの傾向に着目し、然るべき時期に障害が検出されていることを確認する。 あるべき姿 問題事例 結合試験では設計に起因し修正の影響範囲も大きい と考えられる「機能/クラス」などが修正されている。 設計に起因する障害が 減少せず、相対的に増 加している 。設計は成 熟していないと考える。 2 2 3 同様に「値のチェッ ク/代入」に代表され る実装の単純ミスが 修正されている。 SWシステム試験になり、単純な 実装ミスや、逆に修正影響範囲 の大きい重大障害は減少してい る。 特定の障害タイプに偏りがある場合は設計プロ セスのいずれかに問題があると考えられるので 原因を調査する。 ポ イ ン ト ・ 障害内容が各フェーズにふさわしいか、障害タイプより類推する。具体的には、結合試験までに「値の代入 /初期化」などの実装単純ミス、および「機能・クラス」など設計にかかわる重大にミスが修正され、SWシス テム試験以降ではこれらに起因する障害が減少していることを確認する。グラフがこの傾向を示さない場 合、設計・実装の成熟度を疑い、開発プロセスが適切か検証する。 ・ このグラフは「障害タイプの推移」の最終日と同じ結果となる。発信すべきメッセージにあわせて、グラフを 使い分けると良い。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 全体に占める軽微なミスが 減少せず、相対的に増加し ている。実装は成熟してい ないと考える。 分析事例 「障害タイプの分布（発生箇所別）」 目的 37 52 機能ごとの障害発生量から試験の網羅度を推測し、障害タイプよりその成熟度を確認する。 あるべき姿 問題事例 障害が検出されていない機能があ る。試験モレがあると考えられる。 障害タイプの見方については、「③障害タイプ の推移」を参照してください。 2 2 3 障害タイプの出現傾向に偏りがあ る。原因を確認する必要がある。 全機能から満遍なく障害を検出 しており、試験が網羅的である。 ポ イ ン ト ・ モジュール毎に、各フェーズで目的とされている試験が実施されていることを確認する。 ・ 同時期、同規模で開発されたモジュールであれば、同程度の障害傾向が出現すると考えられるため、他と 比較して偏りのあるモジュールでは注意が必要です。ただし、障害数の過多はモジュールの規模により異 なるため、障害密度、試験密度などのメトリクスとあわせて確認する。 ・ このグラフは、「障害タイプの推移」をモジュールごとに詳細化したもの。発信すべきメッセージにあわせて グラフを使い分けると良い。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 分析上、無視できない件数が「そ の他」に分類されている。機能の 分類方法など見直す必要がある。 分析事例 「障害タイプと障害実装タイプの関係」 目的 38 52 障害タイプごとの障害実装タイプより、設計プロセスの弱点を推測する。 あるべき姿 問題事例 機能・クラスの実装モレが多く、上流段階での作 りこみが不足していると考えられる。より広範囲 な問題を抱えている可能性あり。 より深刻な問題といえる「未実装」（＝実装モ レ）が、誤実装（＝実装ミス）よりも少ない。 2 2 3 未実装の中でも、特に深 刻な「機能・クラス」の未 実装がほとんどない。 その他、障害タイプが偏っている場合は、原 因工程を確認する。（次ページも参照） 次ページ：障害タイプと障害実装の関係 ポ イ ン ト ・ 障害タイプと障害実装タイプの関係から、より影響範囲の大きい問題（仕様・設計に関わ る問題）が少ないことを確認する。 ・ 障害タイプの分布に偏りが見られる場合は、障害実装タイプとの関係から、開発工程の どこに問題があるのか特定し、必要に応じて是正措置をとる。 ・ 障害タイプと障害実装タイプの関係は次ページを参照のこと。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 障害タイプと障害実装タイプの因果関係 未実装 影響大 要件・仕様 策定 開 発 工 程 設計 機能・クラス I/F・メッセージ 機能・クラス 関連付け アルゴリズム 値のチェック 同じ未実装・誤実装 でも、その内容により、 原因工程は異なると いえる。 値の代入・初期化 アルゴリズム 実装 影響小 52 機能・クラスの未実装（実装モレ）は、要件・ 仕様の策定段階に問題があると考えられ、 その影響範囲は大きい。 I/F・メッセージ 詳細設計 39 誤実装 関連付け アーキテクチャ 1/2 値の代入・初期化 値のチェック ※主な障害タイプのみ表示 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 値のチェックなどの 誤実装は、単なる コーディングミスと考 えられる。 障害タイプと障害実装タイプの因果関係 障害タイプ 障害実装タイ プ 機能/クラス 40 2/2 未実装 誤実装 ①要件・仕様 ③アーキテクチャ設計 ②要件・仕様（レビュー） ④アーキテクチャ設計 （レビュー） ⑤詳細設計 ⑥詳細設計（レビュー） ⑥詳細設計（レビュー） ⑦実装 52 障害タイプ+障害実装タイプと、 原因工程の関係 関連付け インタフェース/メッセージ 共有リソースのアクセス制御 アルゴリズム 値のチェック 値の代入/初期化 ③アーキテクチャ設計 ④アーキテクチャ設計 （レビュー） ①要求・仕様 ②要件・仕様 （レビュー） ODC分析グラフ （障害タイプと 障害実装タイプの関係） ⑤詳細設計 ⑥詳細設計 （レビュー） ODC分析グラフ （⑦障害タイプと ⑥詳細設計 （レビュー） 障害実装タイプの関係） ⑦実装 「障害タイプ」と「障害実装タイプ」の分布から、改善すべき工程を推測することができる。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 分析事例 「修正ソース種別と障害タイプの関係」 目的 41 52 コードの再利用が適切に行われているか確認する。 あるべき姿 「新規」が最も多く、続いて 「改造・変更」が多い。 一般的に障害量は「新規＞改造･変更」となるが、 派生開発の場合は逆転すること場合もある点に留 意する。 「既存」（流用したコードが原因の 障害）および、「二次障害」（障害 修正が原因の障害）は少ない。 問題事例 修正に起因する障害が多く、 修正プロセスに問題ないか （レビューが行われているか 等）確認する必要がある。 2 2 3 流用コードに障害が多く、流用元の製品 およびその派生製品にも、同様の障害 が潜在していると考えられる。 同時期に改造・変更されたコー ドにも関わらず、特定の障害タ イプが突出している場合は原因 を調べ、改造・変更のプロセス に問題ないことを確認する。 ポ イ ン ト ・ 障害が新規に開発されたコードで最も多く発生していることを確認する。また、同時期に開発・修正された コードであれば、障害の傾向も同等であると考えられる。「新規」と「改造・変更」を比較し、一方に大きな偏 りが見られる場合は、原因を確認するとよい。 ・ 「既存」が多い場合は、既に出荷済みソフトウェアおよび、それから派生したソフトウェアにも同様の障害が 含まれる可能性が考えられる。 ・ 「二次障害」が多い場合、レビューの不足など修正プロセスを点検し、必要なら是正措置をとる。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 分析事例 「発生トリガーと障害タイプの関係」 目的 52 障害について、発生の容易性とその深刻度から、品質の成熟度を推測する。 あるべき姿 問題事例 単純な手順で検出される 障害に、影響範囲の大き い 障害が含まれる ため 、 実際のソフトウェアの成熟 度は低いと考えられる。 単純な手順から複雑な手順まで、幅広く障害を検出しており、試験が成熟していることが伺える。 2 2 3 より単純な手順で検出される障 害について、より深刻な原因を もつ障害は少ない。影響範囲の 大きな障害が簡単に発生する リスクは低いと考えられる。 深刻な原因 「回復・例外」など特定のトリガーに深刻 な障害が集中している場合は、設計や 実装に問題がないか原因を確認する。 軽微な原因 単純な 手順 ポ イ ン ト 42 複雑な 手順 ・ 発生トリガー毎の障害タイプから、深刻な障害が単純な操作で出現しないことを確認する。「機能・クラス」 が出現している場合、設計･実装の成熟度を疑うが、特にそれが「基本操作」などの単純な操作で出現する 場合は注意が必要。 ・ 「負荷・ストレス」、「起動・再起動」、「回復・例外」など比較的操作が特定できるトリガーで深刻な障害が発 生している場合は、トリガーに対する設計・実装が適切にされているか、確認する。 ・ このグラフは、必要に応じて時系列、工程別、機能別の視点を追加して分析を行うと良い。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. Agenda 43 １ 背景 ２ ODC分析とは ３ ODC属性について ４ ODC分析の進め方 ５ ODC分析導入にあたって ６ 今後の発展性について ７ まとめ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 導入経緯 44 52 2007年に、ODC分析の提唱者であるIBM社より直接スキルトランスファーを受け、 2008年よりパイロットプロジェクトでの展開を開始した。ODC分析導入にあたって は、以下の取組みを行った。 1. 障害管理ツールを改変し、ODC属性を記述する欄を設ける。 2. 障害管理ツールに登録されたデータから、エクセルのODCグラフを出力するマ クロを作成。 3. 勉強会を実施し、全設計者、テスターにODC属性を理解してもらい、障害管 理時に正しく付与してもらうように指導。 4. ODC分析結果をフェーズ移行判定の判定材料とすることを明示。 導入初期段階では上記の活動を行っても、しっかりと属性を付与してもらうことは 難しかった。特に「障害タイプ」の属性は比較的難易度が高く、自発的に属性を付 与してもらい有効なODC分析を定常的に行うまでには、最低３サイクルのプロジェ クトを廻す必要があると感じられた。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. プロセス整備 45 ODC分析を正しく実行するためには、障害の発見者、修正者が共に、ODC属性 を良く理解し正しく割り付けることが鍵となる。また、その割り付けはプロジェクト 間でぶれることなく一義的に行わなければならない。 そのため、SQA(Software Quality Assurance) が各プロジェクトの障害登録のチェックを行い、指導を強化 すると共に、障害管理ツールそのものに手を加え、正しくODC属性を付与するた めの仕組み作りが求められた。 また、SEPG (Software Engineering Process Group) を中心とした「標準開発 プロセス・ワーキンググループ」を結成し、標準開発プロセスの品質管理サブプロ セスにて、導入マニュアルやテンプレート、ガイドラインを整備し、全社員が社内イ ントラ上で閲覧できるようにした。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 意識改革の波及効果 46 52 ODC分析では、試験を実施した障害発見者により決定する属性と、開発サイド の障害修正者により決定する属性の両面から、ソフトウェアの品質を多角的に 可視化できるため、開発者とテスターの協業が生まれ、ソフトウェアの品質を高 めようとするベクトルを一致できる副次的な効果が大きかった。具体的に、開発 者は自身のコードに対する不具合を指摘されるのでテスターを快く思わない ケースがあったり、テスターも試験を十分に行ったのか常に問いただされ同じテ ストケースを繰り返すといった主体性に欠ける一面もあったりするが、ODC分析 では両者が障害の原因に向き合い品質を改善していこうという機運が生まれ 結果として組織全体の意識改革に寄与する波及効果があった。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. Agenda 47 １ 背景 ２ ODC分析とは ３ ODC属性について ４ ODC分析の進め方 ５ ODC分析導入にあたって ６ 今後の発展性について ７ まとめ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 今後の発展性について ① 48 52 ＯＤＣ分析手法は、検証領域に留まらず、開発設計段階の設計レビュー、コードレビューに 関しても活用することが可能です。レビューで上がる有効指摘に関して、同様なODC属性 を付与し分析することにより、開発上流プロセスの問題箇所を特定することが出来ると共 に、そのレビュー自体が有効に機能していることを実証することも可能となります。 （ハードウェアも含めたシステム全体） ユーザーニーズ 妥当性検証 システム/サブシステム 要求分析/定義 システム/サブシステム テスト システム/サブシステム 基本設計 システム/サブシステム 結合・結合テスト サブシステム/ コンポーネント開発 ソフトウェア 要求分析/定義 ソフトウェア 基本設計 ソフトウェア システムテスト レビュー工程 ソフトウェア 詳細設計 ＯＤＣ分析の 実施領域 ソフトウェア 結合テスト ソフトウェア ユニットテスト ソフトウェア実装 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. （コンポーネントとしてのソフトウェア） 検証領域 今後の発展性について ② 49 52 ＯＤＣ分析手法は、コンポーネントとしてのソフトウェアに限らず、ハードウェアも含め たシステム及びシステムズ全体におけるテスト活動領域でも適応可能と考えます。 （ハードウェアも含めたシステム全体） ユーザーニーズ 妥当性検証 ＯＤＣの 分析対象 システム/サブシステム 要求分析/定義 ＯＤＣ分析の 実施領域 システム/サブシステム 基本設計 システム/サブシステム テスト システム/サブシステム 結合・結合テスト サブシステム/ コンポーネント開発 ソフトウェア 要求分析/定義 検証領域 ソフトウェア システムテスト ソフトウェア 基本設計 ソフトウェア 結合テスト ソフトウェア 詳細設計 ソフトウェア ユニットテスト ソフトウェア実装 （コンポーネントとしてのソフトウェア） Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. Agenda 50 １ 背景 ２ ODC分析とは ３ ODC属性について ４ ODC分析の進め方 ５ ODC分析導入にあたって ６ 今後の発展性について ７ まとめ Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 まとめ 51 52 Orthogonal Defect Classification分析（直交欠陥分類）は、個々の欠陥を複数 の独自で重複・冗長性のない属性で分類することにより、効率的に原因・傾向分 析する品質検証手法です。 欠陥そのものの傾向を見るだけでなく、開発工程の問題箇所を特定すると共に、 開発工程や試験工程の成熟度を多角的に評価できる利点があり、適切な是正 策を講ずることにより、集中的に欠陥を除去し、最終的にはソフトウェアの品質を 担保する説明責任を果たすことが可能となります。 検証領域における有効な分析手法として、ご参考にしていただけると幸いです。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52 ご清聴ありがとうございました。 Embedded Technology West 2014 IPAセミナー Copyright © 2014 Olympus Software Technology Corp. All rights reserved. 52