Эта Архитектурная Структура особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия, и она, по-видимому, уникальна в использовании «операционных представлений». Эти представления предлагают обзор и детали, направленные на конкретных заинтересованных лиц в их области и во взаимодействии с другими областями, в которых будет работать система. [3]
Обзор
DoDAF обеспечивает основополагающую структуру для разработки и представления описаний архитектуры, которые обеспечивают общий знаменатель для понимания, сравнения и интеграции архитектур в организационных, совместных и многонациональных границах. Он устанавливает определения элементов данных, правила и отношения, а также базовый набор продуктов для последовательной разработки систем, интегрированных или федеративных архитектур. Эти описания архитектуры могут включать семейства систем (FoS), системы систем (SoS) и сетецентрические возможности для взаимодействия и взаимодействия в небоевой среде. [1]
Ожидается, что компоненты DoD будут соответствовать DoDAF в максимально возможной степени при разработке архитектур в рамках департамента. Соответствие гарантирует, что повторное использование информации, архитектурных артефактов, моделей и точек зрения может быть совместно использовано с общим пониманием. Все основные закупки вооружений и информационных технологий для Министерства обороны США должны разрабатывать и документировать архитектуру предприятия (EA) с использованием представлений, предписанных в DoDAF. Хотя DoDAF явно нацелен на военные системы, он имеет широкую применимость в частном, государственном и добровольном секторах по всему миру и представляет собой одну из большого числа структур архитектуры систем . [4] [5]
Целью DoDAF является определение концепций и моделей, которые можно использовать в шести основных процессах DoD: [6]
Интеграция и развитие совместных возможностей (JCIDS)
Планирование, программирование, бюджетирование и исполнение (PPBE)
Система оборонных закупок (DAS)
Системная инженерия (СИ)
Оперативное планирование (OPLAN)
Управление портфелем возможностей (CPM)
Кроме того, конкретными целями DoDAF 2.0 были: [6]
Установить руководство по содержанию архитектуры как функции цели – «соответствие цели»
Повысьте полезность и эффективность архитектур с помощью строгой модели данных — метамодели DoDAF (DM2), — чтобы архитектуры можно было интегрировать, анализировать и оценивать с большей точностью.
История
Эволюция DoDAF с 1990-х годов. DoDAF V2.0 был выпущен в мае 2009 года. [1]
Первая версия разработки 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, чтобы предложить руководство, описания продуктов и дополнительную информацию в двух томах и Desk Book. Он расширил применимость принципов и практик архитектуры ко всем областям миссии, а не только к сообществу C4ISR. Этот документ рассматривал использование, интегрированные архитектуры, политику DoD и федеральную политику, ценность архитектур, меры архитектуры, процессы поддержки принятия решений DoD, методы разработки, аналитические методы и CADM v1.01, и перешел к подходу на основе репозитория, сделав акцент на элементах данных архитектуры, которые включают продукты архитектуры. [1] В феврале 2004 года была выпущена документация версии 1.0 с томами «I: Определения и руководящие принципы», «II: Описания продуктов» и «Deskbook». В апреле 2007 года была выпущена версия 1.5 с документацией «Определения и руководящие принципы», «Описания продуктов» и «Описание данных архитектуры». В этот период были дополнительно разработаны концепции и термины, которые с тех пор были заменены другими подходами. Например, Mission Needs Statement (MNS) был типом документа Министерства обороны США , который определял потребности в возможностях для программы, которые должны были быть удовлетворены комбинацией решений ( DOTMLPF ) для устранения недостатков миссии или повышения эксплуатационных возможностей. Этот тип документа был заменен описанием потребностей в возможностях, называемым Initial Capabilities Document, начиная с CJCSI 3170.01E. CJCSI 3170.01 и 6212.01 были заменены серией CJCSI 5123.01.
Этот термин был введен в качестве основополагающего шага в CJCSI 3170.01B (апрель 2001 г.), 6212.01D (апрель 2005 г.) и Временном руководстве по оборонным закупкам (октябрь 2004 г.).
28 мая 2009 года DoDAF v2.0 был одобрен Министерством обороны. [7] Текущая версия — DoDAF 2.02. [8]
DoDAF V2.0 опубликован на общедоступном веб-сайте. [9]
Другие производные фреймворки, основанные на DoDAF, включают NATO Architecture Framework (NAF) и Ministry of Defense Architecture Framework . Как и другие подходы EA, например, Open Group Architecture Framework (TOGAF), DoDAF организован вокруг общего репозитория для хранения рабочих продуктов. Репозиторий определяется общей схемой базы данных Core Architecture Data Model 2.0 и DoD Architecture Registry System (DARS). Ключевой особенностью DoDAF является совместимость, которая организована в виде ряда уровней, называемых уровнями совместимости информационных систем (LISI). Разрабатываемая система должна удовлетворять не только своим внутренним потребностям в данных, но и потребностям операционной структуры, в которую она установлена.
Возможности и миссия
На схеме показано, как акцентируются возможности, связанные с миссией/курсом действий, потоками, видами деятельности и архитектурой.
Возможности, описанные с помощью архитектур
DoD перешел к фокусировке на предоставлении возможностей, которые являются причиной создания системы/услуги. Модели возможностей описывают таксономию возможностей и эволюцию возможностей. Поток возможностей будет соответствовать определенным действиям, правилам и системам, которые связаны с этой конкретной возможностью.
Концепция возможностей, как она определена Группой метамоделей данных, позволяет ответить на такие вопросы, как:
Каким образом конкретная возможность или возможности поддерживают общую миссию/видение?
Каких результатов можно ожидать от конкретной возможности или набора возможностей?
Какие услуги необходимы для поддержки возможности?
Каков функциональный объем и организационный охват возможности или набора возможностей?
Каков наш текущий набор возможностей, которыми мы управляем как частью портфеля?
[10]
Миссия или курс действий описываются концепцией операций (CONOPS) и организуются по возможностям.
Возможности описываются потоками.
Потоки описываются действиями, выполняемыми последовательно или параллельно.
Действия группируются в Области Миссии. Действия определяют операции для Архитектуры.
Архитектуры организованы по областям миссии. Архитектуры обеспечивают надлежащее ресурсное обеспечение возможностей, требуемых миссией или курсом действий.
Версия 1.5 просмотров
DoDAF V1.5 Связи между представлениями. [1]Структура C4ISR Министерства обороны США
DoDAF V1.5 определяет набор продуктов, модель представления , которые действуют как механизмы для визуализации, понимания и усвоения широкого охвата и сложности описания архитектуры посредством графических, табличных или текстовых средств. Эти продукты организованы в четыре представления:
Каждое представление отображает определенные перспективы архитектуры, как описано ниже. Обычно для каждой разработки системы создается только подмножество полного представления DoDAF. На рисунке представлена информация, которая связывает операционное представление, представление систем и служб и представление технических стандартов. Три представления и их взаимосвязи — обусловленные общими элементами данных архитектуры — обеспечивают основу для выведения мер, таких как совместимость или производительность, а также для измерения влияния значений этих метрик на операционную миссию и эффективность задач. [1]
Все просмотры
Все продукты View (AV) предоставляют всеобъемлющие описания всей архитектуры и определяют область действия и контекст архитектуры. Продукты DoDAF V1.5 AV определяются как:
Определения всех терминов, используемых во всех продуктах.
Оперативный вид
Продукты 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
Документация требований к данным и структурных правил бизнес-процессов операционного представления. (В 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-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. Матрицы отслеживания операционной деятельности в системах и услугах.
Operational Activity to SV-5a and SV-5b — это спецификация взаимосвязей между набором операционных действий, применимых к архитектуре, и набором системных функций, применимых к этой архитектуре. SV-5 и расширение SV-5 из DoDAF v1.0 обозначены как «SV-5a» и «SV-5b» в DoDAF v1.5 соответственно.
Матрица обмена данными систем/услуг SV-6
Определяет характеристики системных данных, которыми обмениваются системы. Этот продукт фокусируется на автоматизированном обмене информацией (из OV-3), который реализован в системах. Неавтоматизированный обмен информацией, такой как устные приказы, фиксируется только в продуктах OV.
Определяет количественные характеристики систем и элементов системного оборудования/программного обеспечения, их интерфейсов (системные данные, переносимые интерфейсом, а также детали коммуникационных линий, реализующих интерфейс) и их функций. Он определяет текущие параметры производительности каждой системы, интерфейса или системной функции, а также ожидаемые или требуемые параметры производительности в указанные моменты времени в будущем. Параметры производительности включают все технические характеристики производительности систем, для которых могут быть разработаны требования и определена спецификация. Полный набор параметров производительности может быть неизвестен на ранних этапах определения архитектуры, поэтому следует ожидать, что этот продукт будет обновляться на протяжении спецификации системы, проектирования, разработки, тестирования и, возможно, даже на этапах ее развертывания и эксплуатации.
Описание эволюции систем/услуг 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.)
Технические стандарты вид
Технические стандарты view (TV) продукты определяют технические стандарты, соглашения о реализации, бизнес-правила и критерии, которые управляют архитектурой. DoDAF V1.5 TV продукты следующие:
Профиль технических стандартов 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. [11]Эволюция представлений DoDAF V1.5 к точкам зрения DoDAF V2.0. [12]Сопоставление представлений DoDAF V1.5 с точками представления DoDAF V2.0. [13]
В DoDAF V2.0 архитектурные точки зрения состоят из данных, которые были организованы для облегчения понимания. Для соответствия стандартам ISO, где это уместно, терминология была изменена с Views на Viewpoint (например, Operational View теперь называется Operational Viewpoint).
Все точки обзора (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: система — это не просто компьютерное оборудование и компьютерное программное обеспечение. Теперь система определяется в общем смысле как совокупность компонентов — машины, человека, — которые выполняют действия (поскольку они являются подтипами исполнителя) и взаимодействуют или взаимозависимы. Это может быть что угодно, то есть что угодно, от небольших единиц оборудования, которые имеют взаимодействующие или взаимозависимые элементы, до семейства систем (FoS) и системы систем (SoS). Обратите внимание, что системы состоят из материалов (например, оборудования, самолетов и судов) и типов персонала.
Архитектуры для DoDAF V1.0 и DoDAF V1.5 могут продолжать использоваться. При необходимости (обычно указанной политикой или лицом, принимающим решения), архитектуры DoDAF V1.0 и V1.5 должны будут обновить свою архитектуру. Когда архитектура до DoDAF V2.0 сравнивается с архитектурой DoDAF V2.0, различия в концепциях (такие как Node) должны быть определены или объяснены для более новой архитектуры. Что касается продуктов DoDAF V1.5, они были преобразованы в части моделей DoDAF V2.0. В большинстве случаев метамодель DoDAF V2.0 поддерживает концепции данных DoDAF V1.5, за одним заметным исключением: Node. 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 для картирования возможностей
Сопоставление программ и проектов с возможностями, показывающее, как конкретные проекты и элементы программ помогают достичь возможности.
Точка зрения услуг (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
Одна из трех моделей, используемых для описания функциональности сервиса. Она определяет специфичные для сервиса уточнения критических последовательностей событий, описанных в Operational Viewpoint.
Стандарты точки зрения (StdV)
Профиль стандартов StdV-1
Перечень стандартов, которые применяются к элементам решения. В DoDAF V1.5 это был TV-1.
Прогноз стандартов StdV-2
Описание появляющихся стандартов и потенциального влияния на элементы текущего решения в рамках набора временных рамок. В DoDAF V1.5 это был TV-2.
Системная точка зрения (SV)
Описание интерфейса систем SV-1
Идентификация систем, элементов системы и их взаимосвязей.
Описание потока ресурсов систем SV-2
Описание потоков ресурсов, которыми обмениваются системы.
Матрица систем SV-3
Отношения между системами в данном архитектурном описании. Оно может быть разработано для отображения отношений, представляющих интерес (например, интерфейсы системного типа, планируемые и существующие интерфейсы).
Описание функциональности систем SV-4
Функции (действия), выполняемые системами, и потоки системных данных между системными функциями (действиями).
Матрица отслеживания операционной деятельности и системных функций SV-5a
Сопоставление системных функций (деятельности) с операционными действиями (мероприятиями).
Матрица отслеживания операционной деятельности систем SV-5b
Сопоставление систем с возможностями или операционными действиями (деятельностью).
Матрица потока ресурсов систем SV-6
Содержит подробную информацию об элементах потока системных ресурсов, которыми обмениваются системы, и атрибутах этого обмена.
Матрица измерений систем SV-7
Показатели (метрики) элементов системной модели для соответствующего временного интервала(ов).
Описание эволюции систем SV-8
Планируемые постепенные шаги по миграции набора систем на более эффективный набор или по развитию текущей системы для будущей реализации.
Прогноз развития технологий и навыков систем SV-9
Новые технологии, программные и аппаратные продукты, а также навыки, которые, как ожидается, появятся в течение определенного периода времени и которые повлияют на будущее развитие системы.
Модель правил систем SV-10a
Одна из трех моделей, используемых для описания функциональности системы. Она определяет ограничения, которые накладываются на функциональность системы из-за некоторых аспектов проектирования или реализации системы.
Описание перехода состояний систем SV-10b
Одна из трех моделей, используемых для описания функциональности системы. Она определяет реакции систем на события.
Описание событий-трассировки систем SV-10c
Одна из трех моделей, используемых для описания функциональности системы. Она определяет системно-специфические уточнения критических последовательностей событий, описанных в Operational Viewpoint.
Создание интегрированной архитектуры с использованием DoDAF
Иллюстрация интегрированной архитектуры. [1]
В руководстве архитекторов DODAF 2.0 [14] повторяется определение интегрированной архитектуры из инструкции DOD 4630.8 как «архитектуры, состоящей из нескольких представлений, облегчающих интеграцию и способствующих взаимодействию между возможностями и интегрированными архитектурами. В целях разработки архитектуры термин «интегрированное» означает, что данные, требуемые в более чем одной архитектурной модели, обычно определяются и понимаются в этих моделях. Интегрированные архитектуры являются свойством или принципом проектирования для архитектур на всех уровнях: Возможности, Компонента, Решения и Предприятия (в контексте Архитектуры предприятия (EA) DoD, являющейся федерацией [архитектур]). Проще говоря, интеграция рассматривается в связи элементов, общих для архитектурных продуктов, где элементы, показанные в одном архитектурном продукте (например, используемые сайты или взаимодействующие системы или предоставляемые услуги), должны иметь идентичные номера, имена и значения, отображаемые в связанных представлениях архитектурного продукта».
Существует множество различных подходов к созданию интегрированной архитектуры с использованием 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 [15]
На рисунке «Матрица продуктов DoDAF V1.5» показано, как в инструкции председателя Объединенного комитета начальников штабов (CJCSI) Министерства обороны США (DoD) 6212.01E указано, какие продукты DoDAF V1.5 требуются для каждого типа анализа в контексте ключевого параметра производительности Net-Ready (NR-KPP):
Документ о начальных возможностях (ICD). Документирует потребность в материальном решении для определенного разрыва в возможностях, полученного из начального анализа альтернатив, выполненного оперативным пользователем, и, при необходимости, независимого анализа альтернатив. Он определяет разрыв в возможностях с точки зрения функциональной области, соответствующего диапазона военных операций, желаемых эффектов и времени.
Документ по развитию возможностей (CDD). Документ, который фиксирует информацию, необходимую для разработки предлагаемой программы (программ), обычно с использованием эволюционной стратегии приобретения. CDD описывает доступное увеличение военно-полезных, логистически поддерживаемых и технически зрелых возможностей.
Документ о возможностях производства (CPD). Документ, в котором рассматриваются элементы производства, характерные для отдельного этапа программы приобретения.
План информационной поддержки (ISP). [16] Определение и документирование информационных потребностей, поддержки инфраструктуры, требований к интерфейсам ИТ и NSS и зависимостей с упором на сетецентричность, совместимость, поддерживаемость и достаточность (DODI 4630.8). [17]
План поддержки индивидуальной информации (TISP). Цель процесса TISP — предоставить динамичный и эффективный инструмент для определенных программ (ACAT II и ниже) для разработки требований, необходимых для сертификации I&S. Отдельные менеджеры программ могут запросить адаптацию содержания своего ISP (ref ss). Для программ, не обозначенных как особый интерес OSD ASD (NII) /DOD CIO, компонент примет окончательное решение о деталях индивидуального плана с учетом минимальных требований, указанных в процедурах TISP, связанных со страницей ресурсов CJCSI 6212, и любых особых потребностей, определенных J-6 для процесса сертификации I&S.
Представление
Представления для продуктов DoDAF могут быть получены с помощью многих методов построения диаграмм, включая:
В рамках OMG ведется работа по созданию UPDM (унифицированного профиля для DoDAF и MODAF) для стандартизации представления продуктов DoDAF при использовании UML.
DoDAF в общем описывает в представлении артефакты, которые должны быть созданы, но допускает значительную гибкость в отношении конкретных форматов и методов моделирования. DoDAF deskbook содержит примеры использования традиционных методов системной инженерии и инженерии данных , а во-вторых, формата UML. [18] DoDAF провозглашает широту формата рабочего продукта, не исповедуя одну технику диаграммирования над другой.
Помимо графического представления, обычно требуется предоставлять метаданные в Репозиторий портфеля оборонных информационных технологий (DITPR) или другие архитектурные репозитории.
Мета-модель
DoDAF имеет метамодель, лежащую в основе фреймворка, определяющую типы элементов моделирования, которые могут использоваться в каждом представлении, и отношения между ними. Версии DoDAF с 1.0 по 1.5 использовали метамодель CADM , которая была определена в IDEF1X (позже в UML) с XML-схемой , полученной из полученной реляционной базы данных. Начиная с версии 2.0, DoDAF принял фундаментальную онтологию IDEAS Group в качестве основы для своей новой метамодели. Эта новая метамодель называется «DM2»; аббревиатура от «DoDAF Meta-Model». Каждый из этих трех уровней 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) архитектуры предприятия (EA) Министерства обороны США и с другими авторитетными источниками данных.
Поддержка обнаружения и понимания данных EA:
Обнаружение данных EA с использованием категорий информации DM2
Понимание данных EA с использованием точной семантики DM2, дополненной лингвистической прослеживаемостью (псевдонимами)
Обеспечить основу для семантической точности в архитектурных описаниях для поддержки интеграции и анализа гетерогенных архитектурных описаний в поддержку принятия решений по основным процессам. [6]
DM2 определяет элементы архитектурных данных и обеспечивает интеграцию и объединение архитектурных описаний. Он устанавливает основу для семантической (т. е. понимания) согласованности внутри и между архитектурными описаниями. Таким образом, DM2 поддерживает обмен и повторное использование архитектурной информации среди JCA, компонентов, федеральных и коалиционных партнеров, тем самым облегчая понимание и реализацию взаимодействия процессов и систем. По мере того, как DM2 будет развиваться для удовлетворения текущих требований к данным владельцев процессов, лиц, принимающих решения, архитекторов и новых технологий, он будет развиваться в ресурс, который более полно поддерживает требования к архитектурным данным, опубликованным последовательно понятным способом, и обеспечит большую простоту обнаружения, совместного использования и повторного использования архитектурных данных в пределах организационных границ. [6]
Для облегчения использования информации на уровне данных DoDAF описывает набор моделей для визуализации данных с помощью графических, табличных или текстовых средств. Эти представления относятся к требованиям заинтересованных сторон для создания Архитектурного описания. [6]
Связь с другими архитектурными фреймворками
UPDM (Unified Profile for DoDAF and MODAF ) — это инициатива OMG по стандартизации использования UML и SysML для фреймворков оборонной архитектуры США и Великобритании. Кроме того, многонациональная группа IDEAS , которую поддерживают Австралия, Канада, Швеция, Великобритания, США и наблюдатели НАТО , запустила инициативу по разработке формальной онтологии для корпоративных архитектур.
^ "Часто задаваемые вопросы по архитектуре" . Получено 2007-08-07 .
^ "CJCSM 3170.01C ЭКСПЛУАТАЦИЯ СИСТЕМЫ ИНТЕГРАЦИИ И РАЗВИТИЯ ОБЪЕДИНЕННЫХ ВОЗМОЖНОСТЕЙ". 1 мая 2007 г.обязательные приложения для МКБ, CDD и CPD, например, стр. EA-5 «Обязательно: OV-1»
^ abcdef «Метамодель DoDAF (DM2)» .
^ Памятка директора по информационным технологиям Министерства обороны США о выпуске DoDAF 2.0
^ «DODAF - Архитектурная структура DOD версии 2.02 - Заместитель начальника службы информации DOD».
^ 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 Architecture Guidance" (PDF) , Процедуры взаимодействия и поддержки информационных технологий (ИТ) и систем национальной безопасности (NSS) , 2004, стр. 83
Деннис Э. Висноски и Джозеф Фогель. Dodaf Wizdom: практическое руководство по планированию, управлению и выполнению проектов по созданию корпоративных архитектур с использованием архитектурной структуры Министерства обороны . Wizdom Systems, Inc., 2004. ISBN 1-893990-09-5 .
Доктор Стивен Х. Дэм (2015). DoD Architecture Framework 2.0: Руководство по применению системной инженерии для разработки интегрированных исполняемых архитектур . CreateSpace Independent Publishing Platform, 2015. ISBN 1-502757-62-1 .
Внешние ссылки
На Викискладе есть медиафайлы по теме « Структура архитектуры Министерства обороны» .
