3.9 Системная инженерия

Обзор и мотивация

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

Это отличается от программной архитектуры. Программная архитектура (глава 3.1) решает, как структурированы программные компоненты и как они общаются между собой. Системная инженерия стоит на уровень выше. Она спрашивает, что система в целом должна делать, как программы, оборудование и операторы-люди делят работу и как вы докажете, что законченное работает. Её профессиональный дом INCOSE, Международный совет по системной инженерии, а её опорный стандарт ISO/IEC/IEEE 15288, определяющий процессы жизни системы.

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

Эта глава связана с требованиями к программам (глава 2.8), основами архитектуры (глава 3.1), программными моделями и методами (глава 2.12), совместимостью и открытыми стандартами (глава 3.8) и управлением проектами (глава 10.6).

Ключевые принципы

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы / цена
Полная строгость системной инженерии	Меньше поздних сюрпризов, сильная прослеживаемость, безопаснее и подотчётнее	Высокая начальная цена, медленнее старт, тяжёлый процесс
Лёгкий / только программный подход	Быстро, дёшево, гибко для малого объёма	Ломается на больших многодисциплинарных системах, упускает интерфейсы и эмерджентность
На основе моделей (MBSE)	Единый источник истины, лёгкая прослеживаемость, согласованные представления	Цена инструментов и обучения, смена культуры, кривая обучения
Системная инженерия на основе документов	Знакомо, низкая цена инструментов, легко делиться	Документы расходятся, прослеживаемость ручная и подвержена ошибкам

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

Вопросы для обсуждения с командой

