Loading article…
製品ファミリエンジニアリング( PFE ) は、製品ラインエンジニアリングとも呼ばれ、ソフトウェアエンジニアリング研究所によって作成された「ドメインエンジニアリング」の考え方に基づいています。この用語は、カリフォルニア大学アーバイン校の1980 年の博士論文[1]で James Neighbors によって造られました。ソフトウェア製品ラインは日常生活で非常に一般的ですが、製品ファミリを正常に確立する前に、広範なプロセスに従う必要があります。このプロセスは、製品ファミリエンジニアリングとして知られています。
製品ファミリ エンジニアリングは、組織の製品プラットフォームの基礎となるアーキテクチャを作成する方法として定義できます。共通性と計画された可変性に基づいたアーキテクチャを提供します。さまざまな製品バリアントは基本製品ファミリから派生できるため、ファミリ内の製品を再利用および差別化する機会が生まれます。製品ファミリ エンジニアリングは、自動車業界で広く使用されている車両プラットフォームと概念的に似ています。
製品ファミリー エンジニアリングは、新製品を作成するための比較的新しいアプローチです。製品コンポーネントを再利用し、コストと時間を削減しながら可変性を適用できるように、新製品をエンジニアリングするプロセスに重点を置いています。製品ファミリー エンジニアリングは、コンポーネントと構造を可能な限り再利用することに重点が置かれています。
いくつかの研究により、製品開発に製品ファミリーエンジニアリングのアプローチを使用すると、いくつかの利点が得られることが証明されています。[2]以下にそのいくつかを挙げます。
- 生産性の向上
- 高品質
- 市場投入までの時間を短縮
- 労働力の必要性が低い
下記のノキアの事例もこれらの利点を実証しています。
全体的なプロセス
製品ファミリ エンジニアリング プロセスは、複数のフェーズで構成されます。主な 3 つのフェーズは次のとおりです。
- フェーズ1:製品管理
- フェーズ2:ドメインエンジニアリング
- フェーズ3:製品エンジニアリング
このプロセスは、より高い抽象レベルでモデル化されています。これには、ソフトウェアだけでなく、あらゆる種類の製品ラインとファミリに適用できるという利点があります。このモデルは、どの製品ファミリにも適用できます。図 1 (下記) は、プロセス全体のモデルを示しています。以下では、プロセスについて詳しく説明します。プロセスの説明には、アクティビティの詳細と、使用されている重要な概念が含まれています。斜体で印刷されたすべての概念は、表 1 で説明されています。
フェーズ1: 製品管理
最初のフェーズは、プロセス全体の開始です。このフェーズでは、特に経済的側面に関して、いくつかの重要な側面が定義されます。このフェーズでは、市場戦略の概要を策定し、製品ファミリーに含めるべきものと含めるべきでないものを 示す範囲を定義します。
ビジネスビジョンを評価する
この最初のアクティビティでは、製品ラインの範囲を定義するのに関連するすべてのコンテキスト情報が収集され、評価されます。明確な市場戦略を定義し、消費者の需要などの外部市場情報を考慮することが重要です。このアクティビティでは、ガイドライン、制約、製品戦略を含むコンテキスト ドキュメントを作成する必要があります。
製品ラインの範囲を定義する
スコープ内の側面を定義するために、スコープ設定手法が適用されます。これは、外部要因が考慮されたプロセスの前のステップに基づいています。出力は、現在の製品と将来の製品のリストと製品ロードマップを含む製品ポートフォリオの説明です。
フェーズ 1 の製品管理は、製品ファミリ エンジニアリング プロセスの一部であるかどうかについては議論の余地があります。これは、製品の側面ではなく管理の側面に重点を置いた個別のビジネス プロセスと見なすことができるからです。ただし、フェーズ 2 では、スコープの大部分がこのフェーズで定義されているため、このフェーズからの重要な入力が必要になります。したがって、この観点から、ドメイン エンジニアリング プロセスのベースとして、製品管理フェーズ (フェーズ 1) をプロセス全体に含めることが重要です。
フェーズ2: ドメインエンジニアリング
ドメイン エンジニアリング フェーズでは、製品ライン全体に対する可変要件と共通要件が収集されます。目標は、再利用可能なプラットフォームを確立することです。このフェーズの出力は、製品ライン内のすべての製品に対する一連の共通要件と可変要件です。
ドメイン要件を分析する
このアクティビティには、概念要件に関してドメインを分析するためのすべてのアクティビティが含まれます。要件は分類され、2 つの新しいアクティビティに分割されます。出力は、ドメイン分析を含むドキュメントです。
図 1 からわかるように、共通要件を定義するプロセスは、可変要件を定義するプロセスと並行して行われます。両方のアクティビティは同時に行われます。
共通要件を定義する
製品ラインの共通要件を引き出し、文書化するためのすべてのアクティビティが含まれており、再利用可能な共通要件を含むドキュメントが作成されます。
可変要件を定義する
製品ラインの可変要件を引き出し、文書化するすべてのアクティビティが含まれ、結果として可変要件を含む文書が作成されます。
デザインドメイン
このプロセス ステップは、製品ラインの リファレンス アーキテクチャを定義するアクティビティで構成されます。これにより、製品ライン内のすべての製品の抽象構造が生成されます。
ドメインを実装する
このステップでは、再利用可能なコンポーネントの詳細な設計とこれらのコンポーネントの実装が作成されます。
テストドメイン
コンポーネントの再利用性を検証および確認します。コンポーネントは仕様に照らしてテストされます。さまざまなユースケースとシナリオですべてのコンポーネントのテストに成功すると、ドメイン エンジニアリング フェーズが完了します。
フェーズ3: 製品エンジニアリング
最終段階では、製品 X が設計されます。この製品 X はドメイン エンジニアリング フェーズの共通性と可変性を使用しているため、製品 X はドメイン エンジニアリング フェーズで確立されたプラットフォームから派生しています。基本的に、前のフェーズのすべての共通要件と類似性に加えて、独自の可変要件が採用されています。ドメイン エンジニアリング フェーズのベースと製品エンジニアリング フェーズの個々の要件を使用して、完全な新しい製品を構築できます。その後、製品が完全にテストされ、承認されると、製品 X を配信できます。
製品要件を定義する
個々の製品の製品要件仕様を開発し、前のフェーズの要件を再利用します。
デザイン製品
製品アーキテクチャを作成するためのすべてのアクティビティ。「設計ドメイン」ステップの参照アーキテクチャを活用し、参照アーキテクチャの必要な部分を選択して構成し、製品固有の適応を組み込みます。
製品を構築する
このプロセスでは、再利用可能なコンポーネントの選択と構成を使用して製品が構築されます。
テスト製品
このステップでは、製品が仕様に照らして検証および検証されます。テスト レポートには、実行されたすべてのテストに関する情報が記載されており、製品に起こり得るエラーの概要がわかります。次のステップで製品が受け入れられない場合、プロセスは「製品の構築」に戻ります。図 1 では、これは「[不満足]」として示されています。
製品の提供とサポート
最後のステップは、最終製品の承認です。製品が正常にテストされ、完成品として承認された場合は、納品できます。製品が仕様を満たしていない場合は、再構築して再度テストする必要があります。
次の図は、上で説明した製品ファミリ エンジニアリングの全体的なプロセスを示しています。これは、さまざまなステップに関連付けられたすべての概念を含む完全なプロセスの概要です。
プロセスデータ図
左側には上から下までのプロセス全体が描かれています。左側のすべてのアクティビティは、点線で右側の概念にリンクされています。各概念には番号が付けられており、他の概念との関連性を反映しています。
概念のリスト
以下に概念のリストを説明します。ほとんどの概念定義は Pohl、Bockle、Linden (2005) から抽出されており、いくつかの新しい定義も追加されています。
表1: 概念のリスト
例
製品ファミリ エンジニアリングの使用例には、非常に成功した例がいくつかあります。製品ファミリ エンジニアリングの抽象モデルでは、さまざまな用途が考えられますが、そのほとんどは消費者向け電子機器市場に関連したものです。以下に、Nokia の実際の経験に基づいた、製品ライン エンジニアリング プロセスの適用例を示します。
Nokia はさまざまな種類の製品を製造しています。その中には、携帯電話製品ファミリーがあり、現在、毎年 25 ～ 30 の新製品が発表されています。これらの製品は世界中で販売されているため、さまざまな言語やユーザー インターフェイスをサポートする必要があります。ここでの主な問題は、複数の異なるユーザー インターフェイスをサポートする必要があることです。新製品が次々と登場するため、これをできるだけ効率的に行う必要があります。製品ファミリー エンジニアリングにより、さまざまな製品用のソフトウェアを作成し、多様性を利用して各携帯電話に合わせてソフトウェアをカスタマイズできます。
Nokia のケースは、通常のソフトウェア製品ラインに似ています。最初のフェーズである製品管理では、さまざまな携帯電話シリーズの範囲を定義できます。2 番目のフェーズであるドメイン エンジニアリングでは、ファミリと個々の電話の種類 (6100/8300 シリーズなど) の要件が定義されます。このフェーズでは、製品ファミリ全体のベースとなるソフトウェア要件が作成されます。これにより、ソフトウェアの開発プロセス全体が迅速化されます。最後のフェーズである製品エンジニアリングでは、個々の電話の種類に重点が置かれます。前のフェーズの要件を使用して、開発中の電話の種類ごとに個別のソフトウェアが作成されます。
製品ラインの使用により、ノキアは新しい携帯電話モデルの生産を5～10モデルから約30モデルに増やす機会を得ました。[3]
参照
参考文献
- ^ https://escholarship.org/uc/item/5687j6g6 コンポーネントを使用したソフトウェア構築、2021-01-09 取得
- ^ Clements P. & Northrop LM (2003)。ソフトウェア製品ライン。プレゼンテーション、カーネギーメロンソフトウェアエンジニアリング研究所。2006 年 3 月 26 日に http://www.sei.cmu.edu/ から取得。
- ^ カーネギーメロンソフトウェアエンジニアリング研究所 (SEI)。ソフトウェア製品ライン。2006 年 2 月 17 日に https://web.archive.org/web/20171005173029/http://www.sei.cmu.edu/productlines/ から取得。
- Jan Bosch著「ソフトウェア アーキテクチャの設計と使用: 製品ライン アプローチの採用と進化」、ACM Press/Addison-Wesley Publishing Co.、ニューヨーク、NY、2000 ISBN 978-0201674941 https://www.amazon.com/Design-Use-Software-Architectures-Bosch/dp/0201674947
- 欧州ソフトウェア研究所 (ESI)。2006 年 2 月 17 日に https://web.archive.org/web/20070203151901/http://www.esi.es/Families/famResults.html から取得。
- ポール K.、ボックル G.、リンデン F. ファン ダー (2005)。ソフトウェア製品ラインエンジニアリング。ベルリン、ハイデルベルク、ニューヨーク: Springer-Verlag。ISBN 978-3-540-28901-2 https://www.amazon.com/Software-Product-Line-Engineering-Foundations-dp-3540243720/dp/3540243720
外部リンク
- カーネギーメロンソフトウェアエンジニアリング研究所 (SEI) ソフトウェア製品ライン (アーカイブコピー)
- 欧州ソフトウェア研究所 (ESI)
- ソフトウェア製品ライン
- ソフトウェア製品ラインエンジニアリングコース、B. Tekinerdogan、ビルケント大学
- トリーア大学、コンピュータサイエンス