**********************************************************************
セッションS3-c チュートリアル
テーマ：実践ソフトウェアプロダクトライン 〜 現実的な適用アプローチ 〜
講師：山内 和幸 （エクスモーション） 
日時：2010/9/3 10:30〜12:00
参加人数：32名（終了時）
**********************************************************************

○ 本セッションの概要

製品ファミリの開発生産性/品質向上を狙って，ソフトウェアプロダクトライン
（以下，SPL）の導入を考えている企業は少なくないが，その障壁は小さくない．
本セッションでは，導入リスクを低く抑えて，比較的短期間でPL開発へ移行する
為の実戦的なアプローチを紹介する．


○ 内容

1. PL開発の概観(入門SPLの振り返りとデモ)
2. PL開発への移行
　2-1. ステップ0：調査・計画
　2-2. ステップ1：統合
　2-3. ステップ2：導出
　2-4. ステップ3：進化
3. 複雑な開発状況への適用
4. 質疑・応答

1. プロダクトライン開発の概観

● PL開発の重要ポイント

　・可変性分析
	→ 製品ファミリ(スコープ)に属する製品間の「違い」を把握
　・再利用資産 
	→ PLアーキテクチャの決定，フィーチャとコンポーネントの対応付け
　・製品導出
	→ 可変性に基づく資産の効率的な利用


● デモ 〜 液晶時計 〜

◇ シナリオ：液晶置時計の開発メーカＡ社は，以下の様々な製品を開発している

　・ アナログタイプ　　　　→　3本針(時・分・秒)と 2本針(時・分のみ)
　・ ディジタルタイプ　　　→　12時間表示形式と24時間表示形式
　・ 目覚ましアラーム機能　→　アラーム無し，電子音 or メロディの一方，または両方を搭載


◇ 製品マップ(or フィーチャマトリクス(product-feature matrix))

　◆ 各製品にどのフィーチャ(その製品の代表的な特性)が搭載されるか？(下記は一部)


　————————————————————————————————————————————
｜　　　　　　　　　　　　｜製品Ａ｜製品Ｂ｜製品Ｃ｜…｜製品Ｉ｜製品Ｊ｜…｜製品Ｍ｜製品Ｎ｜
｜————————————————————————————————————————————｜
｜時計表示｜アナログ　　　｜　○　｜　○　｜　○　｜…｜　　　｜　　　｜…｜　　　｜　　　｜
｜　　　　｜———————————————————————————————————————｜
｜　　　　｜ディジタル(12)｜　　　｜　　　｜　　　｜…｜　○　｜　○　｜…｜　　　｜　　　｜
｜　　　　｜———————————————————————————————————————｜
｜　　　　｜ディジタル(24)｜　　　｜　　　｜　　　｜…｜　　　｜　　　｜…｜　○　｜　○　｜
｜————————————————————————————————————————————｜
｜アラーム｜電子音　　　　｜　　　｜　　　｜　○　｜…｜　　　｜　○　｜…｜　　　｜　○　｜
｜　　　　｜———————————————————————————————————————｜
｜　　　　｜メロディ　　　｜　　　｜　○　｜　　　｜…｜　　　｜　　　｜…｜　○　｜　　　｜
｜————————————————————————————————————————————｜
｜指示針　｜時針　　　　　｜　○　｜　○　｜　○　｜…｜　　　｜　　　｜…｜　　　｜　　　｜
｜　　　　｜———————————————————————————————————————｜
｜　　　　｜分針　　　　　｜　○　｜　○　｜　○　｜…｜　　　｜　　　｜…｜　　　｜　　　｜
｜　　　　｜———————————————————————————————————————｜
｜　　　　｜秒針　　　　　｜　　　｜　○　｜　　　｜…｜　　　｜　　　｜…｜　　　｜　　　｜
　————————————————————————————————————————————


◇ 可変性モデル

　◆ 製品マップから把握される可変性の関係性をモデル化
　　　　→ 代表例：フィーチャモデル(feature model)

