ГОСТ Р 55346—2012
D.1.11 Операция Buildsolution model (Модель построения решения)
Позволяет идентифицировать показатели эффективности в качестве основыдля компромисса и создавать
модели поведения иструктуры.
D.1.12 Операция Business reality(Реальные условия ведения бизнеса)
Позволяет определять коммерческие факторы, включающие всебя наличие ресурсов, риски влияния и пе
риодот начала разработки продукциидо выхода его на рынок.
D.1.13 Операция By-product (Промежуточный продукт)
Позволяет определять элемент, который будет прирастать в процессе производства, эксплуатации или тех
нического обслуживания системы и в дальнейшем больше не будет ифать полезную роль в жизненном цикле
системы.
D.1.14 Операция Calculate system performance (Расчетфункциональных характеристик системы)
Позволяетиспользовать полученные состояния (значения) атрибутовдля получения комплексныхфункцио
нальных характеристиксистемы с помощьюсоответствующего набора требований.
D.1.15 Операция Change proposal (Изменения вкоммерческом предложении)
Позволяет определять предложение, в котором будут идентифицироваться характеристики изменения ка
кого-либотехническогоэлемента при создании, эксплуатации, техническом обслуживании и утилизациисистемы.
Примечание — Коллектив разработчиков проекта будет рассматривать нетехнические последствия
изменения предложения перед тем. как разрешение этого изменения станет реальным. Объем и формальная
сторонаэтого рассмотрения будет зависетьот ожидаемого влиянияэтогоизменения (вобщем случав этовлияние
будет увеличиваться в процессежизненного цикла системы). Основные принципы организации, предприятия или
проекта будутопределять критерии оценки изменения предложения.
D.1.16 Операция Chosen solution (Выбранное решение)
Позволяетопределять информациюо модели, которая является оптимальной спецификациейсистемы.
Примечание — Показатели эффективности являются основойдля выбораодногоэтого решения из на
борадопустимыхвариантов.
D.1.17 Операция compare Effectivenessof feasible solutions(Эффективностьдопустимых решений)
Позволяет определять категорию всех допустимых решений на основе соответствующих показателей эф
фективности. а также оптимальное решение.
D.1.18 Операция Component for integration (Компонентдля объединения
Позволяет определять компонент, который готов кобъединению сразрабатываемой системой.
D.1.19 Операция Component tier model (Модель компонентоввсистеме)
Позволяет определятьнабор, содержащийконтекстнуюиобъектную модели, характеризующиеданный ком
понентвсистеме.
D.1.20 Операция Concept tiermodel (Модельпонятий всистеме)
Позволяетопределятьнабор разработанныхмоделей, содержащий контекстную иобъектную модели, а так
же характеризующий представление принциповсистемы.
D.1.21 Операция Context model set (Набор контекстных моделей)
Позволяет определять набор, содержащий поведенческую иструктурную модели, а также план реализации
контекста объекта в классе системы.
D.1.22 Операция Control engineering change (Контрольтехническихизменений)
Позволяет анализировать техническое влияние исследованных вопросов и формировать обратную связь
для инициализации процессовконтроля проектас цельюоценки влияния на негостоимости, рискови графика вы
полненияработ.
Примечание — Операция change proposal* является основойдля активации операции manage project
с цельюпросмотра такихнетехнических показателей проекта, как стоимость, риски играфик выполнения работ.
D.1.23 Операция Create behaviourmodel (Формирование модели поведения системы)
Позволяет определятьлибо стимулирующее воздействие, либо реакцию на негодля объекта впредставля
ющей интерессистеме.
D.1.24 Операция Create model forcomponent tie (Формирование моделидля класса компонента)
Позволяетвыполнять процессобщего инженерногомоделирования системдля получения спецификации на
требованиякэлементарной частисистемы или модели класса подсистемы.
D.1.25 Операция Create model forconcept tier(Формирование моделидля класса компонента)
Позволяетвыполнять процессобщего инженерногомоделирования системдля получения спецификации на
требования, направляемые ворганизацию заказчика.
Примечание — При этом моделировании создаются требования, которые часто называются требова
ниями пользователя или заинтересованной стороны (контекстное представление) и системные требования (объ
ектное представление). Указанныетребования могут представляться ввидедокумента, содержащего требования
пользователя (URD). идокумента, содержащего системные требования (SRD).
196