Оперативный вид - Operational View

Пример «Оперативного обзора» (OV) на DoD Концепция электронной коммерции операций.[1]

Оперативный вид (OV) один из основные виды определено в архитектура предприятия (EA) из Структура архитектуры Министерства обороны V1.5 (DoDAF) и связан с концепция операций. В рамках DODAF 2, который был введен в действие в 2009 г., коллекции представлений теперь называются «точками обзора», а не представлениями.

Другие структуры архитектуры предприятия могут иметь или имеют операционные представления. Например, у MODAF есть оперативная точка зрения, а в структуре архитектуры НАТО есть операционная точка зрения (набор подвидов). В этой статье будет более подробно описано построение рабочего вида DoDAF V1.5.

Обзор

«Оперативный обзор» (OV) в DoDAF Каркас архитектуры предприятия (версия 1 / 1.5) («Рабочая точка зрения» в DODAF 2) описывает задачи и действия, операционные элементы и обмен информацией, необходимые для проведения операций. Чистый операционный взгляд не зависит от материала. Однако на операции и их взаимоотношения могут влиять новые технологии, такие как технология совместной работы, при которой усовершенствования процессов практикуются до того, как политика сможет отразить новые процедуры.[1]

Операционная точка зрения предоставляет средства для описания того, что необходимо, без решения или без реализации. Однако могут быть некоторые случаи, когда необходимо задокументировать способ выполнения процессов с учетом ограничений существующих систем, чтобы изучить способы, с помощью которых новые системы могут облегчить оптимизацию процессов. В таких случаях операционное представление может иметь материальные ограничения и требования, которые необходимо учитывать. По этой причине может потребоваться включить некоторые высокоуровневые Системный вид (SV) данные об архитектуре в качестве наложения или дополнения информации к продуктам Operational View.[1]

Темы рабочего обзора

DoDAF

В Структура архитектуры Министерства обороны (DoDAF) определяет стандартный способ организации системная архитектура на дополнительные и последовательные взгляды. Он особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия и, по-видимому, уникален тем, что использует «рабочие представления», детализирующие операционную область внешнего клиента, в которой будет работать разрабатываемая система.

DoDAF просмотреть модель показывает связи между представлениями.[2]

DoDAF определяет набор продуктов, которые действуют как механизмы для визуализации, понимания и ассимиляции широкого объема и сложности описания архитектуры с помощью графических, табличных или текстовых средств. Эти продукты сгруппированы в четырех представлениях:

  • Общий вид (AV),
  • Оперативный обзор (OV),
  • Системный обзор (SV) и
  • Просмотр технических стандартов (ТВ).

Каждый вид отображает определенные перспективы архитектуры, как описано ниже. Для каждой разработки системы обычно создается только подмножество полного набора представлений DoDAF. На рисунке представлена ​​информация, которая связывает рабочее представление, представление систем и служб и представление технических стандартов. Три представления и их взаимосвязь, обусловленная элементами данных общей архитектуры, обеспечивают основу для определения таких показателей, как совместимость или производительность, а также для измерения влияния значений этих показателей на операционную миссию и эффективность задач.[2]

OV продукты

В Структура архитектуры Министерства обороны (DoDAF) определил серию из семи различных типов продуктов Operational View.[1]В этом разделе описаны семь продуктов OV:

  • График концепции высокого уровня (OV-1)
  • Описание подключения рабочего узла (поток ресурсов) (OV-2)
  • Матрица обмена оперативной информацией (поток ресурсов) (OV-3)
  • Схема организационных отношений (OV-4)
  • Модель операционной деятельности (OV-5)
  • Модель рабочих правил, описание перехода между состояниями и трассировка событий

Описание (OV-6a, 6b и 6c)

  • Логическая модель данных (OV-7)

Графическая концепция высокого уровня

  • Концепция операций DoD в области электронной коммерции (OV-1).

  • Совместное сетевое вооружение (НОВИНКА). Графика оперативной концепции (OV-1).

  • Концепция операций совместной оперативной группы (OV-1).

  • Пример OV-1 для NCOW.

  • Графика эксплуатационной концепции высокого уровня (OV-1): графическое и текстовое описание эксплуатационной концепции высокого уровня (высокоуровневые организации, миссии, географическая конфигурация, связь и т. Д.).

