Департамент обороны архитектуры Framework ( DoDAF ) является основой архитектуры для Соединенных Штатов Министерства обороны (МО) , который обеспечивает визуализацию инфраструктуры для конкретных заинтересованных сторон проблем на основе мнений , организованных различными видами . Эти представления являются артефактами для визуализации, понимания и усвоения широкого объема и сложности описания архитектуры с помощью табличных , структурных , поведенческих , онтологических , графических , временных , графических , вероятностных, или альтернативные концептуальные средства. Текущий выпуск - DoDAF 2.02.
Эта архитектура архитектуры особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия, и, очевидно, уникальна в использовании «операционных представлений». Эти представления предлагают обзор и подробные сведения, предназначенные для конкретных заинтересованных сторон в рамках их домена и во взаимодействии с другими доменами, в которых будет работать система. [3]
Обзор
DoDAF обеспечивает фундаментальную основу для разработки и представления описаний архитектуры, которые обеспечивают общий знаменатель для понимания, сравнения и интеграции архитектур через организационные, совместные и многонациональные границы. Он устанавливает определения элементов данных, правила и отношения, а также базовый набор продуктов для последовательной разработки систем, интегрированных или объединенных архитектур. Эти описания архитектуры могут включать семейства систем (FoS), системы систем (SoS) и сетецентрические возможности для взаимодействия и взаимодействия в небоевой среде. [1]
Ожидается, что компоненты DoD будут соответствовать DoDAF в максимально возможной степени при разработке архитектур в рамках Департамента. Соответствие гарантирует, что повторное использование информации, артефактов архитектуры, моделей и точек зрения может быть разделено с общим пониманием. Все основные закупки вооружений и информационных систем Министерства обороны США необходимы для разработки и документирования архитектуры предприятия (EA) с использованием представлений, предписанных DoDAF. Хотя он явно нацелен на военные системы, DoDAF имеет широкое применение в частном, государственном и добровольном секторах по всему миру и представляет собой одну из большого числа структур системной архитектуры . [4] [5]
- Целью DoDAF является определение концепций и моделей, используемых в шести основных процессах DoD: [6]
- Совместная интеграция и развитие возможностей (JCIDS)
- Планирование, программирование, бюджетирование и исполнение (PPBE)
- Система оборонных закупок (DAS)
- Системная инженерия (SE)
- Оперативное планирование (OPLAN)
- Управление портфелем возможностей (CPM)
- Кроме того, конкретные цели DoDAF 2.0 заключались в следующем: [6]
- Установите руководство для содержания архитектуры в зависимости от цели - «соответствие цели».
- Повысьте полезность и эффективность архитектур с помощью строгой модели данных - метамодели DoDAF (DM2), чтобы архитектуры можно было интегрировать, анализировать и оценивать с большей точностью.
История
Первая версия разработки DoDAF была разработана в 1990-х годах под названием C4ISR Architecture Framework. В тот же период эталонная модель TAFIM , начатая в 1986 году, получила дальнейшее развитие. Первая C4ISR Architecture Framework v1.0, выпущенная 7 июня 1996 года, была создана в ответ на принятие Закона Клингера-Коэна . Он обращался к директиве заместителя министра обороны 1995 года о том, что в масштабах Министерства обороны должны быть предприняты усилия по определению и разработке лучших средств и процесса для обеспечения взаимодействия возможностей C4ISR и удовлетворения потребностей военного истребителя. Продолжение усилий по разработке привело в декабре 1997 года ко второй версии, C4ISR Architecture Framework v2.0. [1]
В августе 2003 года был выпущен DoDAF v1.0, который реструктурировал C4ISR Framework v2.0, чтобы предложить руководство, описания продуктов и дополнительную информацию в двух томах и настольную книгу. Это расширило применимость принципов и практик архитектуры ко всем областям миссии, а не только к сообществу C4ISR. В этом документе рассматриваются вопросы использования, интегрированные архитектуры, политики Министерства обороны и федерального правительства, ценность архитектур, показатели архитектуры, процессы поддержки принятия решений Министерства обороны, методы разработки, аналитические методы и CADM v1.01, а также продвигается подход на основе репозиториев с акцентом на элементы данных архитектуры, которые составляют продукты архитектуры. [1] В феврале 2004 года была выпущена документация версии 1.0 с томами «I: Определения и рекомендации», «II: Описания продуктов» и «Настольная книга». В апреле 2007 года была выпущена версия 1.5 с документацией «Определения и рекомендации», «Описания продуктов» и «Описание данных архитектуры».
28 мая 2009 года DoDAF v2.0 был одобрен Министерством обороны. [7] Текущая версия - DoDAF 2.02 [8] DoDAF V2.0 опубликована на общедоступном веб-сайте. [9]
Другие производные структуры, основанные на DoDAF, включают структуру архитектуры НАТО (NAF) и структуру архитектуры министерства обороны . Как и другие подходы EA, например The Open Group Architecture Framework (TOGAF), DoDAF организован вокруг общего репозитория для хранения рабочих продуктов. Репозиторий определяется общей схемой базы данных Core Architecture Data Model 2.0 и DoD Architecture Registry System (DARS). Ключевой особенностью DoDAF является взаимодействие, которое организовано в виде серии уровней, называемых уровнями взаимодействия информационных систем (LISI). Развивающаяся система должна удовлетворять не только свои внутренние потребности в данных, но и потребности операционной структуры, в которую она встроена.
Возможности и миссия
См. Диаграмму для изображения акцента на возможности, связанного с миссией / курсом действий, потоками, действиями и архитектурами.
Министерство обороны сосредоточило внимание на предоставлении возможностей, которые являются причиной создания системы / службы. Модели возможностей описывают таксономию возможностей и эволюцию возможностей. Поток возможности будет приравниваться к конкретным действиям, правилам и системам, которые связаны с этой конкретной возможностью.
Концепция возможностей, определенная ее группой данных метамодели, позволяет ответить на такие вопросы, как:
- Как конкретная способность или возможности поддерживают общую миссию / видение?
- Каких результатов ожидается достичь с помощью конкретной возможности или набора возможностей?
- Какие услуги требуются для поддержки возможности?
- Каков функциональный объем и организационный объем возможности или набора возможностей?
- Каков текущий набор возможностей, которыми мы управляем как часть портфеля?
Миссия или курс действий описываются концепцией операций (CONOPS) и организуются по возможностям.
- Возможности описаны потоками.
- Потоки описываются действиями, выполняемыми последовательно или параллельно.
- Действия сгруппированы в Области Миссии. Действия определяют операции для архитектуры.
- Архитектуры организованы по областям миссии. Архитектура обеспечивает надлежащее финансирование возможностей, требуемых миссией или курсом действий.
Версия 1.5 просмотров
DoDAF V1.5 определяет набор продуктов, модель представления , которые действуют как механизмы для визуализации, понимания и усвоения широкого объема и сложности описания архитектуры с помощью графических, табличных или текстовых средств. Эти продукты сгруппированы по четырем представлениям:
- Все просмотры (AV)
- Оперативный вид (OV)
- Системный взгляд (SV)
- Просмотр технических стандартов (ТВ)
Каждый вид отображает определенные перспективы архитектуры, как описано ниже. Для каждой разработки системы обычно создается только подмножество полного набора представлений DoDAF. На рисунке представлена информация, которая связывает рабочее представление, представление систем и служб и представление технических стандартов. Эти три представления и их взаимосвязь - управляемые элементами данных общей архитектуры - обеспечивают основу для получения таких показателей, как функциональная совместимость или производительность, а также для измерения влияния значений этих показателей на операционную миссию и эффективность задач. [1]
Все просмотреть
Все продукты View (AV) предоставляют всеобъемлющие описания всей архитектуры и определяют объем и контекст архитектуры. Продукты DoDAF V1.5 AV определены как:
- Обзор AV-1 и сводная информация
- Объем, цель, предполагаемые пользователи, изображенная среда, аналитические выводы (если применимо)
- Интегрированный словарь AV-2
- Определения всех терминов, используемых во всех продуктах.
Оперативный вид
Продукты Operational View (OV) предоставляют описания задач и действий, операционных элементов и обмена информацией, необходимой для выполнения миссий DoD. OV обеспечивает текстовое и графическое представление рабочих узлов и элементов, назначенных задач и действий, а также информационных потоков между узлами. Он определяет тип обмена информацией, частоту обмена, задачи и действия, поддерживаемые этим обменом, а также характер обмена. Продукты DoDAF V1.5 OV определяются как:
- Графическая концепция высокого уровня OV-1
- Графическое и текстовое описание высокого уровня операционной концепции (высокоуровневые организации, миссии, географическая конфигурация, связь и т. Д.).
- Описание подключения рабочего узла OV-2
- Рабочие узлы, действия, выполняемые на каждом узле, а также связи и информационные потоки между узлами.
- Матрица обмена оперативной информацией OV-3
- Информация, которой обмениваются узлы, и соответствующие атрибуты этого обмена, такие как носители, качество, количество и требуемый уровень взаимодействия.
- Схема организационных отношений OV-4
- Командование, контроль, координация и другие отношения между организациями.
- OV-5 Модель операционной деятельности
- Действия, отношения между действиями, входы и выходы. Кроме того, наложения могут отображать стоимость, рабочие узлы или другую уместную информацию.
- Модель операционных правил OV-6a
- Один из трех продуктов, используемых для описания последовательности и времени операционной деятельности, который определяет бизнес-правила, ограничивающие операцию.
- OV-6b Описание перехода рабочего состояния
- Один из трех продуктов, используемых для описания последовательности и времени операционной деятельности, которые определяют реакцию бизнес-процесса на события.
- OV-6c Описание трассировки рабочего события
- Один из трех продуктов, используемых для описания последовательности и времени операционной деятельности, который отслеживает действия в сценарии или критическую последовательность событий.
- Логическая модель данных OV-7
- Документирование требований к данным и структурных правил бизнес-процессов для Operational View. (В DoDAF V1.5. Это соответствует DIV-2 в DoDAF V2.0.)
Просмотр систем и сервисов
Представление «Системы и услуги» (SV) - это набор графических и текстовых продуктов, которые описывают системы, услуги и взаимосвязи, обеспечивающие или поддерживающие функции DoD. Продукты SV ориентированы на конкретные физические системы с определенным физическим (географическим) местоположением. Взаимосвязь между элементами данных архитектуры через SV и OV может быть проиллюстрирована по мере того, как системы закупаются и используются для поддержки организаций и их операций. Продукты DoDAF V1.5 SV:
- Описание интерфейса систем / служб SV-1
- Изображает системные узлы и системы, находящиеся в этих узлах, для поддержки организаций / человеческих ролей, представленных рабочими узлами OV-2. SV-1 также определяет интерфейсы между системами и системными узлами.
- Описание связи систем / служб SV-2
- Отображает соответствующую информацию о системах связи, каналах связи и сетях связи. SV-2 документирует виды средств связи, которые поддерживают системы, и реализует их интерфейсы, как описано в SV-1. Таким образом, SV-2 показывает детали связи интерфейсов SV-1, которые автоматизируют аспекты необходимых линий, представленных в OV-2.
- SV-3 Системы-Системы, Услуги-Системы, Матрицы Услуги-Услуги
- предоставляет подробную информацию о характеристиках интерфейса, описанных в SV-1 для архитектуры, в матричной форме.
- Описание функций систем / служб SV-4a / SV-4b
- 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
- Задает характеристики системных данных, которыми обмениваются системы. Этот продукт ориентирован на автоматизированный обмен информацией (из OV-3), который реализован в системах. Неавтоматизированный обмен информацией, такой как устные приказы, фиксируется только в продуктах OV.
- Матрица параметров производительности систем / услуг SV-7
- Определяет количественные характеристики систем и элементов аппаратного / программного обеспечения системы, их интерфейсы (системные данные, переносимые интерфейсом, а также детали канала связи, реализующие интерфейс) и их функции. Он определяет текущие параметры производительности каждой системы, интерфейса или системной функции, а также ожидаемые или требуемые параметры производительности в указанное время в будущем. Рабочие параметры включают в себя все технические характеристики систем, для которых могут быть разработаны требования и определены спецификации. Полный набор параметров производительности может быть неизвестен на ранних этапах определения архитектуры, поэтому следует ожидать, что этот продукт будет обновляться на протяжении всей спецификации системы, проектирования, разработки, тестирования и, возможно, даже ее развертывания и жизненного цикла эксплуатации. фазы.
- Описание эволюции систем / услуг SV-8
- Захватывает планы развития, которые описывают, как система или архитектура, в которую она встроена, будут развиваться в течение длительного периода времени. Как правило, вехи на временной шкале имеют решающее значение для успешного понимания временной шкалы эволюции.
- Прогноз технологий систем / услуг SV-9
- Определяет базовые текущие и ожидаемые вспомогательные технологии, на которые нацелены стандартные методы прогнозирования. Ожидаемые вспомогательные технологии - это те, которые можно разумно спрогнозировать с учетом текущего состояния технологий и ожидаемых улучшений. Новые технологии должны быть привязаны к определенным периодам времени, которые могут коррелировать с периодами времени, используемыми в контрольных точках SV-8.
- Модель правил систем / услуг SV-10a
- Описывает правила, по которым архитектура или ее системы ведут себя в определенных условиях.
- Описание перехода между состояниями систем / служб SV-10b
- Графический метод описания реакции системы (или функции системы) на различные события путем изменения ее состояния. Диаграмма в основном представляет наборы событий, на которые системы в архитектуре будут реагировать (предпринимая действие для перехода в новое состояние) в зависимости от своего текущего состояния. Каждый переход определяет событие и действие.
- Системы / службы SV-10c Описание трассировки событий
- Обеспечивает упорядоченное по времени исследование элементов данных системы, которыми обмениваются участвующие системы (внешние и внутренние), системные функции или человеческие роли в результате определенного сценария. Каждая диаграмма отслеживания событий должна иметь сопроводительное описание, определяющее конкретный сценарий или ситуацию. SV-10c в обзоре систем и услуг может отражать системные аспекты или уточнения критических последовательностей событий, описанных в рабочем обзоре.
- Физическая схема SV-11
- Один из архитектурных продуктов, наиболее близких к реальному системному дизайну в Framework. Продукт определяет структуру различных видов системных данных, которые используются системами в архитектуре. (В DoDAF V1.5. Это соответствует DIV-3 в DoDAF V2.0.)
Просмотр технических стандартов
Продукты с обзором технических стандартов (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 архитектурные точки зрения состоят из данных, организованных для облегчения понимания. Для согласования со стандартами ISO, где это уместно, терминология была изменена с представлений на точку зрения (например, рабочее представление теперь является рабочей точкой зрения).
- Все точки обзора (AV)
- Описывает всеобъемлющие аспекты контекста архитектуры, относящиеся ко всем точкам зрения.
- Точка зрения возможностей (CV)
- Новое в DoDAF V2.0. Формулирует требования к возможностям, сроки доставки и развернутые возможности.
- Точка зрения данных и информации (DIV)
- Новое в DoDAF V2.0. Формулирует взаимосвязи данных и структуры согласования в содержимом архитектуры для возможностей и эксплуатационных требований, процессов системного проектирования, а также систем и сервисов.
- Оперативная точка зрения (OV)
- Включает рабочие сценарии, действия и требования, поддерживающие возможности.
- Точка зрения проекта (PV)
- Новое в DoDAF V2.0. Описывает отношения между эксплуатационными требованиями и требованиями к возможностям, а также различными реализуемыми проектами. Project Viewpoint также детализирует зависимости между возможностями и эксплуатационными требованиями, процессами системного проектирования, системным проектированием и проектированием сервисов в рамках процесса Defense Acquisition System.
- Точка зрения услуг (SvcV)
- Новое в DoDAF V2.0. Представляет дизайн решений, определяющих Исполнителей, Действия, Услуги и их Обмены, обеспечивающих или поддерживающих операционные и функциональные функции.
- Точка зрения стандартов (StdV)
- Переименован из представления технических стандартов. Формулирует применимые операционные, деловые, технические и отраслевые политики, стандарты, руководства, ограничения и прогнозы, которые относятся к возможностям и эксплуатационным требованиям, процессам системного проектирования, а также системам и услугам.
- Системная точка зрения (SV)
- Формулирует для унаследованной поддержки дизайн решений, описывающий системы, их состав, взаимосвязь и контекст, обеспечивающий или поддерживающий операционные и функциональные функции. Обратите внимание : в DoDAF V2.0 система была изменена по сравнению с DoDAF V1.5: система - это не просто компьютерное оборудование и компьютерное программное обеспечение. Система теперь определяется в общем смысле как совокупность компонентов - машины, человека - которые выполняют действия (поскольку они являются подтипами Performer) и взаимодействуют или взаимозависимы. Это может быть что угодно, то есть что угодно, от небольших единиц оборудования, которые имеют взаимодействующие или взаимозависимые элементы, до семейства систем (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 поддерживает концепции данных DoDAF V1.5, за одним заметным исключением: Node. Узел - это сложная логическая концепция, которая представлена более конкретными концепциями.
Все точки обзора (AV)
- Обзор AV-1 и сводная информация
- Описывает видение, цели, задачи, планы, мероприятия, события, условия, меры, эффекты (результаты) и созданные объекты проекта.
- Интегрированный словарь AV-2
- Хранилище архитектурных данных с определениями всех терминов, используемых повсюду.
Точка зрения возможностей (CV)
- CV-1 Видение
- Решает проблемы предприятия, связанные с общим видением трансформационных усилий, и, таким образом, определяет стратегический контекст для группы возможностей. Цель 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
- Описание потоков ресурсов, которыми обмениваются операционные действия.
- Матрица потока операционных ресурсов OV-3
- Описание ресурсов, которыми обмениваются, и соответствующих атрибутов обменов.
- Схема организационных отношений OV-4
- Организационный контекст, роль или другие отношения между организациями.
- OV-5a Дерево декомпозиции операционной деятельности
- Возможности и действия (операционные действия) организованы в иерархическую структуру.
- Модель операционной деятельности OV-5b
- Контекст возможностей и действий (операционные действия) и их отношения между действиями, входами и выходами; Дополнительные данные могут показать стоимость, исполнителей или другую уместную информацию.
- Модель операционных правил OV-6a
- Одна из трех моделей, используемых для описания деятельности (операционной деятельности). Он определяет бизнес-правила, ограничивающие операции.
- Описание перехода состояния OV-6b
- Одна из трех моделей, используемых для описания операционной деятельности (активности). Он определяет реакции бизнес-процессов (действий) на события (обычно очень короткие действия).
- OV-6c Описание трассировки событий
- Одна из трех моделей, используемых для описания деятельности (операционной деятельности). Он отслеживает действия в сценарии или последовательности событий.
Точка зрения проекта (PV)
- Взаимосвязь портфеля проектов PV-1
- Он описывает отношения зависимости между организациями и проектами, а также организационные структуры, необходимые для управления портфелем проектов.
- Сроки реализации проекта PV-2
- Временная шкала программ или проектов с ключевыми вехами и взаимозависимостями.
- PV-3 Project to Capability Mapping (Отображение возможностей проекта)
- Сопоставление программ и проектов с возможностями, чтобы показать, как конкретные проекты и элементы программы помогают реализовать возможности.
Точка зрения услуг (SvcV)
- Описание контекста служб SvcV-1
- Идентификация услуг, предметов обслуживания и их взаимосвязей.
- Описание потока ресурсов служб SvcV-2
- Описание потоков ресурсов, которыми обмениваются службы.
- Матрица систем-сервисов SvcV-3a
- Отношения между системами и сервисами в данном описании архитектуры.
- Матрица услуг-услуг SvcV-3b
- Отношения между сервисами в данном архитектурном описании. Он может быть спроектирован так, чтобы показывать интересующие взаимосвязи (например, интерфейсы сервисного типа, запланированные и существующие интерфейсы).
- Описание функций сервисов SvcV-4
- Функции, выполняемые службами, и служебные данные передаются между служебными функциями (действиями).
- Матрица операционной деятельности SvcV-5 для отслеживания услуг
- Сопоставление услуг (действий) с оперативной деятельностью (действиями).
- Матрица потоков ресурсов служб SvcV-6
- Он предоставляет подробную информацию об элементах потока ресурсов службы, которыми обмениваются службы, и атрибутах этого обмена.
- Матрица показателей услуг SvcV-7
- Меры (метрики) элементов модели услуг для соответствующего периода (ов).
- Описание эволюции сервисов SvcV-8
- Запланированные постепенные шаги по миграции набора сервисов в более эффективный комплект или к развитию текущих сервисов для будущей реализации.
- SvcV-9 Прогноз развития технологий и навыков в сфере услуг
- Новые технологии, программные / аппаратные продукты и навыки, которые, как ожидается, будут доступны в определенный период времени и которые повлияют на развитие услуг в будущем.
- Модель правил служб SvcV-10a
- Одна из трех моделей, используемых для описания функциональности услуги. Он определяет ограничения, налагаемые на функциональность системы из-за некоторых аспектов проектирования или реализации системы.
- Описание перехода между сервисами SvcV-10b
- Одна из трех моделей, используемых для описания функциональности услуги. Он определяет реакцию служб на события.
- Описание трассировки событий служб SvcV-10c
- Одна из трех моделей, используемых для описания функциональности услуги. Он определяет специфические для услуги уточнения критических последовательностей событий, описанных в Рабочей точке зрения.
Точка зрения стандартов (StdV)
- Профиль стандартов StdV-1
- Список стандартов, применяемых к элементам решения. В DoDAF V1.5 это был TV-1.
- Прогноз по стандартам StdV-2
- Описание появляющихся стандартов и потенциального воздействия на текущие элементы решения в течение определенного периода времени. В DoDAF V1.5 это был ТВ-2.
Системная точка зрения (SV)
- Описание интерфейса системы SV-1
- Идентификация систем, системных элементов и их взаимосвязей.
- Описание потока ресурсов системы SV-2
- Описание потоков ресурсов, которыми обмениваются системы.
- Матрица систем-систем SV-3
- Отношения между системами в данном архитектурном описании. Он может быть спроектирован так, чтобы показывать интересующие взаимосвязи (например, интерфейсы системного типа, запланированные и существующие интерфейсы).
- Описание функций систем SV-4
- Функции (действия), выполняемые системами, и системные потоки данных между функциями (действиями) системы.
- SV-5a Операционная деятельность по матрице прослеживаемости функций системы
- Отображение системных функций (действий) обратно в операционные действия (действия).
- SV-5b Операционная деятельность по матрице прослеживаемости систем
- Сопоставление систем с возможностями или оперативной деятельностью (действиями).
- Матрица потоков ресурсов систем SV-6
- Предоставляет подробную информацию об элементах потока системных ресурсов, которыми обмениваются системы, и об атрибутах этого обмена.
- Матрица показателей систем SV-7
- Меры (метрики) элементов модели системы для соответствующего периода (ов).
- Описание эволюции систем SV-8
- Запланированные дополнительные шаги к миграции набора систем на более эффективный пакет или к развитию существующей системы для будущей реализации.
- Прогноз развития технологий и навыков систем SV-9
- Новые технологии, программные / аппаратные продукты и навыки, которые, как ожидается, будут доступны в определенный период времени и которые повлияют на развитие системы в будущем.
- Модель правил системы SV-10a
- Одна из трех моделей, используемых для описания функциональности системы. Он определяет ограничения, налагаемые на функциональность системы из-за некоторых аспектов проектирования или реализации системы.
- Описание перехода между состояниями системы SV-10b
- Одна из трех моделей, используемых для описания функциональности системы. Он определяет реакцию систем на события.
- Описание трассировки событий систем SV-10c
- Одна из трех моделей, используемых для описания функциональности системы. Он определяет специфичные для системы уточнения критических последовательностей событий, описанных в Рабочей точке зрения.
Создание интегрированной архитектуры с использованием DoDAF
В Руководстве архитектора DODAF 2.0 [14] в инструкции 4630.8 Министерства обороны США повторяется определение интегрированной архитектуры как «архитектуры, состоящей из нескольких представлений, облегчающих интеграцию и способствующих взаимодействию между возможностями и между интегрированными архитектурами. Для целей разработки архитектуры термин интегрированный означает, что данные требуемые более чем в одной из архитектурных моделей, обычно определяется и понимается в этих моделях. Интегрированные архитектуры являются свойством или принципом проектирования для архитектур на всех уровнях: возможности, компоненты, решения и предприятия (в контексте архитектуры DoD Enterprise ( EA) является федерацией архитектур). Проще говоря, интеграция рассматривается в соединении элементов, общих для архитектурных продуктов, где элементы, показанные в одном архитектурном продукте (например, используемые сайты или сопряженные системы или предоставляемые услуги), должны иметь идентичный номер, имя и значение появляются в связанных архитектурных продуктах t просмотров. "
Существует множество различных подходов к созданию интегрированной архитектуры с использованием 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 или ISO / IEC 42010 . Но для построения описания архитектуры, соответствующего ANSI / IEEE 1471-2000 или ISO / IEC 42010, необходимо четко определить заинтересованные стороны и их проблемы, которые соответствуют каждому выбранному продукту DoDAF. В противном случае существует риск производства продукции без клиентов.
На рисунке «Матрица продуктов DoDAF V1.5» показано, как председатель Объединенного комитета начальников штабов Министерства обороны (CJCSI) 6212.01E указывает, какие продукты DoDAF V1.5 требуются для каждого типа анализа в контексте Net-Ready. Ключевой показатель эффективности (НР-КПП):
- Документ о начальных возможностях (ICD). Документирует необходимость материального решения для конкретного пробела в возможностях, полученного на основе первоначального анализа альтернатив, выполненного операционным пользователем, и, при необходимости, независимого анализа альтернатив. Он определяет разрыв в возможностях с точки зрения функциональной области, соответствующего диапазона военных операций, желаемых эффектов и времени.
- Документ о развитии возможностей (CDD). Документ, содержащий информацию, необходимую для разработки предлагаемой программы (программ), обычно с использованием эволюционной стратегии приобретения. CDD описывает доступное приращение полезного в военном отношении, материально поддерживаемого и технически зрелого потенциала.
- Документ по производству возможностей (CPD). Документ, в котором рассматриваются производственные элементы, относящиеся к отдельному этапу программы приобретения.
- План информационной поддержки (ISP). [16] Идентификация и документирование информационных потребностей, поддержки инфраструктуры, требований и зависимостей интерфейсов ИТ и NSS с упором на сетецентричность, функциональную совместимость, поддержку и достаточность (DODI 4630.8). [17]
- Индивидуальный план информационной поддержки (TISP). Цель процесса TISP - предоставить динамичный и эффективный инструмент для определенных программ (ACAT II и ниже) для выработки требований, необходимых для сертификации I&S. Некоторые руководители программ могут запросить адаптацию содержания своего интернет-провайдера (см. Ss). Для программ, не обозначенных как особый интерес OSD со стороны ASD (NII) / DOD CIO, компонент примет окончательное решение по деталям индивидуального плана с учетом минимумов, указанных в процедурах TISP, указанных на странице ресурсов CJCSI 6212, и любых особых потребностей, определенных J-6 для процесса сертификации I&S.
Представление
Представления для продуктов DoDAF могут быть получены с помощью многих методов построения диаграмм, включая:
- столы
- IDEF
- Диаграммы сущностей-отношений (ERD)
- UML
- SysML
Существует UPDM (Единый профиль для DoDAF и MODAF) усилия в рамках OMG стандартизировать представление продуктов DODAF когда UML используется.
DoDAF в общем описывает представление артефактов, которые должны быть сгенерированы, но обеспечивает значительную гибкость в отношении конкретных форматов и методов моделирования. В настольной книге DoDAF приведены примеры использования традиционных методов системной инженерии и инженерии данных , а также, во-вторых, формата UML. [18] DoDAF провозглашает широту формата рабочего продукта, не отдавая предпочтение одной технике построения диаграмм над другой.
Помимо графического представления, обычно требуется предоставить метаданные в репозиторий портфеля оборонных информационных технологий (DITPR) или другие архитектурные репозитории.
Мета-модель
DoDAF имеет метамодель, лежащую в основе структуры, определяющую типы элементов моделирования, которые могут использоваться в каждом представлении, и отношения между ними. В версиях DoDAF от 1.0 до 1.5 использовалась метамодель CADM , которая была определена в IDEF1X (затем позже в UML) с XML-схемой, полученной из полученной реляционной базы данных. Начиная с версии 2.0, DoDAF принял онтологию фонда IDEAS Group в качестве основы для своей новой метамодели. Эта новая метамодель называется DM2; аббревиатура от «Мета-модель DoDAF». Каждый из этих трех уровней DM2 важен для конкретного наблюдателя процессов департамента:
- Концептуальный уровень или концептуальная модель данных (CDM) определяет высокоуровневые конструкции данных, из которых создаются описания архитектуры в нетехнических терминах, так что руководители и менеджеры на всех уровнях могут понимать основу данных архитектурного описания. Представлен в DoDAF V2.0 DIV-1 Viewpoint.
- Логическая модель данных (LDM) добавляет в CDM техническую информацию, такую как атрибуты, и, при необходимости, уточняет отношения в однозначном определении использования. Представлен в DoDAF V2.0 DIV-2 Viewpoint.
- Спецификация физического обмена (PES) состоит из LDM с указанными общими типами данных и добавленными атрибутами реализации (например, источник, дата), которые затем генерируются как XSD. Представлен в DoDAF V2.0 DIV-3 Viewpoint. [6]
Цели DM2:
- Создание и определение ограниченного словаря для описания и обсуждения моделей DoDAF (ранее «продукты») и их использования в 6 основных процессах.
- Укажите семантику и формат для объединенного обмена данными EA между: инструментами разработки и анализа архитектуры и базами данных архитектуры в рамках сообщества интересов (COI) DoD Enterprise Architecture (EA) и с другими авторитетными источниками данных
- Поддержка открытия и понимания данных EA:
- Обнаружение данных EA с использованием категорий информации DM2
- Понятность данных EA с использованием точной семантики DM2, дополненной лингвистической прослеживаемостью (псевдонимами)
- Обеспечивает основу для семантической точности в архитектурных описаниях для поддержки интеграции и анализа разнородных архитектурных описаний в поддержку принятия решений основного процесса. [6]
DM2 определяет элементы данных архитектуры и обеспечивает интеграцию и объединение описаний архитектуры. Он устанавливает основу для семантической (т. Е. Понимания) согласованности внутри и между описаниями архитектуры. Таким образом, DM2 поддерживает обмен и повторное использование архитектурной информации между JCA, компонентами, а также федеральными партнерами и партнерами по коалиции, тем самым облегчая понимание и реализацию функциональной совместимости процессов и систем. По мере того, как DM2 созревает для удовлетворения текущих требований к данным владельцев процессов, лиц, принимающих решения, архитекторов, и новых технологий, он превратится в ресурс, который более полно поддерживает требования к архитектурным данным, публикуется в понятной форме и обеспечивает более широкие возможности. простота обнаружения, совместного использования и повторного использования архитектурных данных вне границ организации. [6]
Чтобы облегчить использование информации на уровне данных, DoDAF описывает набор моделей для визуализации данных с помощью графических, табличных или текстовых средств. Эти представления относятся к требованиям заинтересованных сторон для создания описания архитектуры. [6]
Связь с другими архитектурными фреймворками
UPDM (Единый профиль для DoDAF и MODAF ) является инициативой OMG по стандартизации UML и SysML использования для США и Великобритании рамок оборонной архитектуры. Кроме того, многонациональная группа IDEAS , которую поддерживают Австралия, Канада, Швеция, Великобритания, США и наблюдатели из НАТО , выступила с инициативой по разработке формальной онтологии для корпоративных архитектур.
Смотрите также
- Федеральная структура архитектуры предприятия (FEAF)
- IDEAS Group
- IUID
- Мета-модель MODAF
- NCOW
Рекомендации
- ^ a b c d e f g h DoD (2007) DoD Architecture Framework, версия 1.5 . 23 апреля 2007 г.
- ^ DoD (2009) DoD Architecture Framework, версия 2.0 . 28 мая 2009 г.
- ^ (ссылка: Zachman Framework )
- ^ "Часто задаваемые вопросы о структуре архитектуры" . Проверено 7 августа 2007 .
- ^ «ЗАКБМ 3170.01С ЭКСПЛУАТАЦИЯ СИСТЕМЫ ИНТЕГРАЦИИ И РАЗВИТИЯ ОБЪЕДИНЕННЫХ ВОЗМОЖНОСТЕЙ» . 1 мая 2007 г. обязательные приложения для ICD, CDD и CPD, например pg EA-5 "Обязательный: OV-1"
- ^ а б в г д е «Мета-модель DoDAF (DM2)» .
- ^ DoD CIO Memo Высвобождение DoDAF 2,0
- ^ «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, том 2, май 2009 г.» (PDF) .
- ^ Матрица продуктов DoDAF V1.5
- ^ «План информационной поддержки (запись DAU ACQuipedia)» .
- ^ «Руководство по архитектуре E4.A2 ISP» (PDF) , Процедуры взаимодействия и поддержки информационных технологий (ИТ) и систем национальной безопасности (NSS) , 2004 г., стр. 83
- ^ «Архивная копия» . Архивировано из оригинала на 2007-09-27 . Проверено 5 августа 2007 .CS1 maint: заархивированная копия как заголовок ( ссылка )
дальнейшее чтение
- Деннис Э. Вишноски и Джозеф Фогель. Dodaf Wizdom: Практическое руководство по планированию, управлению и выполнению проектов по созданию корпоративных архитектур с использованием структуры архитектуры Министерства обороны . Wizdom Systems, Inc., 2004 г. ISBN 1-893990-09-5 .
- Д-р Стивен Х. Дам (2015). DoD Architecture Framework 2.0: Руководство по применению системной инженерии для разработки интегрированных исполняемых архитектур . Независимая издательская платформа CreateSpace, 2015. ISBN 1-502757-62-1 .
Внешние ссылки
- Домашняя страница DoDAF в DoD CIO
- DODAF 2.02 pdf, август 2010 г.
- Том (Том) I: Обзор и концепции - Руководство для менеджера
- Том II: Архитектурные данные и модели - Руководство архитектора
- Том III: Основа метамодели онтологии и спецификация физического обмена - Руководство разработчика
- Том IV: Журнал - Лучшие практики
- DoDAF v1.5, 23 апреля 2007 г.
- Том I: Определения и рекомендации pdf
- Том II: Описание продукции pdf
- Том III: Описание данных об архитектуре pdf
- DoDAF V1, 9 февраля 2004 г.
- Настольная книга
- Том I: Определения и рекомендации
- Раздел DoDAF форума Architecture Framework Информационный ресурс, посвященный DoDAF в части, касающейся других архитектурных структур
- Архитектура бизнес-предприятия DoD CMO (BEA)
- Руководство по архитектуре DoD BEA 10.0
- Две презентации DoDAF 2.0 с конференций Integrated EA Conferences 2008 и 2009 гг.
- Архитектура информационного предприятия Министерства обороны
- Реестр метаданных
- CJCSI 6212.01 серии
- Документ CJCSI 6212.01F
- Архитектурная структура Европейского космического агентства (ESAAF) - основа для европейских космических систем систем [1]