Краткий конспект моего доклада по содержанию курса системной инженерии на 11й встрече системных инженеров в Бекасово:1. Учебное окружение: смежные кругозоры и интеллектуальные пререквизиты.2. Пример многоуровневой стратегии NVIDIA3. Чему должен учить курс системной инженерии?4. Моделирование и метамоделирование в курсе системной инженерии5. SoTA практик системной инженерии6. Не "олимпиадная системная инженерия".
1. Учебное окружение: смежные кругозоры и интеллектуальные пререквизиты.
Начинать думать о курсе системной инженерии нужно со взгляда в его системное окружение. Системный инженер во всём многообразии частных своих ролей (инженер по требованиям, инженер-архитектор и т.д.) никогда не работает один, занимаясь чистой инженерией. Он взаимодействует с менеджерами и предпринимателями. Поэтому системноинженерный кругозор не может существовать сам по себе, он должен дополняться менеджерским и предпринимательским кругозором -- иначе нельзя будет понять роль и место системных инженеров в разделении труда, нельзя будет разобраться в системной схеме проекта: не будет понимания того, что в головах людей, озабоченных предпринимательством и инженерией.
Кроме того, есть образовательный ценз на курс системной инженерии: студент должен иметь какой-то достаточно высокий уровень интеллекта. Как минимум, у него в голове должна работать машинка типов, он должен разбираться с диаграммами. И пары часов на эксперименты с семантическим треугольником Фреге/Соссюра явно недостаточно. Нужно иметь собранность для удержания внимания в ходе довольно длительных рассуждений, нужно уже освоить онтологику (логику, онтологию, эпистемологию/научное мышление) и коммуникацию, вычислительное мышление (разобраться с digital twins, порождающими подходами), системное мышление (общее для инженерии, менеджмента, предпринимательства).
Это всё требует множества учебных часов, содержание которых необходимо для прохождения курса системной инженерии, но не входящих в собственно обучение системной инженерии -- ни на уровне кругозорном (например, "технологический предприниматель, имеющий системноинженерный кругозор", "директор по развитию, имеющий системноинженерный кругозор"), ни на глубоком прикладном уровне (системный инженер, имеющий менеджерский и предпринимательский кругозор). Это подробно обсуждается в книге/курсе "Образование для образованных 2020" https://system-school.ru/systems-thinking.
Тем самым одинокий кругозорный и тем более прикладной курс системной инженерии в вузе сам по себе существовать не может, от него идут жёсткие требования к содержанию всей учебной программы. К сожалению, в вузовских программах по административным (невозможно пробить нужное число часов для правильных курсов в программе) и содержательным (нет подходящих курсов, их некому читать и нет учебных материалов) причинам организовать правильное курсовое окружение невозможно. Чтобы обучать системной инженерии нужны особые условия, и Школа системного менеджмента (https://system-school.ru) пытается реализовать такие условия. Расчёт на то, что некоторым людям нужно выучиться по избранной ими специализации, но не нужен официальный диплом установленного образца. Они сначала поднимают свой интеллект методологическими трансдисциплинами до уровня, когда могут освоить деятельностные кругозорные трансдисциплины (включая кругозор по системной инженерии/foundations of systems engineering), а потом пройти и прикладные системноинженерные курсы. Конечно, могут найтись и единичные вузы, которые смогут такое организовать у себя, но это будут немногие исключения.
2. Пример многоуровневой стратегии NVIDIA
К сожалению, текущая системная инженерия не похожа на версии, документированные стандартами предыдущих поколений (включая ISO 15288, вышедший в 2003 году и с тех пор принципиально не менявшийся и INCOSE Systems engineering handbook, гармонизированной с этим стандартом). Это произошло потому, что "большие проекты", являющиеся образцами системноинженерных методов, отражённых в стандартах и обсуждающихся до сих пор в INCOSE, главным образом имеют государственное финансирование, и значительная часть из них и вовсе военные проекты. Дело дошло до того, что мы можем говорить о "стагнации и упадке системной инженерии": из-за финансирования таких проектов по принципу "затраты плюс" каждый следующий проект немного дороже и дольше предыдущих, а рынок не может закрыть неудачников (это хорошо видно по классическим проектам системной инженерии: аэрокосмосу, где SpaceX берёт госконтракты по факту через суды).
Примерами, на которых можно обсуждать системную инженерию в тесной связи с менеджментом и предпринимательством (чтобы было хорошо видно, что и как делают инженеры, в каком темпе они работают и как организованы в части менеджмента, чтобы было видно, какая бизнес-стратегия в части предпринимательства) могут быть современные крупные проекты -- и аэрокосмос тут уже не выглядит уж самым крупным.
В качестве примеров можно привести такие инженерные компании с развитием многоуровневых системных архитектур как части их стратегии и их удачные и неудачные проекты, как:
- Huawei и её многоуровневую эко-систему из сервисов (аналогичных сервисам Гугля) и операционной системы, телефонов, базовых станций, чипов для них. Примеры Nokia и Samsung, замахивающихся на части этой инфраструктуры и успех-неуспех в части их менеджмента-предпринимательства-инженерии. Увы, нам очень мало известно подробностей о происходящем в таких компаниях.
- SpaceX в её инженерном проекте StarLink (спутники-наземные станции-терминалы, плюс средства доставки на орбиту -- ускорители-грузовики и космодромы, боковые рынки для средств доставки на орбиту -- типа замены самолётов на дальних рейсах). И опять-таки мы мало знаем про планы и стратегию и тамошнюю инженерию.
- Cerebras (https://cerebras.net/) как поставщика суперкомпьютера-на-чипе, решающего многочисленные инженерные задачи как создания уникального обеспечения проектирования для чипов с 2.6 триллиона транзисторов на данный момент (производство -- кооперация с TMSC), так и многоуровневой архитектуры суперкомпьютеров на базе такого чипа. Тут известно немного больше, но тоже не так много, и это довольно нишевая на данный момент компания, хотя и с большим потенциалом роста.
- NVIDIA с её многоуровневой предпринимательской/инженерной стратегией. В этом случае архитектура предъявляется явно, есть интересные случаи стабилизации аппаратных интерфейсов софтом (CUDA, DOCA), довольно много аппаратуры (включая выход на автомобильный и роботический инженерный фронтир) и масштаб вполне мировой, уж не меньше "аэрокосмоса", https://ailev.livejournal.com/1561799.html.
Для всех этих современных системноинженерных проектов нужно бы рассмотреть и связь всей этой многоуровневости продуктных вертикалей с приходом денег с прикладных уровней и подрывом с заменой "элементной базы", давление рынка на каждом из системных уровней, необходимость согласования работ команд разных уровней (проектирование интерфейсов и общих архитектур -- стандартизация и open architecture, то есть подход унификации в обеспечении взаимодействия, а не интеграции и федерирования), организацию работы (каждый уровень требует команд со своей специализацией, тик-ток методы разработки, обратный манёвр Конвея и т.д.).
Все эти примеры вне фокуса INCOSE сегодня, вне фокуса PMI и прочих монстров-динозавров, берущих своё начало в 90-х годах прошлого века. Увы, тамошние воззрения на системную инженерию -- это уже не SoTA. Нужно смело порвать с ещё десяток лет назад передовым прошлым. Если и делать курс системной инженерии, то нужно готовить студентов к неопределённому хотя бы настоящему, а не хорошо документированному военно-государственному прошлому.
3. Чему должен учить курс системной инженерии?
Главная ошибка при создании курса системной инженерии -- это учить студентов изготавливать предписанный каким-то стандартом набор рабочих продуктов: ConOps, архитектурные диаграммы и архитектурное эссе, план испытаний и т.д.. Практика системной инженерии в её конкретном варианте включает в себя дисциплину системной инженерии и какую-то её технологию (например, Arcadia method c моделером Capella -- https://en.wikipedia.org/wiki/Arcadia_(engineering), или вариант MITRE, или вариант по INCOSE Handbook). Вместо этого нужно добиваться того, чтобы студенты уносили с собой дисциплину системной инженерии, максимально изолированно от технологии -- а технологию они смогли бы использовать из того, что подходит для условий того предприятия, куда они попадут, и переходя из предприятия в предприятие они могли бы свободно менять технологию, опираясь на знание дисциплины.
Примером тут можно было бы считать курс системного менеджмента мhttps://system-school.ru/systems-management. Там учат тому, какие есть отдельные дисциплины менеджмента, дают примеры, заставляют в упражнениях моделировать "на пальцах" -- добиваются, чтобы стало понятно, какие операции/рассуждения делают менеджеры с понятиями, большинство из которых вводится ещё в учебнике системного мышления (обязательный пререквизит). Какой результат? Несколько человек, прошедших MBA сказали при прохождении этого курса (правда, очно-дистантного его варианта), что теперь им стало понятно, чему их учили на MBA -- то есть понятно, как сочетать и использовать прикладные практики, которым их учили для менеджмента, как стыковать их с практиками инженеров и предпринимателей. Вот ровно этому и нужно учить системных инженеров, давать им целостное понимание системной инженерии.
В каком порядке учить кругозорам (сначала менеджмент, потом инженерия, потом предпринимательство, или наоборот, или ещё как "по спирали") -- этот вопрос остаётся открытый. Например, в курсе системного менеджмента довольно подробно проходится понятие практики, даются примеры этих практик (на примере практик самого менеджмента, но и других практик тоже). Это понятно, ибо основные взгляды менеджера на предприятие -- это потоки работ (операционный менеджер, работы как задействование практик) и изменение практик (оргизменения и лидерство). Если учить практикам системной инженерии после курса системного менеджмента, то объект "практика" будет понятен -- и можно обсуждать со студентами, чему и как их учат. Если учить системной инженерии до системного менеджмента, то понятие "практика инженерии требований" будет не слишком определено, будет его трудно обсуждать, трудно выделять дисциплину практики, отделять её от технологии. Возможное тут решение -- это вынос из курсов менеджмента и инженерии методологии как отдельной дисциплины (https://ailev.livejournal.com/1559209.html, а сейчас методология попала в курс менеджмента, следуя традиции OMG Essence, где way of working находится в management area of concern). Но и тогда есть вариант начинать с предпринимательства -- ибо без этого непонятно, откуда вообще берётся системноинженерный проект, инженерия требований довольно сильно опирается на стратегирование, а архитектура определяет стоимость и время готовности инженерного решения, это тоже выходит на предпринимательство. Так что выстраивание последовательности обучения (curriculum) даже в кругозорной части требует дополнительного обсуждения.
В любом случае, нужно преподать следующие дисциплины с упором на их взаимосвязь:
- инженерия требований
- инженерия системной архитектуры
- инженерия проверки и приёмки
- управление жизненным циклом, конфигурацией и изменениями (с учётом того, что часть там может уйти в методологию как трансдисциплину, а часть -- в менеджмент, "системноинженерный менеджмент" ведь как раз в большой части про это)
Ещё один вопрос -- это отличие курса системного мышления от курса системной инженерии. В курсе системного мышления, например, даётся понятие требований. Но в этом курсе ни слова не говорится о том, как эти требования получить, хотя и даётся парочка примеров того, как они выглядят. А ведь нужно указать на подпрактики инженерии требований и дать их примеры: выявления требований, формулирования требований, документирования требований, анализа требований, валидирования требований, управления требованиями. Дать понимание наиболее распространённых практик и их особенностей (JTBD, use cases, user stories и т.д.), дать немного помоделировать требования в простейшей форме, чтобы "почувствовать вкус". Особо заметить, что эти требования дальше будут участвовать в проверке и приёмке. И это на самом общем уровне, без глубокого погружения в инструментарий. Но обязательно у студента должно быть понимание, что такое "хорошо" и что такое "плохо" в инженерии требований, что отличает кулибинство и работу "на коленке" от культурной инженерии требований.
А дальше, если речь идёт уже о прикладном обучении полноценного системного инженера, то нужно дать попробовать пару-тройку методов разработки требований с опорой на технологии "промышленного калибра" (например, используя не простые таблички упражнений в Aisystant, а поручив настроить метамодель управления требований в Confluence+Jira, или coda.io, или чём-то подобном -- и разработать простой набор требований для чего-то конкретного, какого-нибудь не слишком сложного дрона).
И так с каждой поддисциплиной системной инженерии -- практики (а не просто набор объектов внимания, как в системном мышлении) на кругозорном (4-8 кредитов) и на прикладном уровнях (достаточное число часов для профессионального владения предметом, возможно два подуровня -- "магистр системной инженерии" и "магистр системной инженерии, знакомый с какой-то конкретной технологией"). И обязательно -- понимание связи и практик системной инженерии между собой, системной инженерии и инженерии обычных инженерных специальностей, и связи практик системной инженерии и менеджерских практик, предпринимательских практик.
Идеально это было бы сделать не как краткое изложение монстрообразной "дисциплины методологии", а как у Дональда Райнертсена в его учебнике операционного менеджмента The Principles of Product Development Flow (https://yadi.sk/i/sgN9MtqFjebtq): разбить всё на какие-то отдельные принципы и предложить упражнения для лучшего усвоения этих принципов, в том числе и идей как эти принципы использовать вместе.
Как должен выглядеть учебный проект и рабочий проект для кругозорного курса и для прикладного курса -- это обсуждаемо. Опыт показывает, что для кругозорного курса вариант "приготовить обед" и "сделать собачью конуру" не срабатывает, а варианты с рабочими проектами оказываются запредельно сложными хотя бы тем, что определить целевую систему -- это наполовину предпринимательская практика, она запредельно трудна, и трудно продолжать дальше работу с плохо определённой системой. Опять же, до проверки и приёмки в рабочих проектах дело доходит крайне редко, они все находятся на разных стадиях, студенты в этих проектах часто никто и звать их никак -- поэтому разрабатывать ничего не могут, воплощение проекта поэксплуатировать никто не даст -- за время обучения не удаётся обычно спроектировать и изготовить хотя бы прототип.
4. Моделирование и метамоделирование в курсе системной инженерии
Основное умение, которое должны демонстрировать студенты после курса -- это умение развернуть метамодель дисциплин системной инженерии (например, метамодель требований) в каких-то productivity tools, как полноонтологических моделерах, используемых на предприятиях. Это airtable, confluence, notion.io, coda.io, и т.п..
Само умение метамоделировать должно быть вынесено в другие курсы (онтологика как ведущая трансдисциплина метамоделирования, но онтологическое моделирование на productivity tools, включая умение показать трассировки можно смело относить к кругозорному курсу управления жизненным циклом/конфигурацией/изменениями -- традиционные практики, где занимаются метамоделированием/моделированием данных и трассировками/интеграцией данных).
А вот в прикладных курсах системной инженерии нужно будет научить не только развернуть необходимые метамодели, но и дальше отмоделировать согласно каким-то методикам.
Можно считать, что проблема SysMoLan https://ailev.livejournal.com/1443879.html решалась не на том уровне формальности (всё там склонялось к DSL на полнотьюринговом языке или жёсткой логике семантических/знаниевых моделеров). Нужно было брать уровень формальности, используемый в инженерии требований (Doors оказывается при этом вполне эквивалентным современным productivity tools с его метамоделью требований в табличках и ссылками-трассировками) и инженерии системной архитектуры по линии архитектуры предприятия (там довольно давно перешли от не слишком формального ArchiMate на архитектуру в airtable и прочих productivity tools, вот я в архитектуре предприятия давал Архимейт не как рекомендацию, а как опцию и указывал на тот же airtable как альтернативу уже в 2019 году -- https://ailev.livejournal.com/1498813.html).
В Aisystant сегодня моделирование делается довольно убогими "табличками", и для кругозорного уровня это вполне подойдёт. Понятно, что мы будем это развивать до более-менее полноценного моделера (взять coda.io мы не можем, ибо там запретительная цена на эккаунт для тысяч и тысяч наших студентов -- и мы подождём, пока не появится где-то open source вариант подобной среды моделирования, как это произошло со всеми остальными классами систем, и уже тогда развернём её на наших серверах и будем поддерживать). Куда это будет развиваться? В направлении IDE, IWE и IME (interactive modeling environment, см. https://ailev.livejournal.com/1515735.html -- и тамошние рассуждения можно продолжить на productivity tools. Впрочем классические IWE типа Roam -- как раз могут быть использованы как моделеры, хотя там много чего не хватает по сравнению с coda.io или подобными, начиная с коллективной работы).
Что касается прикладных курсов, то вполне возможно обучение работе конкретно с парой-тройкой наиболее распространённых сред (coda.io, confluence+Yogi, notion и т.д.). Хороший пример, как это выглядит, можно найти в докладе Ивана Подобеда, (видео с 8:30:16, https://youtu.be/Qc1L59NvIiw?t=30616, вместо слайдов была живая демонстрация): для целей одновременного обучения более ста архитекторов софта на coda.io он сделал набор шаблонов (те же таблицы, и графы только в чуть другой визуальной форме) для функционального архитектурного моделирования, а для конструктивного моделирования чуть другой набор шаблонов в Confluence.
Если разобраться, как происходит метамоделирование (задание типов объектов, соответствующих понятиям профильной дисциплины -- инженерии требований, инженерии системной архитектуры в варианте какой-то конкретной практике), то это вполне SoTA способ разворачивания своей производственной среды. Главный софт этого моделера при этом должен быть у студента-выпускника в голове: хорошо работающая машинка типов. В любой момент времени студент должен понимать, где у него метамодель (заголовки секций в шаблонах, заголовки колонок в таблицах и списках, в аутлайнах это тип отношений в иерархии), а где собственно модель (в текстах секций, в клетках таблиц, в строчках аутлайнов). А если случились кусочки текста на естественном языке, так часть слов там -- термины, и они довольно жёстко типизированы. Вот этому и учить.
Это довольно сильный ход: выпускники курса системной инженерии должны уметь не только моделировать в данной им старшими товарищами уже настроенной среде (это уровень инженерного ПТУ), но метамоделировать -- они должны знать понятия дисциплин системной инженерии и уметь настроить на них моделер. В простейшем случае этот моделер -- MS Word (или Google Docs), это означает, что выпускники должны писать осмысленные тексты, не путая понятия. Метамоделирование -- это просто чуть более структурированное то же самое: не только заполнить табличку, но и разработать эту заполняемую табличку.
5. SoTA практик системной инженерии
Учить нужно не классической системной инженерии, а современной 2021 года -- и главный тренд тут в том, что разработкой займутся компьютеры. Andrej Karpathy называет это Software 2.0 -- когда софт не пишется, а "познаётся" (сейчас говорят, "выучивается", но это как-то меньше соответствует происходящему, вот тут я играю терминологией на эту тему, предлагая познание/learning: https://ailev.livejournal.com/1548229.html). В оригинале Karpathy говорил, чтобы программисты расслабились: метод градиентного спуска напишет более оптимальный код, чем это смогут сделать сами программисты. В реалии речь идёт, конечно, не только о методе градиентного спуска -- уже можно указать на огромное разнообразие алгоритмов AI, как оптимизационных, так и порождающих. Как минимум, можно указать на поиск-ориентированную системную инженерию (вот я писал о ней в 2014 году -- https://ailev.livejournal.com/1122876.html, вот напоминал в 2019 -- https://ailev.livejournal.com/1469822.html).
В центре там, конечно, приложения вычислительное мышления как трансдисциплины и идеи digital twins и digital threads (мой доклад об этом на 136 заседании Русского отделения INCOSE -- https://www.youtube.com/watch?v=h_hDeO_7fbI, а также текст https://ailev.livejournal.com/1550931.html).
Мы видим, что уже сегодня автомобили "учат", уже сегодня диагностические системы "учат", и там используются новые среды разработки, включая фотореалистичные физические среды для обучения роботов с AI. Примером такой промышленной среды служит Omniverse фирмы NVIDIA -- см. подробности в https://www.cadalyst.com/management/nvidia%E2%80%99s-omniverse-platform-game-changing-potential-large-scale-cad-78607. Традиционные разработчики PLM уже имеют коннекторы в этой среде (скажем, есть коннектор к Bentley iTwin, и заодно нужно обратить внимание, как позиционирует свой iTwin поставщик инфраструктурных СAD/CAE/PLM -- https://www.bentley.com/en/products/product-line/digital-twins/itwin. И есть коннектор у PTC, и у Autodesk -- https://www.autodesk.com/autodesk-university/ru/class/Leveraging-NVIDIA-Omniverse-AEC-2020 и у всех остальных традиционных поставщиков инструментов). Но самое тут показательное -- это использование Omniverse искусственным интеллектом для обучения, см. об этом подробнее в тексте https://ailev.livejournal.com/1564265.html (скажем, создан в виртуальном мире Omniverse автозавод BMW -- целиком. И там выполняется моделирование перемещений роботов с использованием domain randomisation, вид завода чуть-чуть меняется каждый раз в виртуальном мире, а в реальном мире движение автопилотируемых роботов происходит точней и надёжней).
Учить современной системной инженерии без понимания, что это и есть сегодняшние лучшие образцы системной инженерии -- этого нельзя допустить. Нельзя готовить студентов к инженерным проектам прошлого, нужно их готовить к инженерным проектам будущего, даже тем проектам, о которых преподаватели ещё не знают. Не нужно их, конечно, учить конкретно работе в Omniverse и работе с конкретными программами машинного обучения, но нужно как-то дать студентам представление о том, "с какой стороны подойти к этой корове".
Вычислительное мышление тут должно лечь в основу, ибо речь идёт об использовании системными инженерами вычислительных огромных мощностей -- один рассчёт легко будет тянуть на миллионы долларов (если традиционные алгоритмы машинного обучения при добавлении вычислительной мощности выходят на плато качества результата, то современные многоуровневые/глубокие алгоритмы при добавлении вычислительной мощности продолжают добавлять качество результата -- и для выигрыша в конкуренции нужно будет просто добавить вычислительной мощности. Стоимость этой мощности падает экспоненциально, но потребность в ней растёт быстрее, чем падает цена -- https://ailev.livejournal.com/1536283.html. Студент должен понимать, что это ему придётся объяснять начальству, зачем и почему ему нужна вычислительная мощность для инженерной работы, курс это должен внятно и с примерами объяснять (в курсе вычислительного мышления это объяснение будет общим для менеджмента, инженерии, предпринимательства, науки, медицины и т.д. -- а тут должна быть учтена специфика именно системной инженерии).
6. Не "олимпиадная системная инженерия".
Одна из опасностей -- повторить беду обучения программной инженерии, где программиста учат решать олимпиадные задачки: сочинять хитрый алгоритм из сотни строк, так называемое programming-in-the-small. Нет, учить нужно аналогу programming-in-the-large, то есть участию в коллективной разработке, а не одиночному прохождению жизненного цикла какой-то системы. Вот я писал об этом в тексте 2019 года "Умненькие дебилы: умны в деле-в-малом, дебилы в деле-в-большом", https://ailev.livejournal.com/1496789.html
Есть множество подходов к обучению инженеров командной работе, нужно изучить современный опыт (например, https://en.wikipedia.org/wiki/Collaborative_learning -- учить сразу работать в командах, причём в неодинаковых ролях).
Это замечание относится наполовину к содержанию образования: курс должен чётко продемонстрировать разнообразие ролей системных инженеров, а не рисовать гипотетическую фигуру "системного инженера", который окажется похож то ли на фигуру сельского фельдшера, лечащего все болезни, то ли на фигуру главного врача, который уже не совсем и врач, а почти администратор -- но основная врачебная деятельность идёт в рамках врачебных подролей -- хирургов, терапевтов, или даже подподролей -- хирургов-кардиологов и нейрохирургов, так и основная системноинженерная работа идёт в рамках подролей системного инженера -- инженера по требованиям, инженера по испытаниям и т.д..
Но наполовину это замечание к организации обучения: нужно ли для кругозорного короткого курса обязательно организовывать командную работу, или как-то можно без этого обойтись? По идее, ведь ровно тот же вопрос стоит и перед методистами курсов менеджмента и предпринимательства, там же тоже не "олимпиадный менеджер", решающий короткие менеджерские задачки, не требующие понимания командного взаимодействия! Материалы по interactive collaborative learning (пример: https://yadi.sk/i/By2j210fNkB-lQ), увы, не внушают доверия (организация команды студентов в рабочих проектах автоматически не даёт понимания engineering-in-the-large -- множество команд приводят к тому, что "командой работать веселее" и это поднимает мотивацию, но понимание работы in-the-large и умение это обсудить -- вот этого в материалах interactive collaborative learning почему-то не видно). Так что этот вопрос тоже нужно изучать дополнительно.
Источник: https://www.facebook.com/ailevenchuk/posts/10220911498351270