Получите образец ТУ или ГОСТа за 3 минуты

Получите ТУ или ГОСТ на почту за 4 минуты

ГОСТ Р 57318-2016

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

57318—

2016

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ
Применение и управление процессами системной инженерии

Издание официальное

Москва

Стандартинформ

2017

Предисловие

1    РАЗРАБОТАН ООО «НИИ экономики связи и информатики «Интерэкомс» (ООО «НИИ «Интер-экомс»)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»

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

4    ВВЕДЕН ВПЕРВЫЕ

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

© Стандартинформ, 2017

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

ГОСТ P 57318—2016

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

3 Термины и определения, сокращения

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

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

3.1.1    приобретающая сторона (acquirer): Правообладатель, который приобретает или получает продукт или услугу от поставщика.

Примечания

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

2    Термин «клиент» является более общим, чем термин «приобретающая сторона», «оператор» или «пользователь», поскольку он включает в себя их роли помимо других.

3.1.2    соглашение (agreement): Взаимное признание сроков и условий, в соответствии с которыми осуществляются рабочие отношения.

Примечание — См. ГОСТ Р ИСО/МЭК 15288—2005.

3.1.3    распределение (allocation): Процедура, применяемая при проектировании системы и направленная на распределение требований к значениям характеристик объекта по компонентам и подсистемам в соответствии с установленным критерием.

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

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

Примечание — См. ГОСТ Р ИСО/МЭК 15288—2005.

3.1.5    ограничение (constraint): Требование, которое способно ограничивать проектное решение или реализацию SEP-процесса и не может быть изменено предприятием.

Примечание — Ограничение обычно является не распространяемым.

3.1.6    потребитель (customer): Организация или лицо, получающие продукцию.

Пример — Клиент, заказчик, конечный пользователь, розничный торговец, бенефициар и покупатель.

Примечания

1    Потребитель по отношению к организации может быть внутренним или внешним.

2    См. ГОСТ ISO 9000-2011.

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

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

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

7

3.1.8    проектная характеристика (design characteristic): Проектные атрибуты или отличительные особенности, которые относятся к поддающемуся измерению описанию продукта или процесса.

3.1.9    проектирование под заданную стоимость (design to cost): Цели производственных затрат (проектирование в пределах заданной стоимости производства продукции) и затрат на жизненный цикл продукции (проектирование в пределах заданной стоимости жизненного цикла), используемых для приближения проекта к контрольным показателям затрат.

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

3.1.10    анализ эффективности (effectiveness analysis): Анализ того, насколько качественно проектное решение будет выполнять или соответствовать ожидаемым эксплуатационным сценариям.

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

3.1.12    конечный продукт (end item): Сущность (аппаратные средства, программное обеспечение, данные, материалы, услуги и/или методы), отождествляемая с SBS-элементом.

3.1.13    предприятие (enterprise): Часть организации, отвечающая за приобретение и поставку продукции и/или услуг в соответствии с соглашениями.

Примечания

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

2    См. ГОСТ Р ИСО/МЭК 15288—2005.

3.1.14    основные средства (facility): Физические средства или оборудование, способствующие выполнению действий (например, здания, инструменты, принадлежности).

Примечание — См. ГОСТ Р ИСО/МЭК 15288—2005.

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

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

3.1.17    системная инженерия с учетом человеческого фактора (human systems engineering): Деятельность, осуществляемая на протяжении жизненного цикла системы, рассматривающая человека как элемент системной инженерии (в том числе сточки зрения удобства эксплуатации, критериев/ показателей эффективности и общих затрат на владение) и включающая определение и обобщение трудовых ресурсов, персонала, его обучения, инженерную психологию, вредные условия производства и проблемы безопасности.

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

3.1.19    спецификация интерфейса (interface specification): Описание основных функциональных, рабочих и проектныхтребований/ограничений на общей границе мехщу двумя или более элементами системы.

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

системами.

3.1.20    жизненный цикл (life cycle): Развитие системы или продукта, которое инициируется воспринимаемой заинтересованной стороной потребностью вплоть до вывода продукта из эксплуатации.

3.1.21    расходы за жизненный цикл системы (life cycle cost): Общий объем инвестиций в разработку, производство, проведение испытаний, распределение, эксплуатацию, техническую поддержку, обучение персонала и вывод из эксплуатации.

8

ГОСТ Р 57318-2016

