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