SPLE tutorial in Kumamoto

2008/11/20
組込みシステム産学官連携技術交流会 in 熊本
ソフトウェアプロダクトライン開発ワークショップ
「SPLE，如何に取り組むべきか？」
山内 和幸
概要
プロダクトライン（PL）開発を始めるに当たって、検討すべきこ
とと、幾つかのアプローチを紹介
1.
「ゴール」と「現状」の確認


2.
PL化する対象の特定

3.
ゴール： SPLEがもたらす効果
現状：
Family Evaluation Framework による評価
スコーピング
Light weight なアプローチの紹介

Extractive (+ Reactive) アプローチ
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
1
1
2008/11/20
「ゴール」と「現状」の確認
2
ソフトウェアプロダクトライン工学とは？（１）
ソフトウェアプロダクトライン工学（SPLE）と聞いて、何をイメー
ジしますか？
最先端の開発手法／技術
ソフトウェア開発の現状を救う、画期的な方法論
 経営哲学
 怪しい欧米の思想
 etc.


大抵の場合、十分な理解ができてないことが多い
質の良い（日本語の）情報が尐ない
工学体系として規模が大きいので、全体像が掴みにくい
 これまでの技術と似た部分が多いので、同じものだと捉えてし
まう
 etc.


Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
3
2
2008/11/20
ソフトウェアプロダクトライン工学とは？（２）
SPLE =

長年に渡って蓄積された、ソフトウェア工学の集大成


体系的な再利用をベースとした、ソフトウェア開発手法／技術
ソフトウェア工学技術と、ビジネスの融合

ビジネス価値の最大化に視点を置いた手法
これまでのソフトウェア工学に対して、

よりビジネスを意識した手法


どんなに開発生産性や再利用率が高くても、ビジネス上の効果が
出なければ無意味
個別の１製品の開発ではなく、同系列多品種の開発を意識した
手法

個別最適ではなく、全体最適
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
4
なぜソフトウェアプロダクトライン工学？
よく聞く話 － 「我社でもSPLEを導入したい」
質問： なぜ、SPLEを導入したいのですか？

この質問に対して、的を得た回答ができない場合は、導入リス
クが高い


抱える問題が、SPLEとは関係ないこともあり得る
あるいは、SPLEの採用を始めるには、組織の成熟度が低い
上記質問の回答に対して、「何故？」を数回繰り返してみよう

その結果、得られる答えが「導入目的」のはず
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
5
3
2008/11/20
プロダクトライン開発がもたらす効果
 SPLEを導入したい理由は、以下の期待される効果が企業にとって
魅力的だからに他ならない

直接的な効果
 開発工数の削減  開発コストの低減

初期投資を除いて、再利用資産部分の開発工数は０



再利用を前提としているため、スクラッチから開発する場合と比較して、短期
間で製品が開発できる


正確には、製品開発からのフィードバックの取り込み等があるため、０ではない
開発期間の短縮  新製品の短期での市場投入
短縮度合いは、再利用資産の規模／質／可変性の実現方法等に依存する
副次的な効果
 製品品質の向上

既に品質保証された再利用資産を利用するため、新規開発と比較して品質
を高く維持できる
 解決したい課題（つまり、導入目的）が、上記効果によって解消さ
れるならば、SPLEの導入は理にかなっていると言える
6
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
SPLEの投資対効果
工数
個別システム開発
PL開発1機種の
開発工数
プロダクトライン開発
経験則2：
工数削減効果は、PL開発で
2～3機種目から得られる
PL初期投資
個別システム1機種の
開発工数
経験則1：
投資額は通常、個別システム
開発の1～2機種分に相当
製品世代
1
2
3
4
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
5
6
7
4
2008/11/20
ゴールと現状の理解
 SPLEによってもたらされる状態が（１つの）ゴールだとしたら、そこと現状
のギャップは？

ギャップが大きいほど、導入障壁／リスクは大きい
 ゴールを明確にするために、SPLEを正し
く知ることが必要
 謳われている効果が出る理由は理解
しておきたい
 自分達が、今どのレベルにあるのかを、
客観的に知ることが重要
 評価軸としては、以下の手法を使うこ
とができる
 Product Line Technical Probe
 Family Evaluation Framework
