Метод системной инженерии




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

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

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


Обзор существующих методов и процессов системной инженерии

Первой организацией, предложившей формальное описание процесса системной инженерии, было Министерство обороны США. Соответствующий документ получил название военного стандарта MIL-STD-498. С тех пор этот процесс подвергся нескольким итерациям, и последняя официальная редакция стандарта (прежде чем его поддержка была прекращена) имела номер MIL- STD-499B. Это процесс показан на рис. 4.7 и включает четыре основных действия: анализ требований, анализ функций и их привязка, синтез, а также системный анализ и управление. На рисунке показаны задачи, входящие в состав каждого действия.
Хотя этот военный стандарт считается устаревшим, он по-прежнему используется в качестве руководства многими организациями и является основой для понимания современных процессов системной инженерии.

Известны три имеющих промышленное значение стандарта, содержащих описание процесса системной инженерии: IEEE-1220, EIA-632 и ISO/IEC 15288. Знакомясь с этими описаниями, обратите внимание, что в каждом из этих документов аспекты, имеющие отношение к процессу инженерии систем, так или иначе сочетаются с описанной выше моделью жизненного цикла. Последовательность, в которой мы представим эти три метода, выбрана не случайно: они рассматриваются в порядке приближения к модели жизненного цикла создания системы. Вообще-то на первое место в этой цепочке можно было бы поместить вышеупомянутый военный стандарт. Иными словами, положения стандарта MIL-STD-499B в наименьшей степени привязаны к модели жизненного цикла.

И наоборот, то, что сказано в стандарте ISO/IEC 15288, вполне можно рассматривать как модель жизненного цикла для создания системы.

На рис. 4.8 представлен процесс, описанный в IEEE-1220. Основная управленческая деятельность показана в центре диаграммы. Ее (по часовой стрелке, начиная с левого нижнего угла) окружает поток действий, который начинается с «входов процесса» и заканчивается «выходами процесса». Этот процесс можно считать обобщением военного стандарта: имеются четыре основных действия, а между ними - шаги по верификации или валидации.
На рис. 4.9 показан процесс, описанный в EIA-632. Фактически в стандарте EIA- 632 описана совокупность 13 взаимосвязанных процессов. На рисунке отчетливо видна итеративная и циклическая природа этих связей. Хотя в целом поток движется сверху вниз, процессы могут многократно повторяться на протяжении жизненного цикла системы.

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

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


Метод системной инженерии

Метод системной инженерии можно представить себе как систематическое применение научного метода к инженерной деятельности по созданию сложной системы. Можно считать, что он включает четыре основных вида деятельности, которые применяются последовательно, как показано на рис. 4.11:
  1. Анализ требований.
  2. Функциональное описание.
  3. Описание физической реализации.
  4. Валидация проектных решений.

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

1. Анализ требований (постановка задачи). 

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


2. Описание функций (анализ функционирования и привязка функций). 

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


3. Описание физической реализации (синтез, анализ физической реализации и размещение элементов). 

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


4. Валидация проектных решений (верификация и оценка). 

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