Структура архитектуры Министерства обороны

DOD Architecture Framework v1.5.

Dodaf Architecture Framework Версия 2.0

Структура архитектуры Министерства обороны ( DODAF ) является структурой архитектуры для Министерства обороны США (DOD), которая предоставляет инфраструктуру визуализации для конкретных проблем заинтересованных сторон с помощью точек зрения, организованных различными взглядами . Эти взгляды являются артефактами для визуализации, понимания и ассимиляции широкого объема и сложностей описания архитектуры с помощью табличного , структурного , поведенческого , онтологического , графического , временного , графического , вероятностного или альтернативного концептуального средства. Текущий релиз DODAF 2.02.

Эта архитектурная структура особенно подходит для крупных систем со сложными проблемами интеграции и совместимости, и, по -видимому, уникальна в использовании «операционных взглядов». Эти представления предлагают обзор и детали, направленные на конкретные заинтересованные стороны в их домене и взаимодействие с другими доменами, в которых система будет работать.

Обзор

DODAF предоставляет основополагающую основу для разработки и представления описаний архитектур, которые обеспечивают общий знаменатель для понимания, сравнения и интеграции архитектур по организационным, совместным и многонациональным границам. Он устанавливает определения элементов данных, правила и отношения и базовый набор продуктов для последовательной разработки систем, интегрированных или федеративных архитектур. Эти описания архитектуры могут включать в себя семьи систем (FOS), систем систем (SOS) и сетевые ориентиры для взаимодействия и взаимодействия в нечастоте.

Ожидается, что компоненты DOD будут соответствовать DODAF в максимально возможной степени при разработке архитектур в департаменте. Соответствие гарантирует, что повторное использование информации, архифактов архитектуры, моделей и точек зрения может быть передано с общим пониманием. Все основные приобретения системы вооружений и системы информационных технологий США необходимы для разработки и документирования архитектуры предприятия (EA) с использованием представлений, предписанных в DODAF. Несмотря на то, что он явно направлен на военные системы, DODAF обладает широкой применимостью в частном, общественном и добровольном секторах по всему миру и представляет собой одну из большого количества системных рамках архитектуры .

• Цель DODAF - определить концепции и модели, пригодные для использования в шести основных процессах DOD:
  1. Интеграция и разработка совместных возможностей (JCID)
  2. Планирование, программирование, бюджетирование и исполнение (PPBE)
  3. Система приобретения обороны (DAS)
  4. Системная инженерия (SE)
  5. Оперативное планирование (Оплан)
  6. Управление портфелем возможностей (CPM)
• Кроме того, конкретные цели Dodaf 2.0 были:
  1. Установить руководство для контента архитектуры как функция цели - «подходит для цели»
  2. Увеличьте полезность и эффективность архитектур через строгую модель данных - мета -модель DODAF (DM2) - поэтому архитектуры могут быть интегрированы, проанализированы и оценены с большей точностью.

История

Эволюция Додафа с 1990 -х годов. Dodaf v2.0 был выпущен в мае 2009 года.

Первая версия Development Dodaf была разработана в 1990 -х годах под названием C4ISR Architecture Framework. В тот же период эталонная модель TAFIM , которая была инициирована в 1986 году, была дополнительно разработана. Первая структура архитектуры C4ISR v1.0, выпущенная 7 июня 1996 года, была создана в ответ на принятие Закона Клингер-Коэна . Он рассмотрел заместитель секретаря в области обороны 1995 года о том, что должны быть предприняты усилия по всему миру по определению и разработке лучших средств и процесса для обеспечения того, чтобы возможности C4ISR были совместимы и удовлетворяли потребности боевика. Продолжающиеся усилия по разработке были получены в декабре 1997 года во второй версии, C4ISR Architecture Framework v2.0.

В августе 2003 года был выпущен DODAF V1.0, который реструктурировал C4ISR Framework v2.0, чтобы предложить руководство, описания продуктов и дополнительную информацию в двух томах и настольной книге. Он расширил применимость архитектурных принципов и практик ко всем областям миссии, а не только сообщество C4ISR. В этом документе рассматривались использование, интегрированные архитектуры, DOD и федеральные политики, ценность архитектур, архитектурные меры, процессы поддержки принятия решений DOD, методы разработки, аналитические методы и CADM v1.01 и перешел к подходу на основе хранилища, сделав акцент на Элементы данных архитектуры, которые составляют архитектурные продукты. В феврале 2004 года документация версии 1.0 была выпущена с томом «I: определения и руководящие принципы», «II: описания продукта» и «настольная книга». В апреле 2007 года версия 1.5 была выпущена с документацией «Определения и руководящие принципы», «Описания продуктов» и «Описание данных архитектуры». Этот период дополнительно разработал концепции и термины, которые с тех пор были заменены различными подходами. Например, Заявление о необходимости миссии (MNS) представляло собой документ Министерства обороны США , который определил потребности в программе для удовлетворения комбинации решений ( DOTMLPF ) для разрешения дефицита миссии или для повышения эксплуатационных возможностей. Этот тип документа был заменен описанием потребностей возможностей, называемых начальным документом возможностей, по состоянию на CJCSI 3170.01e. CJCSI 3170.01 и 6212.01 были заменены серией CJCSI 5123.01.