3.1.22    модель жизненного цикла (life cycle model): Структурная основа процессов и действий, относящихся к жизненному циклу, которая также служит в качестве общей ссылки для установления связей и взаимопонимания сторон.

Примечание — См. ГОСТ Р ИСО/МЭК 15288—2005.

3.1.23    показатель (мера) эффективности (measure of effectiveness; МОЕ): Показатель, с помощью которого приобретающая сторона может измерять уровень своей удовлетворенности продуктами, выпускаемыми в результате технических действий.

3.1.24    критерий оценки выполнения работы; MOP (measure of performance): Инженерный показатель, который определяет проектные требования, необходимые для соответствия установленным.

Примечание — В общем случае для каждого МОЕ может существовать несколько МОР-критериев.

3.1.25    оператор (operator): Лицо или организация, которые вносят вклад в реализацию функциональных возможностей системы и применяют знания, умение и процедуры при выполнении определенной функции.

Примечания

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

2    Некоторые операторы в сочетании с их знаниями, умением и выполняемыми процедурами могут рассматриваться как элемент системы.

3    См. ГОСТ Р ИСО/МЭК 15288—2005.

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

3.1.27    требование (requirement): Документально изложенный критерий, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения.

3.1.28    спецификация, технические требования (specification): Документ, определяющий в полной, точной, проверяемой форме требования, дизайн, поведение или другие свойства системы либо компонента и зачастую процедуры для определения, выполняются ли эти требования.

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

3.1.30    стадия (stage): Период в пределах жизненного цикла системы, относящийся к состоянию системного описания или непосредственно к самой системе.

Примечания

1    Этапы относятся к периодам значительного продвижения системы и достижения запланированных сроков на протяжении жизненного цикла.

2    Этапы могут перекрывать друг друга.

3    См. ГОСТ Р ИСО/МЭК 15288—2005.

3.1.31    правообладатель, заинтересованная сторона (stakeholder): Сторона, имеющая право, долю или претензии на систему или на владение ее характеристиками, удовлетворяющими потребности и ожидания этой стороны.

Примечание — См. ГОСТ Р ИСО/МЭК 15288—2005.

3.1.32    состояние (state): Режим или ситуация в течение срока службы объекта, когда она удовлетворяет определенному условию, выполняет некоторые действия или ожидает определенного события.

3.1.33    поставщик (supplier): Организация или лицо, которые вступают в соглашение с приобретающей стороной на поставку продукта или услуги.

Примечание — См. ГОСТ Р ИСО/МЭК 15288—2005.

3.1.34    система (system): Набор элементов, которые взаимодействуют в соответствии с проектом, в котором элементом системы может быть другая система, называемая подсистемой; система может быть управляющей системой или управляемой системой и включать аппаратные средства, программное обеспечение и взаимодействие с человеком.

3.1.35    архитектура системы (system architecture): Совокупность проектных архитектур для продуктов и процессов их жизненного цикла.

9

3.1.36    структурная декомпозиция элементов системы; SBS (system breakdown structure): Иерархия элементов, связанных процессов жизненного цикла, а также персонала, используемых для назначения коллективов разработчиков, проведения технического анализа, разделения поставленного задания и соответствующего распределения ресурсов между каждым из заданий, что необходимо для достижения намеченных проектом целей.

Примечание — SBS-структуру можно использовать в качестве основы при отслеживании затрат и контроле.

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

3.1.38    анализ компромиссный решений (trade-off analysis): Аналитическая оценка действий по принятию решений, в ходе которых производится выбор из различных требований и альтернативных решений на основе конечной выгоды заинтересованных сторон.

3.1.39    пользователь (user): Лицо или группа лиц, извлекающих пользу в процессе применения системы.

Примечания

1    Роль пользователя и роль оператора могут быть выполнены одновременно или последовательно одним и

тем же лицом или организацией.

2    См. ГОСТ Р ИСО/МЭК 15288—2005.

3.1.40    базовая линия требований (requirements baseline): Фиксированный набор согласованных, проверенных и утвержденных требований к конкретному варианту продукта.

3.2 Сокращения

BIT — встроенное испытание (Built-in test);

FAIT — производство, сборка, интеграция и проведение испытаний (Fabrication, assembly, integration and test);

FIT — локализация отказа/дефекта (Fault-isolation test);

