ソフトウェアプロダクトライン構築（SPL開発）の4ステップ

SPL開発への移行の進め方～１．調査・計画

SPL開発に移行する際に、既存資産を一度にまとめて統合することは、決して容易ではありません。そのため、事前に既存資産の全体像をしっかり把握し、最適な統合順となる移行計画を立案することが重要になります。図4は移行計画を立案するプロセスを示しています。

SPL｢プロダクトライン開発｣への移行の進め方【１．調査・計画】既存資産を解析して製品を統合する順序を決定し、具体的な移行プランを立案します｜既存のコード/モデル⇒既存資産を解析する⇒既存資産の解析結果⇒製品の統合順を決める⇒製品の統合順⇒スケジュールを決定する⇒スケジュール

「1.1.既存資産を解析する」では、既存資産のコード/モデルなどを解析することによって、製品間の類似度を把握します。

「1.2.製品の統合順を決定する」では、製品間の類似度が高い順に製品の統合順序を決定します。

「1.3.スケジュールを決定する」では、各製品の資産を統合し、コア資産化するまでに要する工数を見積り、全ての製品の資産を統合するまでの詳細なスケジュールの立案を行います。

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

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

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

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

SPL｢プロダクトライン開発｣への移行の進め方【２.既存資産を統合・差分分析】移行プランに従って既存資産の要求やコード/モデルを統合し、統合結果から製品間の差分を明らかにします｜Requirement Integration：要求を中心に資産を統合する、Rapid Integration：コードモデルを中心に資産を統合する

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

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

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

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

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