ГОСТ Р 57318—2016
тесты следует выполнятьдля тех элементов, которые обычно поддерживаются операторами, пользова
телями или инженерами службы эксплуатации; их можно использовать для диагностических операций
при технической поддержке мероприятий, требующих технического обслуживания на низком уровне.
6.5.14 Оценка развития производственных возможностей
В проекте следует предусмотреть оценку проектных альтернативных решений, предназначенную
либо для определения их возможностей в части модернизации или развития, применения новых техноло
гий. повышения рабочих характеристик ифункциональных возможностей, либодля внесения других рента
бельных или конкурентных улучшений, когда система будет находиться в условиях промышленной эксплу
атации или на рынке. Следует определить ограничения, которые могут препятствовать развитию системы,
а также проанализировать и определить подходы по преодолению этих ограничений. В рамках проекта не
обходимо предусмотреть такое управление конфигурацией продуктов, которое будетобеспечивать эффек
тивные возможности продуктов в части развития/модернизации. Возможность оказывать поддержку в про
цессе развития системы может потребовать и параллельной поддержки процесса развития продукции. Это
соображение может значительно усложнять требования к финансовой поддержке и обучению персонала.
6.5.15 Окончательное оформление проектных решений
В рамках проекта следует предусмотреть окончательное оформление выбранного альтернатив
ного решения, а также обозначений и описаний интерфейсов (внутренних и внешних) для конструктив
ных элементов.
6.5.16 Инициализация поэтапного развития
В проекте при необходимости следует предусмотреть инициализацию поэтапного развития любо
го конструктивного элемента, для которого было выбрано технологическое решение, худшее из техно
логий с повышенным риском, и для которого возможности развиваться были предусмотрены в
элемен те и в элементах интерфейсов.
6.5.17 Формирование комплекта документов по интеграции
В проекте при необходимости следует предусмотреть выполнение чертежей, схем, документации
на программное обеспечение, ручных процедур и т. п.. предназначенное для документирования вы
бранных конструктивных элементов (в виде комплекта документов по интеграции).
6.5.18 Создание проектной архитектуры
В проекте следует предусмотреть создание проектной архитектуры, соответствующей уровню
развития, предназначенной для документирования проектного решения и интерфейсов и включающей в
себя требования прослеживаемости и матрицы распределения с целью распределения функциональ ных
и эксплуатационных требований между элементами системы. Определение проектной архитекту ры
следует сохранять в интегрированном хранилище вместе с результатами анализа компромиссных
решений, проектных обоснований и ключевых решений, которые должны обеспечивать прослеживае
мость требований в нисходящем и восходящем направлениях по архитектуре. Верификация проектной
архитектуры (см. 6.6) должна быть осуществлена для подтверждения выполнения утвержденных для
базовой линии требований и функциональной архитектуры.
6.6 Проектная верификация
В проекте следует предусмотреть выполнение верификации правильности проектных решений с
целью подтверждения того, что:
а) требования на самом низком уровне проектной архитектуры, в том числе полученные/перешед-
шие с других уровней, прослеживаются до верифицированной функциональной архитектуры;
б) проектная архитектура соответствует прошедшей валидацию базовой линии.
Задачи, связанные с проектной верификацией, приведены на рисунке 15.
6.6.1 Выбор подхода к проектной верификации
В проекте следует предусмотреть возможность выбора подходов к верификации проектной архитек туры.
оценке полноты проекта и определению степени соответствия МОЕ-локазателям и МОР-критериям.
6.6.1.1 Определение требований к проверкам, анализу, подтверждению или испытаниям
В проекте следует предусмотреть выбор соответствующего метода верификации [осмотра, ана
лиза (в том числе макетов или моделей), подтверждения или испытаний) для оценки того, выполняются
ли функциональные и эксплуатационные требования, проектные характеристики, указанные в проект
ной архитектуре. Матрицу верификации разрабатывают для соотнесения метода проверки (проверок) с
требованиями к функциональной архитектуре и базовой линии требований. В проекте также следует
выбирать работоспособные модели или прототипы (которые могут быть частичными или полными), а
также привлекатьУне привлекать персонал к проекту (в зависимости от целей и задач верификации).
49