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

開発プロセスの定義から、各開発工程での検証作業は検証目的に沿ったトリガー（行為）を持って行っている（はず）です。そのことから、しかるべき検証ができ、しかるべき不具合が発見できると考えます。

また、トリガーは潜んでいる不具合を発見するために必要な環境や条件がそろっているか否と深い関係があり、不完全な環境や条件での実施では十分にそのトリガー（行為）の有効性は発揮できないと言えます。

プロジェクト状況：

この事例は、タイトなスケジュールとなってプロジェクトが進行していました。理由は、設計作業が遅れて十分な設計レビューがないまま、テスト工程を開始せざるを得ないと判断されたからです。
現状、機能テストが十分に完了しないまま、次のシステムテストを開始した状況です。

図表１は、発見された不具合の工程別不具合数の割合（工程別不具合数/総不具合数）を示しています。

ODC分析での見方と評価：

システムテストの途中ですが、明らかに設計工程からの不具合の漏れが十分に単体・機能テストで検出できず、システムテストに漏れて発見されていることを示しています。

このことから、次の指摘が挙げられます。

指摘：開発プロセスの期待とは乖離した不具合の出方をしている

システムテストでの不具合数が増加していることから、設計工程からの不具合の漏れを、本来機能テストを含め前工程でも発見可能な不具合までもシステムテストで発見していると見えます。

このことは、システムテストでやるべきシステムレベルのテスト（システムテストのトリガー）に行き着く前に、単体・機能テストのトリガーによる不具合によってシステムテストがしばしば中断して、完遂できていないことを示しています。

さらに、設計レビューや機能テストでの作業コストに対して、システムテストでは接続機器の調達や他システムの使用などコストのかかるテストになっているにも関わらず、あるべきでない前工程で見つかるべき不具合を高コストな環境で発見していることになります。

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

示唆される対応策：設計レビューから機能テストまでを再度やり直す

設計レビューを再度やり直し、機能テストまでを再実行すべきです。

スケジュールのプレッシャーがあっても、このままシステムテストを続けることは、継続して高コストな前工程からの不具合を見つけるだけで、本来のシステムテストの進捗にはつながらないからです。

つまりシステムテストを開始できる条件・状況が整っていないということで、工程をさかのぼって検証を見直しし再実行することで開始条件を整えるべきです。

この事例はトリガー属性分析とはいえ、具体的なトリガー属性の議論になっていないと思われるかもしれません。
その通りで、トリガー属性の定義は「不具合を検出した行為」を指すものであることから、検証作業行為そのものを意味し、開発プロセスでの工程作業、検証作業の定義に則したものであるか否か、その属性分布からカバレッジの妥当性、十分性を見ることはできます。
しかしながら、それ以上の品質議論にはなかなか膨らまない属性とも言えます。

このことから、トリガー属性単独で評価するよりも、タイプ属性と組み合わせることで設計の複雑度合、完成度合などの評価に有効に使えると考えます。
トリガー属性の「行為」という性質から実施した人の行為のスキル、経験値などに依存する部分があることにも注意が必要です。

ここで、第4回で解説した「トリガー属性とレビューアの経験値との関係」について再掲します。

図表2の通り、設計レビューにおいてレビューアのスキル・経験値によってレビューの質や視野に差があることが分かっています。このプロジェクトの場合、設計レビューがないままテストを開始したという状況です。
つまり、図表2はトリガーによる設計検証がすっぽり抜けていることを意味しています。

このことは、レビューで見つかるべき不具合がそのままテスト工程に漏れていったことを意味します。

さらにこのプロジェクトの場合、単体・機能テストでの不具合摘出の割合が予想を下回っていることから、同じく第4回で解説した「トリガー属性とテスターの経験値との関係」を図表3として再掲します。

設計レビューからの漏れ不具合が歴然とある中で、それらを摘出すべき単体・機能テストを実施したにも関わらず、システムテストへ不具合が漏れていったことから、図表3からテストカバレッジの不足あるいはテスターの力量の不足が明らかです。

以上のことから、対応策として設計レビューから単体・機能テストに至る検証を見直して再実行する前に、担当したレビューア、テスターの適格性を再検証し、不足があれば強化する必要性を示唆しています。

ソース・コードは、その開発履歴と（意図的、潜在的に関わらず）残存不具合を持っています。拡張開発や派生開発などの場合、新規開発コード部分は誰もが注目しますが、もともと持っていたベース・コード部分にはあまり注意が払われないことがよくあります。

