ГОСТ Р 57318-2016. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Применение и управление процессами системной инженерии

(утв. и введен в действие Приказом Росстандарта от 06.12.2016 № 1947-ст)

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

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

ПРИМЕНЕНИЕ И УПРАВЛЕНИЕ ПРОЦЕССАМИ СИСТЕМНОЙ ИНЖЕНЕРИИ

Industrial automation systems and integration. Application and management of the systems engineering processes

ГОСТ Р 57318-2016

Предисловие

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и) Вывод из эксплуатации

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

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

При проектировании продуктов и процессов жизненного цикла человека следует рассматривать в качестве элемента системы [как оператора, ремонтника (специалиста по техническому обслуживанию и ремонту), члена производственного и обучающего коллективов и т.д.] с целью понимания проблем интеграции человека/системы и обеспечения того, что продукты системы являются технологичными, ремонтопригодными и полезными и что процессы в системе оптимизированы и обеспечивают должный уровень качества производства и снижение общих производственных затрат. На рисунке 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 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

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

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

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

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

Примечания

1 Другими терминами, обычно связанными с данным термином, являются термины «покупатель», «клиент» и «заказчик». При этом приобретающая сторона может одновременно быть владельцем, пользователем или эксплуатирующей организацией <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): Расположение проектных элементов, обеспечивающее получение проектного решения для продукта или процесса жизненного цикла, которое предназначено для удовлетворения требований к функциональной архитектуре и базовой линии.

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): Общий объем инвестиций в разработку, производство, проведение испытаний, распределение, эксплуатацию, техническую поддержку, обучение персонала и вывод из эксплуатации.

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

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

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

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

Примечание - В общем случае для каждого MOE может существовать несколько MOP-критериев.

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): Совокупность проектных архитектур для продуктов и процессов их жизненного цикла.

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);

MOE — показатель эффективности (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. управление рисками,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.6.1 Данные

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

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

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

Таблица 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.11.1 Параллельная инженерия

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

4.11.2 Комплексные коллективы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.14.1 Реинжиниринг

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

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

4.14.2 Самооценка

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

4.14.3 Анализ полученного опыта

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

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

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

• этапы разработки:

а) определение системы;

б) определение подсистем;

1. предварительное проектирование подсистем (preliminary design of subsystems),

2. детализированное проектирование компонентов подсистем (detailed design of subsystem components),

3. FAIT-процесс;

• этапы выполнения работ:

а) производство;

б) техническая поддержка.

Приведенные выше этапы изображены на рисунке 7.

Определение системы	Определение подсистем
	Предварительное проектирование	Детализированное проектирование	Производство, сборка, интеграция/сопряжение, проведение испытаний FAIT

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

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

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

5.1.1 Определение системы

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

5.1.1.1 Концепция системы

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

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

5.1.1.2 Исходные планы технического проектирования

В проекте следует создавать требуемые планы технического проектирования (engineering plan) для жизненного цикла системы, которые должны включать:

а) критерии для мероприятий, выполняемых для оценки хода определения системы;

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

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

5.1.1.3 Подсистемы и интерфейсы подсистем

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

5.1.1.4 Определение проблем, связанных с интерфейсом типа «человек — система»

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

5.1.1.5 Факторы, влияющие на качество жизненного цикла системы

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

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

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

5.1.2 Спецификации

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

5.1.2.1 Спецификации на интерфейсы системы, продукта и подсистемы

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

5.1.2.2 Спецификации на систему и продукт

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

5.1.2.3 Предварительные спецификации на подсистемы

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

5.1.2.4 Полные предварительные спецификации на интерфейс типа «человек — система»

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

5.1.2.5 Полные предварительные спецификации на трудовые ресурсы, персонал и его обучение

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

5.1.3 Базовые линии конфигурации

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

5.1.3.1 Базовые линии системы

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

5.1.3.2 Базовые линии запроектированной подсистемы

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

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

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

5.1.4.1 Анализ альтернативных концепций

Для выбора альтернативной концепции (или нескольких концепций), в которой будут определены мероприятия, описанные в 5.1.1.2 - 5.1.3.2, в проекте при необходимости следует предусмотреть анализ альтернативных концепций, в ходе которого необходимо оценивать каждую концепцию со следующих точек зрения:

а) наиболее целесообразное распределение продуктов и подсистем, обеспечивающее обоснованную концепцию системы;

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