　　　　　　　　　　　　　　　 液照度計
　　　　　　　　　　　　　　／　　　　　＼
　　　　　　　　　　時計表示　　　　　　　アラーム
　　　　　　　    ／ (代替) ＼　　　　　／　　　　＼
　　　　　アナログ　　　　デジタル　 電子音o　　メロディo
　　　　　／　　　　　　／ (代替) ＼
　　　 指示針　　　　12時間　　　24時間
　　／　 ｜　 ＼
　時針　分針　秒針o

　※ 注：
　　・ o が付されているものはオプション
　　・ (代替)は，一方のみが排他的に選択される
　　・ ツリー構造は，そのフィーチャを構成する
　　・ 但し，(時計表示 → アナログ/デジタル)，(アラーム → 電子音/メロディ)，
　　　 (デジタル → 12時間/24時間)は汎化・特化


◇ 再利用資産(１)：PLアーキテクチャ

　◆ 対象PLに属する全製品をカバーする，共通のアーキテクチャを決定
　　　　→ 製品毎に差異があるので，冗長性を持つ


◇ 再利用資産(２)：コンポーネント

　◆ 各フィーチャと，製品開発時に利用されるコンポーネントの対応付け
　◆ 共通部のみで構成されるものと，可変部を含むものがある
　　　→ 後者は汎用コンポーネント(generic component)と呼ばれる

　※ 注：ここでは，UML(クラス図)を用いてコンポーネントが示された．
　　　　 UMLにおける可変点の扱いは，可変点であるフィーチャに対応するクラスに
　　　　 <<variants>>を付している．


◇ デモンストレーション

　◆ ツール：統合開発環境 Eclipse IDE for Java，可変性管理ツール pure::variants
　◆ 内容：pure::variantsによる可変性のモデル化と，可変性の決定に基づく製品導出


2. プロダクトライン開発への移行 〜 RIPPLEアプローチ 〜

● 既存資産の利用可能性

　◇ SPLEの導入を考えている企業は，すでに系列製品の開発を行っている．
　　　　→ 新規市場参入時にPL開発を導入することはしない
　　　　　　　　∵ 共通性・可変性の知見がなく，ドメインの特性も分からないため

　◇ 従って，「再利用の可能性のある資産を保有している」
　　　　→ 問題は，その資産が以下を満たすか？(※１)
　　　　　　　　・ 予測される将来的な拡張に対して，用意に対応可能か？
　　　　　　　　・ 無駄な工数を割くことなく，製品開発を行うことが可能か？
　　　　
　　　　→ 上記 2項目を満たすように，既存資産に改善を加える．


● PL開発へのステップ

　◇ まずは，既存資産を活用した移行を検討するべき
　　　　・ 現状の把握：(主に)ソースコードから，重複部分，差異を分析
　　　　・ 既存資産ベースの移行可能性を評価：(※１)を満たすよう，既存資産を
　　　　　 改善することが可能か？

　◇ 既存資産ベースの移行が可能な場合

　　　　1. 技術面での移行
　　　　　　　　・ 重複の削除，将来的な拡張に備えて，既存資産をリファクタリング
　　　　　　　　・ ビジネス視点での将来の変化を予測し，技術的にサポート可能な
　　　　　　　　　 よう，製品の品質を改善
　　　　2. 体制面での移行
　　　　　　　　・ 開発プロセス，組織体制の見直し
　
　◇ 現状の開発スタイル
　　　　◆ 個別開発型：
　　　　　　　　・ 複数のメインラインが並行に存在
　　　　　　　　・ 各ラインはバージョンアップはするものの，派生はしない
　　　　◆ 派生開発型：
　　　　　　　　・ メインラインから複数のブランチが派生
　　　　　　　　・ 各製品ブランチから，さらに製品ブランチが派生
　　　　　　　　・ メインラインがどこなのか分からなくなる
　　　　◆ 統合開発型：
　　　　　　　　・ メインラインから複数のブランチが派生
　　　　　　　　・ 各ブランチはバージョンアップはするものの，派生はしない
　　　　　　　　・ 各ブランチの対応は，メインラインに統合
　　　　　　　　・ 製品間の差異を分析し，効果的に管理するには至っていない

