odc分析による欠陥除去と品質成熟度の可視化 · sec高信頼化技術適用事例...

Copyright © 2014 Olympus Software Technology Corp. All rights reserved.

Embedded Technology West 2014 IPAセミナー

SEC高信頼化技術適用事例

ODC分析による欠陥除去と品質成熟度の可視化～医療機器の安全性・高品質を担保するために～

２０１４年７月２９日

オリンパスソフトウェアテクノロジー株式会社

山崎隆

ODC: Orthogonal Defect Classification （直交欠陥分類）

2



52

１背景

ODC属性について

４

５

ODC分析の進め方

ODC分析導入にあたって

ODC分析とは

３

２

６今後の発展性について

７まとめ

Agenda

3



52

１背景

Agenda


４

５



ODC分析とは

３

２


７まとめ

4



52 オリンパスの医療事業

内視鏡システム

EVIS EXERA III / EVIS LUCERA SPECTRUM

小腸用カプセル内視鏡

外科用エネルギーデバイス

THUNDERBEAT

内視鏡外科手術統合システム

ENDOALPHA

内視鏡洗浄消毒装置

OER

※実際のカプセルにはロゴが入っていません。

世界初、バイポーラ高周波・

超音波の統合エネルギー

デバイス

5



52 医療機器に求められることとは

安全性高品質

生命の安全にかかわる医療機器は、求められる安全性・品質のレベルが格段

に高くなっています。

医療機器の開発において重要なことは、手技を理解してリスクマネジメントを行

い、リスクの高い事象に対しては、設計上しっかり対処することです。

使用する人の意思通りに動くことは当然として、トラブル時を含めたあらゆる

ユースケースを想定し、万が一にも正しく動かなくなってしまった場合でも、患者

様や、医療従事者への損害を限りなく少なくするため、きめ細やかな仕様を設

定し、その仕様を確実に検証し、品質を高めることが求められています。

製品の安全性をソフトウェア開発の観点から規制する動きが世界中で活発化し

ておりソフトウェア開発に対する法規制への対応も必須となっています。

6



52 ODC分析の対象領域

ソフトウェアの検証領域における分析手法であり、その分析対象は、要求分析/定義から検証業務に至るソフトウェア開発全体に及びます。

サブシステム/ コンポーネント開発

システム/サブシステム基本設計

システム/サブシステム結合・結合テスト

システム/サブシステム要求分析/定義

システム/サブシステムテスト

ユーザーニーズ妥当性検証

ソフトウェア実装

ソフトウェア詳細設計

ソフトウェアユニットテスト

ソフトウェア基本設計

ソフトウェア結合テスト

ソフトウェア要求分析/定義

ソフトウェアシステムテスト

（ハードウェアも含めたシステム全体）

（コンポーネントとしてのソフトウェア）

検証領域

ＯＤＣ分析の

実施領域

ＯＤＣの

分析対象

7



52

情報の蓄積と活用

障害件数の把握

残存障害の予測

④品質メトリクス ①品質管理図 ③信頼度成長曲線 ②ODC分析

障害原因の分析

障害密度

出荷システム結合単体

障害発生状況と原因の分析

品質可視化の手法群での位置づけ

ODC分析は障害発生状況と原因分析のための手法です。

8



52

１背景


４

５



ODC分析とは

３

２


７まとめ

Agenda

9



52 ODC分析とは

概要：

Orthogonal Defect Classification（直交欠陥分類、以下ＯＤＣ）に

よる分析は、1992年 IBM Watson研究所により提唱された障害の

定量的分析手法。排他的（Orthogonal）な複数の属性を用いて分

析することにより、障害を多次元のソフトウェア空間領域上に位置

づけることできる。

具体的にODC分析では検出された障害に直交した複数の属性を付

与し、多角的な視点から分析を行う。独自で重複・冗長性のない属

性を定義し、その属性のみに注目しながら分類することにより効率

的に分析を行うことができることを特徴とする。 ODC分析により得

られる結果は、偏在する障害領域を特定するだけではなく、それが

作り込まれた開発工程をも特定することが可能となる特徴を有する。

10



52 ODC分析の位置づけ

223

障害分析の代表的な手法には、「統計的手法」と、「要因分析的手法」がある。

「ODC分析」は、両者の中間に位置する分析手法。

■ ODC分析の特徴

過去のデータとの比較、

成熟度曲線モデル

を用いる手法。

統計的手法

要因分析的手法

是正処置に直結しない

不具合の

詳細を調査する手法

個々の不具合の意味論を捕らえ、その分布をもとに

製品の経過、成熟度を考察する

ODC Orthogonal Defect

Classification （直交欠陥分類）多くの労力・コストが必要

効率よく原因・傾向が分析できる

容易に現状を理解することはできるが、原因の分析や発生工程の特定ができない。