в) выполнение спецификаций на интерфейсы системы и продуктов, а также предварительной спецификации на систему;

г) описание базовых линий системы;

д) оценка рисков, связанных с конкретной концепцией;

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

5.1.4.2 Анализ определения системы

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

а) определение обладает достаточной степенью зрелости и соответствует SEMS-критериям;

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

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

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

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

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

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

5.2.1 Предварительное определение подсистемы

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

5.2.1.1 Сборки и их интерфейсы

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

5.2.1.2 Компоненты и их интерфейсы

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

5.2.1.3 Риски для подсистемы и компонентов

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

5.2.1.4 Определение проблем, связанных с интерфейсом «человек — система»

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

5.2.1.5 Показатели качества жизненного цикла

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

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

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

5.2.2 Спецификации на подсистемы

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

5.2.2.1 Спецификации на систему и продукт

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

5.2.2.2 Спецификации на подсистемы

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

5.2.2.3 Спецификации на интерфейс компонентов

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

5.2.2.4 Предварительные спецификации на компоненты

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

5.2.2.5 Корректировка предварительных спецификаций на интерфейс типа «человек — система»

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

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

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

5.2.3 Базовые линии конфигурации

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

5.2.3.1 Базовые линии системы

На этапе предварительного проектирования в рамках проекта необходимо обновлять и контролировать все изменения в базовых линиях системы.

5.2.3.2 Изменение базовых линий системы с учетом результатов проектирования

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

5.2.3.3 Изменение базовых линий компонентов с учетом выполненных работ

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

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

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

5.2.4.1 Анализ подсистем

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

а) степень зрелости определения подсистемы в достаточной мере соответствует SEMS-критериям;

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

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

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

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

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

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

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

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

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

5.3.1 Детализированное определение подсистем

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

5.3.1.1 Определение компонентов

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

5.3.1.2 Риски на уровне компонентов

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

5.3.1.3 Определение проблем, связанных с интерфейсом типа «человек — система»

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

5.3.1.4 Показатели качества жизненного цикла системы

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

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

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

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

В проекте следует предусмотреть корректировку необходимых планов технического проектирования и технического плана (engineering and technical plans) для учета изменений, вызванных SEP-процессом на этапе детализированного проектирования для определения подсистем и учета планирования на FAIT-этапе.

5.3.2 Спецификации

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

5.3.2.1 Спецификации на систему, продукт, подсистемы и сборки

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

5.3.2.2 Спецификации на компоненты

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

5.3.2.3 Обновление спецификаций на интерфейс типа «человек — система»

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

5.3.2.4 Обновление спецификаций на трудовые ресурсы, персонал и обучение

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

5.3.3 Базовые линии конфигурации

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

5.3.3.1 Обновление базовых линий системы и базовых линий с учетом результатов проектирования

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

5.3.3.2 Установление базовых линий с учетом выполненных работ

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

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

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

5.3.4.1 Анализ компонентов

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

а) каждое детализированное определение компонента достаточно хорошо продумано и удовлетворяет показателям эффективности/качества работы (MOE/MOP);

б) спецификации на компоненты являются адекватными и содержат достаточно данных для определения концепции компонента;

в) риски, связанные с компонентами и процессами жизненного цикла, оценены и снижены до уровня, приемлемого для поддержки FAIT;

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

д) решения в части конфигурации определения детализированных компонентов приняты с учетом результатов анализа и технических данных.

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

5.3.4.2 Анализ подсистем

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

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

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

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

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

5.4.1 Системная интеграция и проведение испытаний

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

5.4.2 Анализ, устранение недостатков и повторные испытания

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

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

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

5.4.4 Спецификации

В проекте следует предусмотреть корректировку и контроль всех изменений в утвержденных спецификациях.

5.4.5 Базовые линии конфигурации

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

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

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

5.4.6.1 Анализ готовности к испытаниям

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

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

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

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

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

5.4.6.2 Функциональный аудит конфигурации

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

5.4.6.3 Анализ для производственной аттестации

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

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

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

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

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

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

е) процедуры обработки рисков соответствуют требованиям производства;

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

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

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

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

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

Рисунок 8 — Перечень работ на этапе производства и технической поддержки

5.5.1 Системная продукция

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

5.5.1.1 Производственно-технологические недостатки

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

5.5.1.2 Утилизация побочных продуктов и отходов

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

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

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

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