FMEA— анализ видов и последствий отказов (Failure modes and effects analysis);

IPT — комплексная рабочая группа (Integrated product team);

МОЕ — показатель эффективности (Measure of effectiveness);

MOP — критерий оценки выполнения работы (Measure of performance);

SBS — структурная декомпозиция элементов системы (System breakdown structure);

SEMS — основной план-график работ по системной инженерии (Systems engineering master schedule);

SEP — процесс системной инженерии (Systems engineering process);

TPM — технический показатель эффективности (Technical performance measure).

4 Общие требования

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

Для достижения намеченной цели предприятие должно:

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

б)    применять SEP-процесс на каждом уровне системы;

в)    контролировать ход выполнения работ посредством проведения следующих мероприятий:

1)    технический анализ по достижении каждого уровня разработки,

2)    управление рисками,

ГОСТ P 57318—2016

3)    управление данными,

4)    управление интерфейсами,

5)    управление конфигурацией,

6)    количественная оценка хода выполнения работ на основе показателей эффективности;

г)    создавать модели и прототипы для поддержки компромиссных решений;

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

эксплуатации;

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

Особые требования и рекомендации приведены в других разделах настоящего стандарта.

4.1 Процесс системной инженерии

Предприятие должно применять нормативные положения, описанные в разделе 6 и приведенные на рисунке 4, с целью получения технических характеристик, исходных данных и сопутствующих продуктов (см. раздел 5). SEP-процесс является общим процессом решения проблем (механизмом), позволяющим идентифицировать и совершенствовать определения продукта и процесса в системе. Этот процесс применяют на протяжении всего жизненного цикла системы и для всех видов деятельности, связанных с разработкой продуктов, проверкой/проведением испытаний, производством, обучением персонала, эксплуатацией, технической поддержкой, распространением, выводом из эксплуатации, а также с аспектами инженерной психологии. На рисунке 4 изображены подпроцессы SEP-процесса и показано, как их необходимо итерационно выполнять для получения согласованной совокупности требований, способов функционирования и проектных решений. Подпроцессы, задачи и работы SEP-процесса подробно описаны в разделе 6.

ВХОДНЫЕ ДАННЫЕ

ПРОЦЕССА

гС

Анализ требований

>

Конфликты требований и ограничений

Требования базовой линии

Компромиссные требования и воздействия

Валидация требований

)

I___________

Утвержденные требования базовой линии

Функциональный анализ

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

Исследование и оценка компромиссных требований

Система —-1

<

<

К

Функциональная архитектура

Функциональная

верификация

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

I___________

Требования

Верифицированная функциональная к проектным решениям

архитектура

Синтез/обобщение

>

и альтернативам

Исследование и оценка функциональных компромиссов

Анализ

Физическая архитектура

Компромиссное i проектное j

решение i__

и воздействия

Исследование и оценка компромиссного проектного решения

Верификация проекта

Верифицированная физическая архитектура_

Управление/контроль

С

>

– ВЫХОДНЫЕ ДАННЫЕ ПРОЦЕССА

Рисунок 4 — Схема процесса системной инженерии (SEP)

11

4.2    Методы и процедуры системной инженерии

Предприятие должно разработать и поддерживать методы и процедуры управления выполнением SEP-процесса, которые определяют требования к планированию, реализации и контролю разработки продуктов и процессов и интеграции типа «человек — система». Методы и процедуры должны устанавливать парадигму предприятия для системной инженерии, на которой может быть основано обучение персонала, а специфические для проекта мероприятия могут быть адаптированы и выполнены. Методы и процедуры предприятия должны учитывать:

а)    применение SEP-процесса на протяжении всего жизненного цикла проекта;

б)    подготовку и утверждение плана управления работами по системной инженерии;

в)    подготовку и утверждение основного плана-графика работ по системной инженерии (SEMS) и его детализацию;

г)    подготовку и утверждение интегрированного комплекта документов;

д)    мониторинг и отчетность о ходе выполнения работ по проекту;

е)    подготовку и выполнение технического анализа;

сбор и поддержание информации в интегрированном хранилище;

и) постоянное совершенствование продукции и процессов.

4.3    Планирование технических мероприятий

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

4.3.1    План технического проектирования

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

4.3.2    Основной план-график работ

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

4.3.3    Детализированный план-график

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

ГОСТ P 57318—2016

4.3.4    Технические планы

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