障害の発生原因や工程はわかるが、障害件数に比例して、実施が困難となる。

11



52 ODC分析とは

223

例えるならこういうこと・・・

現在の総数は○件・・・。

この1週間で○件増加。

障害１の原因は○○で重要度は○、作りこみ工程と障害機能の関連が高いため品質向上のためには・・・障害２の場合は・・・

あらかじめ障害内容に応じてタグをつけたよ。タグの数を集計してみたよ。

特別な手間を掛けずに品質を捉えることができるが、中身を知らないので問題点の特定などはできない。そのため是正処置に繋がりにくい。

統計的手法

全体を眺める

ODC分析

障害の発生原因や発生工程など、何もかも把握できるが、とにかく手間が掛かる・・・。

要因分析的手法

全てを調べる

手間を掛けずに障害傾向を捉えることができる。複数の観点で多角的に分析することで問題点の特定もできる。

タグだけを見る

障害障害を多方面からみると、線の交わる箇所に真の問題が潜んでいたりする！

12



52 ODC分析の考え方

利点１：不具合分析の観点充実と効率化付与した属性の分析により、不具合の発見や修正内容に関する特徴・傾向がわかる。・個々の不具合を調査する前にODC分析を行うことで、問題箇所の推定ができる。・不具合の発見や修正内容に関する特徴・傾向から、ソフトウェアの成熟度を推定できる。

利点２：不具合分析によるプロセスの改善ソフトウェア開発プロセスの面から不具合を分析することができる。・個々の不具合に対する対策を立てるためではなく、ソフトウェア開発プロセスのどの工程に問題があったのか特定し、プロセス改善のために分析を行う。

機能

インターフェイス

タイミング

アルゴリズム

代入・初期化

【修正タイプ】

【検出工程】出荷後ＳＷシステム試験結合試験単体試験属性の例

この辺に潜むのは

サソリ級の障害

この辺りに潜むのは

ミジンコ級の障害

ソフトウェア空間（多くの障害を含む）

ODC分析では発見された不具合に属性を付与し、多角的な視点から分析を行う。

独自で重複・冗長でない属性定義（＝直交した属性定義）を用いることで、効率よい分析を行うことができる。

13



52 ODC分析で解ること実例１

223

「発生トリガー」による試験成熟度の評価

試験の成熟度が評価でき、潜在障害の有無を推測できる。

②しかし、検出された障害の７割近くがいまだに単純な操作によるものであり、試験が成熟している（＝やりつくした）とは言えない。

①全体として障害は収束傾向にあるといえる。

③さらに、まったく検出されていない障害があり、これらは実運用開始後（＝出荷後）に検出される可能性が高い。

14



52 ODC分析で解ること実例2

223

「障害タイプ」による実装成熟度の評価

実装の成熟度が評価でき、潜在障害の有無を推測できる。

①結合試験からSWシステム試験へと移行しているにもかかわらず、障害の出現傾向に大きな変化が無いことから、開発または試験が狙い通り進んでいないと考えられる。

SWシステム試験結合試験

③さらにケアレスミスが全期を通してほぼ一定の割合で発生している。実装が成熟しているとは考えにくい。

②特にSWシステム試験終盤になって、「機能・クラス」など影響範囲の大きい修正が続いており、二次障害が懸念される。

15



52 導入のメリット・デメリット

223

分析用タグの分だけ入力する手間がかかる

また入力方法について基本的な知識が必要。慣れるまでは大変である。

デメリット（課題）

１．品質が客観的にわかる

傾向を様々な角度から分析でき、成熟度をはじめとする傾向分析が可能である。

２．開発工程の問題点がわかる

「障害タイプ」と「障害実装タイプ」から、どの工程で不具合を埋め込んだか容易に推測できる。これら情報が無いと障害処理票から詳細を読み取り、不具合の埋め込み工程を推測しなければならない。

３．要因分析的手法よりコストがかからない

ODC分析は分析用に付けたタグに基づき分析するので、詳細を見ない分だけ、要因分析手法より低コスト（簡単）である。

メリット

16



52

１背景


４

５



ODC分析とは

３

２


７まとめ

Agenda

17



52 ODC属性について

■ 障害情報とODC分析

■ ODC属性とは？

ODC分析を実施するには、あらかじめインシデントをいくつかの観点で分類する必要がある。その各観点を、ODC分析では「ODC属性」と呼び、全部で５つ＊の属性を採用している。

ただし、ODC分析ではODC属性だけを分析するとは限らない。実際の分析では、一般的な障害情報である「ランク」や「発生日」、あるいは障害管理DBに登録する「ステータス」なども、ODC分析の材料として併用している。

＊実際には８つ定義されているが、そのうちの５つを適用している。

発生トリガー

検出工程障害タイプ

障害実装タイプ

修正ソース種別

