ГОСТ Р 57310—2016
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 Общая информация
Обратное проектирование предполагает, что программное обеспечение уже существует и способ
но справиться с требованиями к обмену информацией, но есть необходимость в охвате дополнитель
ных требований, которые могут поддерживаться.
14