5.5.4 Совершенствование системы

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

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

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

5.5.4.2 Спецификации

В проекте следует предусмотреть корректировку и контроль всех изменений в утвержденных спецификациях.

5.5.4.3 Базовые линии конфигурации

В проекте следует предусмотреть корректировку и контроль всех изменений установленных базовых линий.

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

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

Рисунок 9 — Параллельный инжиниринг процессов жизненного цикла

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

5.6.1 Разработка процессов жизненного цикла

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

5.6.2 Спецификации

В проекте следует предусмотреть подготовку и контроль спецификаций того же типа, что и в 5.1 - 5.5 (для жизненного цикла процессов и услуг).

5.6.3 Базовые линии

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

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

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

Рисунок 10 — Анализ требований

6.1.1 Определение ожиданий заинтересованных сторон

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

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

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

в) естественные и искусственно созданные среды, в которых продукт(ы) могут функционировать или эксплуатироваться;

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

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

6.1.2 Определение проектных и производственных ограничений

Предприятие должно выявлять и определять проектные и производственные ограничения, которые влияют на проектные решения.

6.1.2.1 Проектные ограничения

Проектными ограничениями могут быть следующие:

а) утвержденные спецификации и базовые линии, разработанные при предыдущих применениях SEP-процесса;

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

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

г) наличие автоматизированных (или рекомендованных к применению) средств;

д) механизмы управления (контроля);

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

ж) повторно используемые и готовые коммерческие продукты (COTS).

6.1.2.2 Производственные ограничения

Производственными ограничениями (уникальными для конкретного предприятия) могут быть:

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

б) общие спецификации, стандарты или рекомендации, используемые на предприятии;

в) методики и процедуры;

г) отраслевые технологии;

д) установленные в жизненном цикле процессов функциональные возможности;

е) распределение физических, финансовых и человеческих ресурсов по техническим мероприятиям.

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

6.1.3 Определение внешних ограничений

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

а) государственное и международное законодательство и нормативы;

б) технологическая база;

в) промышленные, международные и другие общие спецификации, стандарты и рекомендации;

г) технические требования, стандарты и рекомендации, связанные с человеком;

д) доступность трудовых ресурсов, набор и отбор персонала;

е) конкурентные возможности продукции.

6.1.4 Определение рабочих сценариев

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

6.1.5 Определение показателей эффективности

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

6.1.6 Определение границ системы

В проекте следует предусмотреть определение:

а) какие элементы системы находятся под проектным контролем и какие элементы не подпадают под подобный контроль;

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

6.1.7 Определение интерфейсов

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

6.1.8 Определение среды применения

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

6.1.9 Определение концепций жизненного цикла процесса

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

6.1.9.1 Трудовые ресурсы

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

6.1.9.2 Персонал

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

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

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

6.1.9.4 Инженерная психология

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

6.1.9.5 Безопасность

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

6.1.10 Определение функциональных требований

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

6.1.11 Определение требований к рабочим характеристикам

В проекте следует предусмотреть определение требований к рабочим характеристикам каждой функции системы. Эти требования должны определять качество выполнения функциональных требований, необходимое для соответствия MOE-показателям. Эти требования к рабочим характеристикам соответствуют MOP-критериям, которые отнесены к различным подфункциям при функциональном декомпозиционном анализе и по которым оценивают проектные решения [полученные в результате синтеза (см. 6.5)]. Обычно существует несколько MOP-критериев для каждого MOE-показателя, связывающего соответствующие области изменения характеристик.

6.1.12 Определение режимов работы

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

6.1.13 Определение технических показателей эффективности

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

6.1.14 Определение проектных характеристик

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

6.1.15 Определение эргономических факторов

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

6.1.16 Установление базовой линии требований

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

а) Для эксплуатационного аспекта:

1. обоснование производственной необходимости;

2. результаты анализа эксплуатации системы;

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

4. состояния/события, на которые должны реагировать системные продукты;

5. эксплуатационные ограничения, в том числе с учетом MOE-показателей;

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

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

8. определение операций, необходимых для обеспечения безопасности;

9. концепции процесса жизненного цикла, учитывающие MOE-показатели, наиболее значимые MOP-критерии и уже существующие продукты и услуги;

10. оперативные интерфейсы с другими системами, платформами, людьми и/или продуктами;

11. границы системы.

б) Для функционального аспекта:

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