現状とゴールの
ギャップ
8
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
Family Evaluation Framework*1 （１）
• Collaboration
Responsibilities
• Structure
Organization
• Roles &
• Collaboration
• Application
Process
• Domain
Architecture
• Variability
• Reference
• Reuse
Architecture
• Strategic
• Vision
• Financial
aspects
Business
• Commercial
dimension
Level 1
Project
based
Independent
development
Initial
Project
Level 2
Aware
Standardised
infrastructure
Managed
Reuse
Level 3
Managed
Software
platform
Defined
Weakly
connected
Level 4
Measured
Variant
products
Quantitatively
managed
Synchronized
Level 5
Optimizing
Configuring
Optimising
Domain
oriented
2008et
eXmotion
Co., Ltd.
All rights
reserved.
*1 F.Copyright(C)
van der Linden
al: “Software
Product
Lines
in Action” より
9
5
2008/11/20
Family Evaluation Framework （２）
自組織の状態を、４つの視点から評価
ビジネス（Business）
 アーキテクチャ（Architecture）
 プロセス（Process）
 組織（Organization）
 各視点は、さらにいくつかの小項目に分かれる

自分達が目指す状態が、BAPOそれぞれに対してどのレベル
なのかを確認
現状を評価し、どれだけのギャップがあるのか、どこを改善
すべきかを把握

どこから改善するか  導入戦略の一部
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
10
PL化する対象の特定
11
6
2008/11/20
SPLEのキー概念
SPLE を正しく理解する上で、以下の概念は理解しておきたい
スコーピング（scoping）
 ドメイン分析とアプリケーション分析（domain analysis and
application analysis）
 共通性と可変性（commonality and variability）
 決定モデル（decision modeling）
 結合時間（binding time）
 実体化支援（instantiation support）

これらの内、PL化する対象を特定するためには、スコーピン
グが役に立つ

スコーピングは、”Business” と “Architecture” の接点となる
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
12
スコーピング
スコーピングとは、PL開発の対象とする製品群／ドメイン群
の範囲を決める活動
戦略的な意思決定活動
 経営的視点（製品ポートフォリオ）と、技術的視点（何を再利用
可能にすべきか）の両方が必要

PuLSE-Eco*2では、以下の２つのステップにて実施される

PLマッピング

ドメイン・ポテンシャル分析


製品群と、それを構成する機能の対応関係を把握
製品群を構成するドメインの内、再利用の可能性の高いドメインを
特定
*2 K. Schmid: “A comprehensive product line scoping approach and its validation” より
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
13
7
2008/11/20
製品ポートフォリオ
既存の製品群、及び将来に予定されている製品群のリスト

例えばiPodの場合
※ iPodの開発に、SPLEが使われているかどうかは不明
品種
iPhone
空間軸での派生に伴う可変性
iPod touch
iPod
iPod nano
iPod shuffle
時間
時間軸でのバージョンアップに伴う可変性
14
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
PLマッピング
 対象となる製品群を構成する機能を、どのように組み合わせて、
製品を構成するかを計画
 個々の製品に搭載される機能は、機能-製品マトリクス（feature
product matrix）に記載

製品と機能の対応表
iPod
classic
iPod
shuffle
iPod
nano
iPod
touch
iPhone
3G
音楽再生
○
○
○
○
○
ビデオ再生
○
○
○
○
操作入力
○
○
○
○
○
通話
○
通信
○
○
○
GPS
※ ここに記載しているものは、iPod の機能の一部です
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
15
8
2008/11/20
ドメイン・ポテンシャル分析
製品に搭載されるソフトウェアを構成するドメインが、プロダ
クトライン開発に適しているかどうかを評価

「適している」 ＝ 「再利用の可能性が高い」
再利用性の可能性が高いドメインほど、コア資産化した場合
の効果が大きい
可能性が低いドメインは、資産化しても使われないので、投資
に見合わない
 様々な視点から、再利用の可能性を評価する必要がある

Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
16
ドメイン・ポテンシャル分析の評価基準
1. 成熟度

どの程度ドメインを理解しているか、どの程度ドメイン内の概念が整理されている
か
2. 安定性

概念や挙動が、どの程度安定しているか、あるいは標準化されているか
3. 共通性と可変性

どの程度の共通性／可変性があるか、また可変性は整然としているか
4. 凝集度と結合度

機能性が十分に凝集していて、かつ他のドメインと強く結合していないか
5. 既存資産

そのドメインの既存資産が既に存在するか
6. リソース制約

プロダクトライン開発を始めるに当たって、どんなリソース（人／物／金）が利用可
能か
7. 組織制約