　　　　→ 構成管理の状況を見れば，どのスタイルに該当するかは把握可能
　　　　　　　　→ 構成管理されていないのならば，ほとんどが個別開発型


● 技術面から見たPL開発への移行

　◇ 技術的なPL開発移行とは：
　　　　◆ 複数ある資産の一本化 → 再利用資産化
　　　　　　　　→ 個別/資産開発から統合開発型へ
　　　　◆ 資産中の可変性の分析・管理
　　　　　　　　→ 可変性に基づく，再利用資産からの製品導出を実現

　◇ どちらの方法をとるべき？
　　　　◆ 既存資産の再利用資産化　→　○
　　　　◆ 新規に再利用資産を構築　→　△

　　　　→ 既存資産の品質に依存する


● RIPPLEアプローチ

　◇ “extractive & reactive”アプローチ：PL開発移行手段の 1つ
　　　　◆ 既存資産をフル活用して再利用資産を構築し，そのあとに製品開発を行い
　　　　　ながら，資産を洗練・進化させていく

　◇ e-motion社のアプローチ
　　　　“extractive & reactive”アプローチを以下の 3段階で実施
　　　　1. 既存資産の統合による，資産の一元化(Rapid Integration)
　　　　2. 一元化した資産の可変性分析と整理による，製品導出の仕組み作り(Production)
　　　　3. 製品開発との協調による，資産の洗練・進化(Product Line Evolution)

　　　　→ 短期間でのPL開発の導入が可能

　◇ 移行フロー

　　　　移行対象の選定 → 対象の解析 → 移行プランの策定 → 工数の予測
　　　　
　　　　→　移行工数は許容範囲か？
　　　　　　・ Yes：<<RIPPLEアプローチ>>
　　　　　　・ No：再検討が必要か？
　　　　　　　　　　・ Yes：「移行対象の選定」へ
　　　　　　　　　　・ No：PL開発の効果あり？
　　　　　　　　　　　　　　・ Yes：再構築 → <<RIPPLEアプローチ>>
　　　　　　　　　　　　　　・ No：移行中断


● 既存資産ベースの移行可能性の評価

　◇ 既存資産を分析することで，RIPPLEアプローチの適用可能性を検討
　　　　・ どれだけの資産があるのか？
　　　　・ どの資産が利用可能か？
　　　　・ それぞれの資産の品質(とくに保守性)はどうか？
　　　　・ 現存する可変性や，その実現メカニズムは適切か？
　　　　・ etc

　◇ 技術的な視点だけでなく，ビジネス的視点からも評価
　　　　・ 移行に必要な工数は？
　　　　・ 移行に際して，どれだけのリソース(人・物・金)が利用可能か？
　　　　・ 移行して効果がある(QCDの向上が見込める)ドメインか？
　　　　・ etc


2-1. PL開発への移行 ステップ0：調査・計画

● 既存資産のブランチのうち，どれを将来の再利用資産とするかを決定

　◇ 基準：今後の製品が，そのブランチを基に開発される可能性があるか？
　　　　　　・ ある：統合対象として検討
　　　　　　・ ない：統合対象から外す

　　　※ 一度に決定する必要はない


● 対象の解析

