Эта архитектура архитектуры особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия и, по-видимому, уникальна в использовании «оперативных представлений». Эти представления предлагают обзор и подробную информацию, предназначенную для конкретных заинтересованных сторон в их области и во взаимодействии с другими областями, в которых будет работать система. [3]
Обзор
DoDAF обеспечивает основополагающую основу для разработки и представления описаний архитектуры, которые обеспечивают общий знаменатель для понимания, сравнения и интеграции архитектур за пределами организационных, совместных и многонациональных границ. Он устанавливает определения, правила и связи элементов данных, а также базовый набор продуктов для последовательной разработки систем, интегрированных или объединенных архитектур. Эти описания архитектуры могут включать семейства систем (FoS), системы систем (SoS) и сетецентрические возможности для взаимодействия и взаимодействия в небоевой среде. [1]
Ожидается, что компоненты DoD будут соответствовать DoDAF в максимально возможной степени при разработке архитектур внутри отдела. Соответствие гарантирует, что повторное использование информации, архитектурных артефактов, моделей и точек зрения может быть общим и понятным. Все крупные приобретения Министерства обороны США оружия и систем информационных технологий должны разрабатывать и документировать корпоративную архитектуру (EA) с использованием представлений, предписанных DoDAF. Хотя DoDAF явно нацелен на военные системы, он имеет широкое применение в частном, государственном и добровольном секторах по всему миру и представляет собой одну из большого количества структур системной архитектуры . [4] [5]
Целью DoDAF является определение концепций и моделей, которые можно использовать в шести основных процессах Министерства обороны: [6]
Интеграция и развитие совместных возможностей (JCIDS)
Планирование, программирование, составление бюджета и исполнение (PPBE)
Система оборонных закупок (DAS)
Системная инженерия (SE)
Оперативное планирование (ОПЛАН)
Управление портфелем возможностей (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 и теперь предлагает руководство, описания продуктов и дополнительную информацию в двух томах и настольной книге. Это расширило применимость принципов и практик архитектуры ко всем направлениям миссии, а не только к сообществу C4ISR. В этом документе рассматриваются использование, интегрированные архитектуры, политика Министерства обороны и федеральная политика, ценность архитектур, меры архитектуры, процессы поддержки принятия решений Министерства обороны, методы разработки, аналитические методы и CADM v1.01 , а также переход к подходу на основе репозитория, делая упор на элементы данных архитектуры, которые составляют архитектурные продукты. [1] В феврале 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 был одобрен Министерством обороны. [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 (DARS). Ключевой особенностью DoDAF является совместимость, которая организована в виде ряда уровней, называемых уровнями совместимости информационных систем (LISI). Разрабатываемая система должна удовлетворять не только свои внутренние потребности в данных, но и потребности операционной системы, в которой она установлена.
Возможности и миссия
На диаграмме изображен акцент на возможностях, связанный с миссией/курсом действий, потоками, действиями и архитектурой.
Возможности, описанные с помощью архитектур
Министерство обороны сосредоточило внимание на предоставлении возможностей, которые и являются причиной создания системы/услуги. Модели возможностей описывают таксономию возможностей и эволюцию возможностей. Поток возможностей будет соответствовать конкретным действиям, правилам и системам, которые связаны с этой конкретной возможностью.
Концепция возможностей, определенная в группе данных метамодели, позволяет ответить на такие вопросы, как:
Как конкретная способность или возможности поддерживают общую миссию/видение?
Каких результатов ожидается достичь с помощью конкретной способности или набора возможностей?
Какие услуги необходимы для поддержки возможности?
Каков функциональный объем и организационный объем возможности или набора возможностей?
Каков наш текущий набор возможностей, которыми мы управляем в рамках портфеля?
[10]
Миссия или курс действий описываются Концепцией операций (CONOPS) и организованы по возможностям.
Возможности описываются Threads.
Потоки описываются действиями, выполняемыми последовательно или параллельно.
Действия сгруппированы по направлениям миссии. Действия определяют операции для Архитектуры.
Архитектура организована по областям миссий. Архитектура обеспечивает надлежащее обеспечение возможностей, необходимых для миссии или курса действий.
Просмотры версии 1.5
DoDAF V1.5 Связи между представлениями. [1]Структура DoD C4ISR
DoDAF V1.5 определяет набор продуктов, модель представления , которые действуют как механизмы визуализации, понимания и усвоения широкого объема и сложности описания архитектуры с помощью графических, табличных или текстовых средств. Эти продукты организованы в четырех представлениях:
Каждый вид отображает определенные аспекты архитектуры, как описано ниже. Для каждой разработки системы обычно создается только подмножество полного набора представлений DoDAF. На рисунке представлена информация, которая связывает эксплуатационный взгляд, взгляд на системы и услуги и взгляд на технические стандарты. Три представления и их взаимосвязи, основанные на элементах данных общей архитектуры, обеспечивают основу для получения таких показателей, как совместимость или производительность, а также для измерения влияния значений этих показателей на эффективность оперативной миссии и задач. [1]
Все просмотреть
Все продукты представления (AV) предоставляют всеобъемлющие описания всей архитектуры и определяют объем и контекст архитектуры. AV-продукты DoDAF V1.5 определяются как:
Определения всех терминов, используемых во всех продуктах.
Операционный вид
Продукты Operational View (OV) предоставляют описания задач и действий, оперативных элементов и обмена информацией, необходимых для выполнения миссий Министерства обороны. OV обеспечивает текстовое и графическое представление рабочих узлов и элементов, назначенных задач и действий, а также информационных потоков между узлами. Он определяет тип обмениваемой информации, частоту обмена, задачи и действия, поддерживаемые этим обменом, а также характер обмена. Продукты DoDAF V1.5 OV определяются как:
Графическое изображение концепции высокого уровня эксплуатации OV-1
Графическое и текстовое описание высокого уровня оперативной концепции (организации высокого уровня, миссии, географическая конфигурация, возможности подключения и т. д.).
Описание подключения оперативного узла OV-2
Операционные узлы, действия, выполняемые на каждом узле, а также связи и потоки информации между узлами.
OV-3 Матрица обмена оперативной информацией
Информация, которой обмениваются узлы, и соответствующие атрибуты этого обмена, такие как носитель, качество, количество и требуемый уровень совместимости.
Схема организационных отношений OV-4
Командование, контроль, координация и другие взаимоотношения между организациями.
Модель оперативной деятельности ОВ-5
Действия, отношения между действиями, входами и выходами. Кроме того, наложения могут отображать стоимость, производительность узлов или другую соответствующую информацию.
Модель эксплуатационных правил OV-6a
Один из трех продуктов, используемых для описания последовательности и сроков операционной деятельности, который определяет бизнес-правила, ограничивающие операцию.
OV-6b Описание перехода в рабочее состояние
Один из трех продуктов, используемых для описания последовательности и сроков операционной деятельности, который определяет реакцию бизнес-процесса на события.
Описание трассировки эксплуатационных событий OV-6c
Один из трех продуктов, используемых для описания последовательности и сроков оперативной деятельности, который отслеживает действия в сценарии или критической последовательности событий.
Логическая модель данных OV-7
Документирование требований к данным и правил структурных бизнес-процессов Операционного представления. (В DoDAF V1.5. Это соответствует DIV-2 в DoDAF V2.0.)
Представление о системах и услугах
Представление систем и сервисов (SV) представляет собой набор графических и текстовых продуктов, описывающих системы, сервисы и взаимосвязи, обеспечивающие или поддерживающие функции Министерства обороны. Продукты 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 Матрицы прослеживаемости операционной деятельности к функциям систем, эксплуатационной деятельности к системам и услугам
Эксплуатационная деятельность для SV-5a и 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
Определяет базовые текущие и ожидаемые вспомогательные технологии, на которые были нацелены стандартные методы прогнозирования. Ожидаемые вспомогательные технологии – это те, которые можно разумно спрогнозировать с учетом текущего состояния технологий и ожидаемых улучшений. Новые технологии должны быть привязаны к конкретным периодам времени, которые могут коррелировать с периодами времени, используемыми в контрольных точках СВ-8.
Модель правил систем/услуг SV-10a
Описывает правила, согласно которым архитектура или ее системы ведут себя в заданных условиях.
Описание перехода состояний систем/служб SV-10b
Графический метод описания реакции системы (или функции системы) на различные события путем изменения ее состояния. Диаграмма в основном представляет наборы событий, на которые системы в архитектуре будут реагировать (выполняя действия по переходу в новое состояние) в зависимости от текущего состояния. Каждый переход определяет событие и действие.
Описание трассировки событий систем/служб SV-10c
Обеспечивает упорядоченное по времени исследование элементов системных данных, которыми обмениваются участвующие системы (внешние и внутренние), системные функции или роли людей в результате определенного сценария. Каждая диаграмма трассировки событий должна иметь сопроводительное описание, определяющее конкретный сценарий или ситуацию. SV-10c в представлении «Системы и услуги» может отражать специфичные для системы аспекты или уточнения критических последовательностей событий, описанных в операционном представлении.
Физическая схема СВ-11
Один из архитектурных продуктов, максимально приближенных к реальному проектированию системы в Framework. Продукт определяет структуру различных видов системных данных, которые используются системами в архитектуре. (В DoDAF V1.5. Это соответствует DIV-3 в DoDAF V2.0.)
Просмотр технических стандартов
Продукты представления технических стандартов (TV) определяют технические стандарты, соглашения о реализации, бизнес-правила и критерии, которые управляют архитектурой. Телевизионные продукты DoDAF V1.5 следующие:
Профиль технических стандартов StdV-1 — извлечение стандартов, применимых к данной архитектуре. (В DoDAF V1.5. В DoDAF V2.0 переименован в StdV-1.)
Прогноз технических стандартов StdV-2 — описание новых стандартов, которые, как ожидается, будут применяться к данной архитектуре в течение соответствующего набора сроков. (В DoDAF V1.5. В DoDAF V2.0 переименован в StdV-2.)
Точки зрения версии 2.0
Схема точек зрения DoDAF V2.0. [11]Эволюция представлений DoDAF V1.5 к точкам зрения DoDAF V2.0. [12]Сопоставление представлений DoDAF V1.5 с точками обзора DoDAF V2.0. [13]
В DoDAF V2.0 архитектурные точки зрения состоят из данных, организованных для облегчения понимания. Для приведения в соответствие со стандартами ISO, где это необходимо, терминология была изменена с «Представлений» на «Точку зрения» (например, «Оперативный вид» теперь является «Оперативной точкой зрения»).
Все точки обзора (AV)
Описывает всеобъемлющие аспекты контекста архитектуры, которые относятся ко всем точкам зрения.
Точка зрения на возможности (CV)
Новое в DoDAF V2.0. Формулирует требования к возможностям, сроки поставки и развернутые возможности.
Точка зрения данных и информации (DIV)
Новое в DoDAF V2.0. Описывает связи данных и структуры согласования в содержании архитектуры для возможностей и эксплуатационных требований, процессов системного проектирования, а также систем и услуг.
Оперативная точка зрения (OV)
Включает операционные сценарии, действия и требования, поддерживающие возможности.
Точка зрения проекта (PV)
Новое в DoDAF V2.0. Описывает взаимосвязь между эксплуатационными требованиями и требованиями к возможностям, а также различными реализуемыми проектами. «Точка зрения проекта» также подробно описывает зависимости между возможностями и эксплуатационными требованиями, процессами системного проектирования, проектированием систем и проектированием услуг в рамках процесса системы оборонных закупок.
Точка зрения служб (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. Узел — это сложное логическое понятие, которое представлено более конкретными понятиями.
Все точки обзора (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 это была СВ-11.
Обратите внимание, что в разделе «Логическая модель данных» обсуждается взаимосвязь этих трех моделей данных DIV со сравнением концептуальной, логической и физической моделей данных.
Оперативная точка зрения (OV)
Графическое изображение общей концепции эксплуатации OV-1
Высокоуровневое графическое/текстовое описание эксплуатационной концепции.
Описание потока эксплуатационных ресурсов OV-2
Описание потоков ресурсов, которыми обмениваются операционные виды деятельности.
Матрица потоков операционных ресурсов OV-3
Описание обмениваемых ресурсов и соответствующих атрибутов обмена.
Схема организационных отношений OV-4
Организационный контекст, роль или другие отношения между организациями.
OV-5a Дерево декомпозиции оперативной деятельности
Возможности и деятельность (оперативная деятельность) организованы в иерархическую структуру.
Модель оперативной деятельности ОВ-5б
Контекст возможностей и действий (оперативной деятельности) и их взаимосвязь между действиями, входами и выходами; Дополнительные данные могут показывать стоимость, исполнителей или другую соответствующую информацию.
Модель эксплуатационных правил OV-6a
Одна из трех моделей, используемых для описания деятельности (оперативной деятельности). Он определяет бизнес-правила, которые ограничивают операции.
Описание перехода состояний OV-6b
Одна из трех моделей, используемых для описания оперативной деятельности (деятельности). Он определяет реакцию бизнес-процесса (действия) на события (обычно очень короткие действия).
Описание трассировки событий OV-6c
Одна из трех моделей, используемых для описания деятельности (оперативной деятельности). Он отслеживает действия в сценарии или последовательности событий.
Точка зрения проекта (PV)
Взаимоотношения портфеля проектов PV-1
Он описывает отношения зависимости между организациями и проектами, а также организационные структуры, необходимые для управления портфелем проектов.
График реализации проекта ПВ-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
Одна из трех моделей, используемых для описания функциональности сервиса. Он определяет специфичные для услуги уточнения критических последовательностей событий, описанных в «Эксплуатационной точке зрения».
Точка зрения стандартов (StdV)
Профиль стандартов StdV-1
Список стандартов, применимых к элементам решения. В DoDAF V1.5 это был ТВ-1.
Прогноз стандартов StdV-2
Описание новых стандартов и потенциального влияния на текущие элементы решения в пределах установленных временных рамок. В DoDAF V1.5 это был ТВ-2.
Системная точка зрения (SV)
Описание интерфейса системы SV-1
Идентификация систем, системных элементов и их взаимосвязей.
Описание потока ресурсов системы SV-2
Описание потоков ресурсов, которыми обмениваются системы.
Матрица систем-систем СВ-3
Отношения между системами в данном архитектурном описании. Его можно спроектировать так, чтобы показать интересующие взаимосвязи (например, интерфейсы системного типа, запланированные и существующие интерфейсы).
Описание функциональных возможностей системы СВ-4
Функции (действия), выполняемые системами, и системные потоки данных между системными функциями (действиями).
Матрица отслеживания эксплуатационной деятельности СВ-5а по функциям систем
Отображение системных функций (действий) обратно в оперативные действия (деятельности).
Матрица прослеживаемости систем SV-5b от эксплуатационной деятельности
Сопоставление систем с возможностями или оперативной деятельностью (деятельностью).
Матрица потоков ресурсов системы SV-6
Предоставляет подробную информацию об элементах потока системных ресурсов, которыми обмениваются между системами, и атрибутах этого обмена.
Матрица мер системы СВ-7
Меры (метрики) элементов системной модели для соответствующего периода времени.
Описание эволюции систем СВ-8
Запланированные дополнительные шаги по переходу набора систем к более эффективному набору или по развитию текущей системы для будущей реализации.
Прогноз технологий и навыков систем SV-9
Новые технологии, программные/аппаратные продукты и навыки, которые, как ожидается, будут доступны в заданные сроки и которые повлияют на будущее развитие системы.
Модель правил системы СВ-10а
Одна из трех моделей, используемых для описания функциональности системы. Он определяет ограничения, которые накладываются на функциональность системы из-за некоторых аспектов проектирования или реализации системы.
Описание перехода состояния системы СВ-10б
Одна из трех моделей, используемых для описания функциональности системы. Он определяет реакцию систем на события.
Описание трассировки событий системы SV-10c
Одна из трех моделей, используемых для описания функциональности системы. Он определяет специфичные для системы уточнения критических последовательностей событий, описанных в «Эксплуатационной точке зрения».
Создание интегрированной архитектуры с использованием DoDAF
Иллюстрация интегрированной архитектуры. [1]
В Руководстве архитекторов DODAF 2.0 [14] повторяется определение интегрированной архитектуры, содержащееся в Инструкции Министерства обороны США 4630.8: «Архитектура, состоящая из нескольких представлений, облегчающих интеграцию и обеспечивающих взаимодействие между возможностями и интегрированными архитектурами. Для целей разработки архитектуры термин «интегрированный» означает, что данные Интегрированные архитектуры являются свойством или принципом проектирования для архитектур на всех уровнях: возможности, компоненты, решения и предприятия (в контексте архитектуры предприятия Министерства обороны США ( Проще говоря, интеграция рассматривается как соединение элементов, общих для архитектурных продуктов, где элементы, представленные в одном архитектурном продукте (например, используемые сайты или взаимодействующие системы или предоставляемые услуги), должны иметь идентичный номер, имя и значение отображаются в представлениях продуктов, связанных с архитектурой».
Существует множество различных подходов к созданию интегрированной архитектуры с использованием 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 или, по крайней мере, три представления можно рассматривать как точки зрения ANSI/IEEE 1471-2000 или ISO/IEC 42010 . Но чтобы построить описание архитектуры, соответствующее ANSI/IEEE 1471-2000 или ISO/IEC 42010, необходимо четко определить заинтересованные стороны и их проблемы, которые соответствуют каждому выбранному продукту DoDAF. В противном случае существует риск производства продукции без клиентов.
Матрица продуктов DoDAF V1.5 [15]
На рисунке «Матрица продуктов 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). Для программ, не обозначенных ASD (NII) / DOD CIO как особый интерес OSD, компонент примет окончательное решение по деталям индивидуального плана с учетом минимумов, указанных в процедурах TISP, ссылки на которые приведены на странице ресурсов CJCSI 6212, и любых особых потребностей, выявленных J-6 для процесса сертификации I&S.
Представление
Представления продуктов DoDAF могут быть созданы с помощью многих методов построения диаграмм, включая:
В OMG существует UPDM (унифицированный профиль для DoDAF и MODAF) по стандартизации представления продуктов 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 (ранее «продуктов») и их использования в шести основных процессах.
Укажите семантику и формат для обмена данными интегрированного EA между: инструментами разработки и анализа архитектуры и базами данных архитектуры в Сообществе интересов (COI) Министерства обороны США по архитектуре предприятия (EA) и с другими авторитетными источниками данных.
Поддержка обнаружения и понимания данных EA:
Обнаружение данных EA с использованием категорий информации DM2.
Понятность данных EA с использованием точной семантики DM2, дополненной лингвистической прослеживаемостью (псевдонимами).
Обеспечьте основу для семантической точности в архитектурных описаниях для поддержки интеграции и анализа разнородных архитектурных описаний в поддержку принятия решений по основному процессу. [6]
DM2 определяет элементы архитектурных данных и обеспечивает интеграцию и объединение архитектурных описаний. Он устанавливает основу для семантической (т.е. понимания) согласованности внутри и между архитектурными описаниями. Таким образом, DM2 поддерживает обмен и повторное использование архитектурной информации между JCA, компонентами, федеральными и коалиционными партнерами, тем самым способствуя пониманию и реализации функциональной совместимости процессов и систем. По мере развития DM2 для удовлетворения текущих требований к данным владельцев процессов, лиц, принимающих решения, архитекторов и новых технологий, он превратится в ресурс, который более полно поддерживает требования к архитектурным данным, публикуется в последовательно понятной форме и позволяет добиться большего. простота обнаружения, обмена и повторного использования архитектурных данных за пределами организации. [6]
Чтобы облегчить использование информации на уровне данных, DoDAF описывает набор моделей для визуализации данных с помощью графических, табличных или текстовых средств. Эти мнения относятся к требованиям заинтересованных сторон для создания архитектурного описания. [6]
Связь с другими архитектурными средами
UPDM ( унифицированный профиль для DoDAF и MODAF ) — это инициатива OMG по стандартизации использования UML и SysML для структур оборонной архитектуры США и Великобритании. Кроме того, многонациональная группа IDEAS , которую поддерживают Австралия, Канада, Швеция, Великобритания, США и наблюдатели НАТО , выступила с инициативой по разработке формальной онтологии для корпоративных архитектур.
^ «Часто задаваемые вопросы по архитектуре Framework» . Проверено 7 августа 2007 г.
^ «CJCSM 3170.01C РАБОТА СИСТЕМЫ ИНТЕГРАЦИИ И РАЗВИТИЯ ОБЪЕДИНЕННЫХ ВОЗМОЖНОСТЕЙ» . 1 мая 2007 г.обязательные приложения для МКБ, CDD и CPD, например, стр. EA-5 «Обязательно: OV-1»
^ abcdef «Метамодель DoDAF (DM2)» .
^ Памятка директора по информационным технологиям Министерства обороны США о выпуске DoDAF 2.0
^ «DODAF - Структура архитектуры DOD, версия 2.02 - Заместитель директора по информационным технологиям Министерства обороны» .
^ Веб-сайт ИТ-директора 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
^ «Архивная копия». Архивировано из оригинала 27 сентября 2007 г. Проверено 5 августа 2007 г.{{cite web}}: 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 .
Внешние ссылки
На Wikimedia Commons есть медиафайлы, связанные с архитектурой Министерства обороны США .
