ГОСТ Р 57310-2016 (ИСО 29481-1:2010). Национальный стандарт Российской Федерации. Моделирование информационное в строительстве. Руководство по доставке информации. Методология и формат

(утв. и введен в действие Приказом Росстандарта от 02.12.2016 № 1915-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р 57310-2016"]:::rst
  click n0 "https://bukva.ai/docs/gost-r-57310-2016" "ГОСТ Р 57310-2016. Национальный стандарт Российской Федерации. Моделирование информационное в строительстве. Руководство по доставке информации. Методология и формат (утв. и введен"
  n1["ГОСТ Р 10.0.03-2019"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-r-10-0-03-2019" "ГОСТ Р 10.0.03-2019. Национальный стандарт Российской Федерации. Система стандартов информационного моделирования зданий и сооружений. Информационное моделирование в строительстве."
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

МОДЕЛИРОВАНИЕ ИНФОРМАЦИОННОЕ В СТРОИТЕЛЬСТВЕ

РУКОВОДСТВО ПО ДОСТАВКЕ ИНФОРМАЦИИ. МЕТОДОЛОГИЯ И ФОРМАТ

Building information models. Information delivery manual. Methodology and format

(ISO 29481-1:2010, Building information models — Information delivery manual — Part 1: Methodology and format, MOD)

ГОСТ Р 57310-2016 (ИСО 29481-1:2010)

Предисловие

1 ПОДГОТОВЛЕН структурными подразделениями Акционерного общества «Научно-исследовательский центр „Строительство“ (АО „НИЦ „Строительство“) ЦНИИСК им. В.А. Кучеренко совместно с НИИЖБ им. А.А. Гвоздева на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4»

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 465 «Строительство»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 2 декабря 2016 г. № 1915-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 29481-1:2010 «Моделирование информационное зданий и сооружений. Руководство по доставке информации. Часть 1. Методология и формат» (ISO 29481-1:2010 «Building information models — Information delivery manual. Part 1: Methodology and format», MOD). При этом в него не включены разделы А.4 и А.5 приложения А примененного международного стандарта, являющиеся либо ссылками на внешние интернет-ресурсы, либо информацией, не упоминаемой в контексте основной части настоящего стандарта. Указанные разделы приложения, не включенные в основную часть настоящего стандарта, приведены в дополнительном приложении ДА.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ 1.5-2012 (пункт 3.5)

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

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

1. Область применения

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

Настоящий стандарт включает в себя:

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

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

2. Нормативные ссылки

В настоящем стандарте нормативные ссылки отсутствуют.

3. Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 руководство по доставке информации (information delivery manual, IDM): Документация, охватывающая бизнес-процесс и обеспечивающая подробные характеристики информации, которую пользователь, выполняющий определенную роль, должен предоставить на определенном этапе в рамках реализации проекта.

3.2 актор (actor): Лицо, организация или ее подразделение (такое как департамент, группа и т.д.), вовлеченные в процесс строительства.

3.3 информационная модель объекта строительства (building information model): Совместно используемое цифровое представление физических и функциональных характеристик какого-либо объекта капитального строительства (включая здания, мосты, дороги и прочее), формирующее надежную основу для принятия решений на протяжении всего жизненного цикла: от первоначальной идеи до вывода объекта из эксплуатации.

3.4 информационная система здания (building information system): Система, используемая для создания, сопровождения, определения или исключения элементов информационной модели объекта строительства.

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

3.5 нотация моделирования бизнес-процессов (business process modelling notation, BPMN): Нотация для создания диаграмм бизнес-процессов, которая разработана для легкого понимания всеми пользователями.

3.6 бизнес-требования (business requirements): Требования, которые описывают в бизнес-терминах то, что необходимо предоставить или реализовать.

3.7 бизнес-правило (business rule): Утверждение, которое формально определяет или ограничивает некоторые аспекты бизнеса, правило, согласно которому функционирует организация, или политика организации, или решения, влияющие на бизнес-процессы.

3.8 требования к обмену информацией (exchange requirement, ER): Набор информации, необходимый для обмена в процессе поддержания конкретного бизнес-требования на определенной фазе или стадии процесса.

Примечание - Требования к предоставлению информации могут использоваться как синоним требований к обмену информацией.

3.9 модель требования к обмену информацией (exchange requirement model, ERM): Техническое выражение требования к обмену информацией в виде схемы.

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

3.10 функциональная часть (functional part, FP): Часть информации, входящая в требования к обмену информацией, которая может быть полностью самостоятельно определена.

3.11 карта взаимодействия (interaction map): Представление ролей и транзакций, соответствующих конкретной цели, в виде карты.

3.12 управленческий информационный обмен (management communication): Совместное использование информации в целях управления.

3.13 модель (model): Изображение системы, которое позволяет исследовать ее свойства.

3.14 карта процесса (process map, PM): Представление характеристик процесса, соответствующего поставленной цели, в виде карты.

3.15 роль (role): Функция, выполняемая актором в определенный момент времени.

Примечание - Роль актора определяется действием и результатом, а не его профессией.

3.16 схема (schema): Схема является формальным отображением структуры определенного набора информации.

3.17 транзакция (transaction): Акт взаимодействия между двумя ролями, соответствующий отношениям между ними.

4. Руководство по доставке информации

4.1. Полная схема

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

4.2. Разбиение полной схемы на составляющие

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

4.3. Поддержка информационного моделирования объектов строительства

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

4.4. Поддержка бизнес-требований

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

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

4.5. Поддержка программных решений

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

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

4.6. Поддержка строительного процесса

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

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

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

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

4.8. Содержание конкретных руководств

Содержание конкретного руководства должно:

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

4.9. Пользователи настоящего стандарта

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

Другие участники будут в основном использовать данные руководства, разработанные с учетом настоящего стандарта. Кроме того, некоторые пользователи конкретных руководств смогут определить требования к новым руководствам и, таким образом, стать пользователями настоящего стандарта в качестве разработчиков. К таким пользователям относятся:

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

5. Структура руководства

5.1. Краткий обзор

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

a) компоненты верхнего слоя структуры относятся к процессам, средний слой занимают данные, а нижний включает в себя элементы используемого программного обеспечения;

b) аналогичным образом, компоненты, относящиеся к практической деятельности, находятся в верхнем слое структуры, а элементы анализа и программных компонентов — в нижнем.