そのドメインがどのように組織体と関係しているか、再利用が支持されるかどうか
8. 市場可能性

（組織の）内部的／外部的に、そのドメインをPL化することで、どのような可能性が
あるか
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
17
9
2008/11/20
ドメイン・ポテンシャル分析の結果
 評価基準の内、No.１～５を定量化

各基準の値域は、実施する組織にて定義
3
3
2.5
2.5
2
2
1.5
1.5
1
1
0.5
0.5
0
0
PL化の効果が低いドメイン
PL化の効果が高いドメイン
 これに、No.６～８の評価基準を加味して、対象ドメインのPL化の可
能性を評価

単にgo/stopではなく、どのようにアプローチしていくかも検討するのが
ベター
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
18
スコーピングの結果と移行計画
機能-製品マトリクスと、ドメイン・ポテンシャル分析結果を基
に、何を再利用対象とするかを決定
併せて、以下も検討
「いつ」再利用可能にするか  開発計画
「どこで」再利用可能にするか  組織構成
 「誰が」再利用可能にするか  リソース配置
 「どうやって」再利用可能にするか  アーキテクチャ


一度に全ての候補を再利用可能にすることもできるし、段階
的に再利用資産に加えていくこともできる


この決定こそが、“戦略的な移行計画”
組織の現状に合わせて、最適な移行計画を練ることが重要
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
19
10
2008/11/20
移行計画の違いによる、投資対効果の変化
工数
個別システム開発
段階的移行
一括展開
たとえ損益分岐点が同じだとしても、長期視点で見れば、一括展開
した方が効果は高い（一括展開が理想的に実施された場合）
• 段階的移行の方が、初期投資が小さくてすむ
（トータルでの投資額は、一括展開を超える）
• 部分的な移行の積み重ねなので、移行に伴う各種変更も局所
化される  リスク小
世代
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
20
Light weight なアプローチの紹介
21
11
2008/11/20
SPLEの導入アプローチ
 SPLEの導入において、以下の２つのアプローチが対比される
 Proactiveアプローチ（事前準備型）


先に再利用資産を構築し、その後に製品開発を開始
Reactiveアプローチ（都度対応型）


製品開発と同時に再利用資産を構築
あるいは製品開発後に、共通化可能な資産を抽出
 どちらのアプローチを採るにせよ、現実には、製品開発を一時的に止め
て／遅らせて、PL開発に移行するのはリスクが高い
 移行が100%成功する保証はない
 製品リリースタイミングを逃すと、競合他社にシェアを奪われる

移行期間が長いほど、リスクは増加
 既存資産を放棄して、スクラッチからPL開発に入るか？
 現実には難しい
 可能な限り、既存資産を活用する方が、リスクは尐ない
 組織によっては、既にSPLEのエッセンスを取り入れた開発を、暗黙の内に
実施している場合もある
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
22
現実的な導入アプローチ
 近年、Extractive（+ Reactive）というアプローチの事例が聞かれるよ
うになってきた
既存資産からコア資産を抽出し、それが可変性に耐えうるように徐々
に進化させて行く方法
 スクラッチからPLアーキテクチャを定義して、再利用コンポーネントを
開発していく方法と比較して、
 初期投資が尐なくて済む
 段階的な移行がしやすいため、各種変更によるリスクが小さい

 ただし、必ずしもこのアプローチが良い訳ではない
“Cost（既存資産のPL化） ＞ Cost（スクラッチから資産構築）”ならば、
Extractiveでは効果が薄い
 ドメイン／設計ナレッジの抽出に留めるべき
 アプローチ決定時には、「ゴール」と「現状」をよく検討した上で、適切
なアプローチを選ぶことが重要

Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
23
12
2008/11/20
Gears*3に見る、PL開発への移行方法（１）
*3 Gears は、米国 BigLever Software, Inc. の製品
Problem Space
Step 3: Top Tier
• フィーチャモデルを作成し、機能の組み合わせによる製品構成
をコントロール
• 製品ポートフォリオの最適化
Top Tier:
製品ポートフォリオ管
理の最適化
Middle Tier:
コア資産を核とした製品群開発
への移行
Base Tier:
既存資産の可変性管理と、製品ソフト
ウェアの自動構成
C. W. Krueger: “The 3-Tiered Methodology” より
Step 2: Middle Tier
• モジュラリティの高いアーキテクチャを構築し、そこで定義され
る汎用コンポーネントを開発
• 個別資産による「製品開発」から、プロダクトラインアーキテク
チャ／汎用コンポーネント等のコア資産をベースとした「製品群
開発」へ移行
Step 1: Base Tier
• 既存資産に存在する変動部の情報を収集／整理
• 変動点のコンフィグレーション用プロファイルを作成し、各製品
に必要な資産を自動的に構成
Solution Space
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
24
pure::variants*4 に見る、PL開発への移行方法（２）
*4 pure::variants は、ドイツ pure systems GmbH の製品
Problem Space
Solution Space
 既存の製品が、どういう関係にあるか（独立、流用開発、資産