Где вы построили ровно то, что требовала спецификация, и всё же поставили неверную систему, и что бы это поймало? Верификация (построили ли мы правильно) и валидация (построили ли мы правильную вещь) отвечают на разные вопросы, и система может пройти каждый тест верификации, провалив валидацию, потому что сама спецификация была неверной. В больших программах их сводят в «тестирование», так что никто не валидирует по реальной потребности оператора до поздней стадии, когда исправление стоит в тысячи раз дороже изменения требования. Принесите прошлый пример, где поставленная система соответствовала требованиям, но не попала в реальную потребность, и спросите, какая деятельность по валидации (симуляция с реальными операторами, ранний прототип в поле) выявила бы это раньше. Планируйте обе проверки с самого начала и пишите требования и интерфейсы так, чтобы их вообще можно было верифицировать. Это различие решает, куда вы тратите дефицитные усилия на рецензирование.
Как вы охотитесь за плохим эмерджентным поведением до ввода системы в эксплуатацию, а не после? Сочетание безопасных подсистем может создавать опасные состояния, которых не проявляет ни одна часть, и нельзя вытестировать эмерджентность из системы, которую вы никогда не моделировали. Для программы, критичной для безопасности или миссии, неожиданное взаимодействие то, что ранит кого-то или проваливает миссию, поэтому его нужно найти до живой эксплуатации. Принесите ваш подход к моделированию целого (симуляция, структурированный анализ опасностей, модель SysML, фиксирующая взаимодействия) и спросите, какое поведение между подсистемами вы действительно исследовали, а какое отбросили допущением. Хорошая эмерджентность часто цель системы и стоит проектирования в её сторону; плохая эмерджентность отказ, против которого нужно проектировать. Если ваша единственная стратегия интеграции соединить части и посмотреть, что получится, вы планируете обнаружить эмерджентность в эксплуатации.
Когда должны быть заморожены решения по оборудованию с долгим сроком поставки и как этот срок определяет расписание вашей программы? Когда система включает заказное оборудование, их нужно проектировать совместно: чип задаёт потолки по времени, памяти и мощности, в которых живёт программа, а сроки поставки оборудования часто доминируют над всем расписанием. Команды, воспринимающие программу как отделимую, оптимизируют локально, а затем сталкиваются с ограничениями оборудования на интеграции, теряя месяцы. Принесите сроки поставки оборудования и дату, к которой должно быть решено деление функций между оборудованием и программой, и пересматривайте это деление по мере появления ограничений, а не замораживайте вслепую. Чем раньше вы решите, какие функции живут в кремнии, а какие в программе, тем меньше дорогих разворотов вы встретите. Интерфейсы между ними заслуживают документа управления интерфейсом и владельца с каждой стороны, потому что позднее изменение там расходится рябью по всему, чего касается.
Можете ли вы проследить одну потребность заинтересованной стороны до требования, элемента проекта и теста, который её доказывает, и кто поддерживает эту связь живой? Прослеживаемость позволяет показать в любой момент, что каждая потребность покрыта и каждая часть существует по причине, но в большой программе матрица гниёт в тот миг, когда ею никто не владеет. Противоположное тяготение реально: инженеры воспринимают прослеживаемость как бюрократические накладные расходы, а матрица, поддерживаемая вручную, устаревает быстрее, чем меняется проект. Принесите одну настоящую нить из текущей программы и попробуйте пройти её от конца до конца прямо в комнате, от названной потребности заинтересованной стороны к распределённому требованию, к подсистеме и элементу проекта, который её удовлетворяет, к тесту верификации, и отметьте, где цепь рвётся. Решите, кто владеет матрицей и должна ли она жить в модели, где прослеживаемость запрос, а не ручная погоня. Для корпоративных и государственных программ матрица также артефакт аудита, которого требуют регуляторы и закупающие органы, поэтому разорванная цепь не просто замедляет инженерию; она может застопорить сертификацию или оплату.
Стоят ли подход на основе моделей своих инструментов и смены культуры для вас или он станет дорогим «полочным» ПО? Системная инженерия на основе документов знакома и дёшева в инструментах, но её документы расходятся, а прослеживаемость ручная и подвержена ошибкам; MBSE заменяет груду одной связанной моделью ценой инструментов, обучения и подлинной смены культуры. Любая крайность дорога: пропустите MBSE на большой многодисциплинарной программе, и вы заплатите сюрпризами на интеграции, внедрите её без дисциплины поддержания модели актуальной, и она сгниёт в «полочное» ПО хуже, чем отсутствие модели. Принесите честную оценку зрелости ваших инструментов, кто в команде действительно может создавать и поддерживать модель SysML и какая одна высокорисковая подсистема могла бы стать пилотом подхода, где общая модель окупается быстрее. Решайте постепенно, а не предписывайте всей организации сразу. Для большой корпоративной или государственной программы со многими поставщиками взвесьте, не является ли общая модель единственным реалистичным способом удерживать требования, интерфейсы и тесты согласованными между подрядчиками, которые иначе обмениваются устаревшими документами.
Всерьёз ли ваш план жизненного цикла финансирует эксплуатацию и вывод из эксплуатации или он тихо останавливается на запуске? Стадии, доминирующие в совокупной стоимости долговечной системы, её эксплуатация десятилетиями и безопасный вывод, это те, которые ранние планы регулярно игнорируют, потому что давление всегда в том, чтобы поставить. Противоположное соображение в том, что деньги и внимание наиболее дефицитны именно тогда, когда эти поздние стадии кажутся самыми далёкими, поэтому эксплуатация, сопровождение, миграция данных и утилизация откладываются, пока не становятся дорогой рискованной суматохой. Принесите текущий план жизненного цикла и проверьте, названы ли в нём владельцы, бюджеты и критерии выхода для эксплуатации и вывода или он воспринимает запуск как финишную черту. Спросите, что происходит с данными и оборудованием в конце жизни и кто платит за годы сопровождения между ними. Для корпоративных и государственных систем, которые должны работать двадцать или тридцать лет, а затем выводиться под общественным вниманием, непланированный вывод может нарушить регуляторные, экологические обязательства или обязательства по хранению записей, поэтому вывод принадлежит плану и бюджету с первого обзора замысла.

Взгляд по секторам

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

Малый бизнес. Без выделенного системного инженера и при ограниченном бюджете опирайтесь на опубликованные стандарты и купленные подсистемы, а не на самодельную интеграцию, которую вам придётся проектировать и верифицировать самим. Отдавайте предпочтение поставщикам, открывающим ясные спецификации интерфейсов, чтобы части подходили друг к другу без заказного соединителя, которым вы должны владеть вечно. Формулируйте выбор «строить или покупать» вокруг того, какие интерфейсы вы реалистично можете контролировать и верифицировать на протяжении жизни продукта, а остальное покупайте.

