製品ファミリーエンジニアリング
製品ファミリーエンジニアリング（PFE）は、プロダクトライン・エンジニアリングとも呼ばれ、1980年にカリフォルニア大学アーバイン校のジェームス・ネイバーズ（James Neighbors）が学位論文で用いた造語で、[1]ソフトウェアエンジニアリング研究所（Software Engineering Institute）が生み出した「ドメイン・エンジニアリング（domain engineering）」の考えに基づいている。ソフトウェア製品ラインは、私たちの日常生活においてごく一般的なものですが、製品ファミリーを成功裏に確立するには、広範なプロセスに従わなければならない。このプロセスは、製品ファミリーエンジニアリングとして知られている。
製品ファミリーエンジニアリングは、組織の製品プラットフォームの基礎となるアーキテクチャを作成する手法として定義できる。これは、共通性と計画された可変性に基づくアーキテクチャを提供する。さまざまな製品バリエーションは、基本的な製品ファミリーから派生させることができるため、ファミリー内の製品を再利用し、差別化する機会が生まれる。製品ファミリーエンジニアリングは、自動車業界で広く使われている車両プラットフォームと概念的に似ている。
製品ファミリーエンジニアリングは、新製品を生み出すための比較的新しいアプローチである。製品のコンポーネントを再利用し、コストと時間を削減しながら可変性を適用できるように、新製品をエンジニアリングするプロセスに焦点を当てている。製品ファミリーエンジニアリングとは、コンポーネントや構造を可能な限り再利用することである。
製品ファミリーエンジニアリングのアプローチを製品開発に用いると、いくつかの利点があることがいくつかの研究で証明されている。[2]以下にそのいくつかを列挙する：
- 生産性の向上
- 品質の向上
- 市場投入までの時間の短縮
- 労働力の削減
後述のノキアのケースも、こうした利点を示している。
プロセス全体
[編集]プロダクト・ファミリー・エンジニアリング・プロセスは、いくつかのフェーズから構成される。主な3つのフェーズは以下のとおりである：
- フェイズ1: 製品管理
- フェイズ2: ドメイン・エンジニアリング
- フェイズ3: プロダクト・エンジニアリング
このプロセスは、より抽象度の高いレベルでモデル化されている。これには、ソフトウェアだけでなく、あらゆる種類の製品ラインや製品ファミリーに適用できるという利点がある。このモデルは、あらゆる製品ファミリーに適用できる。図1（下）にプロセス全体のモデルを示す。以下、プロセスを詳細に説明する。プロセスの説明には、アクティビティと使用されている重要な概念の詳細が含まれている。イタリック体で示した概念はすべて、表1で説明している。
フェイズ1: 製品管理
[編集]最初の段階は、プロセス全体の立ち上げである。この段階では、特に経済的側面に関して、いくつかの重要な側面が定義される。この段階では、市場戦略の概要と、製品ファミリーの中にあるべきものとそうでないものを示すスコープを定義する責任がある。
ビジネスビジョンの評価
[編集]この最初の活動では、製品ラインの範囲を定義するために関連するすべてのコンテキスト情報が収集され、評価される。明確な市場戦略を定義し、消費者の需要などの外部市場情報を考慮に入れることが重要である。この活動では、ガイドライン、制約条件、製品戦略を含むコンテキスト文書を作成する。
プロダクトラインのスコープの定義
[編集]スコープ技法は、どの側面がスコープの範囲内にあるかを定義するために適用される。これは、外的要因が考慮されたプロセスの前のステップに基づいている。出力は、現在および将来の製品のリストと製品ロードマップを含む製品ポートフォリオの説明である。
フェーズ1の製品管理が製品ファミリーエンジニアリングのプロセスの一部であるかどうかは議論の余地がある。しかしフェーズ2では、スコープの大部分がこのフェーズで定義されるため、このフェーズからの重要なインプットが必要となる。したがって、この観点からは、製品管理フェーズ（フェーズ1）をドメインエンジニアリングプロセスのベースとしてプロセス全体に組み込むことが重要である。
フェイズ2: ドメイン・エンジニアリング
[編集]ドメイン・エンジニアリングのフェーズでは、製品ライン全体の可変要件と共通要件が収集される。その目的は、再利用可能なプラットフォームを確立することである。このフェーズのアウトプットは、製品ラインの全製品の共通要件と可変要件のセットである。
ドメイン要件の分析
[編集]このアクティビティには、コンセプト要件に関してドメインを分析するためのすべてのアクティビティが含まれる。要件は分類され、2つの新しいアクティビティに分割される。アウトプットは、ドメイン分析の文書である。
図1に見られるように、共通要件を定義するプロセスは、可変要件を定義するプロセスと並行して行われる。両方の活動は同時に行われる。
共通要件の定義
[編集]製品ラインの共通要件を引き出して文書化するためのすべてのアクティビティが含まれ、その結果、再利用可能な共通要件を含む文書が作成される。
可変要件の定義
[編集]製品ラインの可変要件を引き出して文書化するためのすべてのアクティビティが含まれ、その結果、可変要件を含む文書が作成される。
ドメインの設計
[編集]このプロセス ステップは、製品ラインのリファレンス アーキテクチャを定義するアクティビティで構成される。これにより、製品ライン内のすべての製品の抽象構造が生成される。
ドメインの実装
[編集]このステップでは、再利用可能なコンポーネントの詳細な設計とこれらのコンポーネントの実装が作成される。
ドメインのテスト
[編集]コンポーネントの再利用性を詳細かつ有効性を検証する。 コンポーネントは仕様に照らしてテストされる。さまざまなユースケースやシナリオですべてのコンポーネントのテストが成功すると、ドメイン・エンジニアリングのフェーズが完了する。
フェイズ3: プロダクト・エンジニアリング
[編集]最終段階では、製品Xが設計されている。この製品Xは、ドメイン・エンジニアリングのフェーズの共通性と可変性を利用しているため、ドメイン・エンジニアリングのフェーズで確立されたプラットフォームから製品Xが派生している。 基本的に、前のフェーズからのすべての共通要件と類似点に加えて、独自の可変要件が適用される。ドメイン・エンジニアリングのフェーズのベースと製品エンジニアリングフェーズの個別の要件を使用して、完全な新製品を構築できる。製品が完全にテストされ、承認された後、製品Xを納品できる。
製品要件の定義
[編集]個々の製品の製品要件仕様を作成し、前のフェーズの要件を再利用する。
製品の設計
[編集]製品アーキテクチャを作成するためのすべてのアクティビティ。「ドメインの設計」ステップからのリファレンス アーキテクチャを利用し、リファレンス アーキテクチャの必要な部分を選択して構成し、製品固有の適応を組み込む。
製品の構築
[編集]このプロセスでは、再利用可能なコンポーネントの選択と構成を使用して製品が構築される。
製品のテスト
[編集]このステップでは、製品が仕様に照らして詳細かつ有効性が検証される。テストレポートには、実行されたすべてのテストに関する情報が記載されており、製品で発生する可能性のあるエラーの概要が示される。次のステップのプロダクトが受け入れられない場合、プロセスは「ビルドプロダクト」にループバックする。図1では、これは「[unsatisfied]」として示されている。
製品の納品とサポート
[編集]最後のステップは、最終製品を受け入れることである。 テストが正常に完了し、完成であることが承認された場合は、納品することができる。製品が仕様を満たしていない場合は、再構築して再度テストする必要がある。
次の図は、上で説明した製品ファミリー エンジニアリングの全体的なプロセスを示している。これは、さまざまなステップに関連するすべての概念を含む完全なプロセスの概要である。
プロセスデータ・ダイアグラム
[編集]左側には上から下までの全プロセスが描かれている。左側のすべてのアクティビティは、点線を通じて右側の概念にリンクされている。すべての概念には番号があり、他の概念との関連性を反映している。
コンセプトのリスト
[編集]以下に概念を含むリストを説明する。 ほとんどの概念定義は Pohl, Bockle & Linden (2005) から抽出されており、いくつかの新しい定義も追加されている。
| コンセプト | 定義 |
|---|---|
|
ドメイン分析 |
この文書には、共通要件と可変要件を分割できるドメインの分析を含む。 |
|
再利用可能な 共通要件 |
この文書には、製品ラインのすべての製品に共通の要件を含む。 |
|
可変要件 |
この文書には、さまざまな製品のカスタマイズされた要件の派生を含む。 |
|
リファレンス アーキテクチャ |
製品ラインのすべての製品に有効な静的および動的分解を決定。 また、設計、部品の実現、およびそれらを組み合わせて製品を形成する方法を導く共通のルールの集合でもある。 |
|
可変モデル |
製品ラインの可変性を定義。 |
|
再利用可能なコンポーネントの設計および実装資産 |
製品ファミリー全体に関連する、設計および実装の側面の主要コンポーネント。 |
|
テスト結果 |
ドメインテストで実行されたテストの出力。 |
|
再利用可能なテスト成果物 |
テスト成果物には、ドメイン テスト計画、ドメイン テスト ケース、ドメイン テスト ケース シナリオを含む。 |
|
要求仕様 |
特定の製品の要件。 |
|
製品アーキテクチャ |
リファレンスアーキテクチャと同等であるが、これには製品固有のアーキテクチャを含む。 |
|
実行中の アプリケーション |
後でテストできる動作するアプリケーション。 |
|
詳細な設計成果物 |
これらには、各コンポーネントの静的および動的構造をキャプチャするさまざまな種類のモデルを含む。 |
|
試験報告書 |
製品のすべてのテスト結果の文書。 |
|
問題の報告 |
製品のテスト中に発生したすべての問題をリストした文書。 |
|
最終製品 |
完成品の納品。 |
|
ファミリーモデル |
すべてのファミリーメンバーとすべてのサブ製品の重複するコンセプト。 |
|
ファミリーメンバー |
個々の製品のコンセプト。 |
|
コンテキストドキュメント |
範囲を決定するための重要な情報を含む文書。ガイドライン、制約条件、生産戦略を含む。 |
|
ガイドライン |
市場/ビジネス/製品ガイドライン |
|
制約条件 |
市場/ビジネス/製品の制約条件 |
|
製品戦略 |
市場を見据えた製品戦略 |
|
製品ポートフォリオの説明 |
重要な特性を備えた、利用可能なすべての製品を含むポートフォリオ。 |
|
現在および将来の 製品リスト |
現在のすべての製品と将来生産される製品のリスト。 |
|
製品 ロードマップ |
製品ラインのすべての製品の機能を説明し、その機能を各製品の一部である共通の機能と、一部の製品の一部のみである可変機能に分類。 |
表1: コンセプトのリスト
事例
[編集]製品ファミリーエンジニアリングを使用して非常に成功した好例がいくつかある。製品ファミリーエンジニアリングの抽象モデルにより、さまざまな種類の使用が可能になるが、そのほとんどは家庭用電化製品市場に関連している。以下に、ノキアの実体験に基づいた製品ライン エンジニアリングプロセスの適用例を示す。
ノキアはさまざまな種類の製品を製造している。その中には携帯電話製品ファミリーも含まれており、現在では毎年25～30の新製品が含まれている。これらの製品は世界中で販売されているため、さまざまな言語とユーザーインターフェイスをサポートする必要がある。ここでの主な問題は、いくつかの異なるユーザーインターフェイスをサポートする必要があることである。また、新製品は非常に早く次々に成功するため、これを可能な限り効率的に行う必要がある。製品ファミリーエンジニアリングにより、さまざまな製品用のソフトウェアを作成し、多様性を利用してソフトウェアをさまざまな携帯電話ごとにカスタマイズすることが可能になる。
ノキアのケースは、通常のソフトウェア製品ラインと同等である。最初の段階である製品管理では、さまざまな携帯電話シリーズの範囲を定義できる。第2フェーズであるドメイン・エンジニアリングでは、ファミリーおよび個々のタイプの電話機 (6100/8300 シリーズなど) の要件が定義される。このフェーズでは、製品ファミリー全体のベースとして機能するソフトウェア要件が作成される。これにより、ソフトウェアの開発プロセス全体が高速化される。最後の段階である製品エンジニアリングでは、個々のタイプの電話機に重点を置く。前のフェーズの要件は、開発中の電話の種類に応じた個別のソフトウェアを作成するために使用される。
製品ラインの使用により、ノキアは新しい携帯電話モデルの生産を5～10モデルから約30モデルに増やすことができた。[3]
関連項目
[編集]- Automatic programming
- Domain analysis
- Feature model
- Feature-oriented programming
- Multiagent systems product lines
- Systems Engineering
- Version Management
脚注
[編集]- ^ https://escholarship.org/uc/item/5687j6g6 Software construction using components, Retrieved 2021-01-09
- ^ Clements P. & Northrop L.M. (2003). Software Product Lines. Presentation Carnegie Mellon Software Engineering Institute. Retrieved March 26, 2006, from: http://www.sei.cmu.edu/
- ^ Carnegie Mellon Software Engineering Institute (SEI). Software Product Lines. Retrieved February 17, 2006, from: https://web.archive.org/web/20171005173029/http://www.sei.cmu.edu/productlines/
- Jan Bosch, Design and use of software architectures: adopting and evolving a product-line approach, ACM Press/Addison-Wesley Publishing Co., New York, NY, 2000 ISBN 978-0201674941 https://www.amazon.com/Design-Use-Software-Architectures-Bosch/dp/0201674947
- European Software Institute (ESI). Retrieved February 17, 2006, from: https://web.archive.org/web/20070203151901/http://www.esi.es/Families/famResults.html
- Pohl K., Bockle G., & Linden F. van der (2005). Software Product Line Engineering. Berlin, Heidelberg, New York: Springer-Verlag. ISBN 978-3-540-28901-2ISBN 978-3-540-28901-2 https://www.amazon.com/Software-Product-Line-Engineering-Foundations-dp-3540243720/dp/3540243720