Описание подключения рабочего узла

  • Шаблон ОВ-2.

  • Условный пример OV-2, изображающий поставщиков услуг.

  • Шаблон UML OV-2.

  • Описание подключения рабочего узла (OV-2): рабочие узлы, действия, выполняемые на каждом узле, а также объекты подключения и информационный поток между узлами.

Матрица обмена оперативной информацией

  • ОВ-3 - Шаблон.

  • Матрица обмена оперативной информацией (OV-3): информация, которой обмениваются узлы, и соответствующие атрибуты этого обмена, такие как носители, качество, количество и требуемый уровень взаимодействия.

Схема организационных отношений

  • ОВ-4 - Шаблон.

  • Образец UML OV-4.

  • Схема организационных отношений (OV-4): командование, контроль, координация и другие отношения между организациями.

Модель операционной деятельности

  • Схема иерархии операционной деятельности (OV-5) - шаблон.

  • Схема операционной деятельности (OV-5) - Шаблон.

  • OV-5 - Шаблон с условными аннотациями.

  • Пример UML OV-5.

  • Модель операционной деятельности (OV-5): Действия, отношения между действиями, входы и выходы. Кроме того, наложения могут отображать стоимость, рабочие узлы или другую уместную информацию.

Другие продукты OV

  • Модель рабочих правил, описание перехода между состояниями и описание трассировки событий (OV-6a, 6b и 6c)
    • Модель операционных правил (OV-6a): один из трех продуктов, используемых для описания последовательности и времени операционной деятельности, который определяет бизнес-правила, ограничивающие операцию.
    • Описание перехода рабочего состояния (OV-6b): один из трех продуктов, используемых для описания последовательности и времени операционной деятельности, который определяет реакцию бизнес-процесса на события.
    • Описание трассировки операционного события (OV-6c): один из трех продуктов, используемых для описания последовательности и времени оперативной деятельности, который отслеживает действия в сценарии или критическую последовательность событий.
  • Логическая модель данных (OV-7): документирование требований к данным и структурных правил бизнес-процессов для операционного представления.

Исполняемая операционная архитектура

Анатомия исполняемой операционной архитектуры.

Помимо изучения поведения во времени, можно также оценить общую динамическую стоимость миссии во времени с точки зрения долларовых затрат на человеческие ресурсы и ресурсы системы / сети и долларовых затрат на их процессы. Анализ долларовых затрат в исполняемые архитектуры - это первый шаг в инвестиционной стратегии, основанной на архитектуре, когда нам в конечном итоге необходимо согласовать архитектуры с решениями о финансировании, чтобы гарантировать, что инвестиционные решения напрямую связаны с целями миссии и их результатами. На рисунке справа показана анатомия одной из таких динамических моделей.[1]

Переходы состояний в исполняемых операционных архитектурных моделях обеспечивают описания условий, которые управляют поведением событий процесса при реагировании на входные данные и при создании выходных данных. Состояние определяет реакцию процесса на события. Ответ может варьироваться в зависимости от текущего состояния и набора правил или условий. Параметры распределения определяют время выполнения процесса. Примеры стратегий распределения включают: постоянные значения, список событий, постоянный интервал, нормальное распределение, экспоненциальное распределение и так далее. Приоритет определяет стратегию обработки, если два входа поступают в процесс одновременно. Входы с более высоким приоритетом обычно обрабатываются перед входами с более низким приоритетом.[1]

Примеры гистограмм, показывающих результаты моделирования.

Процессы, получающие несколько входных данных, должны определять, как реагировать. Примеры ответов включают: обрабатывать каждый вход в порядке поступления независимо друг от друга, обрабатывать только тогда, когда все входы доступны, или обрабатывать, как только любой вход обнаружен. Процессы, производящие несколько выходных данных, могут включать вероятности (в сумме 100%), при которых будет производиться каждый выход. Гистограммы являются примерами сгенерированных описаний времени. Они представляют собой графические представления процессов, человеческих и системных ресурсов, а также их использованной мощности с течением времени в ходе моделирования. Эти гистограммы используются для выполнения динамического анализа воздействия на поведение исполняемой архитектуры. На рис. 4-23 показан пример, показывающий результаты моделирования потенциала человеческих ресурсов.[1]

Смотрите также

Рекомендации

  1. ^ а б c d е ж грамм Рабочая группа DoD Architecture Framework (2003). DoDAF 1.5 Том 2, 15 августа 2003 г.
  2. ^ а б МО (2007) DoD Architecture Framework, версия 2.0. 28 мая 2009 года