2. требования к характеристикам, включая качественные (насколько хорошо), количественные (в каком объеме) и временные (циклические) (насколько долго, насколько часто) требования;

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

4. критерии для выбора TPM-показателей;

5. функциональные требования к интерфейсу с внешними системами, системами более высокого уровня или с взаимодействующими системами, платформами, персоналом и/или продуктами;

6. режимы работы;

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

в) Для конструктивного аспекта:

1. ранее утвержденные спецификации и базовые линии;

2. проектные интерфейсы с другими системами, платформами, персоналом и/или продуктами;

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

4. характеристики оператора(ов) и вспомогательного персонала, включая особые требования к конструкции, соответствующим перемещениям или визуальные/нагрузочные ограничения;

5. характеристики информационных дисплеев и органов управления;

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

7. конструктивные ограничения, в том числе проектные, производственные и внешние ограничения, которые ограничивают конструктивные решения и/или процедуры разработки;

8. возможности проектирования и постепенного планового развития.

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

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

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

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

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

6.2.1 Сравнение требований с ожиданиями заинтересованных сторон

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

6.2.2 Сравнение требований с производственными и конструктивными ограничениями

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

6.2.3 Сравнение требований с внешними ограничениями

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

6.2.4 Определение отклонений и конфликтов

В проекте следует предусмотреть определение и оценку отклонений и конфликтов (противоречий), возникающих при выполнении работ по 6.2.1 - 6.2.3 и требующих разрешения путем перебора требований, проанализированных при уточнении базовой линии требований.

6.2.5 Утверждение прошедшей валидацию базовой линии требований

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

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

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

а) описание проблемы, определенной при анализе требований с более высокой детализацией;

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

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

6.3.1 Функциональный содержательный анализ

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

6.3.1.1 Анализ функционального поведения

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

6.3.1.2 Определение функциональных интерфейсов

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

6.3.1.3 Распределение требований к рабочим характеристикам системы

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

6.3.2 Функциональная декомпозиция

В проекте необходимо предусмотреть декомпозицию системы на подфункции с целью определения:

а) альтернативных структур подфункций и последовательностей;

б) функциональных интерфейсов;

в) требований к рабочим характеристикам.

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

6.3.2.1 Определение подфункций

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

6.3.2.2 Определение состояний и режимов подфункций

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

6.3.2.3 Определение функциональной циклограммы

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

6.3.2.4 Определение потоков данных и сигналов управления

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

6.3.2.5 Определение режимов функциональных отказов и их последствий

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

6.3.2.6 Определение функций мониторинга безопасности

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

6.3.3 Создание функциональной архитектуры

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

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

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

6.4.1 Определение процедур верификации

В проекте следует предусмотреть определение процедур верификации созданной функциональной архитектуры.

6.4.2 Оценка проведения верификации

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

6.4.2.1 Верификация полноты архитектуры

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

6.4.2.2 Верификация функциональных и эксплуатационных показателей

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

6.4.2.3 Верификация выполнения ограничений

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

6.4.3 Определение отклонений и конфликтов

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

6.4.4 Создание верифицированной функциональной архитектуры

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

6.5. Синтез

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

6.5.1 Группирование и распределение функций

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

6.5.2 Идентификация альтернативных проектных решений

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

6.5.3 Оценка безопасности и экологических опасностей

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

6.5.4 Оценка показателей качества жизненного цикла

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

6.5.5 Оценка технологических требований

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

6.5.6 Определение конструктивных и эксплуатационных характеристик

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

6.5.7 Определение физических интерфейсов

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

6.5.8 Определение возможностей стандартизации

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

6.5.9 Определение доступности готовых к использованию продуктов

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

6.5.10 Определение альтернативы «изготавливать или покупать»

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

6.5.11 Разработка моделей и прототипов

В проекте следует предусмотреть разработку моделей и/или прототипов:

а) для определения и снижения рисков, связанных с интеграцией имеющихся и новых технологий;

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

в) проверки того, что проектное решение отвечает функциональной архитектуре и базовой линии требований.

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

6.5.12 Оценка видов отказов, их последствий и критичности

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

6.5.13 Оценка потребности в проведении тестирования решений

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

6.5.14 Оценка развития производственных возможностей

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

6.5.15 Окончательное оформление проектных решений

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

6.5.16 Инициализация поэтапного развития

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

6.5.17 Формирование комплекта документов по интеграции

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