ODC属性 ODC属性は様々なプロジェクトの障害実績から統計的に設定されているため、あらゆるプロジェクトに対して適用することが可能。共通の属性を使うことで、プロジェクト間の品質分析ができるようになる。

発見者により決定する属性修正者により決定する属性

18



52 ODC属性について

■ ODC属性の分類

今回対象としたODCの共通属性

（1）検出工程（Defect Removal Activities）

（2）発生トリガー（Triggers）

（3）障害タイプ（Defect Type）

（4）障害実装タイプ（Qualifier）

（5）修正ソース種別（Age）

個別対応としたODC属性

（６）影響範囲（Impact）

（７）発生箇所（Target）

（８）発生源（Source）

全ての

プロジェクトで

共通に

使用する

ＯＤＣ属性

プロジェクト毎に

個別に

設定する

ＯＤＣ属性

19



52 属性① 「検出工程」

選択肢意味備考

結合試験結合試験中に検出された障害。

SWシステム試験 SWシステム試験中に検出された障害。

出荷試験出荷試験中に検出された障害。

出荷後ユーザーに納入後に検出された障害。

検出工程は、いつ障害が検出されたかを示す。

同ランクの障害なら、より下流で検出される方がプロダクトとしては深刻といえる。

深刻度小

大

■ 「検出工程」

内容障害を検出した工程を識別する。

用途・目的検出時期から、問題の深刻度、テストの成熟度を推測する。

発見者が登録

20



52 属性② 「発生トリガー」 1/4

内容障害を検出するに至ったきっかけを識別する。

用途・目的手順の複雑度から、テストの成熟度を推測する。


基本操作（標準設定）

次ページ参照。

基本操作（オプション等の変更あり）

操作順序に依存

複数機能の相互作用

負荷・ストレス

回復・例外

起動・再起動

構成

発生トリガーは、試験手順の複雑度を示す指標となる。

より複雑な試験が行われているほど、試験は成熟している（しっかり試験されている）といえる。

手順の複雑度小

大

■ 「発生トリガー」発見者が登録

21




223

選択肢意味

基本操作

（標準設定）パラメーター、オプションなどは全く変更せず、単一機能のみを実行した時。

基本操作

（オプション等の変更あり）パラメーター、オプションなどを変更し、単一機能のみを実行した時。

操作順序に依存複数の機能を特定の順番で実行したとき（各機能を別々に行えば正常動作する場合）、もしくは単一機能を何回も実行した時。

複数機能の相互作用複数の機能が同時に動作しているとき。もしくはその後。

負荷・ストレス各リソース（メモリーなど）の限界値付近でテストした時。

回復・例外リカバリー/例外処理のテストケースを実行した後。

起動・再起動シャットダウン、スリープ、ネットワーク遮断、電源遮断などから通常状態に戻した後。

構成あるソフトウェアをダウンロード/インストールした後。もしくは、あるハードウェアを接続した後。

次ページ「フローチャート」も参照

選択肢の意味

22



52 属性② 「発生トリガー」 3/4：選択肢の選び方

223

基本操作（標準設定） Basic, Coverage

スタート

回復・例外 Recovery/Exception

意図的にシステムレベルの例外処理を試すための試験で不具合が見つかったか？

負荷・ストレス Workload/ Stress

意図的にシステムレベルの限界値付近を試すための試験、システムに対してストレスを与える試験で不具合が見つかったか？

起動・再起動 Startup/Restart

例外処理後の起動あるいは再起動で不具合が見つかったか？

構成 HW/SW Configuration

H/WあるいはS/W構成を変更したことによって不具合が見つかったか？

基本操作（オプション等の変更あり） Variation

入力値・パラメータの変更によって見つかったか？

１つの機能のみの試験で不具合が見つかったか？

同じ手順の繰り返しによって不具合が見つかったか？

操作順序に依存 Sequencing

複数機能を特定の順番で実行したことによって不具合が見つかったか？複数機能の相互作用

Interaction

複数の機能を同時に実行したことによって不具合が見つかったか？

やり直しもっとも近いものを選び直してください。

不具合の再現手順をイメージ

する

試験の「狙い目」に着目

No

Yes

手順の複雑さに着目（次ページも参照）

23




223

基本操作（標準設定）

基本操作（オプション等の変更あり）

操作順序に依存

複数機能の相互作用

オプションなどは全く変更せず、単一機能のみを実行したときに不具合が見つかった。

パラメータ、オプションなどを変更し、単一機能のみを実行したときに不具合が見つかった。

複数の機能を特定の順番で実行したとき、もしくは単一機能を何回も実行したときに不具合が見つかった。

複数の機能が同時に動作しているとき。もしくはその後に不具合が見つかった。

×

×

既定状態

×

入力値変更

×

×

発生トリガーにおける手順の複雑さ

24



