TRAK - TRAK

Структура TRAK - сформирована из 1 метамодели, 5 архитектурных точек зрения и 24 архитектурных точек зрения.

TRAK генерал структура архитектуры предприятия ориентирована на системных инженеров на основе MODAF 1.2.

История

TRAK был первоначально заказан London Underground Limited.[1][2] Разработка началась в 2009 году и основывалась на текущих представлениях об архитектурном описании лондонского метрополитена, которые основывались на ISO / IEC 42010 и были привязаны к системная инженерия жизненный цикл, определенный в ISO / IEC 15288 .

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

TRAK был выпущен под лицензиями с открытым исходным кодом в феврале 2010 г.

Он был официально принят Министерство транспорта Великобритании который возглавляет Руководящую группу TRAK, которая управляет общим направлением, стратегией и официальными выпусками TRAK.

Команда разработчиков ТРАК получила награду Рабочей группы.[3] (фото на INCOSE Страница транспортной рабочей группы [4]). TRAK стал финалистом конкурса IET Innovation Awards 2011.[5]

Терминология

Кортеж описания архитектуры
Элемент описания архитектуры с именованным типом, который имеет именованную связь либо с тем же, либо с другим элементом описания архитектуры, например Организация A «имеет часть» задания B. Она следует естественной языковой конструкции Subject - Предикат - Объект - также используется в RDF. Видеть Кортеж. TRAK требует, чтобы каждый кортеж был явным.
Главный вид архитектуры
Каждый стереотип метамодели TRAK имеет тип представления основной архитектуры. В описании архитектуры или модели каждый элемент должен быть объявлен или показан в его главном типе представления архитектуры, прежде чем его можно будет использовать в любом другом типе представления.
Перспектива
ISO / IEC 42010: 2007 относится к архитектурной перспективе, поскольку «Совместное использование архитектурных моделей также способствует« аспектно-ориентированному »стилю архитектурного описания».[6] Группировка связанных и пересекающихся архитектурных видов.
Вид
ISO / IEC 42010 относится к архитектурному взгляду как «рабочий продукт, выражающий архитектуру системы с точки зрения конкретных системных проблем». Представление TRAK определяется как продукт архитектуры в метамодели TRAK. Представление TRAK представляет собой набор кортежей описания архитектуры в соответствии с его основной точкой зрения.
Смотровая площадка
ISO / IEC 42010: 2007 - Точка зрения определяет набор соглашений (нотации, языки и типы моделей) для построения определенного вида представления. В TRAK точка обзора - это спецификация для одного вида TRAK.

Структура TRAK

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

ТРАК имеет 24 точки зрения архитектуры которые сгруппированы в 5 перспектив. Каждая точка обзора принадлежит одной перспективе и задает один Посмотреть (тип). Каждая точка обзора определяет, какие наборы типов элементов описания архитектуры и взаимосвязей (кортежи) могут появляться. Типы и отношения элементов описания архитектуры задаются метамоделью TRAK.