Этот термин был введен в качестве фундаментального шага в CJCSI 3170.01b (апрель 2001 г.), 6212.01d (апрель 2005 г.) и промежуточное руководство по приобретению обороны (октябрь 2004 г.).

28 мая 2009 года Министерство обороны Dodaf V2.0 было одобрено. Текущая версия Dodaf 2.02 Dodaf v2.0 публикуется на публичном веб -сайте.

Другие производные рамки, основанные на DODAF, включают структуру архитектуры НАТО (NAF) и Фреймворк Министерства обороны . Как и другие подходы EA, например, в рамках открытой групповой архитектуры (TOGAF), DODAF организован вокруг общего репозитория для хранения рабочих продуктов. Репозиторий определяется моделью данных 2.0 базы данных общей схемы базы данных и системой реестра архитектур DOD (DARS). Ключевой особенностью DODAF является совместимость, которая организована как серия уровней, называемых уровнями взаимодействия информационной системы (LISI). Развивающаяся система должна соответствовать не только своим внутренним потребностям данных, но и в рамках рабочей структуры, в которую она установлена.

Возможности и миссия

См. Диаграмму для описания акцента возможностей, связанного с миссией/курсом действий, нити, мероприятиями и архитектурой.

Возможности, описанные с архитектурами

Министерство обороны направилось к тому, чтобы сосредоточиться на доставке возможностей, что является причиной создания системы/сервиса. Модели возможностей описывают таксономию возможностей и эволюцию возможностей. Поток возможностей будет соответствовать конкретным действиям, правилам и системам, которые связаны с этой конкретной способностью.

Концепция возможностей, определяемая ее группой данных метамодели, позволяет отвечать на такие вопросы, как:

• Как конкретные возможности или возможности поддерживают общую миссию/видение?
• Какие результаты должны быть достигнуты с помощью конкретной возможности или набора возможностей?
• Какие услуги необходимы для поддержки возможности?
• Какова функциональная область и организационное расстояние возможностей или набора возможностей?
• Какова наш текущий набор возможностей, которыми мы управляем в рамках портфеля?

Миссия или курс действий описываются концепцией операций (CONOPS) и организованы возможностями.

• Возможности описываются потоками.
• Потоки описываются действиями, выполненными в последовательных или параллельных.
• Мероприятия сгруппированы в области миссии. Действия определяют операции для архитектуры.
• Архитектуры организованы областями миссии. Архитектуры обеспечивают правильный ресурс возможностей, требуемых миссией или курсом действий.

Версия 1.5 Просмотры

Dodaf v1.5 Связи между взглядами.

DOD C4ISR Framework

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

• Все вид (из)
• Оперативный взгляд (OV)
• Системный вид (SV)
• Просмотр технических стандартов (ТВ)

В каждом представлении изображены определенные перспективы архитектуры, как описано ниже. Только подмножество полного видового сбора DODAF обычно создается для каждой разработки системы. На рисунке представлена ​​информация, которая связывает эксплуатационное представление, представление систем и услуг, а также представление технических стандартов. Три взгляда и их взаимосвязи, обусловленные элементами данных общих архитектурных данных - обеспечивают основу для Получение мер, таких как совместимость или производительность, и для измерения влияния значений этих метрик на оперативную миссию и эффективность задачи.

Все вид