52 属性③ 「障害タイプ」 1/2


値の代入/初期化

次ページ参照。

値のチェック

アルゴリズム

共有リソースのアクセス制御

インタフェース/メッセージ

関連付け

機能/クラス

GUI 次ページ参照。

障害タイプは、その障害が他に与える影響を考える上での指標となる。

開発終盤で影響度の大きい障害が多発する場合は注意が必要である。

他への影響度小

大

内容修正内容に基づき、障害の種類を分類する。

用途・目的他の情報と組み合わせて障害の深刻度、影響範囲を推測する。

修正者が登録 ■ 「障害タイプ」

25



52 属性③ 「障害タイプ」 2/2

223

選択肢意味具体例修正・影響範囲

値の代入 /初期化

値の代入、初期化の修正が必要な障害。（ただし、複数のステートメントの修正が必要な場合は、「アルゴリズム」を選択する。）

値の初期化ミス／クラス生成時にコンストラクター呼び出し忘れ、呼び出し結果が正しくない・・・

値のチェック条件式におけるデータチェックの修正が必要な障害。（ただし、複数行の修正が必要な場合は、「アルゴリズム」を選択する。）

IF文、switch文の値チェックミス・処理忘れ／メソッド引数のチェック部のミス・処理忘れ・・・

アルゴリズムメソッド内、関数内のロジックの修正が必要な障害。

IF文内の処理のロジックミス／リスト構造のサーチロジックのミス／ローカルデータ構造のミス・・・


共有リソースのアクセス制御部分の修正が必要な障害。

排他処理ミス／共有メモリ上のデータ更新処理の順番ミス・・・

インタフェース/メッセージ

モジュール、デバイスドライバー、関数、コンポーネント、オブジェクト間の、パラメータやデータ受け渡しなどにかかわる修正が必要な障害。

インターフェースは数値へのポインターを指定しているが、コードそのものは文字へのポインターと扱っていた場合など。

関連付けクラス内のメソッド、データ間の問題、インスタンス化および継承に関する修正が必要な障害。

クラスメソッドがオーバーライドされていて動作が予想と違っていた、インスタンス可数が間違って制限されていた場合など。

機能/クラス設計変更を必要とし、機能実現性や（ユーザー、ハードウェアなどに対する）外部インターフェース、グローバルデータの構造に影響する障害。

クラス不足、データサイズが要求に満たない、などの機能実現性に影響する設計変更が必要な場合。

GUI リソースデータのみ修正が必要な障害。ソースコードの修正は不要。

GUIリソースの修正など。

影響範囲

小

大

単一行

複数行（単一モジュール）

複数個所

設計全体

26



52 属性④ 「障害実装タイプ」


誤実装誤って実装。多くの障害は「誤実装」を原因とする。

未実装実装し忘れ。もし開発終盤になって「実装し忘れ」が検出された場合、プロセスに問題があると推測できる。

余分余計な実装が障害の原因となった場合。

「余分」が障害の原因となることは少ないが、発生した場合は原因を調べる必要がある。

内容障害の実装パターンを３種類で分類する。

用途・目的障害の混入時期とあわせてプロセス上の問題箇所を推測する。

■ 「障害実装タイプ」修正者が登録

27



52 属性⑤ 「修正ソース種別」


新規今回の開発で新規に作成したコードで問題が発生。

一般的な問題。

既存以前の開発から流用したコードで障害が発生。

すでに出荷済みのソフトウェアにも、潜在的障害があることを示す。

改造/変更以前の開発から流用したコードを改良した箇所で障害が発生。大量に検出された場合、影響範囲の確

認不足などが考えられる。二次障害

障害を修正した箇所で別の障害が発生した。

内容コードを修正した場合、そのコードの種類を識別する。

用途・目的潜在障害の有無およびその影響範囲検証プロセスの精度を推測する。

■ 「修正ソース種別」修正者が登録

28



52

１背景


４

５



ODC分析とは

３

２


７まとめ

Agenda

29



52 ＯＤＣ分析の流れ

Step2：潜在障害の推測品質は顕在障害数だけではなく、潜在障害も考慮して判断する必要がある。そのため潜在障害の有無を、「成熟度」と「網羅率」の2つの観点から確認する。

必要に応じて「修正ソース種別と障害タイプの関係」、「発生トリガーと障害タイプの関係」も参照する.。

Step4：完成度の検証最後に解決状況の推移を確認し、修正されるべき障害が修正されていることを確認する。

障害ランクの推移

発生トリガーの推移

障害タイプの推移

障害タイプの分布（発生箇所別）

発生トリガーの分布（発生箇所別）

成熟度の検証

網羅率の検証

品質の可視化

（品質管理図などによる障害修正状況の確認）

解決状況の推移

障害タイプと障害実装タイプの関係

結果の裏づけ

（中間評価）