　◇ 統合対象が，どの程度類似している or 異なっているかを多面的に解析
　　　　◆ 解析対象：主にコード，モデルでも可
　　　　◆ 解析項目(例)：
　　　　　　　　・ アーキテクチャ構造
　　　　　　　　　　　→ アーキテクチャの安定度，求められる特性を把握
　　　　　　　　・ 差分解析(類似度や共通部/可変部など)
　　　　　　　　　　　→ ブランチ間の類似度を計測し，それを基に移行の容易さと
　　　　　　　　　　　　順序を検討
　　　　　　　　　　　→ 類似度が高ければ，資産化が容易と考えられる
　　　　　　　　・ 可変性情報の抽出
　　　　　　　　　　　→ 2つのブランチ間の共通部/可変部を比較により計測し，可視化
　　　　　　　　　　　
　　　　　　　　　　　※ コードから抽出可能な「違い」
　　　　　　　　　　　　　　・ ファイルの有無(製品への搭載有無)
　　　　　　　　　　　　　　・ シンボル情報(プリプロセッサ・ディレクティブなど)
　　　　　　　　　　　　　　・ コード差分

　　　　　　　　　　　この違いが発生する理由こそが可変性！
　　　　　　　　　　　　　　・ なぜ違うのかを精査することで，可変性を見つけられる
　　　　　　　　　　　　　　・ 一般的に「違い」の数よりも「可変性」の数の方が多い


● 移行プランの策定

　◇ 解析結果に基づき，移行プランを策定

　　　　◆ 効果の高いコンポーネント(or パッケージ)に優先順位づけ


● 工数の予測

　◇ 予測すべき２種類の工数
　　　　
　　　　◆ 移行にかかる工数：
　　　　　　　　・ 現在の開発スタイルからPL開発への移行

　　　　◆ 移行後のメンテナンス工数：
　　　　　　　　・ 現在のスタイルで開発を継続した場合と，PL開発へ移行した場合
　　　　　　　　　の累積メンテナンス工数

　　　　→ これらを総合的に判断し，移行妥当性を検討


● 予測工数に基づく，統合対象の見直し

　◇ 既存コードに存在する「違い」が大きければ大きいほど，統合には工数がかかる

　◇ 移行作業が許容値を超えた場合の対策
　　　　・ 許容値を上げる
　　　　・ 統合対象ブランチを減らす
　　　　・ 統合対象コンポーネントを減らす

　◇ 段階的な移行も可能
　　　　・ 次機種の予定がしばらくないブランチの統合は後回し
　　　　・ 機種毎にほとんど作り変える，変更のパターンが読めないコンポーネント
　　　　　は統合しない or 優先度を下げる


2-2. PL開発への移行 ステップ1：統合

● 統合ステップ

　◇ 個別開発/派生開発のどちらからの移行か？

　　　　◆ 個別開発：差分の再開発 → 基本的に新規開発なので，本セッションでは省略

　　　　◆ 派生開発：既存資産の統合


● 既存資産の統合

　◇ 統合作業は単調だが，非常に工数がかかる
　　　　→ 作業内容の標準化による自動化を図る

　◇ 統合作業にはいくつかの方針がある

　　　　1. 単純に統合し，コードのリファクタリングはしない
　　　　　　　　・ 作業の自動化しやすい
　　　　　　　　・ 可変性と無関係なもの(コードの書き方の違い など)によっても，
　　　　　　　　　工数が発生

　　　　2. 統合と同時にリファクタリングを実施
　　　　　　　　・ ミスがあった場合に問題が特定しにくい
　　　　　　　　・ どんなリファクタリングをすればよいのかは，変更のパターンが
　　　　　　　　　分からなければ判断できない

　　　　※ 統合時にはリファクタリングをするべきではない

● 既存資産の統合：工程解説

　1. 統合順序の決定

　　　　◆ 調査結果を基に，工数が少なくなるよう統合順序を決定

　　　　◆ 基本方針：
　　　　　　・ 類似度が高いものから実施
　　　　　　・ 規模の大きいものへ，小さいものを足すように統合

　2. 対象ブランチの用意

　　　　◆ 最初の統合：統合する 2つのブランチを用意

　　　　◆ 2回目移行：既に統合したブランチと，次に統合するブランチを用意

　3. ブランチの統合

　　　　◆ 変更のある部分にシンボルを付与

　4. プリプロセス

　　　　◆ 付与したシンボルを基に，統合済みブランチから元のブランチをそれぞれ生成