6.5.18 Создание проектной архитектуры

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

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

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

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

б) проектная архитектура соответствует прошедшей валидацию базовой линии.

6.6.1 Выбор подхода к проектной верификации

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

6.6.1.1 Определение требований к проверкам, анализу, подтверждению или испытаниям

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

6.6.1.2 Определение процедур верификации

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

6.6.1.3 Создание среды верификации

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

6.6.2 Оценка проведения верификации

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

6.6.2.1 Верификация полноты архитектуры

В проекте необходимо проводить верификацию, что:

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

б) требования к функциональной архитектуре распределяются и соотносятся с проектной архитектурой.

Все внутренние и внешние проектные интерфейсы должны прослеживаться (в восходящем и нисходящем порядке) до исходных требований.

6.6.2.2 Верификация функциональных и эксплуатационных показателей

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

6.6.2.3 Верификация соблюдения ограничений

Проект должен подтверждать, что:

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

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

6.6.3 Определение отклонений и конфликтов

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

6.6.4 Верифицированная проектная архитектура

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

6.6.5 Верифицированные проектные архитектуры процессов жизненного цикла

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

6.6.6 Верифицированная архитектура системы

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

6.6.7 Создание спецификаций и базовой линии конфигурации

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

6.6.8 Разработка структурной декомпозиции системы (SBS)

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

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

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

6.7.1 Оценка конфликтных требований

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

6.7.2 Оценка функциональных альтернатив

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

6.7.3 Оценка проектных альтернатив

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

6.7.4 Определение факторов риска

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

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

б) как можно выявлять факторы риска, если они имеют место быть;

в) как фактор риска может влиять на затраты, план-график и результаты деятельности.

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

6.7.5 Определение области применения анализа компромиссных решений

В проекте следует предусмотреть область применения анализа компромиссных решений. К данному типу анализа может относиться:

а) Субъективный анализ — его выбор может делаться на основании решения аналитика или разработчика, которое не требует особой строгости для формального изучения и для которого последствия не слишком важны; имеется лишь одно альтернативное решение, которое выглядит явно лучше других; и/или отсутствует время, необходимое для более формального подхода (большинство анализов компромиссных решений, выполняемых для решения задач в рамках SEP-процесса, носят субъективный характер);

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

в) Формальный анализ — анализ, формально проводимый при использовании результатов, рассмотренных в рамках технического анализа.

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

6.7.5.1 Выбор методологии и критериев успеха

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

6.7.5.2 Определение альтернативных решений

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

6.7.5.3 Создание среды для анализа альтернативных (компромиссных) решений

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

6.7.6 Проведение анализа компромиссных решений

В проекте следует предусмотреть выполнение задач 6.7.6.1 - 6.7.6.4 с той степенью точности, которая необходима для завершения анализа компромиссных решений:

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

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

в) синтеза, поддерживающего проектные решения.

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

6.7.6.1 Анализ затрат в части жизненного цикла

В проекте следует предусмотреть анализ затрат на проект и на заказчика альтернативных подходов к рассматриваемой системе и оценке эффективности системы. Анализ затрат на жизненный цикл позволяет:

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

б) давать необходимую информацию о затратах для оценки эффективности системы;

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

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

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

6.7.6.2 Анализ системы и экономической эффективности

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

а) определения влияния результатов деятельности на затраты;

б) рассмотрения добавленной стоимости как функции затрат;

в) поддержки идентификации требуемых рабочих характеристик и требований;

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

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

6.7.6.3 Анализ безопасности и воздействия на окружающую среду

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

6.7.6.4 Количественная оценка факторов риска

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

6.7.7 Выбор вариантов обработки рисков

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

6.7.8 Выбор альтернативных рекомендаций

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

6.7.9 Компромиссные решения и их последствия

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

6.7.10 Оценка эффективности проекта

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

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

В проекте следует предусмотреть выполнение управленческих задач, предназначенных для руководства и документирования мероприятий SEP-процесса. Задачи, связанные с управлением, приведены на рисунке 17. Конечные результаты и результаты испытаний, планируемые для проведения мероприятий SEP-процесса (план технического проектирования, основной план-график работ и детализированный план-график), а также технические планы, составленные инженерами-специалистами, должны контролироваться в рамках проекта. Задачи управления должны обеспечивать:

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

б) планирование и входные данные для последующего применения SEP-процесса;

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

