SPL開発への移行の進め方～２.既存資産を統合・差分分析

SPL開発への移行の進め方～２．既存資産を統合・差分分析

RIPPLEの二つの統合アプローチ

SPL開発への移行アプローチであるRIPPLEは、既存資産統合の進め方と して、二つのアプローチを用意しています。

一つは要求を中心に資産を統合するRequirement Integrationのアプローチ、もう一つはコード/モデルを中心に資産を統合するRapid Integrationのアプローチです。図5は二つのアプローチの違いを示しています。

要求中心のアプローチの場合、まずは代表製品の既存資産から、要求仕様をUSDM形式で明らかにします。その後、他製品の要求仕様の差分を記述粒度を保ったまま統合し、製品群全体の要求仕様と製品ごとに搭載されている機能を定義します。

USDM形式で記述することによって、製品群全体の機能を漏れなく、正確に把握することができ、加えて製品ごとの機能の差異が明らかになります。

つまりこのアプローチは、既存資産の要求仕様の統合と製品群における搭載機能の違いに関する分析（可変性分析）を同時に、かつ確実に行うことができます。

一方、コード/モデル中心のアプローチの場合は、複数製品間のコード/モデルに共通した処理や異なる処理を、ツールによって自動的に判別し、判別結果を確認しながら差分を統合することで、全製品を導出可能な、包括的なコード/モデルを作成します。この場合、コード/モデルの統合はスピーディーに行えますが、製品群の可変性を分析するためには、製品間のコード/モデルの単純な差異から、製品間の要求の違いを導出する必要があります。

これら二つのアプロ―チは、可変性分析を確実に行う事を重視するか、統合するスピードを重視するかで、使い分けることができます。

一般的なトップダウンのアプローチとの違い

可変性分析における成果物は、全製品に共通・可変な機能をツリー構造で表現し、機能間の依存関係（他機能を要求・排除する関係）を定義した「フィーチャーモデル」と呼ばれるものです。

一般的なSPL開発では、フィーチャーモデルを作成する前に、製品群全体の機能を製品企画書等のビジネス要件から抽出し、製品ごとの機能搭載の有無を分析する必要があります（図6上）。

この場合、企画書等からトップダウン的に詳細な機能を、網羅的かつ粒度を統一して見極めることは困難であるため、フィーチャーモデルは粗い粒度となりやすく、実際に開発されるアーキテクチャの実体とかけ離れてしまう恐れがあります。

これに対してRIPPLEアプローチでは、前述のように製品群の特性を、既存資産を元に仕様の粒度まで網羅的に分析するため、より詳細で粒度の統一された、アーキテクチャの実体に近いフィーチャーモデルを定義することができます（図6下）。

SPL関連コラム

SPL（プロダクトライン）開発に関する記事を見る

他のソリューションを見る

最新コラム