В продолжение первой статьи о Системном Инжиниринге [1] необходимо дать базовые определения, рассмотреть основные процессы, принятые в Системном Инжиниринге и указать на принятые стандарты в этой области. Будем подходить системно к этому процессу, и разложим все в логической последовательности.
Мы можем считать, что в настоящий момент Системный Инжиниринг стал вполне самостоятельной инженерной дисциплиной, которая имеет в своем арсенале такие инструменты как качественное моделирование (моделирование данных, моделирование процессов), количественное моделирование (поведенческое моделирование, системы управления с обратной связью, компромиссное моделирование), физическое моделирование (прототипы для подтверждения требований, тестирование удобства использования, прототипирование для решения вопросов по интерфейсам, интеграция).
И в тоже время Системный инжиниринг сам развивает такие специфичные области знаний как: определение проблемы (концепция эксплуатации системы, границы системы, иерархия целей, определяющие требования), параллельное проектирование (фазы жизненного цикла системы, интеграция и квалификация подсистем), архитектура систем(функциональная/логическая, физическая/операционная, интерфейсов), допуски и компромиссы (уровень концепций, управление рисками, ключевые параметры эффективности). [2]
Но есть в Системным Инжиниринге и специфичные области знаний, характерные и выделяющие эту дисциплину от других инженерных дисциплин. Мы можем сказать, что области науки управления (экономика, анализ бизнес-решений, исследования в области управления бизнес-процессами) и социальные науки (мультидисциплинарная командная работа, организационное поведение, лидерство) являются уникальными для Системного Инжиниринга.
Далее поговорим о базовых терминах или определениях для единообразия описания дальнейших процессов и сохранения единства смысла. [3]
Будем говорить, что система, это смесь подсистем, агрегатов, навыков, и техник способная выполнять и/или поддерживать операционную (или не операционную роль).
Потребитель — это выгодополучатель от выходов или продуктов рабочих процессов или покупатель этих продуктов или услуг.
Требования — а) характеристики, которые определяют уровни выполнения, необходимые для достижения специфичных целей при заданных наборах условий и б) обязательные заявления в документе или контракте.
Функция — задача, действие, или активность, которая должна быть выполнена для достижения желательного результата. Способность системы или элемента системы.
Границы системы — что то, что обозначает границу или предел данной системы (например, внешняя граница системы, где ее функции заканчиваются или начинают взаимодействовать с «внешним миром»).
Интерфейс — общая граница между двумя или более системами, или элементами системы (например функции, физические компоненты, организационные структуры).
Измерение эффективности — метрики, используемые для количественного измерения эффективности продуктов или процессов системы в показателях, которые описывают их полезность или ценность для потребителя.
Для выполнения своих функций Системный Инжиниринг использует специфичные процессы — специальные, характерные для данной дисциплины мероприятия, применимые для разработки систем включая:
– Анализ требований: оценка исходных потребностей и переход к требованиям системы;
– Функциональный анализ: идентификация функциональности, требуемой для достижения требований системы и размещение требований по этим функциям;
– Синтез: разработка проектов системы и решений по компонентам системы для удовлетворений установленных требований;
– Системный анализ и контроль: анализ и оценка результатов, и другие мероприятия для их согласования и уточнения. А также управление техническими усилиями между дисциплинами и документирование результатов;
– Верификация: выполняемые мероприятия и элементы системы, необходимые для оценки прогресса и эффективности разрабатываемых системных продуктов и процессов и для измерения соответствия спецификации.
Все эти и другие, присущие данной дисциплине процессы возникают или применяются на этапах Жизненного Цикла системы. Это понятие включает в себя все этапы любой системы или продукта — от замысла до утилизации. В простейшем случае жизненный цикл может состоять из следующих этапов — определение концепции, разработка, внедрение и эксплуатация. В сложных случаях, например при разработке нового автомобиля, этапы жизненного цикла могут быть обогащены такими стадиями как — уточнение требований, экономическое планирование, обучение, и в конце, концов утилизация продукции отслужившей своей срок.
Некоторые из применяемых процессов, например такого, как верификация могут применяться многократно и на разных этапах жизненного цикла системы. Процессы Системного Инжиниринга обеспечивают некую «инструкцию» по использованию методов или инструментов на протяжении всего жизненного цикла системы. Процессы можно категорировать на:
– технические процессы;
– проектные процессы;
– организационные процессы;
– процессы контрактования.
Можно составить обобщенный или типовой список процессов Системного Инжиниринга:
– Анализ «миссии» (концепция);
– Анализ требований;
– Управление базовой конфигурацией системы;
– Функциональный анализ;
– Определение возможных компромиссов;
– Анализ альтернатив;
– Синтез системы;
– Интеграция системы;
– Верификация и валидация системы;
– Планирование Системного Инжиниринга.
На рисунке 1 можно увидеть место процессов Системного Инжиниринга.
Рис. 1. Типичная схема воплощения процессов Системного Инжиниринга.
По мере развития дисциплины возникали и совершенствовались ее модели, делались попытки стандартизировать подходы и процессы. Одними из первых к этому приступили в министерстве обороны США, в частности ведомственный Университет Закупок [4], где в свободном доступе находится документ, раскрывающий все основные понятия системного инжиниринга и его практическое применение в оборонной отрасли [5]. В общем, надо отметить, что военные и государственные структуры США (в том числе NASA) много внимания уделяли и продолжают уделять внедрению подходов системного инжиниринга при разработке новых проектов. Они также сыграли большую роль в стандартизации процессов Системного Инжиниринга.
На рисунке 2 представлена схема рабочих процессов Системного Инжиниринга согласно концепциям, разработанным DAU.
Рис. 2. Традиционные процессы Системного Инжиниринга (DAU).
Согласно INCOSE (Международный Совет по Системному Инжинирнгу) общий вид процессов системного инжиниринга был преобразован в V-диаграмму (Рис. 3) [6] для того, чтобы подчеркнуть, что:
– Должен существовать процесс Верификации между фазами, для проверки соответствия того, что выполнено с требованиями.
– Должен существовать процесс Валидации, для подтверждения того, что вся система удовлетворяет заявленным потребностям.
– Должна быть произведена Декомпозиция (разбитие на мелкие блоки) и определение того, что собственно должно быть построено.
– Должен существовать процесс интеграции и проверки (верификации) того, что должно быть построено.
Рис. 3. V-диаграмма согласно INCOSE.
Остановимся подробнее на процессах описанных парой абзацев выше.
Итак, с самого начала — определяем, что именно мы должны построить, проводим анализ миссии, создаем концепцию. Цели у этой стадии следующие — определить проблемы или возможности, которые возникают при решении этой проблемы; определяем потенциальных участников системы, потребителей или выгодополучателей; ну и собираем все высокоуровневые «хотелки», формальные и неформальные желания участников проекта или системы.
Далее проводим анализ требований. Мы делаем это для того, чтобы: определить реальных потребителей системы, переводим «желания» и «хотелки» в реальные, формальные требования, валидируем эти требования (подтверждаем и утверждаем) с потребителями.
Далее создаем некую базовую линию проекта или системы, которую будем тщательно отслеживать. Если возникают изменения в системных требованиях или концепции, или на стадии дизайна, все это отразится на базовой линии и ее нужно менять. Фактически это некий общий взгляд на систему всех участников. Нельзя допускать, чтобы на каком-то этапе точки зрения на систему разных участников начали отличаться.
Затем проводим функциональный анализ для определения функциональных возможностей и особенностей системы в общепринятых выражениях. И опять валидируем (утверждаем с потребителями) функциональное описание системы.
Далее рационально изучить возможные компромиссы системы, что может привести к удешевлению или техническому упрощению системы не в ущерб уже валидированным параметрам. На этой стадии мы изучаем разные способы обеспечить заявленную функциональность системы, убираем заранее неприемлемые решения, определяем риски, ассоциированные с каждым из приемлемых решений.
Для того, чтобы не упустить что-то важное необходимо провести анализ альтернатив. Для этого необходимо оценить эффективность всех найденных и не отброшенных на предыдущем этапе альтернативных подходов к решению и выбрать наиболее приемлемые из них.
Далее мы проводим первоначальный синтез системы, где определяем физические компоненты предпочитаемых системных решений, и разрабатываем системную архитектуру.
Затем проводим системную интеграцию, при которой определяем интерфейсы между физическими компонентами системы, определяем интерфейсы между компонентами системы и внешним окружением, определяем управляющие параметры и характеристики всех интерфейсов.
Как одну из заключительных фаз проводим верификацию системы. Проводим тесты, инспекции, симулирование и моделирование физической архитектуры предпочитаемого системного решения. Определяем и решаем любые несоответствия системы с заявленными требованиям.
Одной из главных фаз является планирование системного инжиниринга. Мы должны составить планы для всех технических усилий и мероприятий Системного Инжинирнга и интегрировать его с мероприятиями проектного управления (устанавливаем сроки, назначаем ресурсы и пр.).
У каждой фазы должен быть свой итог или продукт. Перечислим их в том же порядке:
– Анализ миссии (концепция) — собственно описание миссии или документ, отражающий потребности потребителей.
– Анализ требований — документы, формально описывающие эти требования, разного рода спецификации и описания.
– Управление базовой линией — план управления базовой линией, журналы изменений (документов, конфигураций, программного обеспечения и др.).
– Функциональный анализ — блок-диаграмма функциональных потоков, иерархичная функциональная диаграмма, функциональная архитектура.
– Изучение компромиссов — формально описанные критерии принятия решений, измеряемые параметры, весовые факторы разных параметров, результаты изучения.
– Анализ альтернатив — описание альтернатив, предпочтительные решения, стоимость, временные затраты, технические концепции.
– Синтез системы — физическая архитектура(-ы) системы.
– Системная интеграция — описание всех интерфейсов и ревью системы в целом.
– Верификация системы — описание метрик верификации, акты несоответствия и отчет о готовности системы.
– Планирование Системного Инжиниринга — план управления Системным Инжинирингом, план(-ы) снижения рисков, план(-ы) верификации, план управления командами.
С первых лет основания Системного Инжиниринга как отдельной дисциплины делались попытки стандартизировать подходы к ней. Тем самым создавались правила, по которым следовало осуществлять процессы Системного Инжиниринга. Но и сами процессы слегка видоизменялись со временем.
Одним из первых стандартов по Системному Инжинирингу был военный стандарт США MIL-STD-499 [7] датированный 1969 годом и акцентирующий внимание на управленческих вопросах. Более поздние редакции этого стандарта вводили понятия процессов Системного Инжиниринга (90-е годы). В это же время был создан INCOSE — Международный Совет По Системному Инжинирингу [8]. Позднее военный стандарт был аннулирован и материалы из него вошли в отраслевой ANSI/EIA стандарт (ANSI/EIA 632) [9] и позднее уже организация ISO приняла аналогичный стандарт — ISO 15288 («Инжиниринг систем и программного обеспечения — процессы жизненного цикла систем»), последняя редакция которого датирована 2015 годом [10].
Литература:
- Сычёв В. А. Общие вопросы системного Инжиниринга. // Вопросы управления и экономики: современное состояние актуальных проблем: сб. ст. по материалам XIII Международной научно-практической конференции «Вопросы управления и экономики: современное состояние актуальных проблем». — № 7(13). — М., Изд. «Интернаука», 2018. Стр.77–84.
- Haskins, C. (Editor). International Council on Systems Engineering (INCOSE), Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities Version 3.2.2. 2011. INCOSE-TP‐2003‐002‐03.2.2, San Diego, CA.
- Sage, Andrew P. and William B. Rouse, Handbook of Systems Engineering and Management, John Wiley & Sons, Sep 20, 2011 — Technology & Engineering — 1504 pages. ISBN: 111821000X, 9781118210000
- Defense Acquisition University (DAU). URL: https://www/dau/mil/ (дата обращения 25.07.2018).
- Defense Acquisition Guidebook (DAG). URL: https://www.dau.mil/tools/dag/Pages/DAG-Page-Viewer.aspx?source=https://www.dau.mil/guidebooks/Shared %20Documents %20HTML/Foreword.aspx. (дата обращения 25.07.2018).
- Systems Engineering Handbook V4.0 Tutorial. //D. D. Walden, G. J. Roedler, K. J. Forsberg, R. D. Hamelin, and, T. M. Shortell (Eds). San Diego, CA: International Council on Systems Engineering. Published by John Wiley & Sons, Inc INCOSE 2015. Product Number: INCOSE-TP-2003–017–02
- MIL-STD-499, MILITARY STANDARD: SYSTEM ENGINEERING MANAGEMENT (17 JUL 1969). URL: http://everyspec.com/MIL-STD/MIL-STD-0300–0499/MIL-STD-499_10376/. (дата обращения 25.07.2018).
- INCOSE — International Council of Systems Engineering. URL: www.incose.org/ (дата обращения 25.07.2018).
- Processes for engineering a system EIA632. URL: https://www.sae.org/standards/content/eia632/. (дата обращения 25.07.2018).
- ISO/IEC/IEEE 15288:2015. URL: https://www.iso.org/standard/63711.html. (дата обращения 25.07.2018).