г) информирование специалистов, принимающих решения на уровне технического анализа и анализа проекта.

6.8.1 Техническое руководство

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

6.8.1.1 Управление данными

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

6.8.1.2 Управление конфигурацией проекта

В рамках проекта планируются и реализуются следующие функции:

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

б) контроль технических изменений;

в) учет состояний;

г) аудит конфигурации.

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

6.8.1.3 Управление интерфейсами

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

6.8.1.4 Управление рисками

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

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

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

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

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

6.8.1.5 Оценка хода выполнения работ, основанная на результатах деятельности

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

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

1. обеспечивать выполнение необходимых технических задач,

2. демонстрировать рост достижений и их зрелость,

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

4. подтверждать, что затраты, план-график и риски невыполнения обязательств в части соответствия техническим задачам, требованиям и целям находятся под контролем;

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

1. для оценки соответствия требованиям,

2. оценки соответствия уровню технического риска,

3. инициализации разработки планов по устранению выявленных недостатков,

4. анализа предельных выгод-затрат на результаты деятельности, превышающие установленные требования.

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

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

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

6.8.2 Отслеживание результатов анализа системы и испытаний

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

6.8.3 Отслеживание требований и изменений в проекте

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

6.8.4 Отслеживание хода выполнения работ относительно плана-графика проекта

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

6.8.5 Отслеживание хода выполнения работ относительно плана технического проектирования

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

6.8.6 Отслеживание производственно-технических показателей

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

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

б) определения степени удовлетворения потребностей заинтересованных сторон и получения признания общества;

в) предоставления оценок затрат и плана-графика работ для новой продукции и обеспечения более оперативного реагирования на запросы заинтересованных лиц.

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

1. внедрить систему менеджмента качества и достичь эффективного использования ресурсов;

2. оценивать в целом систему менеджмента качества и эффективность производства;

3. сравнивать с намеченными целями и задачами;

4. обнаруживать проблемы на более ранних стадиях проекта;

5. проводить бенчмаркинг SEP-процесса.

6.8.7 Корректировка спецификаций и базовых линий конфигурации

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

6.8.8 Корректировка аспектов требований и архитектур

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

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

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

6.8.10 Корректировка технических планов

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

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

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

А.1 Процесс системной инженерии

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

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

А.2 Системная инженерия на предприятии

Цель схемы, приведенной на рисунке А.1, — это представление системной инженерии как общетехнического мероприятия, ответственного за создание конструкции продукта, а также одновременно за процессы разработки, испытаний, производства, технического обслуживания, эксплуатации, обучения персонала, распределения и вывода из эксплуатации. Таким образом, термин «системная инженерия» подразумевает, что полный системный подход должен быть применен к разработке систем. Для коммерциализации продукта и достижения признания со стороны заинтересованных сторон и общества предприятие должно заниматься двумя основными процессами. SEP-процесс создает проект/конструкцию продукта и инфраструктуру его поддерживающего жизненного цикла. Производственный процесс преобразует сырье, детали и т.д. и собирает их в готовые продукты в соответствии с объединенными в единый массив данных спецификациями и инструкциями. В последующих подразделах приведены некоторые из общих понятий, представленных на рисунке А.1.

А.2.1 Рыночные возможности

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

А.2.2 Новые технологические достижения

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

А.2.3 Среда проектирования

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

а) комплексная, междисциплинарная коллективная работа;

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

А.2.4 Производственная среда

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

А.2.5 Внешняя среда по отношению к проекту

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

А.2.6 Продукция

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

А.3 Проблемы системной инженерии и пространство решений

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

Б.1 Шаблон производственного плана

Шаблон производственного плана (engineering plan template) предназначен для предоставления предприятию формы для подготовки плана управления системной инженерией. Как правило, проект имеет специфический производственный план для каждого этапа разработки и использует его для управления и отслеживания деятельности по системной инженерии. Этот план должен соответствовать планам по управлению проектами, а также общим планам предприятия, его возможностям, ограничениям и ожиданиям клиентов.

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

Б.2 Структура производственного плана

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

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

Рисунок Б.2 — Пример оформления содержания

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

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

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

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

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

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

