ODC分析についてのよもやま話 〜 ソフトウェア不具合についてのあれやこれや・・・〜第６回「ODC分析の事例研究」

プロジェクト状況：

あるプロジェクトで、開発として実施する最終テスト工程であるシステムテストも終盤にさしかかっています。発見された不具合数も収束してきました。（図表1）

現状のよくある判定

適用された開発プロセスに沿って計画どおり開発・テストを進めてきて、次の判定基準を満たしたことから、「出荷可能」と判断しました。

1)　各工程で定義された開発・テスト活動は、全て完了した。
2)　摘出された不具合は、全て修正した。
3)　摘出された不具合検出数は、おおむね品質計画どおりの傾向を示し、
4)　システム終盤に来て、新しく摘出される不具合数は収束している。

しかしながら、ここで各工程で発見された不具合についてODC分析を実施してみると、次のようなタイプ属性分布が示されました。（図表２）

これを見て、みなさんはどう判定しますか？

ODC分析での見方と評価

Function(機能性に関わるタイプ属性)の割合が、他のタイプ属性の割合の減少傾向と異なり、工程が進むにつれ明らかに継続して増加傾向を示しています。（図表３赤矢印）
「何かおかしい？」また「何がおかしい？」のかを考えてみてください。

注）このグラフで注意していただきたいのは、図表３のグラフの縦軸目盛りは各工程での件数でなく、各属性の占める割合(%)で分布を示していることです。
ODC分析での属性分布を示すときは、各工程でそれぞれの属性が占める割合（各属性の件数/その工程での不具合総数）を％で示すことで、件数が多い／少ないに関わらず、相対的な比率で出方が顕著になり評価できます。

ここで思い出していただきたいのが、第４回で解説した不具合についての気づきの一つである、以下に示す「タイプ属性と開発プロセスの関係」です。

▶　各工程で出てしかるべきタイプ副属性は、開発プロセスの観点から理論的に図表4のように予測できます。

これらのことを踏まえると、次のような二つの指摘が挙げられます。

指摘1：Function(機能性)に関わる不具合の前工程からの漏れ

Function(機能性)に関わる不具合は、設計レビュー、コード検証、単体テスト、機能テスト(統合テスト)での検証過程にて、おおむね摘出されている(はず)です。

この事例では開発前半でのFunctionの不具合の割合が他と比べて特に多くないことから、各工程での検証が不十分で、Functionの不具合が後工程へ漏れて残存していることを示している、と捉えることができます。
つまりは、今後もFunctionの不具合が出続ける可能性を示唆しています。

指摘2：残存不具合 (Function) 対応によるシステムテストへの影響

現在進行中のシステムテストにおいて、すでに前工程で摘出されている（はず）のFunction(機能性)の不具合対応により、システムテスト遂行が頻繁に阻害されている、と捉えることができます。
このことから、システムテスト実施の妥当性、十分性に懸念があり、重大なシステム不具合が摘出されず残存している可能性があることを示唆しています。

 これらの指摘に対し、示唆される対応策を二つ説明します。

示唆される対応策1：設計工程検証(設計レビューやコード検証)での機能性に対する次のようなレビュー観点の見直しが必要であることを示唆しています。

▶　要求仕様の詳細化の十分性、正確性
▶　要求仕様と設計仕様との整合性、トレーサビリティー（ひも付け）
▶　設計レビュー、コード・インスペクションでのレビューアの適格性

示唆される対応策2：機能テストのカバレージの網羅性と詳細性および実施体制の再検証が必要なことを示唆しています

▶　機能テストでの、検証観点、テスト項目が設計仕様書を網羅しているか。（ここで食い止めるべき）
▶　テスターの選定は適正か、テストの合否判定基準は正しく文書化され教育されているか。

以上が、【事例研究１】でのODC分析の見方と評価になります。

当然のことですが、この事例のようにシステムテストも終盤でこのようなことが判明すること自体が問題です（遅すぎます）。
そこで、ODC分析を用い、開発工程の初期段階から定期的に実施することで、各工程での「何かおかしい？」に早期に気付きを得て、対応策が的確に実施できるのです。

プロジェクト状況：　

基本設計でのレビューを経て、詳細設計についてのレビューを実施しました。
基本設計時と詳細設計時それぞれでの指摘事項を、タイプ属性による分析をし比較すると、図表5のようなタイプ属性の分布の推移を示しました。

注）詳細設計のグラフで、青色は本来基本設計で発見されるべき不具合を、だいだい色は詳細設計で発見されてしかるべき不具合を示します。

次に、「何がおかしいのか」という観点で、このグラフを分析してみましょう。

ODC分析での見方と評価：

