ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(3) ―― 導入方法と効果は開発タイプごとに異なる
●[分析1] 顧客要求をサービス視点で分解し，さらに設計構造視点で分解する
ここでは，下記の手順で分析を進めました（図3）．
- ケーパビリティ・フィーチャ：顧客要求をサービス視点で分解し，複数の下位機能を抽出する．サービス視点で分解できなくなるまで，これを続ける．
- 実装技法フィーチャ：最下位の機能を実現するために必要な設計部品を実装技法フィーチャ上に定義する．設計構造視点で分解できなくなるまで，これを続ける．
- サービス視点から定義した設計部品と，設計構造視点で分解した設計部品を組み上げて，システム構造を決定する．なお，組み上げの際に不足する設計部品（サービス視点からは見えない設計部品）があれば，追加定義する．
図3 顧客要求をサービス視点で分解し，さらに設計構造視点で分解したフィーチャ図
この分析方法のメリットは，機能から設計部品を抽出するので，機能が影響を与える設計部品の特定が容易であることです．またデメリットは，実装技法フィーチャ上にサービス視点から定義した設計部品と設計構造視点から定義した設計部品がさまざまなレイヤに混在するため，設計部品間の整合性が低いことです．
●[分析2] 顧客要求をサービス視点と設計構造視点個別に分解し，対応する機能と部品を関連付ける
ここでは，下記の手順で分析を進めました（図4）．
- ケーパビリティ・フィーチャ：顧客要求をサービス視点で分解し，複数の下位機能を抽出する．サービス視点で分解できなくなるまで，これを続ける．
- 実装技法フィーチャ：顧客要求を実現するシステムを設計構造視点で分解し，複数の設計部品を抽出する．設計構造視点で分解できなくなるまで，これを続ける．
- 対応する機能と設計部品を関連付ける．
図4 サービス視点と設計構造視点個別に分析して対応付けたフィーチャ図
この分析方法のメリットは，設計構造としては最適な構造になること，また，サービス視点，設計構造視点から個別に分析するので，フィーチャ分析が容易なことです．デメリットは，機能と設計部品が1:1に対応しないものが存在し，一つの機能を変更すると複数の設計部品に影響が出ることです．