4.4    Стратегии развития

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

4.5    Моделирование и макетирование

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

4.6    Интегрированное хранилище

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

4.6.1    Данные

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

4.6.2    Технические средства

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

4.7    Интегрированный комплект документов

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

13

в 4.7.1—4.7.4, и дополняться после каждого применения SEP-процесса для представления более подробной информации на каждом уровне разработки.

Таблица 1 —Содержимое интегрированного комплекта документов

Интегрированный комплект документов должен включать (но не ограничиваться) следующие элементы

A.    Аппаратные средства:

1)    компоновочные чертежи (Arrangement drawings) —документы, содержащие взаимосвязи между основными подсистемами или компонентами системы;

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

3)    схемы электрических соединений (Connection drawings) —документы, содержащие схемы электрических соединений установок или их составных устройств и частей;

4)    конструктивные чертежи (Construction drawings) — документы, содержащие чертежи конструкций зданий или

сооружений;

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

6)    деталировочные чертежи (Detail drawings) — документы, содержащие описание и полные требования к готовому(ым) субкомпоненту(ам), указанному(ым) на чертеже;

7)    чертежи в вертикальных проекциях (Elevation drawings) —документы, содержащие вертикальные проекции зданий и сооружений (или профили оборудования);

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

9)    монтажные чертежи (Installation drawings) — документы, содержащие информацию об общей конфигурации и информацию о монтаже элемента на креплении или на связанном с ним элементе;

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

11)    блок-схемы программного управления (Numerical control drawings) — документы, содержащие полные проектные и функциональные технические требования и требования к продукту для облегчения производства с помощью ленточного контроллера;

12)    схемы размещения трубопроводов (Piping diagrams) — документы, содержащие схему взаимных соединений трубопроводов, труб или шлангов и при необходимости последовательность потоков гидравлических жидкостей или сжатого воздуха в системе;

13)    схемы монтажных соединений (Wire lists) — документ в виде книги с чертежами, содержащий табличные данные и инструкции, необходимые для выполнения проводных соединений компонентов или между компонентами;

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

15)    схемы прокладки кабелей и кабельных жгутов (Wiring and cable harness drawings) — документ, содержащий пути прокладки групп сбандажированных определенным образом проводов, что упрощает их монтаж;

16)    макеты, имитационные модели или проектные базы данных для проектирования (Models, simulations, or design databases) дают физическое, аналитическое или цифровое представление о любом элементе, указанном в 1)—15)

Б. Программное обеспечение:

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

2)    программные листинги исходных кодов (Software source code listings) — документ, содержащий действующие инструкции по работе с исходными кодами, которые представляют собой конечную реализацию

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

1)    трудовые ресурсы, персонал и учебные материалы (Manpower, personnel, and training documentation) —документ, содержащий знания, навыки и способности, требования к обучению и пригодности людей к эксплуатации, техническому обслуживанию/поддержке системы на протяжении всего ее жизненного цикла;

2)    компоновочные чертежи рабочего пространства (Workspace arrangement drawings) — документ, иллюстрирующий взаимосвязи людей, которые обеспечивают поддержку каждого этапа жизненного цикла с основными подсистемами (или компонентами системы);

Окончание таблицы 1

Интегрированный комплект документов должен включать (но не ограничиваться) следующие элементы

3)    технические требования и чертежи аппаратуры сопряжения (интерфейсов) (Interface design specifications and drawings) — документ, содержащий интерфейсы между людьми, которые обеспечивают поддержку жизненного цикла системы и любые другие аспекты системы, включая интерфейсы типа «человек — человек», «человек — аппаратные средства» и «человек— программное обеспечение»;

4)    диаграммы последовательности операций (Operational sequence diagrams) — графическое представление этого документа содержит описание взаимодействия между людьми и другими подсистемами (или компонентами системы) в результате выполнения задачи стечением времени;

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

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

Г. Элементы, относящиеся к процессам жизненного цикла:

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

4.7.1    Аппаратные средства

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

4.7.2    Программное обеспечение

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

4.7.3    Процессы жизненного цикла

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

4.7.4    Роль человека

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

4.8 Древо спецификаций

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

15