Крупная организация. В масштабе проблема в согласованности между многими командами и поставщиками: общий процесс жизненного цикла, выровненный по ISO/IEC/IEEE 15288, документ управления интерфейсом и названный владелец для каждой границы поставщика и сквозная прослеживаемость, чтобы изменение одного компонента не запускало суматоху на всю программу. Вкладывайтесь в MBSE там, где общая модель держит требования, интерфейсы и тесты согласованными между подрядчиками. Управляйте процессом так, чтобы верификация и валидация оставались различными, а каждое требование было распределено ответственной части.

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

Примеры

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

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

Государственный сектор. Национальный орган аэронавигации модернизирует свою систему управления воздушным движением, критичную для безопасности систему систем, охватывающую радары, рабочие места диспетчеров, связь и программы и работающую круглосуточно. Программа следует ISO/IEC/IEEE 15288 на всём жизненном цикле. Верификация доказывает, что каждая подсистема соответствует спецификации, а валидация через симуляцию с реальными диспетчерами доказывает, что интегрированная система поддерживает безопасные операции до того, как от неё зависит живой трафик. Строгая V&V позволяет органу переключаться по стадиям с запасным вариантом на каждом шаге, потому что здесь непротестированный эмерджентный отказ это событие общественной безопасности.

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

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

Модель зрелости

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

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

Уровень 3: Стандартизация. Системная инженерия это документированная организационная дисциплина, выровненная по ISO/IEC/IEEE 15288 и соблюдаемая командами. Полный жизненный цикл запланирован, прослеживаемость поддерживается от конца до конца, интерфейсы формально контролируются, а верификация и валидация различны и запланированы. MBSE используется на сложных программах.

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

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

Идеи для обсуждения

Где проходит линия между системной инженерией и программной архитектурой в вашей организации и кто владеет пространством между ними?
На вашей крупнейшей программе можете ли вы проследить одну потребность заинтересованной стороны до теста, который её верифицирует? Если нет, что для этого потребовалось бы?
Какие из ваших недавних отказов произошли на интерфейсе и кто им владел?
Окупилась бы MBSE для вас или стала бы дорогим «полочным» ПО при вашей культуре и инструментах?
Всерьёз ли ваш план жизненного цикла рассматривает эксплуатацию и вывод или он тихо останавливается на запуске?

Главные выводы

Системная инженерия проектирует всю систему (программы, оборудование, людей и процессы) от конца до конца и отличается от программной архитектуры.
Планируйте полный жизненный цикл: от замысла через требования, проектирование, интеграцию, V&V, эксплуатацию и вывод.
Прослеживайте каждую потребность до требования, элемента проекта и теста и распределяйте каждое требование ответственной части.
Управляйте интерфейсами явно с чётким владением и документами управления, потому что на границах системы ломаются.
Верификация (построили правильно) и валидация (построили правильную вещь) разные проверки, и нужны обе.
Используйте MBSE и SysML для одного связанного источника истины и используйте системное мышление, чтобы предвосхищать эмерджентное поведение.
Подбирайте вес процесса под размер, срок жизни и риск системы.

Источники и дополнительное чтение

INCOSE, INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
ISO/IEC/IEEE 15288, Systems and Software Engineering: System Life Cycle Processes
ISO/IEC/IEEE 29148, Systems and Software Engineering: Requirements Engineering
Sanford Friedenthal, Alan Moore, and Rick Steiner, A Practical Guide to SysML: The Systems Modelling Language
NASA, NASA Systems Engineering Handbook (NASA/SP-2016-6105)
Andrew P. Sage and William B. Rouse, Handbook of Systems Engineering and Management
Dennis M. Buede and William D. Miller, The Engineering Design of Systems: Models and Methods
Donella H. Meadows, Thinking in Systems: A Primer
Eberhardt Rechtin and Mark W. Maier, The Art of Systems Architecting
U.S. Department of Defence, Defence Acquisition Guidebook (systems engineering guidance)

3.9 Системная инженерия

Обзор и мотивация

Ключевые принципы

Рекомендации

Управляйте полным жизненным циклом системы

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

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

Интегрируйте, а затем верифицируйте и валидируйте

Применяйте системную инженерию на основе моделей

Применяйте системное мышление к эмерджентному поведению

Проектируйте оборудование и программы совместно