© Danilo Beuche, pure-systems GmbH
解析の方向
ドメインエンジニアリング
解決空間 問題空間
モデル モデル
解析の方向
マニュアル ソースコード
要求仕様 コンフィグファイ ル
バージョン管理
変更要求
マニュアル ソースコード
要求仕様 コンフィグファイ ル
バージョン管理
変更要求
© Danilo Beuche, pure-systems GmbH
問題空間のVP抽出
●
典型的な入力
– ユーザードキュメント
● インストール／ユーザーマニュアル
● ホワイトペーパー
– 開発ドキュメント
● 要求仕様、ユーズケース
● アーキテクチャー設計ドキュメント
● バージョン管理システムのログ（特にプロダクトブッシュ）
● コンフィグレーションファイル（特にプロダクトギャング）
● 顧客とのコミュニケーション（機能要求等）
問題空間のモデリング –フィーチャモデル
●
フィーチャーモデルはバリエーションポイントをフォーマルに記載するために、最も頻 繁に用いられる。
－フィーチャーモデルのコンセプトは分かりやすい －複雑なフィーチャーモデルでさえ、扱いが簡単
－殆どの実社会の課題を表現する十分な能力を持つ
●
一つのフィーチャは問題空間の特性であり、当該するバライアビリティを表現する
●
ツリー構造である
●
フィーチャの選択肢には、 (mandatory 全て必須) , (optional いくつでも), (alternative どれか一つ) (or 少なくとも１つ) がある
● フィーチャはコンストレインツを取ることがある（フィーチャ X には Yが必須など）
–
必須、排他など–
推奨、阻止など●
フィーチャは値や特性値も持ち得る
© Danilo Beuche, pure-systems GmbH
解決空間のVPの抽出
● 典型的な入力
–
アーキテクチャー設計ドキュメント–
ソースコード–
コンフィグレーションスクリプト–
プロジェクトのビルド定義（例えば、makefile）–
バージョン管理システムの構造と用法–
コンフィグレーションファイルとファイルフォーマット解決空間のVPをパターンから検出
・殆どの場合、少しのコードを良く見ると、使用されているパター ンが明確になる（プログラマーは繰り返しパターンを使いがちで あるので、小さな範囲内で得られるパターンは限られる）
・大抵コード構造が限定された構文に組み込まれるので、ソ
リューションスペースのパターンは、単純なツールを使って、より 簡単に検出できる。
・問題は、ソリューションから得られるバリエーションポイントの
数は、大抵非常に多くなる
© Danilo Beuche, pure-systems GmbH
解決空間の基本設計
●
参照される基準としてのアーキテクチャー
–
プロダクトから復元できる● プロダクトギャング、プロダクトブッシュ
–
単一のプロダクト又はスクラッチから構築が必要● プロダクトフォレスト
●
コア資産の特定
–
コンポーネントにアーキテクチャー特定の重み付け● 将来の製品での使用可能性
● 既存製品での使用率
● 適用により期待できる効果
–
全ての既存資産を使う必要は無い！© Danilo Beuche, pure-systems GmbH
アプリケーションエンジニアリング ドメインエンジニアリング
解決空間 問題空間
ドメインの熟練者 アーキテクト、開発者
アプリケーション 分析担当
アプリケーション エンジニア
組織内の役割分担
Project Team 4
プラットフォームセントリック
Project Team 2 Project Team 1
Project Team 3
PL Team
PL Core Assets
Project Team 5
Project Team 6
プラットフォームセントリックなアプローチ。
各プロジェクトチームより、多くの人員（リソ ース）を得てプロダクトラインチームを組む。
そして
PL
のコア資産をはじめに作成し管理 する。一旦PL
開発環境が構築されると、コ ア資産は盤石であるが、それまでは各プロ© Danilo Beuche, pure-systems GmbH
進化型プラットフォームセントリック
Project Team 2 Project Team1
Project Team 3
PL Core Assets Product Line Team
Project Team 4 Project Team 5
Project Team 6
各プロジェクトチームから少数の人員を得て、
PL
チームを組む。プロジェクト開発を進めな がら、そこで得られた資産をコア資産に登録 していく。ゆっくりと時間をかけてPL
チーム は大きくなり、コア資産は更に増加し、各プ ロジェクトは、より少ない人員で開発できる ようになっていく。プロジェクトセントリック
Project Team 2 Project Team 1
Project Team 3
Product Line Management Team
PL Core Assets
Project Team 4
Project Team 5
Project Team 6
各プロジェクトチームからの人員は最小限。
PL
チームではなく、PL
マネージメントチーム を組む。このチームは管理に専念し、各プロ ジェクトチームとコミュニケーションを図りな がら、プロジェクトチームの成果物を資産登© Danilo Beuche, pure-systems GmbH
アプローチの比較
プラットフォームセントリック 進化型プラットフォームセントリック プロジェクトセントリック
+ 長所 + 長所 + 長所
プロジェクトへの影響が最小 限定的なリスク 最小のリスク
レガシーが無くても始められる 徐々に組織を変えて行ける 組織的な変更が少ない
投資回収が早い
- 短所 - 短所 - 短所
組織への影響大 再利用性の向上が遅い目 最善の再利用規則が求められる
開始に時間がかかる レガシーシステムを再利用
する必要がある リスクが高い
再利用改善活動が開始されると、各関係者ごとで得られる個別の成果についての情
報交換・意思疎通が重要。だれもその取り組みに興味を持たなければ、協調連携が
複雑であることから、成果は容易に妨げられる。再利用性の無いコードを開発者が
生成したら、それが拡散してしまうことで望ましくない結果が待ち受ける。
© Danilo Beuche, pure-systems GmbH
計画を貫くことは良いことですが、定期的に調整するとより良いでしょう。
全ての障害は予測できませんし、耳を傾け、関係者からのフィードバック
を集めましょう。取り得る改善策を協議し、長期的なものと、急ぎの対策の
両方を得ることをいつも求めましょう。
Trap /catch
© Danilo Beuche, pure-systems GmbH
＜開発が外部委託される場合＞ プロジェクト費用が工 数から算出される為、再利用によって開発時間が短くなっ ても、利益にならない。彼らは再利用から得られる利益に ついて興味が無く、顧客が再利用を推進するように依頼し ても、再利用を成功させようとは考えない。
＜再利用可能な資産を作成・保守しようとするとコストが嵩むケース＞ １つ は、そのドメインや組織に於いて、技術の再利用が非常に困難な場合。２つ目 は、利害関係者に対する再利用の教育が不十分なケース。管理の立場から見 て、全利害関係者に、再利用に関する十分な知識を与える為のコストがかかり すぎる。３つ目は、異なるプロジェクトチームが同じような機能を沢山開発して いるケース。これらのプロジェクトでは、少しずつ違う機能が、実装されており、
これを再利用する場合、プロジェクト間の調整が困難です。
＜使用されない資産を開発するケース＞ コア資産開発チーム が開発した資産を他のチームが使わないケースがあります。こ れは組織上の問題で、何処でも起こることではありません。ある チームが他のチームが開発したコンポーネントや資産を信頼で きない為に、使わないというケースがありました。また、コア資産 が十分でない為に使われなかった例もありました。
＜管理側が再利用の為の開発体制を十分にサポートできないケース＞
非常に重要な問題。なぜなら、高い再利用性を実現するプロジェクトを始 めようとすると、単一のプロジェクトを開発するよりコストが嵩み、開発者 が低コストで生産することを要求するとトラブルになるからです。