в том числе интерфейсы между аппаратными средствами (hardware-hardware interface), программноаппаратными интерфейсами (hardware-software interface), интерфейсы между различным программным обеспечением (software-software interface), интерфейсы типа «человек — человек» (human-human interface), «человек — аппаратные средства» (human-hardware interface) и «человек — программное обеспечение» (human-software interface). Различные спецификации, которые полностью определяют элементы разрабатываемой системы, приведены на рисунке 5. Поскольку проект в целом является высокоуровневой сущностью, то на рисунке 5 демонстрируется, насколько такие мероприятия можно рассматривать в контексте системы. Древо технических требований должно разрабатываться в направлении сверху вниз. Количество уровней на этом древе зависит от этапа жизненного цикла (см. раздел 5), причем самый низкий уровень будет зависеть от сложности проектного элемента и от того, решение какого уровня должно быть принято, чтобы изготовить, приобрести или многократно использовать продукт, связанный сданной спецификацией. В случае персонала, который обеспечивает поддержу системы на протяжении всего ее жизненного цикла, решение о том, обладает ли персонал соответствующими знаниями, навыками и способностями, или о том, каким должен быть уровень подбора кадров, приема на работу или обучения персонала. Этим уровнем может быть уровень подсистемы или любой уровень, вплоть до уровня компонентов.

4.9 Древо чертежей

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

Рисунок 5 — Блок-схема древа спецификаций

ГОСТ P 57318—2016

Содержание

1    Общие сведения……………………………………………………………1

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

1.2    Назначение…………………………………………………………….2

1.3    Порядок использования настоящего    стандарта…………………………………..2

1.4    Структура настоящего стандарта…………………………………………….6

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

3    Термины и определения, сокращения…………………………………………….7

3.1    Термины и определения…………………………………………………..7

3.2    Сокращения…………………………………………………………..10

4    Общие требования…………………………………………………………10

4.1    Процесс системной инженерии……………………………………………..11

4.2    Методы и процедуры системной инженерии……………………………………12

4.3    Планирование технических мероприятий……………………………………..12

4.4    Стратегии развития……………………………………………………..13

4.5    Моделирование и макетирование……………………………………………13

4.6    Интегрированное хранилище………………………………………………13

4.7    Интегрированный комплект документов……………………………………….13

4.8    Древо спецификаций…………………………………………………….15

4.9    Древо чертежей………………………………………………………..16

4.10    Структурная декомпозиция элементов системы………………………………..17

4.11    Интеграция работ по системной инженерии …………………………………..18

4.12    Технический анализ…………………………………………………….18

4.13    Управление качеством…………………………………………………..18

4.14    Совершенствование продукции и процессов…………………………………..18

5    Применение системной инженерии в рамках жизненного цикла системы………………….19

5.1    Этап определения системы………………………………………………..20

5.2    Этап предварительного проектирования………………………………………23

5.3    Этап детализированного проектирования……………………………………..27

5.4    Этапы производства, сборки, интеграции и проведения испытаний…………………..30

5.5    Этапы производства и технической поддержки………………………………….32

5.6    Параллельный инжиниринг процессов жизненного цикла………………………….33

6    Процесс системной инженерии………………………………………………..34

6.1    Анализ требований………………………………………………………34

6.2    Валидация требований…………………………………………………..39

6.3    Функциональный анализ………………………………………………….41

6.4    Функциональная верификация……………………………………………..44

6.5    Синтез……………………………………………………………….45

6.6    Проектная верификация………………………………………………….49

6.7    Анализ системы………………………………………………………..52

6.8    Руководство…………………………………………………………..56

Приложение А (справочное) Роль системной инженерии на предприятии…………………..61

Приложение Б (справочное) План организации работ по системной инженерии………………65

Приложение В (справочное) Взаимосвязь между настоящим стандартом

и ГОСТ Р ИСО/МЭК 15288 …………………………………………. 72

III

ГОСТ P 57318—2016

4.10 Структурная декомпозиция элементов системы