Подпункт 3.1.1.2 Спецификации и базовые линии. Необходимо описать, как будут задокументированы и проконтролированы сформированные спецификации и базовые линии (критерии, требования).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пункт 3.8.3 Управление рисками. Этот пункт должен содержать описание технической программы оценки рисков, в том числе подхода, методов, процедур и критериев их оценки (идентификационные и количественные), выбора вариантов обработки риска и их интеграции в процессе принятия решений. Также здесь необходимо приводить описание рисков, связанных с требованиями к разработке и верификации. Следует определить критические зоны риска, описать планы по минимизации технических рисков (путем дополнительного прототипирования, верификации технологий интеграции и развития системы), а также определить меры по управлению и мониторингу рисков, включая проведение специальных верификаций, TPM-показателей и критических сроков/событий. Здесь следует описать способ объединения TPM-показателей, основного плана-графика и детализированного плана-графика для измерения затрат и запланированных результатов деятельности и связи с SBS-структурой.

Подраздел 3.9 Контроль. Этот подраздел должен содержать обзор планов для сбора проектной информации, сведений об управлении интерфейсами и данными, о планировании на основе событий, о календарном планировании, TPM-показателях, техническом анализе, контроле поставщиков, а также требованиях прослеживаемости.

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

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

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

Пункт 3.9.4 Основной план-график системной инженерии SEMS. Этот пункт должен содержать описание методологии критического пути и критерии перехода событий, используемых для составления основного плана-графика работ и вспомогательного производственного детализированного плана-графика и его структуры. Должен включать описание подходов и методов, запланированных для обновления и поддержания основного и детализированного плана-графика работ.

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

Пункт 3.9.6 Технический анализ. Этот пункт должен содержать описание результатов технического анализа и/или аудитов (системы, подсистем, компонентов и процессов жизненного цикла), применимых к уровню(ям) разработки, охватываемому(мым) производственным планом, описывать планируемые подходы и процедуры для проведения анализов и/или аудитов, а также задачи, связанные с проведением каждого анализа, в том числе обязанности сотрудников и потребности в необходимых процедурах. Данный подраздел также должен включать описание способа подтверждения соответствия производственному плану управления задачами (tasking activity engineering plan)/основному плану-графику работ и/или производственному плану и основным планам-графикам работ предприятия, а также способа определения расхождений между этими планами и оценки системных продуктов и связанных с ними процессов жизненного цикла.

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

Пункт 3.9.8 Требования к прослеживаемости. Этот пункт должен содержать описание выполнения требований к прослеживаемости, а также связей между SEP-мероприятиями, SBS-структурами, корреляции с основным планом-графиком работ и детализированным планом-графиком. Должен описывать взаимосвязь между требованиями к прослеживаемости и управлением данными и интегрированным хранилищем.

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

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

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

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

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

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

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

Подраздел 6.3 Проектирование по критерию стоимости. Этот подраздел должен содержать описание планирования по критерию стоимости и контроля в качестве проектного параметра.

Подраздел 6.4 Стоимостное проектирование. Этот подраздел должен содержать описание подходов и методов стоимостного проектирования на протяжении всего цикла разработки.

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

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

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

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

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

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

Подраздел 7.2 Сокращения и обозначения. Этот подраздел должен содержать алфавитный список всех аббревиатур и сокращений и их описание.

Подраздел 7.3 Глоссарий. Этот подраздел должен содержать алфавитный перечень всех ключевых терминов и их определений в контексте конкретного производственного плана.

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

Приложение В (справочное)

ВЗАИМОСВЯЗЬ МЕЖДУ НАСТОЯЩИМ СТАНДАРТОМ И ГОСТ Р ИСО/МЭК 15288

В.1 Назначение

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

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

В.2 Определения

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

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

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

Примечания

1 Например, когда рассматриваемая система вступает в стадию производства, требуется обеспечивающая производственная система.

2 Каждая обеспечивающая система имеет свой собственный жизненный цикл. Настоящий стандарт может применяться для любой обеспечивающей системы, если она представляется как рассматриваемая система.

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

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

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

Примечания

1 Система может рассматриваться как продукт или как совокупность услуг, которые она обеспечивает.

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

4.18 элемент системы (system element): Представитель совокупности элементов, образующих систему.

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

4.19 рассматриваемая система (system-of-interest): Система, жизненный цикл которой рассматривается в рамках настоящего стандарта.

4.20 жизненный цикл системы (system life cycle): Развитие рассматриваемой системы во времени, начиная от замысла и заканчивая списанием.