（最終評価）

Step3：プロセスの検証さらに、障害対応プロセスの健全さを検証し、中間評価の裏づけとする。必要に応じて、品質管理図等により障害修正・確認が滞りなく実施されているか確認する。

Step1：全体像の確認まず障害数と障害ランクから品質の全体像を捉える。ここでは品質を、「良いと言える」、「悪いと言える」、の2段程度で考える。

ＯＤＣ分析のステップ

Step1と2の結果より、品質を判断する。

Step3と4の結果より、品質を判断する。

30



52 分析事例「発生トリガーの推移」

223

あるべき姿問題事例

・より単純な障害（簡単に見つかる障害）は試験前半で出尽くし、後半はより複雑な傷害（見つけにくい障害）が検出されていることで、試験が成熟していることを確認する。

・発生トリガーの偏りがなく、満遍なく障害が検出されていることも重要。

・成熟の度合いは、同一製品の前バージョンの同一時期と比較するのが効果的。該当製品が無い場合は、同一規模の他製品、あるいは現在のフェーズがSWシステム試験であれば、結合試験の状況と比較してみるのも有効。

ポイント

障害検出の「きっかけ」の変化に着目し、試験の成熟度を確認する。目的

単純系の障害が早い段階で収束している。

単純系の障害収束に伴い、複雑系障害が試験後半で検出されている。

最終的に満遍なく発生トリガーが検出されている。

出現傾向にバラツキがあり。まだ試験されていない手順があると考えられる。

単純系の障害が主体。より複雑な試験を行うことによりさらに障害が検出されると考えられる。

31



52 分析事例「発生トリガーの推移（工程別）」

223


・前フェーズの試験と比較して、状況の変化（改善具合など）を確認したい場合に有効。

・前フェーズと比較して状況が改善されていることを確認。

・その他の着目すべき点は、前頁の「ポイント」を参照のこと。

ポイント

試験フェーズごとの傾向の変化に着目し、試験の成熟度を確認する。目的


単純系の障害は結合試験で出し尽くしているため、SWシステム試験では検出されない。

障害が収束傾向にあり、かつより複雑なトリガーで構成されている。

傾向に変化が見られない。フェーズが進行したが、試験が成熟したとは考えにくい。

障害総数は減少しているが、相変わらず基本障害の占める割合が大きい。成熟していない。

32



52 分析事例「発生トリガーの分布（工程別）」

223


・発生トリガーの分布より、各フェーズで目的とされている試験が実施されていることを確認する。

・具体的には結合試験では、より単純な障害（簡単に見つかる障害）が検出され、SWシステム試験ではより複雑な障害が主に検出されていることを確認する。グラフがこの傾向を示さない場合、試験が戦略的に実施されていない可能性を疑う。

・このグラフは「発生トリガーの推移」の最終日と同じ結果となります。発信すべきメッセージに合わせてグラフを使い分けると良い。

ポイント

工程ごとの発生トリガーの傾向に着目し、然るべき時期に障害が検出されていることを確認する。目的

結合試験では「基本操作」系を中心に、単機能に着目した障害検出されている。

SWシステム試験になり、「負荷・ストレス」などの非機能用件、「回復・例外」などの異常系処理、「起動･再起動」や「構成」などシステム全体に関わる試験が実施されている。

結合試験でシステム全体に関わる障害が検出されている。試験が戦略的に実施されていない可能性がある。

SWシステム試験では、結合試験と比較してより複雑な障害を検出しているが、相変わらず基本的な障害が多い。結合試験の実施が不完全と考えられる。

必要に応じて単体試験、受入試験も評価対象とする。

33



52 分析事例「発生トリガーの分布（発生箇所別）」

223


・モジュール毎に、各フェーズで目的とされている試験が実施されていることを確認する。

・同時期、同規模で開発されたモジュールであれば、同程度の障害傾向が出現すると考えられるため、他と比較して偏りのあるモジュールでは注意が必要です。ただし、障害数の過多はモジュールの規模により異なるため、障害密度、試験密度などのメトリクスとあわせて確認すべき。

・このグラフは、「発生トリガーの推移」をモジュールごとに詳細化したもの。発信すべきメッセージにあわせてグラフを使い分けると良い。

ポイント

機能ごとの障害発生量から試験の網羅度を推測し、発生トリガーよりその成熟度を確認する。目的

発生トリガーの見方については、「発生トリガーの推移」を参照のこと

障害が検出されていない機能がある。試験モレがあると考えられる。

発生トリガーの出現傾向に偏りがある。原因を確認する必要がある。

全機能から満遍なく障害を検出しており、試験が網羅的である。

障害のほとんどが「その他」に分類されており、分析にならない。機能の分類方法を見直す必要がある。

34



52 分析事例「障害タイプの推移」

223

