Systems Engineering: как вести сложные проекты
Есть на свете процесс, позволяющий разрабатывать сколь угодно сложные системы. Но большинство статей по нему — это либо практические описания в духе «смотрите как я сделал», либо копипаста Википедии, ГОСТов и лекций в университете. Не удивительно, что о нем так мало знают.
Давайте мы это исправим!
Зачем нам 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 мы поговорим в следующий раз.
И чем это отличается от давнишнего Системного подхода в менеджменте и базового проектного управления?
Тоже не особо понял :), ток на водопаде можно как угодно процесс выстраивать, а здесь совсем жёсткий хард :)
Все таки это не совсем Системная инженерия. По определению В.Батоврина - СИ это "междисциплинарный подход, определяющий исчерпывающий набор технических и управленческих усилий, необходимых для преобразования совокупности потребностей заинтересованной стороны, ожиданий и ограничений в решение и для поддержки этого решения на протяжении его жизни". Схожее определения давал А.Холл. Это ближе к практике которая в СССР называлась "системотехника". В вашем подходе не проглядывает междисциплинарность, и нет акцента на жизненный цикл. V диаграмма тоже отличается от канонической в ISO 15288 p.s. см например как управляют жизненным циклом систем в NASA https://nodis3.gsfc.nasa.gov/main_lib.cfm
Это упрощенный и облегченный вариант. Конечно, кроме V диаграммы у нас есть детализация циклических работ, которые описывают каждый этам разработки.
Там внутри тот же Agile и Waterfall заложен.
И я бы предложил ссылать на INCOSE, а не NASA