В проекте следует сформировать структурную декомпозицию элементов системы SBS для отображения иерархии продуктов и процессов, которые составляют архитектуру системы. SBS-структуру можно использовать в проекте для разработки и контроля комплекса мероприятий по выполнению проекта и преобразования этого комплекса в рабочие программы, процессы управления конфигурациями, распределения ресурсов, отслеживания изменений требований, управления интерфейсом, предоставления отчетности о затратах и ситуационного планирования. Процессы жизненного цикла закреплены за продуктами, сборками и при необходимости за SBS-уровнем подсборки, а также за людьми, которые обеспечивают поддержку жизненного цикла. Спецификации трудовых ресурсов, персонала и обучения, которые определяют знания, умения, способности, доступность и обучение, необходимы для людей, которые обеспечивают поддержку системы, ее подсистем и компонентов, разработанных для адекватного управления и поддержки системы на протяжении всего ее жизненного цикла. Процессы жизненного цикла могут определяться на каждом SBS-уровне (по мере необходимости) для обеспечения устойчивости жизненного цикла для элементов продукта. Различные элементы системы и процессы жизненного цикла, которые составляют SBS-структуру, приведены на рисунке 6. На нем показаны три основных уровня развития системы: определение системы, предварительное проектирование и детализированное проектирование, через которые система проходит согласно разделу 5.

Рисунок 6 — Блок-схема структурной декомпозиции элементов системы

17

Введение

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

В настоящем стандарте понятие «системная инженерия» определяет подход к разработке продукции и используется в контексте системы. Целью настоящего стандарта не является описание организационных сущностей, которые выполняют работы по системной инженерии или распределению компетенций персонала, вовлеченного в SEP-процессы. Его целью является предоставление руководящих положений в части того, что отдельные организационные сущности, предприятие в целом и его персонал должны делать, чтобы произвести качественную конкурентоспособную продукцию, которая будет востребована на рынке, а также как обеспечить приемлемый доход от вложенных инвестиций, соответствовать ожиданиям заинтересованных сторон и оправдать общественные ожидания.

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

IV

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

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ

Применение и управление процессами системной инженерии

Industrial automation systems and integration.

Application and management of the systems engineering processes

Дата введения — 2017—06—01

1 Общие сведения

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

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

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

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

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

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

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

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

Издание официальное

1.2    Назначение

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

Настоящий стандарт можно использовать совместно с ГОСТ Р ИСО/МЭК 15288, в нем подробно описаны требования к процессам системной инженерии, а также требования в части управления, которые восполняют или дополняют процессы, рассмотренные в ГОСТ Р ИСО/МЭК 15288, однако в последнем приведены дополнительные определения процессов и рекомендации, поддерживающие определение модели жизненного цикла и применение процессов системной инженерии для поддержки жизненного цикла системы.

1.3    Порядок использования настоящего стандарта

1.3.1    Соответствие настоящему стандарту

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

1.3.2    Рекомендации и вопросы адаптации

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

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

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

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

1.3.3    Парадигма системы

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

ГОСТ P 57318—2016

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

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

1.3.3.1 Иерархия элементов системы

Система, как правило, состоит из связанных между собой элементов (подсистем и компонентов) и их интерфейсов. Кроме того, эти элементы включают либо специалистов, необходимых для разработки, реализации, проведения испытаний, распространения, эксплуатации, технической поддержки или вывода из эксплуатации отдельных компонентов системы, либо обучение персонала для выполнения ими своих функций в системе. На рисунке 1 приведена иерархия элементов, которые в совокупности образуют систему. Эта обобщенная иерархия (системы) является ключевой в настоящем стандарте, поскольку она объединяет между собой древа системной архитектуры, технических требований и графических материалов, структурную декомпозицию системы SBS, технические отчеты и базовые линии конфигурации. Многие элементы в иерархии системы по ее классическому определению можно считать (отдельной) «системой», но на самом деле они в иерархии всей системы представляют собой подсистему. Аналогично процессы жизненного цикла представляют собой подсистемы в иерархии общей системы.

Система

I

Продукт/изделие

I

Подсистема

\

Сборки (узлы)

\

Компоненты

I

Субкомпоненты

}

Подсборки

Субкомпоненты

Детая и/части

I

Детая и/части

Рисунок 1 — Иерархия элементов в системе

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

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

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

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

3

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

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

1.3.3.2 Структуры из компоновочных элементов

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

Продукт

Процессы распределения и поддержки

Процессы эксплуатации и обучения

Процесс вывода из эксплуатации

Процессы разработки и испытаний

Подсистема

Подсистема

Подсистема

Подсистема

Подсистема

^ Элементы иерархии продукта □ Процессы жизненного цикла

Рисунок 2 — Основные компоновочные элементы системы

1.3.3.3 Определение продукта и процесса жизненного цикла

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

Система

Производ

ственный

процесс

–    Основные средства

