Systems Engineering: как вести сложные проекты

Есть на свете процесс, позволяющий разрабатывать сколь угодно сложные системы. Но большинство статей по нему — это либо практические описания в духе «смотрите как я сделал», либо копипаста Википедии, ГОСТов и лекций в университете. Не удивительно, что о нем так мало знают.
Давайте мы это исправим!

Если по-простому, то Systems Engineering это процесс, которому можно следовать, если ваша задача – спроектировать и разработать что-то сложнее одного монолитного блока: будь то распределенная система, автомобиль или просто программный продукт, «полная картина» которого не укладывается в голове.

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

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

• DIY-проекты обычно самые «простые» - отсутствие пользователей, требований, ожиданий и рисков. Проект может развиваться без всяких процессов и бюрократии. Появилась идея – накодил!
  
• Стартапы зачастую имеют набор идей, юз-кейсов, тестовых пользователей, план развития; однако низкие риски позволяют стартапу жить и развиваться достаточно гибко по agile-процессам, не боясь «накатывать бету в прод»
  
• Enterprise-системы уже не могут себе позволить обходиться без четких требований, тест-кейсов и полной валидации продукта перед его выпуском: на кону могут быть репутация и бизнес
  
• С автомобилями дела обстоят еще хуже – его системы должны соответствовать всем требованиям законодательства, а safety-critical компоненты должны пройти жесткую сертификацию и доказать, что их использование безопасно, и условная тормозная система не выдаст exception на дороге. Тем не менее, у производителей есть все возможности протестировать каждую систему по-отдельности и автомобиль в целом
  
• А вот с космической миссией дела обстоят иначе: только представьте, у этих ребят есть всего один шанс на успех миссии. Несмотря на проверки каждой из систем по отдельности, самая полная проверка работы всех систем одновременно – это и есть сама миссия. В этих условиях ни одна малейшая деталь в описании требований к миссии, системам, интерфейсам, компонентам, в проверке и валидации всего этого добра не должна быть утеряна (интересный пример: проблемка с Mars Climate Orbiter).
  

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

Концепция Системной Инженерии достаточно проста – это:

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

1. Сформировать цели проекта
Опросить всех заинтересованных (пользователи / менеджмент / команда разработки), определить требования, проанализировать их на полноту и отсутствие противоречий
2. Выделить один/несколько концептов
Проверить на соответствие требованиям, проанализировать и выбрать лучший концепт
3. Декомпозировать
Разбить концепт на компоненты и определить к ним требования
4. Повторить рекурсивно
Пункты (2) и (3) повторить для каждого компонента, пока их составляющие не станут достаточно простыми, чтобы «просто взять и сделать»

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

5. Разработать и произвести
Реализовать полученные на предыдущем этапе компоненты согласно требованиям

6. Модульное тестирование
Протестировать каждый компонент относительно требований к нему
7. Интеграция
Собрать простые компоненты в более сложный согласно архитектуре
8. Повторить рекурсивно
Собрать матрешку в обратном порядке путем повторения (6) и (7), проверяя каждый полученный результат
9. Валидация
Получить итоговую сборку системы и проверить ее относительно исходных целей проекта
10. Сдача проекта
Выполнить миссию / ввести в эксплуатацию.

Обычно этот процесс изображают в виде V-модели, где:

• Описание и декомпозиция – левая часть
• Разработка и производство – середина
• Тестирование и интеграция – правая часть
  

Стрелками по горизонтали обознается соответствие тест-планов дизайну и требованиям на каждом из уровней.

Следует также заметить, что на каждом этапе рабочая группа проекта должна убеждаться в том, что проект движется в нужном направлении и не свернул с пути.

Как вы можете видеть, в этой концепции нет ничего сложного, простое рекурсивное «съедание слона по частям».

Любители agile-разработки успели заметить, что всё это как-то сильно похоже на ненавистный всем водопад. Отчасти так и есть, но:

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

«У меня для вас две новости».

Плохая – в непростых проектах срезать этапы процесса не получится, иначе есть высокая вероятность застрять на интеграции или вовсе не удовлетворить поставленные цели.

Хорошая – есть вариант ускорить и автоматизировать этот процесс. О том, что такое Model-based Systems Engineering мы поговорим в следующий раз.

NASA Systems Engineering Handbook