Все продукты View (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 модель оперативных правил

Один из трех продуктов, используемых для описания последовательности оперативной деятельности и времени, которые определяют бизнес -правила, которые ограничивают работу.

Описание перехода OV-6B OV-6B

Один из трех продуктов, используемых для описания последовательности оперативной деятельности и времени, которые определяют ответы бизнес -процесса на события.

OV-6C Описание оперативного события

Один из трех продуктов, используемых для описания последовательности оперативной активности и времени, которые прослеживают действия в сценарии или критической последовательности событий.

OV-7 модель логических данных

Документация требований к данным и правил структурного бизнес -процесса операционного представления. (В Dodaf v1.5. Это соответствует Div-2 в Dodaf v2.0.)

Просмотр систем и услуг

Systems and Services View (SV) - это набор графических и текстовых продуктов, которые описывают системы и услуги и взаимосвязи, обеспечивающие или поддерживающие функции DOD. Продукты SV фокусируются на конкретных физических системах с конкретными физическими (географическими) местоположениями. Взаимосвязь между элементами данных архитектуры через SV и OV может быть иллюстрирована, поскольку системы закуплены и направлены для поддержки организаций и их деятельности. Продукты Dodaf v1.5 SV:

SV-1 Systems/Services interface Описание

Определяет системные узлы и системы, проживающие в этих узлах, для поддержки организаций/человеческих ролей, представленных оперативными узлами OV-2. SV-1 также идентифицирует интерфейсы между системами и узлами систем.

SV-2 Systems/Services Communications Описание

Описывает соответствующую информацию о системах связи, связях с коммуникациями и коммуникационными сетями. SV-2 документирует виды коммуникационных носителей, которые поддерживают системы и реализуют их интерфейсы, как описано в SV-1. Таким образом, SV-2 показывают детали связи интерфейсов SV-1, которые автоматизируют аспекты игновых линий, представленных в OV-2.

Системные системы SV-3, Services-Systems, Marry-Services Marren

Предоставляет подробную информацию о характеристиках интерфейса, описанных в SV-1 для архитектуры, расположенной в форме матрицы.

SV-4A/SV-4B Systems/Services Описание функциональности

Функциональные иерархии и системные функции SV-4A документируют, и системные данные протекают между ними. SV-4 от Dodaf V1.0 обозначается как «SV-4A» в Dodaf V1.5. Несмотря на то, что существует корреляция между иерархиями OV-5 или бизнес-процесса и функциональной иерархией системы SV-4A, оно не должно быть отображением один на один, следовательно, необходимость в операционной активности для матрицы отслеживания функций систем (матрица прослеживания функций систем ( SV-5A), который обеспечивает это отображение.

SV-5A, SV-5B, SV-5C Операционная деятельность для функции систем, операционная активность для систем и служб отслеживаемости

Операционная деятельность для SV-5A и SV-5B представляет собой спецификацию взаимосвязи между набором операционной деятельности, применимой к архитектуре, и набором системных функций, применимых к этой архитектуре. SV-5 и расширение на SV-5 от DODAF V1.0 обозначены как «SV-5A» и «SV-5B» в DODAF V1.5 соответственно.

SV-6 Systems/Services MATRIX

Определяет характеристики системных данных, обмениваемых между системами. Этот продукт фокусируется на автоматических обменах информации (от OV-3), которые реализованы в системах. Неавтоматизированные обмены информацией, такие как устные заказы, фиксируются только в продуктах OV.

SV-7 Systems/Services Performance Matrix

Определяет количественные характеристики систем и системных аппаратных/программных элементов, их интерфейсов (системные данные, передаваемые интерфейсом, а также детали связи связи, которые реализуют интерфейс) и их функции. Он определяет текущие параметры производительности каждой системы, интерфейса или системной функции, а также ожидаемые или необходимые параметры производительности в указанное время в будущем. Параметры производительности включают все технические характеристики производительности систем, для которых могут быть разработаны требования и определены спецификация. Полный набор параметров производительности может не быть известен на ранних этапах определения архитектуры, поэтому следует ожидать, что этот продукт будет обновлен на протяжении спецификации, проектирования, разработки, разработки, разработки и, возможно, даже его развертывания и эксплуатации фазы.

SV-8 Системы/Служба Эволюция Описание

Устает планы эволюции, которые описывают, как система или архитектура, в которую встроена система, будет развиваться в течение длительного периода времени. Как правило, вехи графиков имеют решающее значение для успешного понимания временной шкалы эволюции.

Прогноз технологий систем/услуг SV-9

Определяет основные текущие и ожидаемые вспомогательные технологии, которые были нацелены с использованием стандартных методов прогнозирования. Ожидаемые технологии поддержки - это те, которые могут быть разумно прогнозировать, учитывая текущее состояние технологий и ожидаемые улучшения. Новые технологии должны быть привязаны к конкретным периодам времени, которые могут коррелировать с периодами времени, используемыми в этапах SV-8.

SV-10A Системных/служб модель правил

Описывает правила, в соответствии с которыми архитектура или ее системы ведут себя в указанных условиях.

SV-10B Systems/Services State Complysing Описание перехода

Графический метод описания ответа системы (или системной функции) на различные события путем изменения его состояния. Диаграмма в основном представляет собой наборы событий, на которые будут реагировать системы в архитектуре (предпринимая действие, чтобы перейти в новое состояние) в зависимости от его текущего состояния. Каждый переход указывает событие и действие.

SV-10C Systems/Services

Обеспечивает упорядоченное исследование элементов системных данных, обмениваемых между системами участия (внешних и внутренних), системными функциями или человеческими ролями в результате конкретного сценария. Каждая схема событий должна иметь сопутствующее описание, которое определяет конкретный сценарий или ситуацию. SV-10C в представлении систем и услуг может отражать системные аспекты или уточнения критических последовательностей событий, описанных в оперативном представлении.

SV-11 Физическая схема

Один из продуктов архитектуры, ближайший к фактическому дизайну системы в рамках. Продукт определяет структуру различных видов системных данных, которые используются системами в архитектуре. (В Dodaf v1.5. Это соответствует Div-3 в Dodaf v2.0.)

Взгляд технических стандартов

Технические стандарты View (TV) Продукты определяют технические стандарты, соглашения о внедрении, бизнес -правила и критерии, которые регулируют архитектуру. Телевизионные продукты Dodaf v1.5 заключаются в следующем:

• Профиль технических стандартов STDV -1 - извлечение стандартов, которые применяются к данной архитектуре. (В Dodaf V1.5. Переименовано в STDV-1 в Dodaf v2.0.)
• Прогноз технических стандартов STDV -2 - Описание новых стандартов, которые, как ожидается, будут применяться к данной архитектуре, в соответствующем наборе сроков. (В Dodaf V1.5. Переименовано в STDV-2 в Dodaf v2.0.)

Версия 2.0 Точки зрения

Диаграмма точек зрения Dodaf v2.0.

Эволюция просмотров Dodaf v1.5 к точкам зрения Dodaf v2.0.

Картирование просмотров Dodaf v1.5 с точками зрения Dodaf v2.0.

В Dodaf v2.0 архитектурные точки зрения состоят из данных, которые были организованы для облегчения понимания. Чтобы соответствовать стандартам ISO, где это необходимо, терминология изменилась с просмотров на точку зрения (например, оперативная точка зрения теперь является оперативной точкой зрения).

Вся точка зрения (OF)

Описывает всеобъемлющие аспекты контекста архитектуры, которые связаны со всеми точками зрения.

Возможность просмотра возможностей (CV)

Новое в Dodaf v2.0. Сформулирует требования о возможностях, время доставки и развернутые возможности.

Данные и информационная точка зрения (Div)

Новое в Dodaf v2.0. Сформулирует отношения данных и структуры выравнивания в контенте архитектуры для возможностей и эксплуатационных требований, системных процессов, а также систем и услуг.

Оперативная точка зрения (OV)

Включает в себя операционные сценарии, действия и требования, которые поддерживают возможности.

Project Viewpoint (PV)

Новое в Dodaf v2.0. Описывает взаимосвязь между требованиями к эксплуатации и возможностям и различными проектами. На просмотре проекта также подробно описывается зависимости между возможностями и эксплуатационными требованиями, процессами системного проектирования, проектирования систем и проектирования услуг в рамках процесса защиты системы приобретения.

Services Viewpoint (SVCV)

Новое в Dodaf v2.0. Представляет дизайн для решений, сформулирующих исполнителей, мероприятия, услуги и их обмены, обеспечивая или поддерживая функции эксплуатации и возможностей.

Точка зрения на стандарты (STDV)

Переименовано из технических стандартов. Сформирует применимые операционные, деловые, технические и отраслевые политики, стандарты, руководство, ограничения и прогнозы, которые применяются к возможностям и эксплуатационным требованиям, системным процессам, а также системам и услугам.

Systems Viewpoint (SV)

Штатует, для устаревшей поддержки , дизайн для решений, артикуляции систем, их композиции, взаимосвязанности и контекста, обеспечивающих или поддерживающие функции эксплуатации и возможностей. Обратите внимание, что система изменилась в Dodaf V2.0 из DODAF V1.5: Система - это не только компьютерное оборудование и компьютерное программное обеспечение. В настоящее время система определяется в общем смысле компонентов - машины, человека - которые выполняют действия (поскольку они являются подтипами исполнителя) и взаимодействуют или взаимозависимы. Это может быть что угодно, т. Е. Все, от небольших кусочков оборудования, которые имеют взаимодействующие или взаимозависимые элементы, до семейства систем (FOS) и системы систем (SOS). Обратите внимание, что системы состоят из материальных (например, оборудования, самолетов и судов) и типов персонала.

Архитектуры для Dodaf V1.0 и Dodaf v1.5 могут продолжать использоваться. Когда это необходимо (обычно указывается политикой или принимающим решения), архитектуры Dodaf V1.0 и V1.5 должны будут обновить свою архитектуру. Когда архитектура Pre-Dodaf v2.0 сравнивается с архитектурой Dodaf v2.0, концептуальные различия (такие как узел) должны быть определены или объяснены для более новой архитектуры. Что касается продуктов DODAF V1.5, они были преобразованы в части моделей DODAF V2.0. В большинстве случаев мета-модель DODAF V2.0 поддерживает концепции данных DODAF V1.5, с одним заметным исключением: Узел. Узел - это сложная, логическая концепция, которая представлена ​​с более конкретными концепциями.

Вся точка зрения (OF)

Обзор AV-1 и краткая информация

Описывает видения проекта, цели, цели, планы, мероприятия, события, условия, меры, эффекты (результаты) и произведенные объекты.

AV-2 Интегрированный словарь

Репозиторий архитектурных данных с определениями всех терминов, используемых в течение всего

Возможность просмотра возможностей (CV)

CV-1 Vision

Относится к вопросам предприятия, связанных с общим видением трансформационных усилий, и, таким образом, определяет стратегический контекст для группы возможностей. Целью CV-1 является предоставление стратегического контекста для возможностей, описанных в описании архитектуры.

Таксономия CV-2

Захватывает таксономии возможностей. Модель представляет иерархию возможностей. Эти возможности могут быть представлены в контексте временной шкалы. CV-2 указывает все возможности, на которые ссылаются на одну или несколько архитектур.

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.

Примечание, см. Модель логических данных для обсуждения взаимосвязи этих трех моделей данных DIV с сравнением концептуальных, логических и физических моделей данных.

Оперативная точка зрения (OV)

OV-1 Высокоуровневая оперативная концепция графика

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

Описание потока эксплуатационных ресурсов OV-2

Описание потоков ресурса, обмениваемых между оперативной деятельностью.

ОВ-3 Матрица потока эксплуатационных ресурсов

Описание обмена ресурсов и соответствующих атрибутов обменов.

OV-4 Организационные отношения диаграммы

Организационный контекст, роль или другие отношения между организациями.

OV-5A оперативная активность дерева разложения

Возможности и деятельность (операционная деятельность), организованные в иерархической структуре.

OV-5B Модель оперативной активности

Контекст возможностей и деятельности (операционная деятельность) и их взаимосвязи между деятельностью, входами и результатами; Дополнительные данные могут показать стоимость, исполнителей или другую соответствующую информацию.

OV-6A модель оперативных правил

Одна из трех моделей, используемых для описания деятельности (оперативная деятельность). Он определяет бизнес -правила, которые ограничивают операции.

Описание перехода OV-6B OV-6B

Одна из трех моделей, используемых для описания операционной активности (активность). Он идентифицирует реакции бизнес -процесса (деятельность) на события (обычно, очень короткие действия).

OV-6C Описание событий

Одна из трех моделей, используемых для описания деятельности (оперативная деятельность). Он прослеживает действия в сценарии или последовательности событий.

Project Viewpoint (PV)

PV-1 Project Portfolio

Он описывает отношения зависимости между организациями и проектами и организационными структурами, необходимыми для управления портфелем проектов.

PV-2 проектные временные рамки

Сроки сроки на программы или проекты, с ключевыми вехами и взаимозависимостями.

PV-3 Проект для картирования возможностей

Картирование программ и проектов с возможностями, чтобы показать, как конкретные проекты и элементы программы помогают достичь возможности.

Services Viewpoint (SVCV)

SVCV-1 Услуги описание контекста

Идентификация услуг, предметов обслуживания и их взаимосвязи.

Описание потока ресурсов SVCV-2 Services

Описание потоков ресурсов, обмениваемых между службами.

SVCV-3A Матрица системных услуг

Отношения между системами и услугами в данном архитектурном описании.

SVCV-3B Services-Services Matrix

Отношения между услугами в данном архитектурном описании. Он может быть разработан, чтобы показать интересующие отношения (например, интерфейсы типа сервиса, запланированные и существующие интерфейсы).

SVCV-4 Услуги Описание функциональности

Функции, выполняемые услугами, и потоки данных обслуживания между функциями обслуживания (действия).

Оперативная деятельность SVCV-5 для отслеживания служб матрицы отслеживания

Картирование услуг (мероприятия) обратно на оперативную деятельность (деятельность).

SVCV-6 Services Services Matrix

Он предоставляет подробную информацию о элементах потока сервисных ресурсов, которые обмениваются между службами и атрибутами этого обмена.

SVCV-7 Services Mears Matrix

Меры (метрики) модели услуг для соответствующих сроков (ов).

SVCV-8 Evolution Evolution Описание

Запланированные постепенные шаги к мигрированию набора услуг в более эффективный набор или к развитию текущих услуг в будущую реализацию.

Прогноз технологий и навыков сервисов SVCV-9

Новые технологии, программные/аппаратные продукты и навыки, которые, как ожидается, будут доступны в данном наборе временных рам, и это повлияет на будущее развитие услуг.

SVCV-10A Services Model Model

Одна из трех моделей, используемых для описания функциональности обслуживания. Он определяет ограничения, которые налагаются на функциональность систем из -за некоторого аспекта проектирования или реализации системы.

SVCV-10B Услуги

Одна из трех моделей, используемых для описания функциональности обслуживания. Он определяет ответы услуг на события.

SVCV-10C Services Services Trace Trace

Одна из трех моделей, используемых для описания функциональности обслуживания. Он определяет специфические для обслуживания уточнения критических последовательностей событий, описанных в оперативной точке зрения.

Точка зрения на стандарты (STDV)

Профиль стандартов STDV-1

Список стандартов, которые применяются к элементам решения. В Dodaf v1.5 это был TV-1.

Прогноз стандартов STDV-2

Описание новых стандартов и потенциального воздействия на текущие элементы решения в рамках сроков. В Dodaf v1.5 это был TV-2.

Systems Viewpoint (SV)

Описание интерфейса систем SV-1

Идентификация систем, системных элементов и их взаимосвязи.

SV-2 Системные ресурсы Описание потока ресурсов

Описание потоков ресурсов обменивается между системами.

SV-3 Системных систем Матрицы

Отношения между системами в данном архитектурном описании. Он может быть разработан, чтобы показать интересующие отношения (например, интерфейсы системного типа, запланированные и существующие интерфейсы).

Описание функциональности SV-4 Систем

Функции (действия), выполняемые системами и потоками системных данных между системными функциями (действия).

Оперативная активность SV-5A для системных функций Функции прослеживаемости

Картирование системных функций (мероприятия) обратно на оперативную деятельность (деятельность).

Оперативная активность SV-5B для системной отслеживаемости матрицы

Картирование систем обратно на возможности или операционную деятельность (деятельность).

SV-6 Системные ресурсы Матрица потока ресурсов

Предоставляет подробную информацию о элементах потока системных ресурсов, которые обмениваются между системами и атрибутами этого обмена.

Системы SV-7 измеряют матрицу

Меры (метрики) системных элементов модели для соответствующих сроков (ы).

SV-8 Systems Evolution Описание

Запланированные постепенные шаги к миграции набора систем в более эффективный набор или к развитию текущей системы в будущую реализацию.

Прогноз технологий и навыков SV-9

Новые технологии, программные/аппаратные продукты и навыки, которые, как ожидается, будут доступны в данном наборе временных рам, и это повлияет на будущее развитие системы.

SV-10A системных правил модели

Одна из трех моделей, используемых для описания функциональности системы. Он определяет ограничения, которые налагаются на функциональность систем из -за некоторого аспекта проектирования или реализации системы.

SV-10B Системные системы Описание перехода

Одна из трех моделей, используемых для описания функциональности системы. Он определяет ответы систем на события.

SV-10C Systems Systems Trace

Одна из трех моделей, используемых для описания функциональности системы. Он идентифицирует системные уточнения критических последовательностей событий, описанных на операционной точке зрения.

Создание интегрированной архитектуры с использованием DODAF

Иллюстрация интегрированной архитектуры.

Руководство по архитекторам DODAF 2.0 Повторная инструкция DOD 4630.8 Определение интегрированной архитектуры как «архитектура, состоящая из нескольких представлений, облегчающих интеграцию и способствуя взаимодействии между возможностями и среди интегрированных архитектур. Для целей развития архитектуры термин интегрированный означает, что данные, требуемые более чем одной из архитектурных Модели обычно определяются и понимаются в этих моделях. Enterprise (в контексте архитектуры DOD Enterprise (EA) является архитектурой федерации). Используемые или системы, предоставленные или предоставляемые системы), должны иметь идентичное число, название и значение, отображаемые в видениях с соответствующей архитектурой ».

Существует много разных подходов к созданию интегрированной архитектуры с использованием DODAF и для определения того, какие продукты требуются. Подход зависит от требований и ожидаемых результатов; т.е. для чего будет использоваться полученная архитектура. В качестве одного примера, DODAF V1.0 указал следующие продукты как «минимальный набор продуктов, необходимых для удовлетворения определения OV, SV и TV. Одно примечание: хотя DODAF не указывает артефакт OV-1 в качестве основного продукта, его разработка настоятельно рекомендуется. Последовательность артефактов, перечисленных ниже, дает предложенный порядок, в котором могут быть разработаны артефакты. Фактическая последовательность генерации представления и их потенциальная настройка является функцией области приложения и конкретных потребностей усилий.

• AV-1: обзор и летняя информация
• AV-2: интегрированный словарь
• OV-1: высокоуровневая оперативная концепция графика
• OV-5: модель оперативной активности
• OV-2: Описание подключения к рабочим узлу
• OV-3: Матрица операционного информационного обмена
• SV-1: Описание системного интерфейса
• TV-1: профиль технических стандартов

Одна из проблем в отношении DODAF заключается в том, насколько хорошо эти продукты соответствуют фактическим проблемам заинтересованных сторон для любой конкретной системы интереса. Можно просмотреть продукты Dodaf или, по крайней мере, 3 просмотра, как ANSI/IEEE 1471-2000 или IC/IEC 42010 точки зрения . Но чтобы построить описание архитектуры, которое соответствует ANSI/IEEE 1471-2000 или ISO/IEC 42010, необходимо четко определить заинтересованные стороны и их опасения, которые отображают каждый выбранный продукт DODAF. В противном случае существует риск производства продуктов без клиентов.

Dodaf v1.5 Matrix

На рисунке «Dodaf v1.5 Products Matrix» показано, как председатель DOD Объединенного начальника штабов (CJCSI) 6212.01E указывает, какие продукты DODAF v1.5 требуются для каждого типа анализа, в контексте готового к сети. Ключевой параметр производительности (NR-KPP):

• Документ начальных возможностей (ICD). Документирует необходимость в материальном решении для конкретного разрыва возможностей, полученного в результате первоначального анализа альтернатив, выполненных оперативным пользователем, и, по мере необходимости, независимого анализа альтернатив. Он определяет разрыв в способности с точки зрения функциональной области, соответствующего диапазона военных операций, желаемых последствий и времени.
• Документ по развитию возможностей (CDD). Документ, который охватывает информацию, необходимую для разработки предлагаемой программы, обычно с использованием стратегии эволюционного приобретения. CDD описывает доступный прирост полезных, логистически поддерживаемых и технически зрелых возможностей.
• Документ по производству возможностей (CPD). Документ, который касается производственных элементов, характерных для одного приращения программы приобретения.
• Информационная поддержка План (ISP). Идентификация и документация потребностей в информации, поддержки инфраструктуры, требования к интерфейсу IT и NSS и зависимости, сосредоточенные на сетевых взаимодействиях, взаимодействии, поддерживаемости и достаточности (DODI 4630.8).
• Аптированный план поддержки информации (TISP). Целью процесса TISP является предоставление динамического и эффективного транспортного средства для определенных программ (ACAT II и ниже) для выполнения требований, необходимых для сертификации I & S. Выбор менеджеров программ может попросить адаптировать содержание их интернет -провайдера (Ref SS). Для программ, не обозначенных OSD, специальный интерес по ASD (NII) /DOD CIO, компонент примет окончательное решение о сведении об адаптированном плане с учетом минимумов, указанных в процедурах TISP, связанных со страницей ресурса CJCSI 6212, и любых особых потребностей, выявленных J-6 для процесса сертификации I & S.

Представительство

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

• столы
• Idef
• Диаграммы отношения сущностей (ERDS)
• Умл
• Sysml

существует усиление UPDM (унифицированный профиль для DODAF и MODAF), В OMG чтобы стандартизировать представление продуктов DODAF при использовании UML.

DODAF в целом описывает представление артефактов, которые будут генерироваться, но обеспечивает значительную гибкость в отношении конкретных форматов и методов моделирования. Настольная книга DODAF содержит примеры при использовании традиционных системных техник и техник для технических данных , а во -вторых, формат UML. Додаф провозглашает широту в формате рабочего продукта, не исповедуя одну технику диаграммы над другой.

В дополнение к графическому представлению, обычно существует требование предоставить метаданные для хранилища портфеля информационных технологий (DITPR) или других архитектурных хранилищ.

Метамодель

Dodaf имеет метамодель, лежащую в основе структуры, определяя типы элементов моделирования, которые можно использовать в каждом представлении, и взаимосвязи между ними. Версии DODAF 1,0 через 1.5 использовали CADM метамодель , которая была определена в IDEF1X (затем в UML) с схемой XML, полученной из полученной реляционной базы данных. Из версии 2.0 Dodaf принял онтологию Foundation Foundation Foundation в качестве основы для своей новой мета-модели. Эта новая метамодель называется «DM2»; аббревиатура для "Dodaf MetaModel". Каждый из этих трех уровней DM2 важен для конкретного зрителя департамента:

1. Концептуальный уровень или концептуальная модель данных (CDM) определяет конструкции данных высокого уровня, из которых архитектурные описания создаются в нетехнических терминах, так что руководители и менеджеры на всех уровнях могут понять основу данных архитектурного описания. Представлено в точке зрения Dodaf v2.0 Div-1.
2. Модель логических данных (LDM) добавляет техническую информацию, такую ​​как атрибуты к CDM, и, при необходимости, проясняет отношения в однозначное определение использования. Представлено в точке зрения Dodaf v2.0 Div-2.
3. Спецификация физического обмена (PES) состоит из LDM с указанными типами данных и атрибутами реализации (например, источником, датой), а затем сгенерированными в виде XSD. Представлено в точке зрения Dodaf v2.0 Div-3.

Цели DM2:

1. Установить и определить ограниченный словарный запас для описания и дискурса о моделях DODAF (ранее «продукты») и их использование в 6 основных процессах
2. Укажите семантику и формат для федеративного обмена данными EA между: инструментами разработки и анализа архитектуры и базами данных архитектуры в рамках сообщества интересов (EA) DOD Enterprise (EA) и с другими авторитетными источниками данных
3. Поддержка обнаружения и понятия данных EA:
   1. Обнаружение данных EA с использованием категорий информации DM2
   2. Понятность данных EA с использованием точной семантики DM2, дополненной лингвистической прослеживаемостью (псевдонимов)
4. Обеспечить основу для семантической точности в архитектурных описаниях для поддержки гетерогенного архитектурного описания интеграции и анализа в поддержку принятия решений основным процессом.

DM2 определяет элементы архитектурных данных и позволяет интеграции и федерации архитектурных описаний. Он устанавливает основу для семантической (то есть понимания) последовательности внутри и между архитектурными описаниями. Таким образом, DM2 поддерживает обмен и повторное использование архитектурной информации между JCA, компонентами и федеральными партнерами и коалиционными партнерами, что облегчает понимание и реализацию совместимости процессов и систем. По мере того, как DM2 созревает для удовлетворения текущих требований к данным владельцев процессов, лиц, принимающих решения, архитекторов и новых технологий, он будет развиваться до ресурса, который более полностью поддерживает требования к архитектурным данным, опубликовано последовательно понятно и будет обеспечить больший Легкость для обнаружения, обмена и повторного использования архитектурных данных по организационным границам.

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

Отношения с другими архитектурными рамками

UPDM . (Unified Profile для DODAF и MODAF ) является инициативой OMG по стандартизации использования UML и SYSML для фреймворков оборонной архитектуры США и Великобритании Кроме того, многонациональная группа идей , которая поддерживается Австралия, Канада, Швеция, Великобритания, США, с наблюдателями НАТО , начала инициативу по разработке формальной онтологии для корпоративных архитектур.

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

• Федеральная структура архитектуры предприятия (FEAF)
• Идеи Группа
• Iuid
• MODAF METAMODEL
• Ncow

Дальнейшее чтение

• Деннис Э. Висноски и Джозеф Фогель. Dodaf Wizdom: практическое руководство по планированию, управлению и реализации проектов по созданию корпоративных архитектур с использованием структуры архитектуры Министерства обороны . Wizdom Systems, Inc., 2004. ISBN   1-893990-09-5 .
• Доктор Стивен Х. Дам (2015). DOD Architecture Framework 2.0: Руководство по применению системной инженерии для разработки интегрированных исполняемых архитектур . CreateSpace Независимая издательская платформа, 2015. ISBN   1-502757-62-1 .

Внешние ссылки

• Dod Cio Home страница
  • I DOD 2.02 PDF, август 2010
  • Том (том) I: Обзор и концепции - Руководство менеджера
  • Том II: Архитектурные данные и модели - Руководство архитектора
  • Том III: Meta-Model Ontology Foundation и спецификация физического обмена-Руководство разработчика
  • Том IV: Журнал - Лучшие практики
• I Dod v1.5, 23 апреля 2007 г.
  • Том I: Определения и руководящие принципы PDF
  • Том II: Описания продукта PDF
  • Том III: Описание данных архитектуры PDF
• Dodaf V1, 9 февраля 2004 г.
  • Настольная книга архивировано 2017-11-15 на The Wayback Machine
  • Том I: Определения и руководящие принципы
• Раздел Dodaf раздела архитектурного форума Информационный ресурс, посвященный DODAF, в связи с тем, что он связан с другими фреймворками архитектуры
• DOD CMO Business Enterprise Architecture (BEA) Архивирована 2020-11-02 на машине Wayback
  • DOD BEA 10.0 Руководство по продукту архитектуры
• Две презентации на DODAF 2.0 из интегрированных конференций EA 2008 и 2009 гг.
• Министерство оборонной информации предприятия архитектура
• Реестр метаданных
• CJCSI 6212.01 Series
  • CJCSI 6212.01F Документ
• Европейское космическое агентство Архитектурная структура (ESAAF) - структура для европейских космических систем систем [1]