5.2. Составляющие заголовков частей руководств

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

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

5.3. Описание варианта использования

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

5.4. Карты взаимодействий

Целью карты взаимодействия является идентификация соответствующих ролей и транзакций для конкретных целей. Руководство приводит различие между ролями инициатора, делающего запрос, и исполнителя, выполняющего запрос. Взаимодействие между этими ролями называется транзакцией.

Карта взаимодействий определяет соответствующие роли, транзакции и отношения между инициатором и исполнителем.

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

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

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

Использование транзакций и вклад соответствующих участников в информационную модель может контролироваться. Для этой цели в состав транзакции могут быть добавлены следующие компоненты в качестве приложений к конкретным сообщениям:

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

5.5. Карты процессов

5.5.1 Основная информация

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

Для представления карты процессов рекомендован подход нотаций моделирования бизнес-процессов (BPMN).

Карта процессов внутри руководств:

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

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

5.5.2 Содержание

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

Карта процессов включает в себя следующую административную информацию:

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

5.5.3 Определение процессов

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

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

5.5.4 Определение объекта данных

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

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

5.5.5 Определение требований к обмену информацией

Требования к обмену информацией являются частным типом данных объекта внутри карты процессов, которая располагается внутри роли информационной модели.

Требования к обмену информацией должны включать в себя следующее:

• имя, которое позволяет идентифицировать цель (правила именования приведены в А.3);
• описание, дающее понятие о целях и содержании.

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

5.5.6 Определение точек согласованного входа

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

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

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

5.6. Требования к обмену информацией

5.6.1 Общая информация

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

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

5.6.2 Содержание

Требования к обмену информацией содержат следующую информацию:

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

5.6.3 Блоки информации

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

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

Блоки информации затем разбиваются для обеспечения:

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

5.7. Функциональные части

5.7.1 Основная информация

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

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

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

5.7.2 Содержание

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

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

5.7.3 Техническая информация

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

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

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

Таблица 2

Перечень разделов

5.7.5 Раздел схемы

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

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

5.7.6 Пример раздела

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

5.8. Функциональные блоки

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

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

Рисунок 5 — Функциональные блоки внутри функциональной части

6. Реализация и проверка компонентов руководства

6.1. Модель требований к обмену информацией

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

Рисунок 6 — Модель требований к обмену информацией

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

Модели требований к обмену информацией особенно значимы, если они являются компонентами руководств по доставке информации, которые:

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

6.2. Бизнес-правила

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

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

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

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

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

Примером бизнес-правила, выраженного как предложение, является требование к площади зоны пространства, которая называется «рабочий офис», быть не меньше 10 м2. В этой форме оно применимо к требованию к обмену информацией. При применении к функциональной части правило кодируется в логической подходящей форме в порядке, в котором выражены атрибуты или свойства.

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

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

Рисунок 7 — Применение бизнес-правил

Таким образом, определенный набор бизнес-правил относится к одной модели бизнес-правил.

Бизнес-правила собраны вместе в наборы таким образом, чтобы каждый набор был применим к конкретному понятному уровню приложения. Например, глобальный набор правил может быть применим ко всем функциональным частям, используемым в руководстве на глобальной основе. Тем не менее локальные наборы правил для использования в конкретном месте (например, в Норвегии) будут применяться только к моделям требований к обмену информацией, используемым в этом месте.

Каждое определенное бизнес-правило должно иметь уникальный идентификатор, который показывает:

• где и кем оно было определено;
• уровень применимости. Например, оно применимо к объекту, перечисленным типам данных или для свойства в наборе свойств;
• индекс или другую ссылку.

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

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

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

6.3. Проверочные тесты

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

Рисунок 8 — Применение общего руководства и дополнительных указаний

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

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

Проверочные тесты применяются для решения следующих задач:

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

7. Общие и частные руководства

7.1. Общее руководство

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

7.2. Применение частных руководств

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

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

8. Процесс разработки руководства

8.1. Цель разработки

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

• с определением сферы деятельности;
• установлением подхода к разработке;
• определением ресурсов;
• установлением плана проекта.

8.1.1 Определение объемов работ

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

8.1.2 Основы подхода к разработке

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

8.1.3 Определение ресурсов

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

8.1.4 План проекта

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

8.2. Этапы разработки руководства

8.2.1 Общая информация

Три подхода к разработке руководства по доставке информации:

• создание процесса;
• определение бизнес-правила;
• обратное проектирование.

8.2.2 Создание процесса

8.2.2.1 Общая информация

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

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

8.2.2.2 Процесс создания

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

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

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

8.2.2.3 Разработка требований к обмену информацией

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

8.2.2.4 Создание функциональных частей

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

8.2.3 Настройка бизнес-правил

8.2.3.1 Определение бизнес-правил

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

8.2.3.2 Локализация бизнес-правил

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

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

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

8.2.4 Обратное проектирование

8.2.4.1 Общая информация

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

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

8.2.4.2 Определение сценария

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

8.2.4.3 Восстановление данных

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

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

8.2.4.4 Создание требования к обмену информацией

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

8.2.4.5 Создание функциональных частей

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

8.2.4.6 Определение бизнес-правил

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

8.2.4.7 Процесс объединения

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

9. Составление компонентов руководства