Логическое определение TRAK состоит из 3 документов, каждый из которых является проектом с открытым исходным кодом на Sourceforge:

  • Документ о структуре архитектуры предприятия TRAK.[7] Это контролирует TRAK в целом. Он определяет перспективы архитектуры TRAK, цвета, официальные правила (правила, влияющие на дизайн TRAK, виды архитектуры и описания архитектуры, минимальный процесс моделирования.
  • Документ «Точки зрения на структуру архитектуры предприятия TRAK».[8] Это определяет точки зрения на архитектуру TRAK.
  • Документ метамодели структуры архитектуры предприятия TRAK.[9] Это определяет элементы описания архитектуры, которые могут появляться в определении точки обзора.

Перспективы архитектуры TRAK

TRAK имеет 5 архитектурных перспектив,[7] каждая из которых объединяет точки зрения на архитектуру и взгляды на перекрывающуюся предметную область:

  • Перспектива предприятия
  • Концепция перспективы
  • Перспектива закупок
  • Перспектива решения
  • Перспектива управления

Перспектива предприятия

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

Концепция перспективы

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

Перспектива закупок

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

Перспектива решения

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

Перспектива управления

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

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

Точки зрения и виды архитектуры TRAK

Каждый вид на архитектуру в TRAK указывается соответствующим точка зрения на архитектуру. Точка обзора обозначается буквой p в нумерации, например. CVp-01 - это архитектурная точка зрения, которая определяет архитектурный вид CV-01.

Обычно используется, если есть риск путаницы с представлением с аналогичным номером в другой структуре, например DODAF или же MODAF тогда используется префикс пространства имен, например ТРАК :: СВ-01

TRAK определяет 24 точки зрения на архитектуру[8] (для сравнения, DODAF 2.0 имеет 52 представления / модели, MODAF 1.2.004 имеет 47 представлений, а NAF 3.1 имеет 49 подпредставлений [10])

  • Перспектива предприятия
    • EVp-01 Корпоративные цели
    • EVp-02 Иерархия возможностей
    • EVp-03 фазировка возможностей
  • Концепция перспективы
    • CVp-01 Concept Need
    • Обмен концептуальными предметами CVp-03
    • CVp-04 от концептуальной деятельности до сопоставления возможностей
    • CVp-05 Концептуальная деятельность
    • Последовательность концепции CVp-06
  • Перспектива закупок
    • Структура закупки ПрВп-01
    • График закупок ПрВп-02
    • ПрВп-03 Ответственность за закупки
  • Перспектива решения
    • Структура решения СВп-01
    • SVp-02 Взаимодействие с ресурсами решения
    • SVp-03 Взаимодействие ресурсов решения с отображением функций
    • SVp-04 Решение Функция
    • SVp-05 Функция решения для отображения концептуальной деятельности
    • Компетентность решения SVp-06
    • Последовательность решения SVp-07
    • SVp-11 Решение Событие Причины
    • Риск решения SVp-13
  • Перспектива управления
    • Словарь описания архитектуры MVp-01
    • MVp-02 Описание архитектуры Запись проекта
    • MVp-03 Требования и стандарты
    • MVp-04 Заверение

Они определены в спецификации точек обзора TRAK. Дополнительная информация представлена ​​в вики сообщества.[11]

Метамодель ТРАК

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

Метамодель ТРАК[9] и упрощает, и расширяет базовые концепции метамодели MODAF 1.2. Он удалил и переопределил стереотипы, и все защитные конструкции были удалены. Спецификация метамодели TRAK содержит сравнение метамодели TRAK в первоначальном выпуске с MODAF 1.2.003. Об этом также говорится отдельно.[12]

Метамодель TRAK показана ниже. Обратите внимание, что это не контролируемая копия.

Значительные изменения по сравнению с MODAF включают:

  • метамодель TRAK нацелена на пользователей (MODAF M3 - это абстрактный профиль UML, предназначенный как спецификация для поставщиков инструментов для реализации MODAF - нет метамодели для пользователей, только фрагменты «упрощенной метамодели», которые стремятся представить более сложный M3). В TRAK показанная метамодель является основной.
  • Система является центральной для TRAK и может представлять жесткие системы и мягкие системы (в MODAF 1.2.003 система является артефактом[13] и часть физической архитектуры и не может включать нефизические части[14] )
  • TRAK может представлять любой тип интерфейса / потока обмена - информацию, энергию или ресурс.
  • TRAK может отображать характеристики обмена, связанные с человеческими ресурсами - организации, должности и роли.
  • TRAK включает средства для представления требований с помощью элементов метамодели Standard (документ / коллекция) и Requirement (атомарная), а также обеспечивается Контрактом.
  • TRAK включает в себя средства для планирования и описания архитектурной задачи и описания архитектуры и ее организации в виде представления (запись проекта описания архитектуры MV-02)
  • могут быть представлены другие типы зависимости и ассоциаций - физическая, членство, степень ответственности
  • TRAK включает средства для описания случаев уверенности (включая верификацию проекта) с использованием конструкции «утверждение - аргумент - свидетельство».
  • TRAK включает средства для описания безопасности / защиты - угроз / опасностей, уязвимостей, смягчения и рисков и причин / воздействий.
  • добавление концепций ISO / IEC 42010 для представления архитектурной задачи, описания архитектуры и архитектурных представлений - чтобы дать возможность описания объема задачи, цели, результатов
  • добавление правил согласованности для контента, которые применяются ко всей коллекции представлений и контекста, для улучшения навигации и видимости контента
  • правила, которые ограничивают то, как и в каком порядке могут быть установлены отношения для улучшения согласованности набора представлений, образующих описание архитектуры

Конструктивно есть и другие изменения:

  • TRAK имеет 24 точки обзора (против 47 просмотров в MODAF)
  • содержание каждой точки обзора определяется в терминах кортежей (конструкция элемента узел - отношение - узел, т.е. тройка или 1,кортеж ) и имеет разрешенные и минимально допустимые правила содержания и соответствия по отношению к другим представлениям в описании архитектуры, поскольку это необходимо для указания однозначно адресуемого пути в метамодели (указание элемента метамодели блока само по себе недостаточно при наличии нескольких взаимосвязей с участием элемента).
  • Поскольку ISO / IEC / IEEE 42010: 2011 определяет архитектуру в терминах отношения системы к ее среде, наименьшей единицей описания архитектуры, которая может появиться в представлении архитектуры TRAK, является кортеж описания архитектуры, то есть узел - отношение - узел.

Способ, которым TRAK управляется и выпускается с помощью набора проектов с открытым исходным кодом, также сильно отличается от других структур архитектуры предприятия. Все запросы на изменение и запросы функций, а также приговоры по ним полностью видны всем, а не только тем, кто определяет или разрабатывает структуру.[15][16][17] Релизы находятся под контролем изменений, и вся история ведется с помощью программного обеспечения для управления версиями (Subversion (SVN) ).

Презентация просмотров ТРАК

TRAK не определяет язык записи или представления (язык описания архитектуры в терминологии ISO / IEC 42010) для представления архитектурных представлений. Поэтому описания архитектуры TRAK не являются UML, SysML или же BPMN модели, хотя любая из этих нотаций может быть использована для подготовки хотя бы некоторых представлений (ADL может не содержать необходимых концепций / стереотипов или может не позволять их соединять способом, необходимым для представления архитектурного представления TRAK).

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

  • 'Система. А -конфигурирован с-> Программного обеспечения. B '
  • 'Требовать. Система А отвечает требованиям к ... -о-о-> Стандарт. Климатические условия окружающей среды ».
  • 'Физический. Строительство щита -имеет-> Уязвимость. Структурная слабость <-exploits- Угроза. Преднамеренное столкновение с самолетом '

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

Пример представления рисков решения TRAK SV-13 в виде графика, показывающего кортежи из метамодели TRAK

TRAK также позволяет строить представление из текстовых утверждений. Поскольку представление TRAK - это набор кортежи / тройки можно использовать график или набор RDF троек, чтобы представить вид TRAK. Онтологическое описание RDF элементов метамодели TRAK находится в стадии разработки.[18]. Это берет определения элементов из выходных данных спецификации метамодели TRAK из графической модели TRAK в пределах Neo4J база данных графов[19]. Архитектурное представление TRAK, состоящее из троек RDF, может быть связано с онтологией метамодели RDF TRAK для формирования граф знаний. Каждая тройка представляет собой факт или утверждение.

TRAK также требует, чтобы у каждого блока было имя. Целью этого является обеспечение того, чтобы представление архитектуры TRAK читалось так, как это имел в виду автор представления, и улучшить семантическую согласованность. Правила представления, которые применяются ко всем архитектурным представлениям TRAK, указаны в общей спецификации TRAK. [7][20] (как «Bye Laws»).

TRAK - это логическое определение: оно указывает, что нужно показывать, и минимально допустимый контент, но не определяет, как этого добиться. TRAK просто определяет элементы узла и соединителя, а также допустимые комбинации (тройки), которые должны / могут появляться в каждом виде. Он не определяет и не требует каких-либо конкретных обозначений или языка. Например, простая блок-схема и соединительная схема (как указано выше) приемлемы, как и набор текстовых операторов, диаграмма с использованием UML, граф или набор троек RDF.

Соображения по ISO 42010

TRAK применяется ISO / IEC 42010 следующими способами: -

  • Описание архитектуры - это ответ на задачу, которая решает проблемы заинтересованного лица (это решается с помощью TRAK :: MVp-02, Архитектура Описание Описание Проектной Записи Viewpoint)
  • каждое архитектурное представление TRAK определяется точкой зрения в рамках архитектуры TRAK
  • каждая точка зрения TRAK определяет заинтересованные стороны, решаемые проблемы, анти-проблемы (вещи, для которых не следует использовать точку обзора), необходимые кортежи метамодели, разрешенные кортежи метамодели, правильность (минимально допустимое содержание) и правила согласованности с другими представлениями в рамках описание архитектуры
  • Правила соответствия определяются точками зрения и для описания архитектуры с использованием метамодели TRAK.

Общее сравнение TRAK и ISO / IEC 42010 содержится в документе «Структура архитектуры предприятия TRAK». Более подробное сравнение с версией стандарта 2011 г. проводится отдельно. [21] и его можно просматривать как набор веб-страниц.[22] Они вместе с матрицей соответствия[23] сравнивать:-

  1. TRAK как структура архитектуры в соответствии с требованиями раздела 6.1 (Структуры архитектуры) ISO / IEC / IEEE 42010: 2011 и;
  2. описание архитектуры, соответствующей TRAK, согласно разделу 5 (Описание архитектуры) ISO / IEC / IEEE 42010: 2011.

Создание описания архитектуры с помощью TRAK

Сам TRAK не требует обязательного процесса. Тем не менее, здесь представлен элемент процесса, поскольку TRAK придерживается стандарта ISO / IEC 42010, в котором говорится, что описание архитектуры создается в ответ на задачу и интересы заинтересованных сторон, а также потому, что TRAK имеет основные представления архитектуры, которые создают зависимости между представлениями и приводит к минимально допустимым наборам архитектурных представлений.

Это приводит к минимальному процессу, который:

  • определить заинтересованную сторону задачи и их обеспокоенность
  • используя точки обзора TRAK, выберите точки обзора, необходимые для решения проблем заинтересованных сторон
  • развивать взгляды которые соответствуют этим точкам зрения, которые решают эти проблемы
  • это, в свою очередь, может потребовать подготовки дополнительных представлений для формирования легитимного разрешенного набора представлений.
  • задокументировать цель, опасения, выводы и описание архитектуры с использованием представления архитектурного проекта MV-02, дополненного представлением словаря архитектуры MV-01

Лицензирование

TRAK выпускается под двумя формами лицензии с открытым исходным кодом:

  • Лицензия свободной документации GNU (GFDL ) для логического определения - документы TRAK Complete, TRAK Metamodel и TRAK Viewpoints
  • Общественная лицензия GNU (GPL ) для реализации TRAK - UML-профиль для TRAK для общих инструментов моделирования UML и TRAK MDG Technology для Системы Sparx Архитектор предприятия инструмент для моделирования.

Поддержка инструментов

TRAK поддерживает инструменты моделирования с помощью следующих механизмов:

Сравнение стереотипов (концепций) в UML с таковыми в метамодели TRAK [28] предоставляет анализ UML-профиля для TRAK, какие точки обзора TRAK и, следовательно, виды TRAK UML могут представлять полностью, частично и не отображать вообще. Это является следствием конструкций, доступных в UML, и конкретной реализации в профиле UML для TRAK, и возникает из-за того, что разные языки описания архитектуры (ADL ) часто разрабатываются для разных целей, а иногда и для разных доменов, например, в ИСО / МЭК 42010 проблемы, которые они решают, отличаются от тех, которые решает структура архитектуры, в данном случае TRAK.

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

Примеры описания архитектуры с использованием TRAK

  • Программа модернизации подповерхности (SSUP). Модернизация сигнального и подвижного состава на линиях Circle, Hammersmith, Metropolitan и District на лондонском метро. Цитируется в исследовании «Соотношение цены и качества железных дорог». Отчет об управлении программой всей системы. 25 мая 2011г.[2]
  • Группа руководства технической стратегией (TSLG). Функциональная архитектура железной дороги[29]
  • Совет по безопасности и стандартам на железнодорожном транспорте (RSSB). Функциональная архитектура железных дорог Великобритании. Текущее исследование - Электронный бюллетень по исследованиям и разработкам RSSB. Выпуск 66. Октябрь 2010.[30] Обоснование выбора / использования TRAK представлено в сводном отчете по задаче.[31] Отдельно описывается проект функциональной архитектуры железной дороги Т912.[32] Функциональная архитектура железной дороги доступна в виде набора HTML-страниц.[33]
  • Бирмингемский университет. InfraGuidER (Руководство по инфраструктуре для экологической эффективности железных дорог), результаты 9 и 18.,[34] минут: D22: 2-й семинар для полюсов передового опыта EURNEX (European Rail Research Network of Excellence) [35]
  • Интегрированный EA 2011. Управление рисками и затратами с помощью подхода EA. Майк Браунсворд (Атего) и Джо Силмон (Центр железнодорожных исследований и образования).[36]
  • Описание архитектуры[22] описание требований соответствия TRAK как структуры архитектуры и описания архитектуры, соответствующей TRAK, требованиям ISO / IEC / IEEE 42010: 2011. Включает примеры следующих представлений: MV-02 Архитектура Описание Проектная запись, Требования и стандарты MV-03 и Гарантия MV-04. Затем базовая модель была использована для создания матрицы соответствия.[23] как пример Модельно-ориентированная системная инженерия.

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

  1. ^ Форумы IET - TRAK - Структура железнодорожной архитектуры
  2. ^ а б Исследование соотношения цены и качества поездов. Отчет об управлении программой всей системы. 25 мая 2011 г. http://www.rail-reg.gov.uk/upload/pdf/rvfm-atkins-programme-management-250511.pdf
  3. ^ Премия Рабочей группы INCOSE 2010 http://www.inosis.org/practice/techactivities/wg/transport/
  4. ^ Рабочая группа по транспортировке INCOSE http://www.inosis.org/practice/techactivities/wg/transport/
  5. ^ IET Innovation Awards 2001 - Финалисты http://conferences.theiet.org/innovation/finalists/index.cfm
  6. ^ ANSI / IEEE Std 1471 :: ISO / IEC 42010 Рекомендуемая практика для архитектурного описания программно-интенсивных систем
  7. ^ а б c Структура корпоративной архитектуры TRAK
  8. ^ а б TRAK00001 TRAK. Структура архитектуры предприятия. Точки обзора
  9. ^ а б TRAK00002 TRAK. Структура архитектуры предприятия. Метамодель
  10. ^ Trak-community.org::Wiki:: Сравнение архитектурных рамок http://trak-community.org/index.php/wiki/Architecture_Framework_Comparison
  11. ^ http://trak-community.org/index.php/wiki/TRAK:TRAK_Viewpoints
  12. ^ http://trak-community.org/index.php/wiki/TRAK:Initial_TRAK_Baseline_vs_MODAF_-_Stereotypes
  13. ^ MODAF Метамодель 1.2.004 MODAF версия 1.2.004
  14. ^ Система обзора MODAF (SV) 26 апреля 2010 г.
  15. ^ Sourceforge. Трекеры ошибок / изменений проекта TRAK. http://sourceforge.net/tracker/?group_id=393432
  16. ^ Sourceforge. Трекеры ошибок / изменений проекта метамодели TRAK. http://sourceforge.net/tracker/?group_id=304403
  17. ^ Sourceforge. TRAK Viewpoints Project Bug / Change Trackers. http://sourceforge.net/tracker/?group_id=304405
  18. ^ Метамодель TRAK (RDF) https://trakmetamodel.sourceforge.io/vocab#
  19. ^ Слива, Ник (8 июня 2020 г.). «Использование ориентированных графов для определения точек обзора для сохранения согласованности метамодели, структуры архитектуры и представлений с использованием различных языков моделирования». Инженерные отчеты. 2 (6). Дои:10.1002 / eng2.12168. Получено 10 ноября 2020.
  20. ^ Архитектура предприятия TRAK
  21. ^ TRAK00015 TRAK. Описание архитектуры. Резюме. Оценка соответствия - ISO / IEC / IEEE 42010: 2011. http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00015_TRAK_AD_Summary_Conformance_with_42010_2011.pdf/download
  22. ^ а б TRAK00013 TRAK. Описание архитектуры. Оценка соответствия - ISO / IEC / IEEE 42010: 2011 http://trak.sourceforge.net/TRAK%20vs%20ISO_42010_AD/index.htm
  23. ^ а б TRAK00014 TRAK. Матрица соответствия. Оценка соответствия - ISO / IEC / IEEE 42010: 2011 http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00014_TRAK_vs_ISO42010_compliance.ods/download
  24. ^ Технология ЦРТ для ТРАК
  25. ^ Проект trakmoodtemp на Sourceforge
  26. ^ проект тракомниграфле на Sourceforge
  27. ^ Проект trakforvisio на Sourceforge
  28. ^ проект trak на Sourceforge
  29. ^ Группа руководства технической стратегией (TSLG). Функциональная архитектура железных дорог. http://www.futurerailway.org/Research/Pages/Railway-Function-Architecture.aspx
  30. ^ Электронный бюллетень по исследованиям и разработкам RSSB. Выпуск 66. Октябрь 2010. Тема T912 Функциональная архитектура железной дороги http://www.rssb.co.uk/SiteCollectionDocuments/research/enews/rd_enewsletter66.htm
  31. ^ Сводный отчет по функциональной архитектуре железной дороги http://www.rssb.co.uk/sitecollectiondocuments/pdf/reports/research/T912_rpt_final.pdf
  32. ^ RSSB. Проект Т912 Функциональная архитектура железной дороги. http://www.rssb.co.uk/RESEARCH/Lists/DispForm_Custom.aspx?ID=955
  33. ^ Функциональная архитектура железной дороги (HTML) http://www.futurerailway.org/research/Pages/EA%20HTML/index.htm
  34. ^ Результаты InfraGuidER http://www.infraguider.eu/prodotti_7.html
  35. ^ Протокол: D22: 2-й семинар для полюсов передового опыта EURNEX http://infraguider.eu/doc/INFRAG_WP5_NIT_DV_022_B.pdf
  36. ^ Integrated EA 2011: управление рисками и затратами с помощью подхода EA http://www.integrated-ea.com/file_download/101/

внешняя ссылка