Loading article…
国防総省アーキテクチャ フレームワーク( DoDAF ) は、米国国防総省(DoD)のアーキテクチャ フレームワークであり、さまざまなビューで編成された視点を通じて、特定の利害関係者の懸念事項に対する視覚化インフラストラクチャを提供します。これらのビューは、表形式、構造、動作、オントロジー、画像、時間、グラフィカル、確率、または代替概念的手段を通じて、アーキテクチャ記述の広範な範囲と複雑さを視覚化し、理解し、取り込むための成果物です。現在のリリースは DoDAF 2.02 です。
このアーキテクチャフレームワークは、複雑な統合と相互運用性の課題を抱える大規模システムに特に適しており、「運用ビュー」を採用している点が明らかにユニークです。これらのビューは、ドメイン内の特定の利害関係者と、システムが動作する他のドメインとの相互作用を対象とした概要と詳細を提供します。[3]
概要
DoDAF は、組織、共同、多国籍の境界を越えてアーキテクチャを理解、比較、統合するための共通基準を確保するアーキテクチャ記述を開発および表現するための基礎フレームワークを提供します。これは、データ要素の定義、ルール、関係、およびシステム、統合、または連合アーキテクチャの一貫した開発のためのベースライン製品セットを確立します。これらのアーキテクチャ記述には、システム ファミリ (FoS)、システム オブ システム(SoS)、および非戦闘環境での相互運用と対話のためのネット中心の機能が含まれる場合があります。[1]
国防総省のコンポーネントは、省内でのアーキテクチャの開発において、可能な限り DoDAF に準拠することが求められています。準拠することで、情報、アーキテクチャ成果物、モデル、および視点の再利用が共通の理解で共有されることが保証されます。米国国防総省のすべての主要な兵器および情報技術システムの取得では、DoDAF で規定されたビューを使用してエンタープライズ アーキテクチャ (EA) を開発し、文書化する必要があります。DoDAF は明らかに軍事システムを対象としていますが、世界中の民間、公共、およびボランティア部門に広く適用でき、多数のシステムアーキテクチャ フレームワークの 1 つとなっています。[4] [5]
- DoDAFの目的は、国防総省の6つのコアプロセスで使用できる概念とモデルを定義することです。[6]
- 共同能力統合開発（JCIDS）
- 計画、プログラミング、予算編成、実行 (PPBE)
- 防衛獲得システム (DAS)
- システムエンジニアリング（SE）
- 作戦計画 (OPLAN)
- 能力ポートフォリオ管理 (CPM)
- さらに、DoDAF 2.0の具体的な目標は以下のとおりです。[6]
- 目的に応じたアーキテクチャコンテンツのガイドラインを確立する - 「目的に適合」
- 厳密なデータ モデルである DoDAF メタ モデル (DM2) によってアーキテクチャの有用性と有効性が向上し、アーキテクチャをより正確に統合、分析、評価できるようになります。
歴史
DoDAF 開発の最初のバージョンは、1990 年代にC4ISRアーキテクチャ フレームワークという名前で開発されました。同じ時期に、 1986 年に開始された参照モデルTAFIMがさらに開発されました。1996 年 6 月 7 日にリリースされた最初の C4ISR アーキテクチャ フレームワーク v1.0 は、クリンガー コーエン法の可決に応じて作成されました。これは、C4ISR 機能が相互運用可能であり、戦闘員のニーズを満たすことを保証するためのより優れた手段とプロセスを定義および開発するために国防総省全体で取り組むという 1995 年の国防副長官の指令に対応したものでした。継続的な開発努力の結果、1997 年 12 月に 2 番目のバージョンである C4ISR アーキテクチャ フレームワーク v2.0 が完成しました。[1]
2003 年 8 月、DoDAF v1.0 がリリースされました。これは C4ISR フレームワーク v2.0 を再構成し、2 巻とデスク ブックでガイダンス、製品の説明、補足情報を提供するものです。これにより、アーキテクチャの原則と実践の適用範囲が、C4ISR コミュニティだけでなく、すべてのミッション エリアに広がりました。このドキュメントでは、使用法、統合アーキテクチャ、DoD と連邦政府のポリシー、アーキテクチャの価値、アーキテクチャの尺度、DoD の意思決定支援プロセス、開発手法、分析手法、およびCADM v1.01 について取り上げ、アーキテクチャ製品を構成するアーキテクチャ データ要素に重点を置くことで、リポジトリ ベースのアプローチに移行しました。[1] 2004 年 2 月、バージョン 1.0 のドキュメントが、巻「I: 定義とガイドライン」、「II: 製品の説明」、および「デスク ブック」とともにリリースされました。2007 年 4 月には、バージョン 1.5 が「定義とガイドライン」、「製品の説明」、および「アーキテクチャ データの説明」のドキュメントとともにリリースされました。この時期には、その後さまざまなアプローチに置き換えられた概念と用語がさらに発展しました。たとえば、ミッション ニーズ ステートメント(MNS) は、ミッションの欠陥を解決したり運用能力を強化したりするために、ソリューションの組み合わせ ( DOTMLPF ) によって満たすべきプログラムの機能ニーズを特定する米国国防総省の文書です。このタイプの文書は、CJCSI 3170.01E 以降、初期機能文書と呼ばれる機能ニーズの説明に置き換えられました。CJCSI 3170.01 および 6212.01 は、CJCSI 5123.01 シリーズに置き換えられました。
この用語は、CJCSI 3170.01B (2001 年 4 月)、6212.01D (2005 年 4 月)、および暫定防衛調達ガイドブック (2004 年 10 月) で基本的なステップとして導入されました。
2009年5月28日、DoDAF v2.0が国防総省によって承認されました。[7]現在のバージョンはDoDAF 2.02です。 [8] DoDAF V2.0は一般のウェブサイトで公開されています。[9]
DoDAF に基づくその他の派生フレームワークには、NATO アーキテクチャ フレームワーク(NAF) や国防省アーキテクチャ フレームワークなどがあります。他の EA アプローチ、たとえばThe Open Group Architecture Framework (TOGAF) と同様に、DoDAF は作業成果物を保持するための共有リポジトリを中心に構成されています。リポジトリは、共通データベース スキーマCore Architecture Data Model 2.0 および DoD Architecture Registry System (DARS) によって定義されます。DoDAF の重要な機能は相互運用性であり、これは情報システム相互運用性のレベル (LISI) と呼ばれる一連のレベルとして構成されています。開発中のシステムは、内部のデータ ニーズだけでなく、システムが設定される運用フレームワークのニーズも満たす必要があります。
能力と使命
ミッション/行動方針、スレッド、アクティビティ、アーキテクチャと結びついた機能の重点の描写については、図を参照してください。
国防総省は、システム/サービスを作成する理由である機能の提供に重点を置くようになりました。機能モデルは、機能の分類と機能の進化について説明します。機能スレッドは、特定の機能にリンクされている特定のアクティビティ、ルール、およびシステムに相当します。
メタモデル データ グループによって定義された機能の概念により、次のような質問に答えることができます。
- 特定の機能または能力は、全体的なミッション/ビジョンをどのようにサポートしますか?
- 特定の機能または機能セットによってどのような成果が達成されると予想されますか?
- 機能をサポートするにはどのようなサービスが必要ですか?
- 機能または機能セットの機能範囲と組織の範囲は何ですか?
- ポートフォリオの一部として現在管理している機能セットは何ですか?
[10]
ミッションまたは行動方針は、作戦コンセプト (CONOPS) によって記述され、機能別に編成されます。
- 機能はスレッドによって記述されます。
- スレッドは、シリアルまたは並列で実行されるアクティビティによって記述されます。
- アクティビティはミッション エリアにグループ化されます。アクティビティはアーキテクチャの操作を定義します。
- アーキテクチャは、ミッション領域別に編成されます。アーキテクチャは、ミッションまたは行動方針に必要な機能の適切なリソースを提供します。
バージョン 1.5 のビュー
DoDAF V1.5 は、グラフィック、表、またはテキストの手段を通じてアーキテクチャ記述の広範な範囲と複雑さを視覚化し、理解し、同化するためのメカニズムとして機能する一連の製品、ビュー モデルを定義します。これらの製品は、次の 4 つのビューに分類されます。
- 全画面表示（AV）
- 運用ビュー(OV)
- システムビュー（SV）
- 技術基準ビュー（テレビ）
各ビューは、以下に説明するように、アーキテクチャの特定の観点を表します。通常、各システム開発では、完全な DoDAF ビューセットのサブセットのみが作成されます。図は、運用ビュー、システムとサービスのビュー、技術標準ビューをリンクする情報を表しています。共通のアーキテクチャ データ要素によって駆動される 3 つのビューとそれらの相互関係は、相互運用性やパフォーマンスなどの指標を導き出すための基礎となり、これらの指標の値が運用ミッションとタスクの有効性に与える影響を測定するための基礎となります。[1]
すべて表示
すべてのビュー (AV) 製品は、アーキテクチャ全体の包括的な説明を提供し、アーキテクチャの範囲とコンテキストを定義します。DoDAF V1.5 AV 製品は次のように定義されます。
- AV-1 の概要と概要情報
- 範囲、目的、対象ユーザー、描写される環境、分析結果（該当する場合）
- AV-2 統合辞書
- すべての製品で使用されるすべての用語の定義。
運用ビュー
運用ビュー(OV) 製品は、DoD ミッションの達成に必要なタスクとアクティビティ、運用要素、および情報交換の説明を提供します。OV は、運用ノードと要素、割り当てられたタスクとアクティビティ、およびノード間の情報フローをテキストとグラフィックで表現します。交換される情報の種類、交換の頻度、これらの交換でサポートされるタスクとアクティビティ、および交換の性質を定義します。DoDAF V1.5 OV 製品は次のように定義されます。
- OV-1 高レベル運用コンセプトグラフィック
- 運用コンセプト（高レベルの組織、ミッション、地理的構成、接続性など）の高レベルのグラフィックとテキストによる説明。
- OV-2 運用ノード接続の説明
- 運用ノード、各ノードで実行されるアクティビティ、およびノード間の接続性と情報フロー。
- OV-3 運用情報交換マトリックス
- ノード間で交換される情報と、メディア、品質、量、必要な相互運用性のレベルなど、その交換に関連する属性。
- OV-4 組織関係図
- 組織間の指揮、統制、調整、その他の関係。
- OV-5 運用活動モデル
- アクティビティ、アクティビティ間の関係、入力と出力。さらに、オーバーレイにはコスト、実行ノード、その他の関連情報を表示できます。
- OV-6a 運用ルールモデル
- 運用を制約するビジネス ルールを識別する運用アクティビティのシーケンスとタイミングを記述するために使用される 3 つの製品のうちの 1 つ。
- OV-6b 運用状態遷移の説明
- イベントに対するビジネス プロセスの応答を識別する運用アクティビティのシーケンスとタイミングを記述するために使用される 3 つの製品のうちの 1 つ。
- OV-6c 運用イベント トレースの説明
- シナリオまたは重要な一連のイベントにおけるアクションをトレースする運用アクティビティのシーケンスとタイミングを記述するために使用される 3 つの製品のうちの 1 つ。
- OV-7 論理データモデル
- 運用ビューのデータ要件と構造的ビジネス プロセス ルールのドキュメント。(DoDAF V1.5 の場合。これは DoDAF V2.0 の DIV-2 に対応します。)
システムとサービスの視点
システムおよびサービス ビュー (SV) は、DoD 機能を提供またはサポートするシステム、サービス、および相互接続を説明するグラフィカルおよびテキスト プロダクトのセットです。SV プロダクトは、特定の物理的 (地理的) 場所を持つ特定の物理システムに焦点を当てています。SV から OV までのアーキテクチャ データ要素間の関係は、組織とその運用をサポートするためにシステムが調達され、配備されるときに例示できます。DoDAF V1.5 SV プロダクトは次のとおりです。
- SV-1 システム/サービス インターフェースの説明
- OV-2 の運用ノードによって表される組織/人間の役割をサポートするために、システム ノードとこれらのノードに常駐するシステムを示します。SV-1 は、システムとシステム ノード間のインターフェイスも識別します。
- SV-2 システム/サービス通信の説明
- 通信システム、通信リンク、および通信ネットワークに関する関連情報を示します。SV-2 は、システムをサポートする通信メディアの種類を文書化し、SV-1 で説明されているようにそのインターフェイスを実装します。したがって、SV-2 は、OV-2 で表されているニードラインの側面を自動化する SV-1 インターフェイスの通信の詳細を示します。
- SV-3 システム-システム、サービス-システム、サービス-サービス マトリックス
- SV-1 で説明されているアーキテクチャのインターフェース特性の詳細をマトリックス形式で提供します。
- SV-4a/SV-4b システム/サービス機能の説明
- SV-4a は、システム機能階層とシステム機能、およびそれらの間のシステム データ フローを文書化します。DoDAF v1.0 の SV-4 は、DoDAF v1.5 では「SV-4a」として指定されています。OV-5 またはビジネス プロセス階層と SV-4a のシステム機能階層の間には相関関係がありますが、1 対 1 のマッピングである必要はありません。そのため、そのマッピングを提供する運用アクティビティからシステム機能へのトレーサビリティ マトリックス (SV-5a) が必要になります。
- SV-5a、SV-5b、SV-5c システム機能に対する運用アクティビティ、システムおよびサービスに対する運用アクティビティのトレーサビリティ マトリックス
- SV-5a および SV-5b の運用アクティビティは、アーキテクチャに適用可能な運用アクティビティのセットと、そのアーキテクチャに適用可能なシステム機能のセットとの関係の仕様です。DoDAF v1.0 からの SV-5 および SV-5 の拡張は、DoDAF v1.5 ではそれぞれ「SV-5a」および「SV-5b」として指定されています。
- SV-6 システム/サービス データ交換マトリックス
- システム間で交換されるシステム データの特性を指定します。この製品は、システムに実装されている自動化された情報交換 (OV-3 から) に重点を置いています。口頭の指示などの非自動化された情報交換は、OV 製品でのみキャプチャされます。
- SV-7 システム/サービス パフォーマンス パラメータ マトリックス
- システムおよびシステム ハードウェア/ソフトウェア項目、それらのインターフェイス (インターフェイスによって伝送されるシステム データ、およびインターフェイスを実装する通信リンクの詳細)、およびそれらの機能の定量的特性を指定します。各システム、インターフェイス、またはシステム機能の現在のパフォーマンス パラメータ、および将来の特定の時点での予想されるまたは必要なパフォーマンス パラメータを指定します。パフォーマンス パラメータには、要件を開発して仕様を定義できるシステムのすべての技術的なパフォーマンス特性が含まれます。アーキテクチャ定義の初期段階では、パフォーマンス パラメータの完全なセットがわからない可能性があるため、この製品は、システムの仕様、設計、開発、テスト、さらには展開および運用のライフサイクル フェーズ全体を通じて更新されることが予想されます。
- SV-8 システム/サービスの進化の説明
- システムまたはシステムが組み込まれているアーキテクチャが長期間にわたってどのように進化するかを説明する進化計画を取得します。一般に、タイムライン マイルストーンは進化のタイムラインを正しく理解するために重要です。
- SV-9 システム/サービス技術予測
- 標準的な予測方法を使用して対象とされた、基盤となる現在の技術と予想されるサポート技術を定義します。予想されるサポート技術とは、現在の技術の状態と予想される改善を考慮して合理的に予測できる技術です。新しい技術は、SV-8 マイルストーンで使用される期間と相関関係がある特定の期間に結び付けられる必要があります。
- SV-10a システム/サービス ルール モデル
- 指定された条件下でアーキテクチャまたはそのシステムが動作するルールを記述します。
- SV-10b システム/サービス状態遷移の説明
- システム (またはシステム機能) の状態を変更することで、さまざまなイベントに対する応答をグラフィカルに記述する方法。この図は基本的に、アーキテクチャ内のシステムが現在の状態に応じて応答する (新しい状態に移行するアクションを実行する) イベントのセットを表します。各遷移は、イベントとアクションを指定します。
- SV-10c システム/サービス イベント トレースの説明
- 特定のシナリオの結果として、参加システム (外部および内部)、システム機能、または人間の役割の間で交換されるシステム データ要素を時系列で調べます。各イベント トレース図には、特定のシナリオまたは状況を定義する説明が付属している必要があります。システムおよびサービス ビューの SV-10c は、運用ビューで説明されている重要なイベント シーケンスのシステム固有の側面または改良を反映している場合があります。
- SV-11 物理スキーマ
- フレームワーク内で実際のシステム設計に最も近いアーキテクチャ製品の 1 つです。この製品は、アーキテクチャ内のシステムによって使用されるさまざまな種類のシステム データの構造を定義します。(DoDAF V1.5 の場合。これは、DoDAF V2.0 の DIV-3 に相当します。)
技術基準の見解
技術標準ビュー (TV) 製品は、アーキテクチャを管理する技術標準、実装規則、ビジネス ルール、および基準を定義します。DoDAF V1.5 TV 製品は次のとおりです。
- StdV-1 技術標準プロファイル- 特定のアーキテクチャに適用される標準の抽出。(DoDAF V1.5 の場合。DoDAF V2.0 では StdV-1 に名前が変更されました。)
- StdV-2 技術標準予測- 適切な期間内に特定のアーキテクチャに適用されることが予想される新しい標準の説明。(DoDAF V1.5 で。DoDAF V2.0 で StdV-2 に名前が変更されました。)
バージョン2.0の視点
DoDAF V2.0 では、アーキテクチャ ビューポイントは、理解しやすいように整理されたデータで構成されています。ISO 標準に合わせるために、適切な箇所で用語がビューからビューポイントに変更されました (たとえば、運用ビューは運用ビューポイントになりました)。
- すべての視点（AV）
- すべての視点に関連するアーキテクチャ コンテキストの包括的な側面について説明します。
- 能力観点（CV）
- DoDAF V2.0 の新機能。機能要件、配信タイミング、展開された機能を明確に示します。
- データと情報の視点 (DIV)
- DoDAF V2.0 の新機能。機能と運用要件、システム エンジニアリング プロセス、システムとサービスに関するアーキテクチャ コンテンツ内のデータ関係と調整構造を明確に示します。
- 運用上の視点（OV）
- 機能をサポートする運用シナリオ、アクティビティ、および要件が含まれます。
- プロジェクト視点（PV）
- DoDAF V2.0 の新機能。運用要件と機能要件、および実装されているさまざまなプロジェクトとの関係について説明します。プロジェクト ビューポイントでは、防衛調達システム プロセス内の機能要件と運用要件、システム エンジニアリング プロセス、システム設計、およびサービス設計間の依存関係も詳しく説明します。
- サービス視点 (SvcV)
- DoDAF V2.0 の新機能。実行者、アクティビティ、サービス、およびそれらの交換を明確にし、運用機能と機能機能を提供またはサポートするソリューションの設計を示します。
- 標準の観点 (StdV)
- 技術標準ビューから名前が変更されました。機能と運用の要件、システム エンジニアリング プロセス、システムとサービスに適用される、運用、ビジネス、技術、および業界のポリシー、標準、ガイダンス、制約、および予測を明確に示します。
- システムの視点 (SV)
- レガシー サポート向けに、システム、その構成、相互接続性、および運用機能と機能を提供またはサポートするコンテキストを明確にするソリューションの設計を明確にします。DoDAF V2.0 ではシステムがDoDAF V1.5 から変更されたことに注意してください。システムは、単なるコンピューター ハードウェアとコンピューター ソフトウェアではありません。システムは現在、アクティビティを実行し (実行者のサブタイプであるため)、相互作用または相互依存しているコンポーネント (マシン、人間) の集合体という一般的な意味で定義されています。これは、相互作用または相互依存する要素を持つ小さな機器から、システム ファミリ (FoS) やシステム オブ システム (SoS) まで、あらゆるものになる可能性があります。システムは資材 (機器、航空機、船舶など) と人員タイプで構成されていることに注意してください。
DoDAF V1.0 および DoDAF V1.5 のアーキテクチャは、引き続き使用できます。適切な場合 (通常はポリシーまたは意思決定者によって指示されます)、DoDAF V1.0 および V1.5 アーキテクチャは、アーキテクチャを更新する必要があります。DoDAF V2.0 以前のアーキテクチャを DoDAF V2.0 アーキテクチャと比較する場合、新しいアーキテクチャの概念の違い (ノードなど) を定義または説明する必要があります。DoDAF V1.5 製品に関しては、それらは DoDAF V2.0 モデルの一部に変換されています。ほとんどの場合、DoDAF V2.0 メタモデルは、1 つの注目すべき例外であるノードを除き、DoDAF V1.5 データ概念をサポートします。ノードは、より具体的な概念で表現される複雑で論理的な概念です。
すべての視点（AV）
- AV-1 の概要と概要情報
- プロジェクトのビジョン、目標、目的、計画、活動、イベント、条件、対策、効果 (成果)、および生成されたオブジェクトについて説明します。
- AV-2 統合辞書
- 建築データリポジトリには、建築全体で使用されるすべての用語の定義が含まれています。
能力観点（CV）
- CV-1ビジョン
- 変革の取り組みに関する全体的なビジョンに関連する企業の懸念事項に対処し、一連の機能の戦略的コンテキストを定義します。CV-1 の目的は、アーキテクチャの説明で説明されている機能の戦略的コンテキストを提供することです。
- CV-2 能力分類
- 機能の分類をキャプチャします。モデルは機能の階層を表します。これらの機能はタイムラインのコンテキストで提示される場合があります。CV-2 は、1 つ以上のアーキテクチャ全体で参照されるすべての機能を指定します。
- CV-3 能力段階
- 異なる時点または特定の期間における能力の計画的な達成。CV-3 は、実行者と場所のソリューションに関係なく、活動、条件、望ましい効果、遵守するルール、リソースの消費と生産、および対策の観点から能力の段階を示します。
- CV-4 機能依存関係
- 計画された機能と機能の論理グループの定義間の依存関係。
- CV-5 能力から組織開発へのマッピング
- 機能要件の達成は、特定の機能フェーズの計画された機能の展開と相互接続を示します。CV-5 は、実行者と場所、および関連する概念の観点から、フェーズの計画されたソリューションを示します。
- CV-6 能力と運用活動のマッピング
- 必要な機能とそれらの機能がサポートする運用アクティビティ間のマッピング。
- CV-7 能力とサービスのマッピング
- 機能と、それらの機能によって有効になるサービス間のマッピング。
データと情報の視点 (DIV)
- DIV-1 概念データモデル
- 必要な高レベルのデータ概念とそれらの関係。
- DIV-2 論理データモデル
- データ要件と構造的ビジネス プロセス (アクティビティ) ルールのドキュメント。DoDAF V1.5 では、これは OV-7 でした。
- DIV-3 物理データモデル
- 論理データ モデル エンティティの物理実装形式 (メッセージ形式、ファイル構造、物理スキーマなど)。DoDAF V1.5 では、これは SV-11 でした。
注:これら 3 つの DIV データ モデルの関係、および概念、論理、物理データ モデルの比較については、 「論理データ モデル」を参照してください。
運用上の視点（OV）
- OV-1 高レベル運用コンセプトグラフィック
- 運用コンセプトの高レベルのグラフィック/テキストによる説明。
- OV-2 運用リソースフローの説明
- 運用アクティビティ間で交換されるリソース フローの説明。
- OV-3 運用リソースフローマトリックス
- 交換されたリソースと交換の関連属性の説明。
- OV-4 組織関係図
- 組織のコンテキスト、役割、または組織間のその他の関係。
- OV-5a 運用活動分解ツリー
- 階層構造で編成された機能とアクティビティ（運用アクティビティ）。
- OV-5b 運用活動モデル
- 能力と活動（運用活動）のコンテキスト、および活動、入力、出力間の関係。追加データには、コスト、実行者、その他の関連情報が表示されます。
- OV-6a 運用ルールモデル
- アクティビティ (運用アクティビティ) を記述するために使用される 3 つのモデルの 1 つ。運用を制限するビジネス ルールを識別します。
- OV-6b 状態遷移の説明
- 運用アクティビティ (アクティビティ) を記述するために使用される 3 つのモデルのうちの 1 つ。イベント (通常は非常に短いアクティビティ) に対するビジネス プロセス (アクティビティ) の応答を識別します。
- OV-6c イベントトレースの説明
- アクティビティ (運用アクティビティ) を説明するために使用される 3 つのモデルの 1 つ。シナリオまたは一連のイベント内のアクションをトレースします。
プロジェクト視点（PV）
- PV-1 プロジェクトポートフォリオ関係
- 組織とプロジェクト間の依存関係と、プロジェクト ポートフォリオを管理するために必要な組織構造について説明します。
- PV-2 プロジェクトのタイムライン
- 主要なマイルストーンと相互依存関係を含む、プログラムまたはプロジェクトのタイムラインの観点。
- PV-3 プロジェクトと能力のマッピング
- 特定のプロジェクトとプログラム要素が機能の達成にどのように役立つかを示すために、プログラムとプロジェクトを機能にマッピングします。
サービス視点 (SvcV)
- SvcV-1 サービスコンテキストの説明
- サービス、サービス項目、およびそれらの相互接続の識別。
- SvcV-2 サービス リソース フローの説明
- サービス間で交換されるリソース フローの説明。
- SvcV-3a システム サービス マトリックス
- 特定のアーキテクチャ記述内のシステムとサービス間の関係。
- SvcV-3b サービス - サービス マトリックス
- 特定のアーキテクチャ記述におけるサービス間の関係。関心のある関係 (例: サービス タイプのインターフェイス、計画されているインターフェイスと既存のインターフェイス) を表示するように設計できます。
- SvcV-4 サービス機能の説明
- サービスによって実行される機能と、サービス機能 (アクティビティ) 間のサービス データが流れます。
- SvcV-5 運用アクティビティからサービスへのトレーサビリティ マトリックス
- サービス (アクティビティ) を運用アクティビティ (アクティビティ) にマッピングします。
- SvcV-6 サービス リソース フロー マトリックス
- サービス間で交換されるサービス リソース フロー要素とその交換の属性の詳細を提供します。
- SvcV-7 サービス対策マトリックス
- 適切な期間におけるサービス モデル要素の測定基準 (メトリック)。
- SvcV-8 サービス進化の説明
- 一連のサービスをより効率的なスイートに移行したり、現在のサービスを将来の実装に進化させたりするための計画された段階的なステップ。
- SvcV-9 サービス技術とスキルの予測
- 特定の期間内に利用可能になると予想され、将来のサービス開発に影響を与える新しいテクノロジー、ソフトウェア/ハードウェア製品、およびスキル。
- SvcV-10a サービスルールモデル
- サービス機能を説明するために使用される 3 つのモデルのうちの 1 つ。システム設計または実装の何らかの側面により、システム機能に課せられる制約を識別します。
- SvcV-10b サービス状態遷移の説明
- サービス機能を説明するために使用される 3 つのモデルの 1 つ。イベントに対するサービスの応答を識別します。
- SvcV-10c サービス イベント トレースの説明
- サービス機能を説明するために使用される 3 つのモデルのうちの 1 つ。運用の観点で説明されている重要なイベント シーケンスのサービス固有の改良を識別します。
標準の観点 (StdV)
- StdV-1 標準プロファイル
- ソリューション要素に適用される標準のリスト。DoDAF V1.5 では、これは TV-1 でした。
- StdV-2 基準予測
- 一定の時間枠内での新しい標準と現在のソリューション要素への潜在的な影響の説明。DoDAF V1.5 では、これは TV-2 でした。
システムの視点 (SV)
- SV-1 システム インターフェースの説明
- システム、システム項目、およびそれらの相互接続の識別。
- SV-2 システム リソース フローの説明
- システム間で交換されるリソース フローの説明。
- SV-3 システム - システム マトリックス
- 特定のアーキテクチャ記述におけるシステム間の関係。関心のある関係 (システム タイプのインターフェイス、計画されているインターフェイスと既存のインターフェイスなど) を表示するように設計できます。
- SV-4 システム機能の説明
- システムによって実行される機能 (アクティビティ) と、システム機能 (アクティビティ) 間のシステム データ フロー。
- SV-5a 運用アクティビティからシステム機能へのトレーサビリティ マトリックス
- システム機能 (アクティビティ) を運用アクティビティ (アクティビティ) にマッピングします。
- SV-5b 運用活動からシステムへのトレーサビリティ マトリックス
- システムを機能または運用アクティビティ (アクティビティ) にマッピングします。
- SV-6 システム リソース フロー マトリックス
- システム間で交換されるシステム リソース フロー要素とその交換の属性の詳細を提供します。
- SV-7 システム対策マトリックス
- 適切な期間におけるシステム モデル要素の測定基準 (メトリック)。
- SV-8 システムの進化の説明
- システム スイートをより効率的なスイートに移行したり、現在のシステムを将来の実装に進化させたりするための計画された段階的なステップ。
- SV-9 システム技術とスキル予測
- 特定の期間内に利用可能になると予想され、将来のシステム開発に影響を与える新しいテクノロジー、ソフトウェア/ハードウェア製品、およびスキル。
- SV-10a システムルールモデル
- システム機能を説明するために使用される 3 つのモデルのうちの 1 つ。システム設計または実装の何らかの側面によりシステム機能に課せられる制約を識別します。
- SV-10b システムの状態遷移の説明
- システム機能を説明するために使用される 3 つのモデルの 1 つ。イベントに対するシステムの応答を識別します。
- SV-10c システム イベント トレースの説明
- システム機能を説明するために使用される 3 つのモデルのうちの 1 つ。運用の観点で説明されている重要なイベント シーケンスのシステム固有の改良を識別します。
DoDAFを使用した統合アーキテクチャの作成
DODAF 2.0 アーキテクト ガイド[14]は、統合アーキテクチャの DOD 命令 4630.8 の定義を次のように繰り返しています。「複数のビューから構成されるアーキテクチャで、統合を容易にし、機能間および統合アーキテクチャ間の相互運用性を促進します。アーキテクチャ開発の目的で、統合という用語は、複数のアーキテクチャ モデルで必要なデータがそれらのモデル間で共通に定義され、理解されていることを意味します。統合アーキテクチャは、機能、コンポーネント、ソリューション、およびエンタープライズ (DoD エンタープライズ アーキテクチャ (EA) がアーキテクチャの連合であるという文脈) のすべてのレベルのアーキテクチャのプロパティまたは設計原則です。簡単に言えば、統合は、アーキテクチャ製品間で共通する項目の接続に見られます。1 つのアーキテクチャ製品に表示される項目 (使用されるサイト、インターフェイスされるシステム、提供されるサービスなど) は、関連するアーキテクチャ製品ビューに表示される番号、名前、および意味が同じである必要があります。」
DoDAF を使用して統合アーキテクチャを作成し、必要な製品を決定するには、さまざまなアプローチがあります。アプローチは、要件と期待される結果、つまり、結果として得られるアーキテクチャの用途によって異なります。1 つの例として、DoDAF v1.0 では、次の製品が「OV、SV、および TV の定義を満たすために必要な最小限の製品セット」としてリストされています。1 つの注意点: DoDAF では OV-1 成果物がコア製品としてリストされていませんが、その開発が強く推奨されています。以下にリストされている成果物の順序は、成果物を開発する推奨順序を示しています。ビュー生成の実際の順序と、それらの潜在的なカスタマイズは、アプリケーション ドメインと作業の特定のニーズによって決まります。
- AV-1: 概要と要約情報
- AV-2 : 統合辞書
- OV-1: 高レベル運用コンセプトグラフィック
- OV-5: 運用活動モデル
- OV-2: 運用ノードの接続性の説明
- OV-3: 運用情報交換マトリックス
- SV-1 : システムインターフェースの説明
- TV-1 : 技術標準プロファイル
DoDAF に関する懸念の 1 つは、これらの製品が、特定の対象システムに対する実際の利害関係者の懸念をどの程度満たしているかということです。DoDAF 製品、または少なくとも 3 つのビューは、ANSI /IEEE 1471-2000またはISO/IEC 42010の 視点として見ることができます。ただし、ANSI/IEEE 1471-2000 または ISO/IEC 42010 に対応するアーキテクチャ記述を構築するには、選択した各 DoDAF 製品にマッピングされる利害関係者とその懸念を明確に特定する必要があります。そうしないと、顧客のいない製品が製造されるリスクがあります。
図「DoDAF V1.5 製品マトリックス」は、国防総省統合参謀本部議長命令 (CJCSI) 6212.01E が、Net-Ready 主要パフォーマンス パラメーター (NR-KPP) のコンテキストで、各タイプの分析に必要な DoDAF V1.5 製品をどのように指定しているかを示しています。
- 初期能力文書 (ICD)。運用ユーザーが実行した代替案の初期分析、および必要に応じて代替案の独立した分析から導き出された特定の能力ギャップに対する物質的ソリューションの必要性を文書化します。機能領域、関連する軍事作戦の範囲、望ましい効果、および時間の観点から能力ギャップを定義します。
- 能力開発文書 (CDD)。通常は進化的取得戦略を使用して、提案されたプログラムを開発するために必要な情報を収集する文書。CDD は、軍事的に有用で、ロジスティックス的にサポート可能で、技術的に成熟した能力の手頃な増加の概要を示します。
- 能力生産文書 (CPD)。取得プログラムの単一の増分に固有の生産要素を扱う文書。
- 情報サポート計画（ISP）。[16]ネット中心性、相互運用性、サポート性、十分性に関する懸念に焦点を当てた情報ニーズ、インフラストラクチャサポート、ITおよびNSSインターフェース要件と依存関係の特定と文書化（DODI 4630.8）。[17]
- カスタマイズされた情報サポート プラン (TISP)。TISP プロセスの目的は、特定のプログラム (ACAT II 以下) が I&S 認証に必要な要件を作成するための動的で効率的な手段を提供することです。一部のプログラム マネージャーは、ISP の内容のカスタマイズを要求できます (ref ss)。ASD (NII) /DOD CIO によって OSD 特別関心として指定されていないプログラムについては、CJCSI 6212 リソース ページからリンクされている TISP 手順で指定された最小要件と、J-6 によって I&S 認証プロセス用に特定された特別なニーズに従って、コンポーネントがカスタマイズされたプランの詳細について最終決定を下します。
表現
DoDAF 製品の表現は、次のようなさまざまな図表作成手法から作成できます。
OMG内では、 UML が使用される場合の DoDAF 製品の表現を標準化するための UPDM (Unified Profile for DoDAF and MODAF) の取り組みがあります。
DoDAFは、生成される成果物の表現を一般的に記述しますが、特定の形式とモデリング手法に関してはかなりの柔軟性があります。DoDAFデスクブックには、従来のシステムエンジニアリングとデータエンジニアリングの手法、そしてUML形式の使用例が示されています。[18] DoDAFは、あるダイアグラム作成手法が他の手法よりも優れていると主張することなく、作業成果物の形式に自由度を宣言しています。
グラフィカルな表現に加えて、通常は、国防情報技術ポートフォリオ リポジトリ (DITPR) またはその他のアーキテクチャ リポジトリに メタデータを提供する必要があります。
メタモデル
DoDAF には、フレームワークの基盤となるメタモデルがあり、各ビューで使用できるモデリング要素の種類とそれらの間の関係を定義します。DoDAF バージョン 1.0 から 1.5 では、 IDEF1X (後に UML)で定義されたCADMメタモデルが使用され、結果として得られるリレーショナル データベースから派生したXML スキーマが使用されました。バージョン 2.0 以降、DoDAF はIDEAS Group基盤オントロジーを新しいメタモデルの基盤として採用しています。この新しいメタモデルは、「DoDAF Meta-Model」の頭字語である「DM2」と呼ばれます。DM2 のこれらの 3 つのレベルはそれぞれ、部門プロセスの特定のビューアーにとって重要です。
- 概念レベルまたは概念データ モデル (CDM) は、アーキテクチャ記述が作成される高レベルのデータ構造を非技術的な用語で定義します。これにより、あらゆるレベルの幹部や管理者がアーキテクチャ記述のデータ ベースを理解できるようになります。DoDAF V2.0 DIV-1 視点で表されます。
- 論理データ モデル (LDM) は、CDM に属性などの技術情報を追加し、必要に応じて関係を明確にして、明確な使用定義を作成します。DoDAF V2.0 DIV-2 視点で表されます。
- 物理交換仕様（PES）は、一般的なデータ型が指定され、実装属性（ソース、日付など）が追加されたLDMで構成され、XSDとして生成されます。DoDAF V2.0 DIV-3 Viewpointで表現されています。[6]
DM2 の目的は次のとおりです。
- DoDAFモデル（旧称「製品」）と6つのコアプロセスにおけるその使用法についての説明と議論のための制約付き語彙を確立し、定義する
- DoDエンタープライズアーキテクチャ（EA）コミュニティオブインタレスト（COI）全体のアーキテクチャ開発および分析ツールとアーキテクチャデータベース、およびその他の信頼できるデータソース間の連合EAデータ交換のセマンティクスと形式を指定します。
- EA データの検出と理解をサポートします。
- DM2 情報カテゴリを使用した EA データの検出
- 言語的追跡可能性（エイリアス）を強化した DM2 の正確なセマンティクスを使用した EA データの理解可能性
- コアプロセスの意思決定をサポートするために、異種のアーキテクチャ記述の統合と分析をサポートするために、アーキテクチャ記述における意味的精度の基礎を提供します。[6]
DM2 は、アーキテクチャ データ要素を定義し、アーキテクチャ記述の統合と連合を可能にします。アーキテクチャ記述内およびアーキテクチャ記述間でのセマンティック (つまり、理解) の一貫性の基盤を確立します。このように、DM2 は、JCA、コンポーネント、および連邦および連合のパートナー間でのアーキテクチャ情報の交換と再利用をサポートし、プロセスとシステムの相互運用性の理解と実装を促進します。DM2 が成熟して、プロセス所有者、意思決定者、アーキテクト、および新しいテクノロジの継続的なデータ要件を満たすようになると、アーキテクチャ データの要件をより完全にサポートし、一貫して理解できる方法で公開されるリソースに進化し、組織の境界を越えてアーキテクチャ データの検出、共有、および再利用をより簡単にします。[6]
データ層での情報の利用を容易にするために、DoDAFは、データをグラフィック、表、またはテキスト形式で視覚化する一連のモデルを記述しています。これらのビューは、アーキテクチャ記述を作成するための利害関係者の要件に関連しています。[6]
他のアーキテクチャフレームワークとの関係
UPDM (Unified Profile for DoDAF and MODAF )は、米国と英国の防衛アーキテクチャ フレームワークの UML と SysML の使用を標準化する OMG の取り組みです。さらに、オーストラリア、カナダ、スウェーデン、英国、米国、 NATOオブザーバーの支援を受ける多国籍のIDEAS グループが、エンタープライズ アーキテクチャの正式なオントロジーを開発する取り組みを開始しました。
参照
参考文献
- ^ abcdefgh DoD (2007) DoD アーキテクチャ フレームワーク バージョン 1.5。2007 年 4 月 23 日
- ^ DoD (2009) DoD アーキテクチャ フレームワーク バージョン 2.0。2009 年 5 月 28 日
- ^ (参考: Zachman Framework )
- ^ 「アーキテクチャ フレームワーク FAQ」 。2007年 8 月 7 日閲覧。
- ^ 「CJCSM 3170.01C 統合能力統合開発システムの運用」 2007年5月1日。ICD、CDD、CPD の必須付録、例: EA-5 ページ「必須: OV-1」
- ^ abcdef "DoDAF メタ モデル (DM2)".
- ^ DoDAF 2.0 をリリースする国防総省 CIO メモ
- ^ 「DODAF - DOD アーキテクチャ フレームワーク バージョン 2.02 - DOD 副最高情報責任者」。
- ^ 国防総省 CIO DoDAF ウェブサイト
- ^ 「DODAF 2.0 の機能の観点」.
- ^ DoDAF V2.0 の視点の図
- ^ DoDAF V1.5 ビューから DoDAF V2.0 ビューポイントへの進化
- ^ DoDAF V1.5 ビューから DoDAF V2.0 ビューポイントへのマッピング
- ^ 「DoDAF V2.0 Volume 2 アーキテクト ガイド 2009 年 5 月」(PDF)。
- ^ DoDAF V1.5 製品マトリックス
- ^ 「情報サポートプラン（DAU ACQuipediaエントリ）」。
- ^ 「E4.A2 ISP アーキテクチャ ガイダンス」(PDF)、情報技術 (IT) と国家安全保障システム (NSS) の相互運用性とサポート性に関する手順、2004 年、83 ページ
- ^ 「アーカイブコピー」。2007年9月27日時点のオリジナルよりアーカイブ。2007年8月5日閲覧。
{{cite web}}: CS1 maint: アーカイブされたコピーをタイトルとして (リンク)
さらに読む
- Dennis E. Wisnoskyおよび Joseph Vogel。『Dodaf Wizdom: 国防総省アーキテクチャ フレームワークを使用してエンタープライズ アーキテクチャを構築するためのプロジェクトの計画、管理、実行に関する実践ガイド』。Wizdom Systems, Inc.、2004 年。ISBN 1-893990-09-5。
- Steven H. Dam 博士 (2015)。DoDアーキテクチャ フレームワーク 2.0: システム エンジニアリングを適用して統合された実行可能アーキテクチャを開発するためのガイド。CreateSpace Independent Publishing Platform、2015 年。ISBN 1-502757-62-1。
外部リンク
ウィキメディア・コモンズには、国防総省のアーキテクチャ・フレームワークに関連するメディアがあります。
- DoD CIO の DoDAF ホームページ
- DODAF 2.02 pdf、2010 年 8 月
- 第 1 巻: 概要と概念 - マネージャー ガイド[永久リンク切れ]
- 第 2 巻: 建築データとモデル – 建築家ガイド
- 第 3 巻: メタモデル オントロジー基盤と物理交換仕様 - 開発者ガイド
- 第 4 巻: ジャーナル - ベスト プラクティス[永久リンク切れ]
- DoDAF v1.5、2007年4月23日
- 第 1 巻: 定義とガイドライン pdf
- Vol II: 製品説明 pdf
- Vol III: アーキテクチャデータの説明 pdf
- DoDAF V1、2004年2月9日
- デスクブック 2017-11-15 にWayback Machineでアーカイブされました
- 第1巻: 定義とガイドライン
- アーキテクチャ フレームワーク フォーラムの DoDAF セクション DoDAF と他のアーキテクチャ フレームワークとの関連に特化した情報リソース
- DoD CMO ビジネス エンタープライズ アーキテクチャ (BEA) 2020-11-02 にWayback Machineでアーカイブされました
- DoD BEA 10.0 アーキテクチャ製品ガイド
- 統合 EA カンファレンス 2008 および 2009 からの DoDAF 2.0 に関する 2 つのプレゼンテーション
- 国防総省情報エンタープライズアーキテクチャ
- メタデータレジストリ
- CJCSI 6212.01 シリーズ
- CJCSI 6212.01F 文書
- 欧州宇宙機関アーキテクチャフレームワーク（ESAAF） - 欧州の宇宙ベースのシステム・オブ・システムのフレームワーク[1]