　5. 統合結果の確認

　　　　◆ プリプロセスで得られたブランチをオリジナルと比較 → 同一であればよい

　6. 統合ミスの修正

　　　　◆ 統合できなかった場所を特定し，修正


2-3. PL開発への移行 ステップ2：導出

● 導出ステップ

　◇ 導出ステップでは，「可変性」に焦点を当てる
　　　　→ スコープ内の可変性を適切に捉え，それを効率よく実現するための仕組みを作る

　◇ 自動化できる部分は少ない
　　　　
　　　　◆ プロセスは想定できるが，中身は知識的集約が多い
　　　　　　　　→ PL開発の成否に大きな影響を与える


● 可変性の分析・管理：工程解説

　1. 可変性情報の抽出

　　　　◆ 統合時に埋め込んだ(あるいは，既存資産に埋まっていた)可変性情報を収集

　2. 可変性情報の分析

　　　　◆ 抽出された可変性情報を整理
　　　　　　　　→ 同義のものを統合，不要なものを削除 etc

　　　　◆ 整理した可変性間の関係をモデル化
　　　　　　　　→ フィーチャモデルなどを利用

　3. 資産のリファクタリング

　　　　◆ 統合した資産中の可変点を，その変更パターン(特性)に合わせて，適切な
　　　　　バインディング・メカニズムへと変更

　4. 製品の導出

　　　　◆ 可変性の決定(≒選択肢の選択)により，再利用資産から製品用資産を導出
　　　　　する仕組みを構築し，製品用資産を導出
　　　　　　　　→ 可変性管理ツール(pure::vatiants)の利用が効果的

　5. テスト

　　　　◆ 導出された製品用資産をテスト
　　　　　　　　→ リファクタリングによる内部構造の変更のため，テストは必須

　　　　◆ テスト資産も既存資産があるならば活用
　　　　　　　　→ ブラックボックステストはこれで十分
　　　　　　　　→ 既存のテスト資産が存在しない場合には，新規にテスト設計を行う

　6. 修正

　　　　◆ テストで導出できなかった部分を特定し，修正


● 可変性の数 vs. 管理手法

　◇ 可変性の数が増えると，分析の難易度が上がる
　　　　　　　　→ 直感的には，可変性の数と工数は指数関数的な増加

　◇ 可変性の数に応じて，分析方法を変える

　　　　◆ 例）n：可変性の数
　　　　　　　　・ 1≦n≦100　　：詳細に依存関係を分析
　　　　　　　　・ 100＜n≦1000	：大まかなグループに分け，各グループで可能なら詳細化
　　　　　　　　・ 1000＜n　　　：列挙するのみ(可変性間の依存関係は分析しない)

　◇ 可変性に対してデフォルト値を用意する
　　　　　　　　→ もっとも高い選択肢をデフォルト値とするとよい


2-4. PL開発への移行 ステップ3：進化

● 進化ステップ

　◇ 製品ファミリの寿命が尽きるまで，長期にわたる資産の維持管理を実施
　　　　・ 絶え間ない追加・変更・修正箇所への対処
　　　　・ 可変性の継続的な管理

　◇ 通常のエンジニアリング技術の多くが利用可能

　◇ 注力すべきは「可変性の管理」と「PLアーキテクチャの保存」
　　　　・ 適切に保守することで，PL開発の効果を大きく得ることができる


● 新規要件への対応

　◇ 再利用資産への追加・変更・修正要求へ対応するためには？

　　　　◆ 事前準備(proactive)
　　　　　　　　・ 先に再利用資産を構築し，その後に製品開発を開始
　　　　　　　　　　　→ 多くの部品を事前に揃えられるため，製品開発の大幅な
　　　　　　　　　　　　効率アップが期待
　　　　　　　　　　　→ 反面，遅延による影響が大きい