9.1. Общая информация

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

9.2. Добавление функциональных частей

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

Каждая функциональная часть имеет полностью определенную схему, которая включает в себя набор объектов. Например, функциональная часть P2, показанная ниже, может включать в себя набор объектов {U, V, W, Z}, в то время как функциональная часть P3 может включать в себя набор объектов {T, U, V, X, Y}. Необходимо отметить, что обе функциональные части включают в себя объекты {U, V} в своих схемах. Это типичный случай для объектов, используемых в функциональных частях схем.

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

Схема функциональной части, которая включает в себя другие функциональные части, эффективно суммирует все наборы объектов. Например, когда функциональная часть P1 включает в себя P2 и P3, P1 будет суммой наборов объектов для P2 и P3, как показано на рисунке 9. Схема P1 содержит набор объектов {U, V, W, Z} + {T, U, V, X, Y}.

Так же, как и включенные функциональные части P2 и P3, часть P1 может содержать локально расположенные объекты, например, {S, X}. Тот факт, что {X} используется в P3, не исключает его использования в P1. В таком случае схема P1 содержит набор объектов, которые точно определены, и наборы объектов, включенные в функциональные части. Таким образом, схема P1 содержит набор объектов {S, X} + [{U, V, W, Z} + {T, U, V, X, Y}]. Расширение даст набор объектов внутри схемы P1 {S, X, U, V, W, Z, T, U, V, X, Y}.

Получается, что схема P1 включает в себя по два вхождения объектов {X}, {U} и {V}, что недопустимо. Набор объектов, образующих схему, может содержать только одно вхождение каждого объекта. Это значит, что совпадение вхождений должно быть урегулировано. Для P1 решением схемы будет {S, T, U, V, W, X, Y, Z} при вхождении каждого объекта по одному разу.

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

Рисунок 10 — Решение схемы добавлением объектов

Так как модель требований к обмену информацией составляется из функциональных частей, схема для модели требований к обмену информацией также составляется путем сложения схем, содержащих функциональные части. Например, если модель требований к обмену информацией R1 включает в себя функциональную часть P1 и P2, то

R1 = P1 + P2.

Однако если функциональная часть P1 включает в себя функциональные части A, B, C, а P2 включает в себя D, E, F, то, следовательно

Рисунок 11 — Разложение функциональных частей

9.3. Добавление моделей требований к обмену информацией

Подобно тому, как модели требований к обмену информацией включают в себя функциональные части, они также могут включать в себя другие требования к обмену информацией. Это означает, что информация уже определена для предварительной модели требований к обмену информацией, которая может использоваться в текущей модели. Такая установка может эффективно использоваться для снижения усилий, затрачиваемых при описании требований к обмену информацией. Например, если требование к обмену информацией R2 содержит требование к обмену информацией R1 и функциональные части P1 и P2, то схема для R2 может быть определена как

R2 = R1 + P1 + P2.

На самом деле, использование модели требований к обмену информацией вышеприведенным образом не отличается от добавления функциональных частей, которые показаны в 9.2. Это связано с тем, что модель требований к обмену информацией сводится к функциональным частям, из которых состоит. Таким образом, ссылка на модель требований к обмену информацией включает в себя набор ссылок на функциональные части, которые применялись при построении модели (см. рисунок 12).

Рисунок 12 — Требования к обмену информацией с функциональными частями

9.4. Блоки информационной модели

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

(справочное)

СПРАВОЧНЫЙ РАЗДЕЛ

А.1 Пример сценария руководства по доставке информации

А.1.1 Общая информация

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

А.1.2 Основные идеи

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

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

Рисунок А.1 — Точки зрения руководства

С обеих точек зрения, есть ряд зон, характеризующих различные элементы руководства (см. рисунок А.2).

Рисунок А.2 — Зоны руководства

С точки зрения требований пользователя, руководство включает в себя:

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

