ГОСТ Р 57310—2016
Наиболее подходящим путем выполнения обратного проектирования является определение сце
нария. поддерживаемого требованиями к обмену информацией, а затем получение информации по
средством работы с программными приложениями.
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 Добавление функциональных частей
Основным блоком руководства, в котором выражена схема, является функциональная часть. Она
определяется техническим содержанием.
Каждая функциональная часть имеет полностью определенную схему, которая включает в себя
набор объектов. Например, функциональная часть Р2. показанная ниже, можот включать в себя набор
объектов {U, V. W. Z}, в то время как функциональная часть РЗ может включать в себя набор объектов
(Т, U. V, X, У}. Необходимо отметить, что обе функциональные части включают в себя объекты {U, V} в
своих схемах. Это типичный случай для объектов, используемых в функциональных частях схем.
Функциональная часть может задействовать или включать в себя другие функциональные ча
сти, что является важным моментом руководства и позволяет однократно определить функциональную
часть, а затем использовать ее множество раз.
Схема функциональной части, которая включает в себя другие функциональные части, эффек
тивно суммирует все наборы объектов. Например, когда функциональная часть Р1 включает в себя Р2 и
РЗ, Р1 будет суммой наборов объектов для Р2 и РЗ. как показано на рисунке 9. Схема Р1 содержит
набор объектов {U, V. W. Z} ♦ {Т, U. V, X. У).
15