品質確保に効果のあった派生開発プロセスの工夫#17

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　　⇒ｐａｒｔ４
　　　⇒ｐａｒｔ５
　　　⇒ｐａｒｔ６（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part６)

対処検討プロセスを順に解説していく。今回は最後のプロセスである「1.5 対処決定」の解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.5 対処決定

1.5.1 プロセスの目的・概要

対処決定プロセスの目的は、「1.4対処案の検証」プロセスの結果を関係者間で協議し、決定することである。
採用された対処案が決定することで、本プロセスは終了となるが、次の「2.開発プロセス群」の実施に先立って、要求事項トレーサビリティ・マトリクスを作成する。本資料の作成によって、次工程の開発箇所を明確にすると共に開発量の見積りを行うことができる。

1.5.2 ツールと手法

以下に、本プロセスで用いるツールと手法について示す。

（１）変更スコープと検証スコープの差異分析
派生開発の特徴の１つとして、プログラムの修正規模とテスト規模が一致しないという点が挙げられる。欠陥修正や機能追加を行った際に、実際に修正したプログラムコードだけをテストするのではなく、修正箇所に影響する母体処理も併せて既存動作への影響がないことを検証しなければならない。派生開発では、常に母体処理のデグレードがないのかを考慮しながらテストを行う必要がある。

こうした特徴の結果、変更量は数ラインなのに、テスト規模が数キロラインに及ぶといったこともあり得る。

このため派生開発では、早めにテスト規模を明確にしておくことが望まれる。テスト規模が曖昧なまま作業を進めると、テスト工程に突入してからはじめて大量のテスト規模になることが判明してスケジュールを圧迫する場合がある。

また、テスト工程に突入してから変更箇所が影響を与える母体処理を検討した結果、母体処理でのデグレードが発覚して手戻りが発生する場合もある。できるだけ早期にプログラムの修正規模とテスト規模の差異を明らかにしておくことで、これらの差異を踏まえたスケジューリングやプロジェクト運営が行えるようになる。

ここで言う変更スコープとは、実際にプログラムを修正した範囲のことを示し、検証スコープとは、テスト対象範囲を示す。この差分をどのように洗い出し、またどのようにプロジェクト計画に反映するのかを示す。

まず検証スコープの優先度を３段階で示す。この段階分けは、適用するプロジェクトやシステムの特性に応じて変更して構わない。固定的な基準を示すわけではない。優先度の意味は、テストを実施する際の優先度と同義である。

・図表1.5-1　検証スコープの段階と優先度

直接検証スコープは、要求コンセプトの実現を保証するためには、必ず検証を行わなければならない範囲を示す。

要求コンセプトを実現するために、実際に修正を行ったプログラムは、必ずこのスコープに属する。ただし場合によっては、実際に修正を行っていないにも関わらず、直接検証スコープに属することもある。

間接検証スコープは、実際に修正を行ったプログラム箇所ではないが、そのプログラムや機能との関連が強い機能やプログラムが含まれる。

例えば、Ａ⇒Ｂ⇒Ｃの順に処理を行う箇所があり、このうち処理Ｂを直接的に修正した場合は、Ｂとインタフェースを行うという意味で、処理Ａと処理Ｃは、間接検証スコープに属する。変更箇所の前後に動作する箇所、および変更箇所と同時に（並列で）動作する箇所、といったような基準で判断を行う。この判断基準は固定的なものではないが、リグレッションテストを行う際に、優先度の比較的高い機能や、重点的に確認をしなければならないテスト項目が該当する。

非関連検証スコープは、要求コンセプトとはほとんど関連のない機能や処理のことである。論理的に考えて影響を及ぼすことはないが、リグレッションテストなどで予期せぬデグレードがないことを確認する程度のスコープと判断してよい。

このうち、間接検証スコープと非関連検証スコープについては、試験対象とする機能やプログラムを事前に特定し、テスト項目数に応じたテスト期間を見積っておくことで、プロジェクト計画への落とし込みができる。

また非関連スコープよりも、間接検証スコープのほうがデグレードの発生確率が高い。デグレード発生に備え、項目数に応じた欠陥摘出予想数を見積り、改修工数も含めてプロジェクト計画に反映することができる。

間接検証スコープと非関連検証スコープのテスト項目は、テスト対象機能の基本動作を再確認しデグレードの有無を判断するだけの場合が多く、それほど多くのテスト工数が必要になることはない。テストの費用対効果によっては、非関連検証スコープはテストを行わない、といった意思決定をすることもできる。

次に直接検証スコープについて説明する。直接検証スコープのうち、テスト項目が漏れやすく注意が必要なのは、変更スコープに含まれてない箇所である。

・図表1.5-2　テストが漏れやすいスコープ

変更スコープには含まれていないので、プログラムの修正をしていないが、直接検証スコープに含まれているので、要求コンセプトを実現するには、この領域の動作が正常であることを検証しなければならない。