基本設計レビューにおいて、Function(機能性)に関わる不具合を多く発見しているのは、早期発見という意味では良いことです。
しかしながら、次工程の詳細レビューでも、30%はFunctionに関わる不具合が摘出され、さらに、そのFunction不具合の1/3が、基本設計レビューで見つけるべき不具合でした。（図表6の赤矢印）

評価の前提として、開発プロセスの「やり方」の定義は、次の二つが定義されている(はず)です。

●基本設計レビューは、要求仕様書を基に基本設計の妥当性を検証する。
●詳細設計レビューは、基本設計書を基に詳細設計の妥当性を検証する。

これらのことを踏まえると、次のような二つの指摘が挙げられます。

 指摘1： 基本設計から詳細設計へ不具合が漏れている。

基本設計レビューで見つけるべき不具合が、詳細設計レビューでも見つかる場合、基本設計レビューの漏れ「Missing(欠如)」なのか、「Incorrect(誤り)」なのかをまず分類します。なぜなら、それぞれで以下のように対応策が異なってくるからです。
以下に、それぞれの状況を説明し、示唆される対応策を挙げることとします。

基本設計レビュー「Missing:欠如」の場合

しばしば起こるのが、基本設計レビューの時点では要求仕様書から「漏れた事柄」のため基本設計書にそもそもその記述がなかった。よってレビューはされなかった、ということがあったとします。さらにその後、要求仕様が変更されることで「漏れていた事柄」が追記され、その変更情報が詳細設計には反映された。となったとしましょう。

このため、詳細設計レビューで基本設計書との不整合が指摘され、詳細設計レビューでの基本設計レビューの「欠如」と判定されたのではないか、というような場合を示しています。

示唆される対応策1：基本設計レビュー「Missing:欠如」の場合　　

日々状況が変化しがちなソフトウェア開発において、変更情報はタイムリーに開発チーム内で共有されるべきです。そのために変更管理のルールが存在します。

この事例の場合、要求仕様変更に対して、変更管理ルールにより、タイムリーにその変更情報が全設計チームに伝わるようになっていたのかが疑われます。
基本設計レビュー完了後であっても、要求変更という重大性を考えると、その変更にもとづいて基本設計レビューをやり直すべきです。

基本設計レビュー「Incorrect:誤り」の場合

基本設計のレビューアが要求仕様あるいは基本設計書の理解を間違っていた場合を示しています。複数のレビューア全員が間違っていたとなると、要求仕様書、あるいは基本設計書の記述内容、記述密度などが誤解を招くような記述になっていると考えられます。

あるいは、レビューアの選定に問題があったことも考えられます。
スキルレベルが同じようなレビューアばかりでレビューをすると、一つの見解が支配的になり、間違った方向へ議論が進むことが多いからです。

示唆される対応策2：基本設計レビュー「Incorrect:誤り」の場合

要求仕様書に限らず設計関連ドキュメント類は、その品質を示すものの一つとして「正確性」と同等に「可読性」が重要です。
誤解を招きやすい、いかようにも解釈できるような記述は極力なくすべきです。
そうした不具合はドキュメント・レビューにて指摘すべきです。

ここでレビューに関して、
第4回で解説しましたトリガー属性と開発プロセス工程との関係の気づきで図表7を示しました。

レビュー実施に際しては、レビューの範囲の偏り、抜け、漏れが起きないように、レビューア選定には広範に知識、経験を持ったメンバーを含めて臨むことが必要だということを示しています。

更に、この事例では次の指摘もあります。

指摘2： 「機能」の割合に比して「ドキュメント」の割合が低く変化していない

上の図表８のように、設計レビューにおいて、多くの場合は設計仕様書のレビューも兼ねていることがほとんどです。
詳細設計レビューで30%を占める「機能」の不具合（うち基本設計の不具合は10%）に対して、「ドキュメント」の基本設計書に対する不具合が5%であることを示しています。
このことからは、何を持って「機能」の不具合に対応したのか、解決策がどういう扱い（基本設計仕様の修正変更の明文化）になっているのか、疑問を感じるべきところです。

この事例からは、要求仕様書の変更があったにも関わらず、基本設計仕様書に変更が反映されていないことが示唆されます。
また、上位ドキュメントと下位ドキュメントの比較による整合性検証が行われていないであろうことも示しています。

まず確認すべきは、「変更が反映された要求仕様書は実在するのか？」ということと、「詳細設計レビューでも機能の不具合を多く指摘されているが、基本設計書に対する不具合の対応は必要ないのか？」ということです。
それらが存在しないならば、変更管理が機能していないことが想定できます。
その結果、基本設計での「ドキュメント」の不具合が修正されず、詳細設計に漏れていると考えられます。
これでは、基本設計書をもとにした詳細設計レビューの正しさも保証できません。