障害内容の変化に着目し、設計及び実装の成熟度を確認する。目的


・障害内容の変化から、ソフトウェアの設計／実装が成熟していることを確認する。

・実装の基本的なミスである「値の代入」、「値のチェック」が時間の経過とともに減少していることを確認し、実装の成熟度を判断する。また、アーキテクチャ設計の問題に相当する「機能/クラス」など、より深刻な障害（影響範囲の大きい障害）の増加傾向より、設計の成熟度を検討する。

・成熟の度合いは、同一製品の前バージョンの同一時期と比較するのが効果的です。該当製品が無い場合は、同一規模の他製品、あるいは現在のフェーズがSWシステム試験であれば、結合試験の状況と比較してみるのも有効。

ポイント

「機能/クラス」など設計に起因するより深刻な障害（修正影響範囲の大きい障害）が少なく、極端な増加傾向も見られない。

「値の代入/初期化」、「値のチェック」など、実装の未熟さを表す問題が、早期に収束している。

全体に占める軽微なミスが多い。コーディング規約などの点検を行う必要がある。

設計に起因する障害が終盤まで発生している。今後も大規模な修正が必要となるため、デグレード、仕様の不整合が生じる可能性がある。

特定の障害タイプに偏りがある場合は設計プロセスのいずれかに問題があると考えられるので原因を調査する。

35



52 分析事例「障害タイプの推移（工程別）」

223

試験フェーズごとの傾向の変化に着目し、設計及び実装の成熟度を確認する。目的


・このグラフは、前グラフの代わりに用いることができます。特に前フェーズの試験と比較して、状況の変化（改善具合など）を確認したい場合に有効。

・前フェーズと比較して状況が改善されていることを確認する。

ポイント

単純な障害は結合試験で解決されているため、SWシステム試験では検出されない。


傾向に変化が見られない。フェーズが進行したが、試験が成熟したとは考えにくい。

障害総数は減少しているが、相変わらず基本障害の占める割合が大きい。成熟していない。

障害が収束傾向にあり、特に影響度の大きな障害が減少している。

36



52 分析事例「障害タイプの分布（工程別）」

223


・障害内容が各フェーズにふさわしいか、障害タイプより類推する。具体的には、結合試験までに「値の代入/初期化」などの実装単純ミス、および「機能・クラス」など設計にかかわる重大にミスが修正され、SWシステム試験以降ではこれらに起因する障害が減少していることを確認する。グラフがこの傾向を示さない場合、設計・実装の成熟度を疑い、開発プロセスが適切か検証する。

・このグラフは「障害タイプの推移」の最終日と同じ結果となる。発信すべきメッセージにあわせて、グラフを使い分けると良い。

ポイント

工程ごとの障害タイプの傾向に着目し、然るべき時期に障害が検出されていることを確認する。目的

同様に「値のチェック/代入」に代表される実装の単純ミスが修正されている。

SWシステム試験になり、単純な実装ミスや、逆に修正影響範囲の大きい重大障害は減少している。

全体に占める軽微なミスが減少せず、相対的に増加している。実装は成熟していないと考える。

設計に起因する障害が減少せず、相対的に増加している。設計は成熟していないと考える。

特定の障害タイプに偏りがある場合は設計プロセスのいずれかに問題があると考えられるので原因を調査する。

結合試験では設計に起因し修正の影響範囲も大きいと考えられる「機能/クラス」などが修正されている。

37



52 分析事例「障害タイプの分布（発生箇所別）」

223


・モジュール毎に、各フェーズで目的とされている試験が実施されていることを確認する。

・同時期、同規模で開発されたモジュールであれば、同程度の障害傾向が出現すると考えられるため、他と比較して偏りのあるモジュールでは注意が必要です。ただし、障害数の過多はモジュールの規模により異なるため、障害密度、試験密度などのメトリクスとあわせて確認する。

・このグラフは、「障害タイプの推移」をモジュールごとに詳細化したもの。発信すべきメッセージにあわせてグラフを使い分けると良い。

ポイント

機能ごとの障害発生量から試験の網羅度を推測し、障害タイプよりその成熟度を確認する。目的

障害タイプの見方については、「③障害タイプの推移」を参照してください。

障害が検出されていない機能がある。試験モレがあると考えられる。

分析上、無視できない件数が「その他」に分類されている。機能の分類方法など見直す必要がある。

全機能から満遍なく障害を検出しており、試験が網羅的である。

障害タイプの出現傾向に偏りがある。原因を確認する必要がある。

38



52 分析事例「障害タイプと障害実装タイプの関係」

223


・障害タイプと障害実装タイプの関係から、より影響範囲の大きい問題（仕様・設計に関わる問題）が少ないことを確認する。

・障害タイプの分布に偏りが見られる場合は、障害実装タイプとの関係から、開発工程のどこに問題があるのか特定し、必要に応じて是正措置をとる。

