運用ビュー

運用ビュー( OV )は、国防総省アーキテクチャ フレームワークV1.5 (DoDAF) のエンタープライズ アーキテクチャ(EA)で定義されている基本ビューの 1 つであり、運用の概念に関連しています。2009 年に運用が開始された DODAF 2 では、ビューのコレクションは「ビューポイント」と呼ばれ、ビューではなくなりました。

その他のエンタープライズ アーキテクチャ フレームワークには、運用ビューが存在する場合があります。たとえば、MODAF には運用ビューポイントがあり、NATO アーキテクチャ フレームワークには運用ビュー (サブビューのコレクション) があります。この記事では、DoDAF V1.5 の運用ビューの構築について詳しく説明します。

DoDAF エンタープライズ アーキテクチャ フレームワーク(バージョン 1/1.5)の「運用ビュー」(OV) (DODAF 2 では「運用ビューポイント」) は、運用を実行するために必要なタスクとアクティビティ、運用要素、および情報交換について説明します。純粋な運用ビューは物質的独立性を持ちます。ただし、運用とその関係は、コラボレーション テクノロジーなどの新しいテクノロジーの影響を受ける可能性があり、ポリシーが新しい手順を反映する前にプロセスの改善が実践されます。^[1]

運用ビューポイントは、ソリューションや実装を必要とせずに、何が必要かを説明する手段を提供します。ただし、新しいシステムでプロセスの合理化を促進する方法を検討するために、現在のシステムの制限を考慮してプロセスの実行方法を文書化する必要がある場合があります。このような場合、運用ビューには対処する必要がある重要な制約と要件がある可能性があります。このため、運用ビュー製品にオーバーレイまたは補足情報として、高レベルのシステムビュー (SV) アーキテクチャデータを含める必要がある場合があります。^[1]

国防総省アーキテクチャ フレームワーク(DoDAF) は、システム アーキテクチャを補完的かつ一貫性のあるビューに編成する標準的な方法を定義します。これは、複雑な統合と相互運用性の課題を抱える大規模システムに特に適しており、開発中のシステムが動作する外部顧客の運用ドメインを詳細に示す「運用ビュー」の使用が明らかに独特です。

DoDAF は、アーキテクチャ記述の広範な範囲と複雑さをグラフィック、表、またはテキストの手段で視覚化し、理解し、統合するためのメカニズムとして機能する一連の製品を定義します。これらの製品は、次の 4 つのビューに分類されます。

• 包括的な全体ビュー（AV）、
• 運用ビュー（OV）、
• システムビュー（SV）と
• 技術標準ビュー（TV）。

各ビューは、以下に説明するように、アーキテクチャの特定の観点を表します。通常、各システム開発では、完全な DoDAF ビューセットのサブセットのみが作成されます。図は、運用ビュー、システムとサービスのビュー、技術標準ビューをリンクする情報を表しています。共通のアーキテクチャ データ要素によって駆動される 3 つのビューとそれらの相互関係は、相互運用性やパフォーマンスなどの指標を導き出すための基礎となり、これらの指標の値が運用ミッションとタスクの有効性に与える影響を測定するための基礎となります。^[2]

国防総省アーキテクチャフレームワーク（DoDAF）は、7つの異なるタイプの運用ビュー製品を定義しています。^[1] このセクションでは、7つのOV製品について説明します。

• 高レベル作戦概念図（OV-1）
• 運用ノード接続（リソースフロー）の説明（OV-2）
• 運用情報交換（リソースフロー）マトリックス（OV-3）
• 組織関係図（OV-4）
• 運用活動モデル (OV-5)
• 操作ルールモデル、状態遷移記述、イベントトレース記述 (OV-6a、6b、6c)
• 論理データモデル (OV-7)

• 
  国防総省電子商取引運用概念 (OV-1)。
• 
  統合ネットワーク対応兵器（新）能力運用概念図（OV-1）。
• 
  統合任務部隊の作戦概念（OV-1）。
• 
  NCOW の例 OV-1。

• 高レベルの運用概念グラフィック (OV-1): 運用概念 (高レベルの組織、ミッション、地理的構成、接続性など) の高レベルのグラフィックとテキストによる説明。