　　　　◆ 都度対応(reactive)
　　　　　　　　・ 製品開発と同時に再利用資産を構築，あるいは製品開発後に共通化
　　　　　　　　　可能な資産を抽出
　　　　　　　　　　　→ 製品開発側のスケジュールで開発可能なため，自由度が高い
　　　　　　　　　　　→ 余分な工数が必要


● 増加する可変性への対処

　◇ 可変性に関する事実

　　　　◆ 製品ファミリの可変性は，時とともに増加する傾向にある

　　　　◆ 可変性の数が多いほど，開発/保守工数は増大する

　◇ 可変性の数をむやみに増やさないこと → 開発を適正な工数にコントロールするため

　　　　◆ 不要となった可変性を除去

　　　　◆ 常に一緒に搭載される可変性を統合

　◇ 定期的な可変性の検査


3. 複雑な開発状況への適用

● 現状の把握：複合型

　◇ 個別 → 派生開発型：複数の個別開発のラインがあり，それぞれが派生開発型に変化

　　　　◆ 検討項目：複数の個別ラインを 1つのPLへ統合するか？
　　　　　　　　・ Yes：主とするラインをPL化し，残りを副とみなして個別型として対処
　　　　　　　　・ No ：対象とするラインを，派生型として対処

　◇ 個別 → 統合開発型：複数の個別開発のラインがあり，それぞれが統合開発型に変化

　　　　◆ 検討項目：複数の個別ラインを 1つのPLへ統合するか？
　　　　　　　　・ Yes：複数の統合ラインの最新版を，個別型として対処
　　　　　　　　・ No ：対象とするラインを，統合型として対処

　◇ 派生 → 統合開発型：派生開発の途中で，統合開発型に変化

　　　　◆ 検討項目：なし
　　　　　　　　・ 複数の統合ラインの最新版を，個別型として対処

　◇ 個別 → 派生 & 統合開発型：複数の個別開発のラインがあり，
　　　　　　 派生開発に変化したものと統合開発型に変化したものがある

　　　　◆ 検討項目：複数の個別ラインを 1つのPLへ統合するか？
　　　　　　　　・ Yes：主とするラインをPL化し，残りを副とみなして個別型として対処
　　　　　　　　・ No ：対象とする部分に合わせて，個別 → 派生形 or 個別 → 統合型として対処

　◇ 派生 → 派生 & 統合開発型：派生開発型の途中で，派生の一部が統合開発型に変化

　　　　◆ 検討項目：複数の個別ラインを 1つのPLへ統合するか？
　　　　　　　　・ Yes：主とするラインをPL化し，残りを副とみなして個別型として対処
　　　　　　　　・ No ：対象とする部分に合わせて，派生型 or 個別型として対処


4. 質疑・応答

Q. フィーチャーツリーを書く際には，人によって差ができてしまう．
　それを上手く(書く人による違いを少なく)作るためにはどのようなアプローチが必要か？

A. まず，顧客から見える部分の分析と，システム開発者からの視点である内部の分析
　に分けるべき．


Q. 可変性の数が増えると分析の難易度が上がってしまうとある．分類をした際の依存
　関係が時間が経つにつれ，
　不必要な分類が発生するのだが，適切な分類方法を教えて頂けないか？

A. すべてを分類すればよいというわけではない．
　例えば，管理者により名前の付け方が異なっている場合は，それは名前が異なるだけ
　なのでまとめるべき．
　ただし，時間が経つにつれ変化する可能性のあるものはまとめるべきではない．


■ まとめ

PL開発は，技術だけではなく，ビジネス戦略，プロセス，組織体制まで含めた包括的な
ソフトウェア開発
プロセスである．従って，その効果が大きい反面，リスクも大きい．特に，PL開発への
短期間移行は大きな課題である．

RIPPLEアプローチは，PL開発の短期間意向を実現する為の手法の 1つである．
その概要は，既存資産をフル活用し，再利用資産を構築し，製品開発を行いながら資産
を洗練・進化させていく．

PL開発への短期間以降により，システム開発の効率化が期待される．

以上．