しかし不具合が摘出された箇所のソース・コードの開発履歴に着目することで、不具合の根本原因にたどり着けることはよくあります。

プロジェクト状況：

この開発プロジェクトは、すでにリリース1 (R1)として出荷されており、その機能拡張としてのリリース2 (R2)の開発工程がほぼ完了した状態です。

リリース1とリリース2のソース属性によるODC分析結果を比較してみると、図表4に示すとおりほぼ同じソース属性分布になっていることから、リリース2も同等品質と判断しようとしています。

次に、「どのように評価すべきか」という観点で、このグラフを分析してみましょう。

ODC分析での見方と評価：

R2はR1とほぼ同じ比率でソース属性の不具合分布を示していますが、このことからR2はR1と同等なコード品質レベルと見るべきではないと言えます。

注目すべきは、ベース・コード部分からの不具合の割合が、R1とR2ともに40%を超えていることです。ベース・コード部分の残存不具合が、R1のときに摘出されず、R2時点でも同数以上残存していたという事を意味しています。ベース・コード部分に注意が払われて来なかったのか、あるいは新規開発部分とベース・コード部分との不整合による不具合には、全てベース・コードの不具合とされている可能性があります。

これらのことから、次の指摘が挙げられます。

指摘：新規開発部分とベース・コード部分の仕様整合性を見直すべき

派生開発、拡張開発の場合、とかく新規開発部分は注意が払われますが、元々あるベース・コード部分の仕様が新規開発部分の仕様と整合性があるかどうかの設計検証がおろそかになっていることを示唆しています。

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

示唆される対応策：関連するベース・コードの仕様との整合性を再検証すべき

ベース・コード部分は、全く検証されていなかったとは考えにくいですが、不具合数の割合から、検証の観点が不足していたと考えられます。
変更や拡張で追加となった新規開発部分の仕様と、関連するベース・コードの仕様との整合性を再検証すべきです。

不具合が摘出された箇所のソース・コードを開発履歴の観点で分析してみることで、設計レビューやコード・インスペクションの「やり方」に関わる妥当性が分かります。

プロジェクト状況：

拡張開発の基本設計が完了し、詳細設計のレビューを兼ねて既に作成した部分のコード・インスペクションを並行して行なった状況です。このコード・インスペクションでは、基本設計レビューで見つかるべき不具合が詳細設計に多く漏れていることが、コードと詳細仕様書を付き合わせることで判明しました。

この時点でのソース属性によるODC分析結果を、図表5に示します。

ODC分析での見方と評価：

上段の基本設計レビューでの不具合の多くは新規機能に集中しており、Missing(欠如)に分類されています。基本設計レビューで見つかるべき不具合が、詳細設計レビューでも多く見つかっていることも分かっています。

詳細設計書と作成したコードを突き合わせると、突出して書き直しコードに集中しており、Incorrect(誤り)に分類されています。これは、詳細設計レビューで発見された不具合のコード上での修正結果と考えられます。
そのうちのIncorrect(誤り)の多さと、依然Missing(欠如)が出ていることから、特に基本設計の要求分析からの不具合の漏れと考えられます。

これらのことから、次の指摘が挙げられます。

指摘：設計レビューで、Missing(欠如)が多いのは基本設計での要求の見落としが主因

設計レビューで、Missing(欠如)が多いのは要求分析から基本設計に至る過程での要求分析が不十分あるいは要求項目の理解不足や見落としていることが主な原因と考えます。

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

示唆される対応策：設計レビューでのMissing(欠如)は、要求から見直す

要求分析から基本設計に取り込むべき事項の抜け漏れを再度検証すべきである。
そのためには、基本設計レビューにて要求事項との突き合わせ、紐付けをやり直す必要がある。

よく言われるのが「要求から設計への紐付け」ということですが、その「やり方」として仕様書など膨大に書かれている設計情報の文字面を追っているだけでは、なかなか抜け漏れは防げないと読者も経験的に感じていると思います。

そこで清水吉男氏によって提唱されたのがUSDM (Universal Specification Describing Manner)です。
USDMは、派生開発推進協議会から発表された要求と仕様を階層化して紐付ける仕様書の書き方手法です。私自身USDMの有効性は実感し実務で使っており、特にODC分析とUSDMとの親和性について、ことあるごとに説いています。
USDMについては、今後予定している「なぜ不具合は起こるのか？」というテーマの回で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

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

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