しかし変更スコープではないために検証が必要であるという意識が薄れ、テスト項目が不足してしまう傾向にある。

変更スコープと直接検証スコープの差異は、要求コンセプトの一部が変更を伴わない母体処理に依存して実現されている場合に発生する。

こうした変更スコープと検証スコープとの差異を明らかにする方法を次に示す。具体例として「ある装置障害の検出ロジックを変更する」という欠陥是正について示す。この欠陥是正のプログラム変更内容は“装置障害の検出ロジック”だけであるが、要求コンセプトは「装置障害を適正に検出し、リカバリ動作を行う」であるとする。つまり、システムとして装置障害を適正に検出し、その後のリカバリ動作も正常に行えることを保証するというものである。

装置障害の検出からリカバリ動作までは、次の処理で構成されているとする。

まず、装置障害を検出する“検出処理”、装置障害の検出を周囲のインタフェース装置へ通知する“通知処理”、装置障害検出後のリカバリ動作を行う“リカバリ処理”の３つである。この３つの処理のうち、今回のプログラム修正範囲は“検出処理”だけである。つまり変更スコープは“検出処理”であるが、要求コンセプトを満たす直接検証スコープは“検出処理”、“通知処理”、“リカバリ処理”の３つの処理となる。

これらの関係を網羅して示すために、マトリクス表記を用いる。“検出処理”では、検出する障害のバリエーションとしてＡ～Ｃ障害の３パターンがあり、今回の変更に関連しているのはＡ障害だけだとする。また、“リカバリ処理”の動作方式としてα～γ方式の３パターンがあるとした場合、マトリクス表記は図表1.5-3のようになる（“通知処理”は、障害内容を通知するだけなので甲処理の１パターンだけとする）。

・図表1.5-3　マトリクスによる変更スコープ／検証スコープ表記

検出処理のＡ障害に関する箇所のプログラムを変更しているからといって、Ａ障害の検出処理だけを検証すれば良いというわけではない。

要求コンセプトを実現するには、通知処理とリカバリ処理についても検証が必要になる。

図表1.5-3の通番１～３は、変更スコープに関連するＡ障害の一連の処理であるため、検証の優先度は最も高いＡ（高）としている。この範囲を直接検証スコープに含めることができる。

通番４～６のＢ障害は、Ａ障害に関連して発生する可能性の高い障害だとしよう。そうした場合、Ａ障害の検出論理の変更によってＢ障害へ影響を及ぼす可能性があるため、優先度をＢ（中）として間接検証スコープに含めている。通番７～９のＣ障害は、Ａ障害・Ｂ障害とも全く関連性のない独立した障害であったとする。このときＣ障害については変更による影響が少ないと判断して、優先度をＣ（低）として非関連検証スコープとした。

上記のスコープのうち、デグレード発生の可能性が最も高いのはＡ障害で、次がＢ障害、最後がＣ障害となる。このうち、Ａ障害の検出論理の変更により、通知処理、リカバリ処理への影響がないのかを確認する必要があることには気が付きやすい。なぜなら変更スコープに直接的に関連する処理であることを把握しやすいからだ。

それと比較すると、Ｂ障害は変更スコープには全く含まれないが、Ａ障害に間接的に関連しているため、場合によってはＢ障害の検出動作などが影響を受けているかもしれない。

さらにＢ障害処理にはプログラムの変更が入っていないので、Ｂ障害処理のプログラムを事前に確認して、変更による影響がないことを机上検証していない場合も多い。Ｂ障害へは影響を及ぼさないという前提条件を設定して、Ａ障害に変更を加えた可能性がある。よって、変更は一切されていないにも関わらず、比較的高い優先度で検証を行う必要がある。

Ｂ障害処理に見るように、変更スコープには含まれていないが、検証スコープの一部である箇所については、スコープ差異が存在するために検証の漏れを引き起こしやすい。図表1.5-3は単純な例を説明したので、マトリクス表記にせずとも把握できるかもしれないが、実際の欠陥対応では処理が複雑に関連している場合もあるため、一旦マトリクス表記を用いて、変更スコープと検証スコープの差異を把握することが望ましい。

どのように検証スコープ（検証の優先度）を定義するのかは、プロジェクトの状況やシステム特性を踏まえて判断すれば問題はない。重要なのは検討を行うための手法を用いて議論のテーブルに載せることである。

マトリクス表記は要求仕様を求める際にすでに作成済みであることが多いため、ほとんどの場合はそれをそのまま用い、図表1.5-3に示す変更欄と検証欄、優先度欄を付与するだけでスコープ差異を検討することができる。

以上でプロセスの説明は終了である。

残りは「開発プロセス群」と「検証プロセス群」だが、ここは参考までに記載したものであり、特に派生開発特有の内容があるわけではない。

よって、派生開発の主要なプロセスについては以上で終了となる。

次回はシリーズエントリの最終回とし、まとめをしてみたい。