–    Оборудование

–    Процедуры

– Прикладное

Подсистема

Подсистема

программное

обеспечение

–    Компьютерные ресурсы

–    Персонал

–    Поставщики/ подрядчики

^ Элементы иерархии продукта ^ Процессы жизненного цикла

Основные средства

Оборудование/

инструменты

Процедуры

Прикладное

программное

обеспечение

Компьютерные

ресурсы

Запасы деталей

Персонал

Поставщики/

подрядчики

Контроль

качества

Процессы распределения и поддержки

Процессы эксплуатации и обучения

Процесс вывода из эксплуатации

–    Основные средства

–    Оборудование/ инструменты

–    Процедуры

–    Прикладное программное обеспечение

–    Компьютерные ресурсы

–    Запасные части

–    Ремонтники

–    Поставщики/ подрядчики

–    Основные средства –    Основные средства

–    Оборудование/    –    Оборудование/

инструменты    инструменты

–    Процедуры    –    Процедуры

–    Прикладное    –    Персонал

программное

обеспечение

–    Компьютерные ресурсы

–    Операторы

–    Инструкторы

Рисунок 3 — Определен

ие процессов жизненного цикла

а)    Разработка

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

б)    Производство

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

в)    Проведение испытаний

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

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

г)    Распространение

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

д)    Эксплуатация

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

е)    Техническая поддержка

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

ж)    Обучение персонала

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

5

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

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

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

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

1.4 Структура настоящего стандарта

В разделе 1 рассмотрены область применения, цели и структура настоящего стандарта.

В разделе 2 приведены нормативные ссылки на документы, используемые в настоящем стандарте.

В разделе 3 приведены термины и определения, а также сокращения, используемые в настоящем стандарте.

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

В разделе 5 приведено описание применения SEP-процесса путем определения системы, подсистемы, производства и технической поддержи.

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

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

В приложении Б приведен шаблон, облегчающий предприятию подготовку плана по системному проектированию.

В приложении В обсуждается ряд ключевых различий между настоящим стандартом и ГОСТ Р ИСО/МЭК 15288.

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

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

ГОСТ ISO 9000-2011 Системы менеджмента качества. Основные положения и словарь

ГОСТ Р ИСО 21504-2016 Управление проектами, программами и портфелем проектов. Руководство по управлению портфелем проектов

ГОСТ Р ИСО/МЭК 15288—2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем

ГОСТ Р ИСО/МЭК 12207—2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

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

1 Общие сведения

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

     1.2 Назначение

     1.3 Порядок использования настоящего стандарта

     1.4 Структура настоящего стандарта

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

3 Термины и определения, сокращения

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

     3.2 Сокращения

4 Общие требования

     4.1 Процесс системной инженерии

     4.2 Методы и процедуры системной инженерии

     4.3 Планирование технических мероприятий

     4.4 Стратегии развития

     4.5 Моделирование и макетирование

     4.6 Интегрированное хранилище

     4.7 Интегрированный комплект документов

     4.8 Древо спецификаций

     4.9 Древо чертежей

     4.10 Структурная декомпозиция элементов системы

     4.11 Интеграция работ по системной инженерии

     4.12 Технический анализ

     4.13 Управление качеством

     4.14 Совершенствование продукции и процессов

5 Применение системной инженерии в рамках жизненного цикла системы

     5.1 Этап определения системы

     5.2 Этап предварительного проектирования

     5.3 Этап детализированного проектирования

     5.4 Этапы производства, сборки, интеграции и проведения испытаний

     5.5 Этапы производства и технической поддержки

     5.6 Параллельный инжиниринг процессов жизненного цикла

6 Процесс системной инженерии

     6.1 Анализ требований

     6.2 Валидация требований

     6.3 Функциональный анализ

     6.4 Функциональная верификация

     6.5 Синтез

     6.6 Проектная верификация

     6.7 Анализ системы

     6.8 Руководство

Приложение А (справочное) Роль системной инженерии на предприятии

Приложение Б (справочное) План организации работ по системной инженерии

Приложение В (справочное) Взаимосвязь между настоящим стандартом и ГОСТ Р ИСО/МЭК 15288

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30
Николай Иванов

Эксперт по стандартизации и метрологии! Разрешительная и нормативная документация.

Оцените автора
Все-ГОСТЫ РУ
Добавить комментарий