С точки зрения технических решений, руководство включает в себя:

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

Вышеперечисленное более детально показано на рисунке А.3.

Рисунок А.3 — Схема идей, имеющих отношение к руководству

А.1.3 Исходное положение

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

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

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

А.1.4 Дорожная карта

Этот сценарий описывает дорожную карту для реализации руководства в проекте строительства. Он состоит из следующих шагов:

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

А.1.5 Определение взаимодействий в управлении

Чтобы поставить взаимодействия в центр внимания, в руководстве используют термин «роль». Это абстрактное понятие, представляющее особую ответственность за предоставление информации. Роль не должна быть связана с организацией или актором. Она делает простым определение взаимодействий в проекте без точного знания о том, кто будет вовлечен в проект. В конце концов, роль будет назначена актору, который должен будет ее выполнять. Руководство позволяет назначить конкретного актора в определенной роли и менять его при каждом событии, предусмотренном ролью.

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

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

• обработка поручений;
• доставка результата;
• обработка вопроса для изменения;
• обзор результатов;

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

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

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

А.1.6 Определение структуры информации строительства

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

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

А.1.7 Определение требований к обмену информацией — связь между объектами

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

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

А.1.8 Выбор строительной информационной системы

Для целей нового строительного проекта используется информационная система здания, которая должна содержать информационную модель объекта строительства. Важным требованием является ее совместимость с настоящим стандартом, т.к. это гарантирует взаимодействие между партнерами, которые также применяют совместимое с руководствами по доставке информации программное обеспечение.

В руководстве роль — это актор, принимающий участие в передаче требований к обмену информацией, а не конкретная личность.

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

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

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

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

Требования к обмену информацией определяются как имеющие отношение к конкретным стадиям проекта. Для согласованности стадии жизненного цикла следует всегда определять с использованием общих основ. В настоящем стандарте использованы следующие стадии идентификации:

• начальная;
• подготовительная;
• проектная;

Термин «актор» используется здесь скорее как термин «агент», чтобы отличать человека от программного обеспечения, т.е. набора программного кода, который может действовать автономно.

Для целей настоящего стандарта основные этапы разбиваются на различные группы стадий для разработки карт процессов и требований обмена. Разбиение на стадии показано в таблице А.1, наряду с перекрестными ссылками стадий.

А.2.2 Местные стадии жизненного цикла

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

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

Там, где используются локальные протоколы, соответствия между стадиями в локальном протоколе и настоящем стандарте должны быть сохранены. В противном случае:

• единый стандартизованный этап распадается на множество стадий в локальном протоколе;
• несколько стандартных этапов объединяются в одну стадию в локальном протоколе.

Стандартные и локальные стадии протокола всегда должны соответствовать друг другу таким образом, чтобы отношения между ними были 1:1, 1:X или X:1. Стадии жизненного цикла не должны пересекать друг друга так, чтобы одна часть стадии локального протокола начиналась в одной стандартной стадии и заканчивалась в другой.

А.3 Правила именования

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

Таблица А.2

Правила именования

(справочное)

ПУНКТЫ ПРИМЕНЕННОГО МЕЖДУНАРОДНОГО СТАНДАРТА, НЕ ПРИВЕДЕННЫЕ В НАСТОЯЩЕМ СТАНДАРТЕ

ДА.1

А.4 Руководство по доставке информации (IDM) использует методы нотаций моделирования бизнес-процессов (BPMN)

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

• Бизнес-процесс, Спецификация примечаний к модели, OMG конечная принятая спецификация, OMG, 2006, доступна по ссылке http://www.bpmn.org/
• White S.A., Введение в BPMN, IBM, 2005, доступна по ссылке <http://www.bpmn.org/Documents/lntroduction_ to_BPMN.pdf>

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

Дополнительная информация о развертывании модельного вида предоставлена по ссылке http://www.blis-project.org/IAI-MVD/.

БИБЛИОГРАФИЯ