• 
  OV-2 テンプレート。
• 
  サービス プロバイダーを示す OV-2 の概念的な例。
• 
  UML OV-2 テンプレート。

• 運用ノード接続の説明 (OV-2): 運用ノード、各ノードで実行されるアクティビティ、およびノー​​ド間の接続性と情報フロー。

• 
  OV-3 – テンプレート。

• 運用情報交換マトリックス (OV-3): ノード間で交換される情報と、メディア、品質、量、必要な相互運用性のレベルなど、その交換に関連する属性。

• 
  OV-4 – テンプレート。
• 
  UML OV-4 サンプル。

• 組織関係図（OV-4）：組織間の指揮、統制、調整、その他の関係。

• 
  運用活動階層図 (OV-5) – テンプレート。
• 
  運用アクティビティ図 (OV-5) – テンプレート。
• 
  OV-5 – 概念的な注釈付きのテンプレート。
• 
  UML 例 OV-5。

• 運用アクティビティ モデル (OV-5): アクティビティ、アクティビティ間の関係、入力と出力。さらに、オーバーレイにはコスト、実行ノード、その他の関連情報を表示できます。

• 操作ルールモデル、状態遷移記述、イベントトレース記述 (OV-6a、6b、6c)
  • 運用ルール モデル (OV-6a): 運用を制約するビジネス ルールを識別する運用アクティビティのシーケンスとタイミングを記述するために使用される 3 つの製品の 1 つ。
  • 運用状態遷移記述 (OV-6b): イベントに対するビジネス プロセスの応答を識別する運用アクティビティのシーケンスとタイミングを記述するために使用される 3 つの製品の 1 つ。
  • 運用イベント トレース記述 (OV-6c): シナリオまたは重要な一連のイベント内のアクションをトレースする運用アクティビティのシーケンスとタイミングを記述するために使用される 3 つの製品の 1 つ。
• 論理データ モデル (OV-7): 運用ビューのデータ要件と構造的なビジネス プロセス ルールのドキュメント。

時間の経過に伴う行動の調査に加えて、人的およびシステム/ネットワーク リソースのドル コストとプロセスのドル コストの観点から、時間の経過に伴う全体的な動的ミッション コストを評価することもできます。実行可能なアーキテクチャのドル コストの分析は、アーキテクチャ ベースの投資戦略の最初のステップです。最終的には、投資決定がミッションの目的とその結果に直接リンクされるように、アーキテクチャを資金調達の決定に合わせる必要があります。右の図は、このような動的モデルの 1 つの構造を示しています。^[1]

実行可能な運用アーキテクチャ モデルの状態遷移は、入力に応答して出力を生成する際のプロセス イベントの動作を制御する条件の記述を提供します。状態は、イベントに対するプロセスの応答を指定します。応答は、現在の状態とルール セットまたは条件によって異なる場合があります。分布設定は、プロセス時間の実行を決定します。分布戦略の例には、定数値、イベント リスト、一定間隔の間隔、正規分布、指数分布などがあります。優先度は、2 つの入力が同時にプロセスに到達した場合の処理​​戦略を決定します。通常、優先度の高い入力は、優先度の低い入力よりも先に処理されます。^[1]

複数の入力を受け取るプロセスは、どのように応答するかを定義する必要があります。応答の例には、各入力を到着順に独立して処理する、すべての入力が利用可能な場合にのみ処理する、または入力が検出されるとすぐに処理するなどがあります。複数の出力を生成するプロセスには、各出力が生成される確率（合計 100 パーセント）を含めることができます。ヒストグラムは、生成されたタイミング記述の例です。ヒストグラムは、シミュレーション実行中のプロセス、人的リソース、システム リソース、およびそれらの使用容量を時間の経過とともにグラフで表したものです。これらのヒストグラムは、実行可能アーキテクチャの動作の動的影響分析を実行するために使用されます。図 4-23 は、人的リソース容量のシミュレーション実行の結果を示す例です。^[1]

• 能力（システムエンジニアリング）
• 実行可能アーキテクチャ
• 運用コンセプト

ウィキメディア・コモンズには、 Operational Viewsに関連するメディアがあります。