・障害タイプと障害実装タイプの関係は次ページを参照のこと。

ポイント

障害タイプごとの障害実装タイプより、設計プロセスの弱点を推測する。目的

より深刻な問題といえる「未実装」（＝実装モレ）が、誤実装（＝実装ミス）よりも少ない。

未実装の中でも、特に深刻な「機能・クラス」の未実装がほとんどない。

次ページ：障害タイプと障害実装の関係

その他、障害タイプが偏っている場合は、原因工程を確認する。（次ページも参照）

機能・クラスの実装モレが多く、上流段階での作りこみが不足していると考えられる。より広範囲な問題を抱えている可能性あり。

39



52 障害タイプと障害実装タイプの因果関係 1/2

機能・クラス

I/F・メッセージ関連付け

機能・クラス

I/F・メッセージ関連付け

アルゴリズム

値のチェック

アルゴリズム

値の代入・初期化

値の代入・初期化値のチェック

未実装誤実装

開発

工

程

実装

詳細設計

アーキテクチャ

設計

要件・仕様策定

影響大

影響小

機能・クラスの未実装（実装モレ）は、要件・仕様の策定段階に問題があると考えられ、その影響範囲は大きい。

値のチェックなどの誤実装は、単なるコーディングミスと考えられる。

同じ未実装・誤実装でも、その内容により、原因工程は異なるといえる。

※主な障害タイプのみ表示

40



52 障害タイプと障害実装タイプの因果関係 2/2

「障害タイプ」と「障害実装タイプ」の分布から、改善すべき工程を推測することができる。

ODC分析グラフ

（⑦障害タイプと障害実装タイプの関係）

①要求・仕様

②要件・仕様（レビュー）

③アーキテクチャ設計

④アーキテクチャ設計（レビュー）

⑦実装

⑤詳細設計

⑥詳細設計（レビュー）

⑥詳細設計（レビュー）

未実装誤実装

機能/クラス ①要件・仕様 ③アーキテクチャ設計

関連付け

②要件・仕様（レビュー） ④アーキテクチャ設計

（レビュー）インタフェース/メッセージ


アルゴリズム ⑤詳細設計 ⑥詳細設計（レビュー）

値のチェック ⑥詳細設計（レビュー） ⑦実装

値の代入/初期化

障害タイプ障害実装タイ

プ障害タイプ+障害実装タイプと、原因工程の関係

ODC分析グラフ

（障害タイプと障害実装タイプの関係）

41



52 分析事例「修正ソース種別と障害タイプの関係」

223


・障害が新規に開発されたコードで最も多く発生していることを確認する。また、同時期に開発・修正されたコードであれば、障害の傾向も同等であると考えられる。「新規」と「改造・変更」を比較し、一方に大きな偏りが見られる場合は、原因を確認するとよい。

・「既存」が多い場合は、既に出荷済みソフトウェアおよび、それから派生したソフトウェアにも同様の障害が含まれる可能性が考えられる。

・「二次障害」が多い場合、レビューの不足など修正プロセスを点検し、必要なら是正措置をとる。

ポイント

コードの再利用が適切に行われているか確認する。目的

「新規」が最も多く、続いて「改造・変更」が多い。

「既存」（流用したコードが原因の障害）および、「二次障害」（障害修正が原因の障害）は少ない。

一般的に障害量は「新規＞改造･変更」となるが、派生開発の場合は逆転すること場合もある点に留意する。

修正に起因する障害が多く、修正プロセスに問題ないか（レビューが行われているか等）確認する必要がある。

同時期に改造・変更されたコードにも関わらず、特定の障害タイプが突出している場合は原因を調べ、改造・変更のプロセスに問題ないことを確認する。

流用コードに障害が多く、流用元の製品およびその派生製品にも、同様の障害が潜在していると考えられる。

42



52 分析事例「発生トリガーと障害タイプの関係」

223


・発生トリガー毎の障害タイプから、深刻な障害が単純な操作で出現しないことを確認する。「機能・クラス」が出現している場合、設計･実装の成熟度を疑うが、特にそれが「基本操作」などの単純な操作で出現する場合は注意が必要。

・「負荷・ストレス」、「起動・再起動」、「回復・例外」など比較的操作が特定できるトリガーで深刻な障害が発生している場合は、トリガーに対する設計・実装が適切にされているか、確認する。

・このグラフは、必要に応じて時系列、工程別、機能別の視点を追加して分析を行うと良い。

ポイント

障害について、発生の容易性とその深刻度から、品質の成熟度を推測する。目的

より単純な手順で検出される障害について、より深刻な原因をもつ障害は少ない。影響範囲の大きな障害が簡単に発生するリスクは低いと考えられる。

複雑な手順

単純な手順

深刻な原因

軽微な原因