このことに対し示唆される対応策は次の通りです。

示唆される対応策3：レビュー対象ドキュメントは、変更管理による正式な最新版を共有する。

変更管理、構成管理のシステム、ルールの有効性を見直し、レビュー対象の正式な最新版が共有できるようにする必要があります。

この事例のように、基本設計レビューが完了した後で要求仕様に変更が入った場合も、「良し」としてきた基本設計への要求変更の影響は検証すべきです。

タイプ属性の識別子であるMissing（忘れてました）とIncorrect（間違えました）は、前工程でのプロセス実施の「やり方」の質を如実に反映する因子です。それでは、その比率に着目するとどうでしょうか。

プロジェクト状況：

かなりタイトなスケジュールで開発を進めているプロジェクトです。設計を終えて、単体テストを開始したが、あまりの不具合の多さに、いったんテストを中断してタイプ属性のM/I比率を分析すると、次のよう（図表９）な分布を示しました。

次に、「何がおかしいのか」という観点で、このグラフを分析してみましょう。

ODC分析での見方と評価：

 単体テスト工程ということで、不具合数が多いのはある程度予想できます。
しかし、テストで見つけるまでもない、設計レビューで見つかるべき不具合が存在していることがよくあります。（設計レビューの質）

 この事例で、まず目に付くのが「アルゴリズム(Algorithm)」の不具合の割合が突出していることです（図表10）。

これらのことを踏まえると、次のような二つの指摘が挙げられます。

指摘1：「アルゴリズム」の不具合の多さ

「アルゴリズム」の不具合の多さは、詳細設計が存在していないか、不十分であることを示している場合が多いです。
このことは、Missing(欠如)の不具合が50%を占めていることから分かります。

また、「アルゴリズム」の不具合が多いと、Function(機能性)の不具合の多さが同調している場合が多いです。

指摘2：機能性のMissingの多さ

Function(機能性)に関わる不具合のうちMissing (欠如)の不具合が多く、該当する工程での不具合総数の1/4 (25%)を占めており、「Function」の不具合数の70%近くを占めている場合です。

このことは、設計工程またはそれ以前の要求分析工程でのレビューが不完全による要求事項あるいは設計要件の見落としや考慮不足が多発していることを示しています。

示唆される対応策：要求から基本設計、詳細設計へのひも付け再検討

単体テストを中断したのは正しい判断と考えられます。
このまま単体テストを続行しても不具合が多発してテストの意味をなさないからです。

そこで、正しく要求が仕様化され、基本設計書、詳細設計書へと抜け漏れなくひも付けられることを再検証すべきでしょう。
要求から設計への抜け漏れがあるならば、工程をさかのぼって再設計、再レビューの実施と仕様書の更新が必要です。

ここで示したタイプ属性のM/I比率の分析ですが、この判定の根拠は第4回で解説した「タイプ属性と開発プロセスとの関係」の気付きの一つである、タイプ属性識別子（M／I比率）の変化の観点（図表11）が参照できます。

これらの事例をまとめると次のことが言えます。 

▶ 要求分析や基本設計、つまり要求の具現化を検討している過程では、要求の抽出漏れや理解不足、考慮不足などで、識別子「Missing」が多くなる傾向にある。
▶ 工程が進み、設計詳細化やそのレビューが進むと、漏れや不足は減少し、当初設計したことの誤りに気づくことが増えるため、識別子「Incorrect」が主体となる。
▶ 工程が進んでも「Missing」が多いのは、上流設計でのレビューの抜け、漏れや不十分さ、あるいは急な要求変更や仕様変更への未対応が示唆される。

今回はODC分析の最も主体となるタイプ属性分析の事例を紹介しました。
次回は、他の属性での分析事例を紹介したいと考えています。

では、また次回お会いしましょう。

参考文献：

*1) Orthogonal Defect Classification – A concept for In-process Measurement
Ram Chillarege, Inderpal S. Bhandari, Michael J. Halliday, etc., IBM Thomas J. Watson Research Center
IEEE Transactions on Software Engineering Vol .18, No. 11, Nov. 1992ⒸIEEE

*2) ｢ソフトウェア不具合改善⼿法ODC分析」 〜 ⼯程の「質」を可視化する 〜
⽇科技連ODC分析研究会編 杉崎眞弘・佐々⽊⽅規
株式会社⽇科技連出版社 (ISBN978-4-8171-9713-9)

*3) INCOSE SYSTEMS ENGINEERING HANDBOOK V.4
A GUIDE FOR SYSTEM LIFE CYCLE PROCESS AND ACTIVITIES
WILEY (ISBN: 978-1-118-99941-7)