【研究室】ソフトウェアプロダクトライン開発(SPL)においては、「アーキテクチャ」を中心とした技術的観点からソフトウェアの再利用の可能性を考慮してPLスコープを決定することが重要

【研究室】ソフトウェアプロダクトライン開発(SPL)においては、「アーキテクチャ」を中心とした技術的観点からソフトウェアの再利用の可能性を考慮してPLスコープを決定することが重要

【研究室】ソフトウェアプロダクトライン開発(SPL)においては、「アーキテクチャ」を中心とした技術的観点からソフトウェアの再利用の可能性を考慮してPLスコープを決定することが重要

ソフトウェアプロダクトライン開発(SPL)においては、「アーキテクチャ」を中心とした技術的観点からソフトウェアの再利用の可能性を考慮してPLスコープを決定することが重要|スコーピング
PL開発では、同系列の製品を製品ファミリとして捉え、この製品ファミリの中で資産を再利用します。この製品ファミリ(に含まれる製品)を定義することを、「スコーピング」と呼びます。スコーピングを行う際には、ビジネスと技術の両面から製品ファミリを考える必要があります。
組込み製品を開発する企業様では、事業戦略や製品戦略としての製品ロードマップを策定するのが通常ですが、これがPL開発のスコープを決定するための第一の入力となります。
ここで、「製品ロードマップ=PLスコープではないのか?」と疑問を持たれる方も多いと思います。これは、ビジネス上の製品ファミリ(製品のカテゴライズに近い)と、開発の効率化という観点で見た場合の製品ファミリは、時として異なるためです。
SPL「プロダクトライン開発」においては、「アーキテクチャ」を中心とした技術的観点からソフトウェアの再利用の可能性を考慮してPLスコープを決定することが重要

典型的な例を挙げてみましょう。「弊社の○○製品は、コストパフォーマンスに優れたローエンドの製品から、最新の△△技術に対応したハイエンド製品までをカバーする...」というような謳い文句の製品ファミリがあったとします。この場合、「ローエンドからハイエンドまで」の全ての製品を、ビジネス視点での製品ファミリとして捉えることもできますし、ローエンドやハイエンドといった幾つかのカテゴリで捉えることもできます。一方、それらの製品の設計を見てみると、ローエンド/ミドルエンド/ハイエンドでハードウェアやエレキ構成が大きく異なり、それらの間でのソフトウェアの再利用は到底現実的ではないとします。この場合、技術視点での製品ファミリは、「ローエンドファミリ」「ミドルエンドファミリ」「ハイエンドファミリ」の3つになります。ソフトウェアの再利用は、それぞれのファミリ内で行われるため、PLスコープはこの3つということになります。つまり、PL開発で言うところのスコープとは、「同一のコア資産を再利用する製品群」ということなのです。そして、資産の再利用が可能かどうかは、対象とする製品のアーキテクチャに大きく依存するため、SPLはアーキテクチャ中心の開発手法と呼ばれるのです。

SPL「プロダクトライン開発」においては、「アーキテクチャ」を中心とした技術的観点からソフトウェアの再利用の可能性を考慮してPLスコープを決定することが重要

あるいは、前述の例の拡張型として、ローエンド/ミドルエンド/ハイエンドでハードウェアやエレキ構成が大きく異なるため、それらの間でのベースソフト(OS/ドライバ等)とミドルウェアは異なるものの、アプリケーションは基本的に同じというような場合は、以下のような階層型のPL開発を行うこともあります。この場合は、プラットフォーム毎のPLとアプリケーションPLがあり、これらの組み合わせにより製品を開発する形となります。

SPL「プロダクトライン開発」においては、「アーキテクチャ」を中心とした技術的観点からソフトウェアの再利用の可能性を考慮してPLスコープを決定することが重要

アーキテクチャに起因する再利用の可能性、あるいは再利用のしやすさという技術的観点を無視してPLスコープを決定すると、極めて保守の困難なソフトウェアを開発する羽目になり、結果として開発生産性や品質を大きく損ねてしまいます。また、技術的観点に偏りすぎると、ビジネスとして想定されうる製品や要件が漏れてしまい、コア資産の再利用可能性が低くなってしまいます。それゆえに、ビジネス要求を十分に捉えた上で、アーキテクチャを中心とした技術的観点からソフトウェアの再利用の可能性を考慮し、PLスコープを決めることが重要になります。

【研究室】SPL(ソフトウェアプロダクトライン)化することで、「派生開発」の重複のムダを排除し、開発効率を劇的に改善|pagetop