Отметим, что в приложении D к ГОСТ Р ИСО/МЭК 15288-2005 предоставлены дополнительные разъяснения и возможные интерпретации некоторых терминов, например, «система», «элемент системы» и «рассматриваемая система». Например, последнее может означать, что системы могут конфигурироваться с одним или несколькими следующими понятиями: аппаратное средство, программное обеспечение, люди, процессы, процедуры, основные средства и встречающимися в природе сущностями. Они могут рассматриваться как продукты или услуги. В стандарте также отмечено, что людей можно рассматривать как пользователей, внешних по отношению к системе и в качестве системных элементов внутри системы.

В.3 Структура системы и терминология

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

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

В подразделе 1.3 установлено иерархическое системное структурное определение настоящего стандарта.

На рисунке В.1 представлена иерархия имен, используемых в настоящем стандарте для описания элементов, составляющих систему. Первые три наименования (система, продукт и подсистема) вносят вклад в создание структуры.

Рисунок В.1 — Структура в виде структурных элементов согласно настоящему стандарту

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

Рисунок В.2 - Рисунок D.3 из ГОСТ Р ИСО/МЭК 15288-2005 для рассматриваемой структуры

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

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

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

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

Рисунок В.2 представляет структуру системы согласно ГОСТ Р ИСО/МЭК 15288 и иерархию продукта <1>, эквивалентную структуре настоящего стандарта. В нем введен другой набор терминов, отличный от используемого в настоящем стандарте:

<1> В ГОСТ Р ИСО/МЭК 15288 система определена (см. B.2, 4.17) как комбинация взаимодействующих элементов, организованных для достижения одной или нескольких намеченных целей; примечание 1 указывает, что системой можно считать продукт или предоставляемую услугу.

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

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

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

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

Исходя из предыдущих сравнений структуры системы (согласно ГОСТ Р ИСО/МЭК 15288) и структурных элементов (согласно настоящему стандарту), на рисунке В.4 приведено сравнение терминов для структурных элементов (настоящий стандарт) и терминов ГОСТ Р ИСО/МЭК 15288.

В ГОСТ Р ИСО/МЭК 15288 отсутствует эквивалент термину «структурный элемент», приведенному в настоящем стандарте.

В.4 Структура процесса и терминология

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

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

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

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

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

Структура процессов и термины в настоящем стандарте и ГОСТ Р ИСО/МЭК 15288 различаются, однако существует определенная связь между подразделами настоящего стандарта и процессами, описанными в ГОСТ Р ИСО/МЭК 15288, которая выходит за рамки настоящего стандарта (раздел 6, определения SEP-процесса). Эти связи между положениями настоящего стандарта и мероприятиями, выполняемыми согласно ГОСТ Р ИСО/МЭК 15288, были определены. В таблице В.2 приведено сопоставление общих требований раздела 4 и задач для SEP-подпроцесса раздела 6 с детальностью в рамках процессов ГОСТ Р ИСО/МЭК 15288. Раздел 5 не внесен в эту таблицу, поскольку он в основном повторяет взаимосвязи, содержащиеся в разделах 4 и 6, с требованиями к деятельности процессов ГОСТ Р ИСО/МЭК 15288, документированию и анализу, проводимому для детальной декомпозиции системы.

Таблица В.2

Примечание — Это сопоставление обобщает взаимосвязи между настоящим стандартом и деятельностью процессов, указанных в ГОСТ Р ИСО/МЭК 15288. Сопоставление включает в себя взаимосвязи между частями необязательных исходных положений и целевыми мероприятиями. Например, подпроцесс задачи раздела 6 (на уровне 6.x.y) обычно соответствует примечаниям мероприятий ГОСТ Р ИСО/МЭК 15288 в области технических процессов. Кроме того, хотя SEP-процесс в соответствии с настоящим стандартом однозначно относится к техническим процессам согласно ГОСТ Р ИСО/МЭК 15288-2005 в части требований и проекта, некоторые аспекты SEP-процесса способствуют выполнению ряда технических процессов, конечной целью которых является установление взаимосвязей с реализованными продуктами системы. Например, 4.5, 6.4, 6.5 и 6.6 поддерживают некоторые рабочие мероприятия по верификации ГОСТ Р ИСО/МЭК 15288 (см. 5.5.7.3, примечания).

В.5 Применение процессов на протяжении всего жизненного цикла системы

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

В разделе 5 этапы описаны с точки зрения системной инженерии — жизненного цикла системы.

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

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

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