共有、etc.）を調査する。
 関係性によって、移行時のリスク等が異なる。
SPLE導入前
既存製品の関係性調査
 調査結果に基づき、どのように移行するのかの計画を立てる
 事前準備型 or 都度対応型，段階的 or 一括移行
移行シナリオの特定
 既存資産に存在する可変性を調査／分析し、再利用単位を
決定する。
• フィーチャモデル
• プロダクトラインアーキテクチャ
 可変性の抽出方法は、既存資産の状況により、次の２通りか
ら選択可能
• フォワード型
製品仕様やマニュアル等から、製品毎の機能の差異を抽
出  アーキテクチャやコードに反映して行く
• バックワード型
アーキテクチャやコード等、設計資産内に存在する可変
性を抽出 製品毎の機能の差異へと昇華させて行く
可変性分析
モデル構築
SPL開発
富士設備工業（株）主催 「プロダクトライン開発セミナー」講演資料より
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
25
13
2008/11/20
終わりに
26
終わりに
SPLEは、効果の大きな戦略的再利用を可能にするが、その
適用にはリスクも多い
リスクを抑えて、効果を得るために、
「ゴール」と「現状」をしっかりと認識し、
経営的／技術的両視点から十分に分析して、
 組織に合った移行計画を立てること！



一括展開 vs. 段階的移行
欧米に負けない、日本発の成功事例を増やして、共有して
いきましょう！

九州、ひいては日本の競争力強化のために！！
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
27
14
2008/11/20
参考資料
 F. van der Linden, K. Schmid, E. Rommes: “Software Product Lines in Action”,
Springer, 2007.
 K. Schmid: “A comprehensive product line scoping approach and its validation”,
Proceedings of the 24th International Conference on Software Engineering.
 C. W. Krueger: “The 3-Tiered Methodology: Pragmatic Insights from New
Generation Software Product Lines”, Proceedings of the 11th International
Software Product Line Conference.
 BigLever Software Inc., http://www.biglever.com/index.html
 D. Beuche: “Software Product Lines and pure::variants”, プロダクトライン開発セミ
ナー資料, http://www.fuji-setsu.co.jp/products/purevariants/pg111.html
 Pure systems GmbH, http://www.pure-systems.com/
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
28
SPLEのキー概念：要約（１）
 スコーピング


PL開発の対象とする製品群／ドメイン群の範囲を決める活動
これにより、再利用範囲が決まるため、戦略的な意思決定が必要
 ドメイン分析とアプリケーション分析

コア資産／製品の二層開発
 コア資産開発： ドメイン・エンジニアリング
 個々の製品開発： アプリケーションエンジニアリング
 共通性と可変性
共通性
 開発する全ての製品に共通の特性
 可変性
 開発する製品群の一部にのみ現われる特性、または製品毎に変わる
特性
 この可変性をコントロールし、製品開発を効率化することが、PL開発の
重要項目

Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
29
15
2008/11/20
SPLEのキー概念：要約（２）
 決定モデル


個々の可変性に対して、「判断」を行うための情報
質問／回答の値域／回答選択時のアクション／制約／他の可変性と
の関連等により構成される
 結合時間
再利用資産には、製品群全体では必要だが、個々の製品には必要の
ない部分も含まれている
 再利用資産 ≒ 汎用資産（Generic Asset）
 この「必要のない部分」をいつそぎ落とすかが、“結合時間”
 可変性をいつ解決（bind）するのか
 コンパイル時、リンク時、実行時、etc.

 実体化支援

再利用資産群から、個々の製品に必要な資産のみを選択して、構成
するための仕組み作り
 ツールによる自動構成等
Copyright(C) 2008 eXmotion Co., Ltd. All rights reserved.
30
16