単純な手順から複雑な手順まで、幅広く障害を検出しており、試験が成熟していることが伺える。単純な手順で検出される障害に、影響範囲の大きい障害が含まれるため、実際のソフトウェアの成熟度は低いと考えられる。

「回復・例外」など特定のトリガーに深刻な障害が集中している場合は、設計や実装に問題がないか原因を確認する。

43



52

１背景


４

５



ODC分析とは

３

２


７まとめ

Agenda

44



52 導入経緯

2007年に、ODC分析の提唱者であるIBM社より直接スキルトランスファーを受け、

2008年よりパイロットプロジェクトでの展開を開始した。ODC分析導入にあたって

は、以下の取組みを行った。

1. 障害管理ツールを改変し、ODC属性を記述する欄を設ける。

2. 障害管理ツールに登録されたデータから、エクセルのODCグラフを出力するマ

クロを作成。

3. 勉強会を実施し、全設計者、テスターにODC属性を理解してもらい、障害管

理時に正しく付与してもらうように指導。

4. ODC分析結果をフェーズ移行判定の判定材料とすることを明示。

導入初期段階では上記の活動を行っても、しっかりと属性を付与してもらうことは

難しかった。特に「障害タイプ」の属性は比較的難易度が高く、自発的に属性を付

与してもらい有効なODC分析を定常的に行うまでには、最低３サイクルのプロジェ

クトを廻す必要があると感じられた。

45



52 プロセス整備

ODC分析を正しく実行するためには、障害の発見者、修正者が共に、ODC属性

を良く理解し正しく割り付けることが鍵となる。また、その割り付けはプロジェクト

間でぶれることなく一義的に行わなければならない。そのため、SQA(Software

Quality Assurance) が各プロジェクトの障害登録のチェックを行い、指導を強化

すると共に、障害管理ツールそのものに手を加え、正しくODC属性を付与するた

めの仕組み作りが求められた。

また、SEPG (Software Engineering Process Group) を中心とした「標準開発

プロセス・ワーキンググループ」を結成し、標準開発プロセスの品質管理サブプロ

セスにて、導入マニュアルやテンプレート、ガイドラインを整備し、全社員が社内イ

ントラ上で閲覧できるようにした。

46



52 意識改革の波及効果

ODC分析では、試験を実施した障害発見者により決定する属性と、開発サイド

の障害修正者により決定する属性の両面から、ソフトウェアの品質を多角的に

可視化できるため、開発者とテスターの協業が生まれ、ソフトウェアの品質を高

めようとするベクトルを一致できる副次的な効果が大きかった。具体的に、開発

者は自身のコードに対する不具合を指摘されるのでテスターを快く思わない

ケースがあったり、テスターも試験を十分に行ったのか常に問いただされ同じテ

ストケースを繰り返すといった主体性に欠ける一面もあったりするが、ODC分析

では両者が障害の原因に向き合い品質を改善していこうという機運が生まれ

結果として組織全体の意識改革に寄与する波及効果があった。

47



52

１背景


４

５



ODC分析とは

３

２


７まとめ

Agenda

48



52 今後の発展性について ①

ＯＤＣ分析手法は、検証領域に留まらず、開発設計段階の設計レビュー、コードレビューに関しても活用することが可能です。レビューで上がる有効指摘に関して、同様なODC属性を付与し分析することにより、開発上流プロセスの問題箇所を特定することが出来ると共に、そのレビュー自体が有効に機能していることを実証することも可能となります。
















検証領域

ＯＤＣ分析の

実施領域レビュー工程

49



52 今後の発展性について ②

ＯＤＣ分析手法は、コンポーネントとしてのソフトウェアに限らず、ハードウェアも含めたシステム及びシステムズ全体におけるテスト活動領域でも適応可能と考えます。
















検証領域

ＯＤＣ分析の

実施領域

ＯＤＣの

分析対象

50



52

１背景


４

５



ODC分析とは

３

２


７まとめ

Agenda

51



52 まとめ

Orthogonal Defect Classification分析（直交欠陥分類）は、個々の欠陥を複数

の独自で重複・冗長性のない属性で分類することにより、効率的に原因・傾向分

析する品質検証手法です。

欠陥そのものの傾向を見るだけでなく、開発工程の問題箇所を特定すると共に、

開発工程や試験工程の成熟度を多角的に評価できる利点があり、適切な是正

策を講ずることにより、集中的に欠陥を除去し、最終的にはソフトウェアの品質を

担保する説明責任を果たすことが可能となります。

検証領域における有効な分析手法として、ご参考にしていただけると幸いです。

52



52

ご清聴ありがとうございました。

odc分析による欠陥除去と 品質成熟度の可視化 · sec高信頼化技術適用事例...

Documents

odc分析による欠陥除去と品質成熟度の可視化 · sec高信頼化技術適用事例...