実践的なSPLEについて
当日アンケートなどで頂いた、ご質問への回答を以下に公開しました。
＜スライドのファイル版＞ 以下に英語版、日本語版を置いています。
顧客事例は削除され、先日お配りした印刷版のみであることをご了承ください。
日本語版
＜ツールの具体的な説明、詳細デモなど＞
当日のデモと、同等の動画ファイルへのリンクは、このページの左側にあります。
＜ダイムラークライスラー社によるSimulinkモデルの変動性管理事例＞
この事例資料
＜フィーチャ間の関連の定義＞
フィーチャー間、フィーチャー・ファミリー間、ファミリー間全てに対して、Relation, Constraints, Restriction等で、関連や制限を定義できます。
Restrictionは、ファミリーモデル上のコンポーネントに対して、フィーチャを関連付けさせるために、主に用いられます（OR、NOT等の論理演算子も使えます）
Constraintsは、より複雑な制限を表現するために使用されます。あるエレメントを有効にする為に必要な条件を記述する事ができます。
Relationは、1対多などの複雑な関連を定義する為の設定で、特定のエレメント同士が同時に選択できない（conflicts）、特定のエレメントが選択されいなければ選択できない(requires)、等の設定を行えます。
これらの設定を基に、VDMモデル上の矛盾を検証することができるようにもなります。また、各エレメントに対して、アトリビュート（パラメーター）を設定し、値の妥当性をチェックしたり、パラメータ値との関連を定義することも可能です。
＜ファミリモデルにレガシーコードやSimulinkを登録してからの作業のイメージ＞
再利用可能なコア資産であるという前提の下で、、
レガシーコードをファミリーモデルとして読み込むと、ファミリーモデル（レガシーコード）内で使用されているフラグと同じ名前のフィーチャーを登録するだけで、ファミリーモデル内を自動的に検索し、フラグを使用しているエレメントがリレーション表示画面に表示されます。つまり、フラグを使用しているエレメント（レガシーコード）が簡単に見つけられます。
Simulinkコネクタでは、ファミリーモデルにサブシステムやブロック、信号線が登録されるのでそれぞれに対して、作成したフィーチャモデルに対応した制限（Restriction）を設定します。例えば、ファミリーモデルの○○ブロックは、△△のフィーチャモデルが選択された時に機能する（Simulinkモデルとして生成される）など。フィーチャモデルは、機能や処理単位で定義します。
＜バージョンやバリアントの差分表示＞
バリアント間で選択されているフィーチャの差分表示は、表形式に表示可能です。”バリアント：テストと欠陥へのリンク”の後半スライドは、複数バリアント間のフィーチャ選択表と、これらに対するBugzillaの連携事例です。バージョンに関しては、同様にCVSなどのバージョン管理ツールと連携させて管理することができます。
＜CAEツールの解析結果のバリアント管理、他 Perforce、UMLなど、各種ツールとの連携＞
CAEツールなどの実績は有りませんが、HW部品の管理デモと同様で、解析結果などを部品として容易に管理できるかと思います。
各種ツールとは、XML形式のファイルの読み書きで、 pure::variantsとデータの連携をとる事が出来ます。また、Eclipse API、Java API、SOAP等の標準的なAPIを備えており、それらの仕様もオープンになっている為、各種ツールとこれらAPIを介して統合することも可能です。
＜なぜ、エンタープライズ版、プロフェッショナル版が有るのか＞
フィーチャー、ファミリー、VDMの各モデルを保存する際に、プロフェッショナル版はXML形式の単一ファイルとして保存し、エンタープライズ版はデータベースとして保存すると言う違いがあります。
そのためエンタープライズ版では、マルチユーザーによる開発・管理を実現できます。また、エンタープライズ版には、ユーザー毎に作業範囲を制限できるメリットもあります。（VDMを含めた）モデル毎、モデルエレメント毎での制限も可能な為、共同開発時のユーザー毎に、細かく作業範囲を規定できます（例えば、ファミリーモデルのみ変更できる、VDMのみ変更できる、フィーチャーモデルのみ変更できる等）
＜なぜSPLは、あまり普及していないのか＞
Daniloさんの経験では、技術面以外の要素が多いようです。
全くの新製品開発では、SPLを適応することが難しい（実績や資産が無いので、フィーチャを割出しにくい）。一旦始まってしまってから途中でプロセスを変更することが厄介。複数プロジェクトが有る場合、各チーム間の連携が良くない（各マネージャさんは、自分のチームのことしか眼中に無い）。各プロジェクトチームが直接のビジネスをになっている為、力があり、プロセス改善チームの意見に耳を貸さない。。 など、人間くさい要因が多いようです。
＜サポート体制＞
pure::variants は、ツールとして安定しており、使用法や設定に関するサポートには、ご心配ないかと思います。 また弊社内で、複数のツールとの統合を確認済です。
プロダクトラインの導入に関しては、弊社でコンサルティングや技術サービスは行っていませんが、pure-systems社とのコンサルティング、あるいは国内でプロダクトライン導入支援を行われている会社をご紹介します。
＜なぜ、富士設備でSPL支援ツールを扱おうと考えたのか＞
弊社にも興味を頂いたようで、ありがとうございます。1年ほど前にMetaEdit+というDSMツールを扱うことになり、モデルからコードを生成させて効率を得るには、SPLの考えが土台になることを知り、その勉強のなかで pure::variants に出会いました。いずれのツールも国内では知られていなかったものの、海外では既に多くの実績があり、機能も洗練されていることから、きっと皆様のお役に立つと考え、取り扱うことにしました。
少し残念なのは、興味深い顧客事例が多くある割には公開されていないことです。SPLの本質からして、技術論よりビジネス戦略となっている為か、成功事例の公開に賛同していただけないそうです。
◇2008年2月8日(金)
プロダクトライン開発セミナー :
バリアント/バライアビリティ管理ツールと、ユーザ事例
市場投入までの時間を短縮し、製品の品質を上げる。
プロダクトライン開発は、再利用技術に基づいた、製品ファミリー全体の戦略的、体系的な開発です。
その実現のためには、製品を共通性と変動要素に分類し、要求、設計、ソフトウェア部品、テストにまで至るコア資産として管理することが必要となります。
とりわけ、製品ファミリーのライフサイクルに渡って、バリアントとバライアビリティを分類し、管理することで、再利用される資産は効率良く開発され、メンテナンスできるようになります。
本セミナーでは、プロダクトライン開発の概念を、バリアント/バライアビリティの管理に着目して紹介し、要件管理、構成管理、デザイン、テストなど各種ツールとの、実践的な連携についても説明します。
また、ユーザ事例を紹介し、現実的な取組みとして、現行の製品開発に於いてレガシーコードを、どの様にしてバリアントとバライアビリティに分類・管理し、体系的再利用としてのプロダクトライン開発を進めていくことができるかという点にも触れます。
講師紹介
Dr. Danilo氏は、独マグデブルグ大学、及び1995年からのGMD First（現、フラウンホーファー研究所）における、組み込みシステムに関する研究、フィーチャベースの開発ツールに対する取組みを基に、2001年に、pure-systems社を設立しました。組み込みシステムを中心に、プロダクトライン開発を支援する、バリアント/バライアビリティ管理ツールの開発を行い、コンサルタントとして顧客のプロダクトライン導入を支援しています。 実践的 ソフトウエアプロダクトライン開発 Blog記事
内容
■プロダクトライン開発：バリアント/バライアビリティの管理について
■pure::variants プロダクトライン開発支援ツール
■レガシーコードをプロダクトラインに（共通性と変動性の抽出と管理）
■ダイムラークライスラー社による、Simulinkモデルの変動性管理事例
■自動車関連企業による、HWとSWコンポーネントの管理と構成
■Danfoss Drives 社による、プロダクトライン開発への取組み