Тренды современной системной инженерии
В системной инженерии SoTA (state-of-the-art, современное состояние метода, лучшие на сегодняшний момент варианты метода из всего их разнообразия) меняется довольно быстро: если брать программную инженерию, то технологии там заменяются практически полностью каждые 4-5 лет, хотя дисциплины computer science и методология в варианте специализации engineering science до software engineering science, которые поддерживаются этими технологиями, выдерживают в своих основных чертах немного дольше.
Программная инженерия (и тесно связанные с ней инженерия систем машинного обучения, инженерия данных, инженерия систем искусственного интеллекта) по части трендов занимает особое место в системной инженерии: поскольку там имеют дело главным образом с информационной работой, в которой не нужно тратить много энергии и времени на перемещение вещества в порядке изменения физического мира, а нужно только менять состояние носителей информации, пробы и ошибки там проходят быстрее, чем во многих других видах инженерии, где дело почти сразу доходит до медленных физических процессов в физическом мире и «пробы и ошибки» (trial-and-errors) делать медленнее. Поэтому программные инженеры быстрее находят новые удачные способы ведения инженерной деятельности. Замечено, что методы, которые становятся повсеместными в программной инженерии, появляются в классической инженерии киберфизических систем где-то через 10 лет, и получают распространение через 15 лет от того момента, когда они впервые были замечены в программной инженерии.
Так, именно в программной инженерии появились методы agile и эволюционной инженерии как противопоставление водопаду с его однократным прохождением жизненного цикла. За последние пять лет нормой инженерного метода в программной инженерии стало не просто создание систем, но создание и развитие, эволюционная/непрерывная инженерия (подробней об этом рассказано в нашем руководстве). Конечно, это уже активно обсуждается в инженерии киберфизических систем, но только малое число предприятий перешло на новые инженерные agile процессы, это особо хорошо заметно по происходящему в ракетостроении: успехи предприятий с agile процессами не сравнить с успехами (вернее, неуспехами) предприятий с классической разработкой.
В системной инженерии киберфизических систем, где есть и программная инженерия, и «железная» инженерия, продолжалось движение в сторону общности инженерной работы для систем самой разной природы, включая выход в работу с сетями и системами с людьми (движение в сторону систем систем). В таких компаниях новинки в инженерном процессе программного обеспечения более быстро воспринимаются в «железной» части.
Таким образом в современных учебниках программной инженерии учат эволюционности инженерии, а в учебниках классической системной инженерии обсуждают безмасштабность, роль системных инженеров в проектах систем самой разной природы (несмотря на продолжающийся акцент на классике систем аэрокосмической и транспортной инженерии, но уже явно звучат призывы внимательно смотреть на системы другой природы), создаваемых на самых разных уровнях масштаба.
Наше руководство снимает это различие, предлагая версию одновременно безмасштабной и эволюционной системной инженерии. Это наш вклад в развитие инженерной науки.
Главный тренд в развитии программной инженерии сейчас — это переход к разработке с использованием AI-copilot, причём сначала это был pair programming (программирование вдвоём, парой — но за клавиатурой один человек, другой помогает думать. За клавиатурой — AI-copilot, а человек помогает думать, Software 3.0, или vibe coding[1], как его определил Andrej Karpathy), а затем — peer programming, когда часть работы берёт на себя AI-агент, сначала автономно выполняющий довольно большие задачи, а потом и берущий на себя решение проблем. Это отражает переход от поддержки AI в части software design, понимаемого как «проектирование кода и кодирование» к поддержке AI полного software process: постановке задачи на очередной инкремент, а затем полностью вся разработка, включая методологическую и архитектурную проработку, проектирование/design и кодирование/coding, оптимизационное компилирование в машинный код, юнит-тестирование в части инженерного обоснования (quality assurance), сборку/интеграцию, системное тестирование (включая архитектурное и безопасности), разворачивание/deployment, введение в эксплуатацию (delivering), мониторинг, получение пользовательской обратной связи (feedback) — и всё это непрерывно/continuous в ходе непрерывной разработки.
В классической инженерии ровно то же самое, за исключением немного другой терминологии того, что называют design/проектирование. Software design чаще всего включает в себя методологические рассмотрения по видам применимых прикладных алгоритмов (из предметной области применения программы — какой процесс в реальном мире поддерживает программа, чаще всего это DDD, domain driven design, когда объекты программы впрямую отражают сущности предметной области применения программы, например, объект invoice/счёт программного кода и базы данных поддерживает объект invoice/счёт реального мира). Design в инженерии — это работа с CAD, создание конструкции, на которую разложены функции системы, причём в русском языке это будет даже два метода работы (практики инженерии), обозначаемые двумя словами: конструирование как создание деталей с их сложной формой и проектирование как указание, как из деталей собирается всё изделие. Это довольно тонкое различие, но инженеры-проектировщики (проектирующие системы из каких-то уже сконструированных других систем — деталей или готовых других модулей-систем) и инженеры-конструкторы в отечественном машиностроении различаются (при вечных спорах, что часто конструктор занимается не только конструированием, но и проектированием, то есть работает и на уровне составных частей конструкции, а не только на уровне отдельных деталей и косного вещества), в западном — не различаются.
Всего же можно выделить для AI-поддержки в программной инженерии разные поколения, обозначаемые Software 1.0, 2.0, 3.0, а сейчас даже можно говорить и о 4.0 (о них подробнее говорится в руководстве по интеллект-стеку в разделе «Алгоритмика»). Софт/software тут сокращение от software engineering:
- Софт/software 1.0, классическое программирование: основано на явном кодирования людьми правил и инструкций на языке программирования.
- Софт/software 2.0[2], differentiable programming: программы дифференцируемы[3], поэтому способны обучаться на основе данных (обычно большой объём данных) и адаптироваться к новым ситуациям. Наиболее распространённая и известная форма дифференцируемых программ — это нейронная сеть, которая может аппроксимировать практически любой алгоритм.
- Софт/software 3.0[4]: Основано на предварительном обучении нейронных сетей в форме больших языковых моделей (large language models, LLM), обученных программировать. Эти модели понимают и программный код, и естественный язык, поэтому им можно давать в том числе и задания найти ошибку в коде, поменять этот код для получения каких-то новых свойств программы. Обычно это или AI-copilot (парное программирование, «второй пилот за штурвалом» и как раз к этому случаю применимо vibe coding), или более-менее автономный AI-агент (самостоятельное выполнение задач «под ключ» по поручениям). Заметим, что в этом варианте вполне присутствует способность к творчеству, ибо написание кода может идти методом проб и ошибок, задействуется меметический алгоритм (в этом случае говорят о reasoning/thinking/«scaling up test-time compute») для получения новых результатов, возможно, недоступных для человеческого мышления.
- Софт/software 4.0 — можно ожидать, что тут будет инициатива агента на выполнение задач: агент будет выполнять и постановку задачи (например, брать обратную связь у пользователей и определять, что ему надо программировать, чтобы развивать систему в сторону её успешности), и программировать, и выводить самостоятельно инкремент системы на введение в эксплуатацию.
В необязательно программной, а именно — системной инженерии, «просто инженерии», мы можем наблюдать те же поколения по отношению к system design (проектирование+конструирование):
- Engineering 1.0: классическая архитектура и design (прежде всего конструирование уровня детали с использованием CAD и имитационного моделирования для расчётов прочности, теплопроводности и т.д.).
- Engineering 2.0: «дифференцируемое всё»[5] (в software 2.0 это было дифференцируемое программирование), например, можно дискретное представление архитектуры сделать непрерывным в так называемом «латентном пространстве» архитектурных решений, а затем найти оптимум — и вернуться в дискретное представление, получив оптимальную архитектуру. Важно, что тут не используются представления на естественном языке, используются представления на формальных языках, но вот операции с ними могут делаться в «латентном пространстве», чтобы иметь возможность задействовать оптимизационные методы вычислительной математики (например, метод стохастического градиентного спуска, SGD[6]). В программной инженерии Andrej Karpathy сказал в 2017 году, говоря о Software 2.0: «Gradient descent can write code better than you. I’m sorry»[7]. Это полностью относится и к engineering 2.0, только вместо code надо подставить проект/design системы.
- Engineering 3.0: это использовать программирование на естественном языке, формализацию и оптимизацию в рамках этой формализации при этом делает «компилятор» так же, как при компиляции кода с формального языка программирования в машинный код. Тут просто добавляется ещё ступенька — формализация делается тоже машиной, CAD-AI-copilot для pair engineering (аналогично парному программированию[8] в программной инженерии) и CAD-AI-agents для peer engineering (аналогично peer programming, отражает «равный статус программиста» для AI-agent). В инженерии «железа» или электрики всё ровно так же, как используется AI-copilots и AI-agents для программистских IDE[9].
- Engineering 4.0: агент инициативно ставит инженерную задачу, которую осмысленно решать, тратить на неё ресурсы, далее — работает агент по решению задач, как в Software 4.0.
На каждом уровне стека масштаба систем для систем разной природы их особенности дают огромное разнообразие трендов в инженерных методах. Общие для всей системной инженерии тренды найти сложно, хотя тренды движения к эволюционной и безмасштабной инженерии общие. Совсем не все инженерные проекты осознанно следуют этим трендам, но кто им не следует — быстро покидает рынок. Мы условно можем разбить общие для инженерии тренды на два вида:
- Тренды концепций целевой системы (концепция системы — это каким образом функциональная организация системы будет отражена её конструкцией). Скажем, в радиоэлектронике это ориентация на микропроцессоры со всё более жёсткими проектными нормами, например, стремительный по историческим меркам прогресс проектных норм в компании TSMC[10], или на использование GPU или TPU, или переход на новые типы ускорителей вычислений для отдельных видов вычислений (сейчас ожидается примерно через пять лет повсеместное применение квантовых компьютеров и оптических вычислителей). В киберфизических системах, особенно в классической робототехнике — это переход на управление на основе искусственных нейросетей. В работе с внутренними состояниями личности это переход к представлениям функционализма, а также переход к представлениям когнитивной революции. В основном это разбиралось в руководстве по системному мышлению.
- Тренды инженерного процесса, то есть методов создания и развития систем, то есть тренды в сервисах организационных систем, которые обычно и служат системами создания. Например, эволюционность инженерии вместо жёстко организованной стадийной водопадной одноразовой разработки — и в программной инженерии, и в практически любой инженерии. С первого раза правильно — но MVP, затем бесконечное развитие системы, сегодня инженерный процесс формулируется примерно так, это было показано в руководстве по методологии. Это дало не только распространение разного сорта вариантов инженерии внутренней платформы разработки (ранее — DevOps и SRE) как способов непрерывной быстрой сборки результатов разработки, а также быстрого обоснования успешности и введения в эксплуатацию. Это дало ещё и возможность непрерывной подстройки бизнесов под меняющиеся потребности клиентов и возможности команды проекта (обсуждается как движение Lean Startup после выхода книги Eric Ries «The Lean Startup» в 2011 году, об этом будет подробней дальше в нашем руководстве). Ещё пример — выход моделирования на стадию эксплуатации, то есть использование цифровых двойников как цифровых моделей, которые отслеживают состояние целевой системы на стадии её эксплуатации. В психотерапии (терапия — это аналог ремонта в инженерии личности) происходит отказ от методов психоаналитиков в силу появления evidence-based методов cognitive and behavior science как «золотого стандарта психотерапии»[11]. В случае методов политики как инженерии общества замена SoTA происходит очень медленно, но тренд очевиден — замена всевозможных диктатур и монархий на более демократические (бескровная смена правителя) формы правления, а также отделение церквей от государства. Хотя тут можно и поспорить: это тренд изменения концепции целевой системы или тренд методов работы создателей из их графа — ибо из одних и тех же людей в обществе мы берём и создателей, и самих членов создаваемого, развиваемого и даже работающего уже общества.
А есть ли тренды концепций использования? Конечно, но в целом потребности людей остаются неизменными: «спасение» (всё, что ведёт к бессмертию), «путешествия» (летать, свобода перемещения), «познание» (обычно в целях спасения и путешествий), делегирование труда. Поэтому функции систем остаются более-менее одни и те же (скажем, у транспорта — перемещение грузов и пассажиров из точки А в точку Б), а вот концепции автомобильного и ракетного транспорта будут разными, пилотируемого и беспилотного — разные, равно как будут разные и инженерные процессы в автомобилестроении и ракетостроении при всей их общности на высоком уровне абстракции.
Тренды концепции целевой системы обычно учитываются в более прикладных инженерных руководствах/регламентах/стандартах по разработке систем той или иной природы. В строительной инженерии учитывают тренды в конструкции зданий, в программной инженерии — тренды в софте (например, появление программ для квантовых вычислений на квантовой аппаратуре). Есть тренды в методах работы, которые настолько привязаны к специфике целевой системы, что их можно учесть только в прикладных очень узких курсах/руководствах/регламентах/инструкциях, например использование методов CRISPR и аналогичных в генной инженерии. Такими узкими прикладными методами являются и spacing и interleaving как методы подачи учебного материала в инженерии мастерства (эти методы обсуждались в начале руководства по системному мышлению, а также они даются в наставлениях по инженерии личности).
Тренды организации инженерной работы, то есть тренды в создании и эксплуатации организационной системы (оргзвена, предприятия, проектной группы, «расширенного предприятия»/«проектной кооперации» какого-то крупного инфраструктурного проекта, и т.д.) обычно рассматриваются в руководствах/стандартах/регламентах/блогпостах по системному менеджменту, а не системной инженерии.
И всё-таки, чтобы подчеркнуть мысль об общности нормативной инженерной науки для всех родов инженерии, приведём примеры нескольких общих трендов, которые нужно учитывать в сегодняшней работе инженеров во всём многообразии их ролей и всём многообразии целевых систем:
- Ведущий тренд — это использование в инженерии AI, а также получение систем (которые всё чаще и чаще — роботы, или системы из людей) путём не просто изготовления, а изготовления и обучения. Но мы это только что разобрали чуть подробней. Это главный, ведущий тренд. Так, порождающее проектирование (generative design) — это использование компьютеров для проектирования, в том числе в последнее время и для разработки концепции системы, и для предложения архитектуры[12]. Подтренд в этом порождающем проектировании, который только-только оформляется — это выучивание функциональности автономных систем в специально сконструированных для этого виртуальных мирах, world models[13]. Дело в том, что сегодняшние киберфизические системы имеют инженерный процесс, похожий на процесс создания зверей: рождается «железо» или «мясо» (при всей неполиткорректности такого названия) с какой-то рудиментарной «прошивкой», а затем происходит обучение в ходе какой-то игры с реальным миром — звери учатся ходить и бегать, охотиться, управлять своим телом, а роботы учатся тоже управлять своим телом в виртуальном мире, а потом это мастерство переносится в реальный мир. Уже не надо писать «программу робота», эту «программу робота» (а любая киберфизическая система по факту — робот) не нужно порождать софту-разработчику, но универсальная программа «искусственного интеллекта» выучивается выполнять какую-то работу в специально созданном для неё виртуальном мире, а потом переносится в реального робота — и всё работает. Автомобиль с нейронной сеткой в его системе управления учится автономному вождению или домашний робот учится вытирать грязные столы в виртуальном мире с точным физическим моделированием, после чего результирующая обученная программа нейронной сети переносится в реальный автомобиль или робот — и всё будет работать[14].
- Повышенное внимание к экологии. Нормативы на загрязнение окружающей среды растут, поэтому строго контролируются различные выбросы в атмосферу, в реки, ограничивается использование токсичных материалов (например, запрещён асбест) — это важно для крупных инженерных объектов, для атомных станций даже иногда возникают парадоксальные ситуации, когда можно брать воду для охлаждения из местных источников, но нельзя потом эту воду в них сливать: у источников естественная радиоактивность больше, чем разрешается для сброса воды от атомной станции! Но и для медицины и даже пищевой промышленности нормативы на ядовитость их целевых систем и используемые «материалы» тоже ужесточаются. Можно спорить, надо ли отслеживать выбросы двуокиси углерода в атмосферу в части их потенциального влияния на климат, ожидает ли нас глобальное потепление или очередной малый ледниковый период, но тут как с гимном: когда Михалкову сказали, что его поэзия для гимна плоха, он ответил: «Плоха или хороша, это неважно. Но когда гимн заиграют — ты встанешь». У инженеров тоже так: они выполняют требования политиков, а требования политиков становятся жёстче.
- Повсеместный переход к эволюционной инженерии и agile методологиям от водопадных. Это мы тоже довольно подробно обсудили, и тут много разных нетривиальных следствий. Например, малый размер инкремента/фичи, проходящего весь путь от замысла до выпуска, максимальная независимость разработки инкрементов друг от друга (этим озабочены архитекторы проекта). Часть этого тренда — параллельная инженерия, когда традиционные стадии водопадного жизненного цикла выполняются параллельно, а не последовательно (скажем, начинаем рыть котлован, строим фундамент одного крыла здания, продолжаем рыть котлован, возводим крыло, в этот момент строим фундамент второго крыла здания, заселяем первое крыло, в этот момент строим второе крыло здания — а то, что оба крыла будут крыльями одного и того же здания обеспечит информационная модель и точность возведения: совпадут все дверные проёмы, все коммуникации, окна везде будут на одинаковой высоте. В принципе, и проектировать эти крылья здания можно было бы не одновременно, а ещё важно, что здание не прекращает модифицироваться даже после окончания основного строительства, адаптивная архитектура[15], адаптивная строительная архитектура тут — синоним эволюционной). Это не только тренд, лежащий в основе эволюционной инженерии («не пытайтесь сделать всю систему целиком одним куском, обеспечивайте в ней фичу за фичей постепенно, подстраиваясь под меняющееся окружение и используя всё новое и новое знание, появляющееся в ходе длинного проекта»). Этот малый размер инкремента помогает ускорить работы, ибо соответствует малой порции работы (small batch size), тренду в операционном менеджменте (об этом уже было сказано в руководстве по рациональной работе, но ещё будет повторено в части операционного менеджмента руководства по системному менеджменту). В инженерии киберфизических систем это появляется после успеха такого сорта подходов в программной инженерии. В социальной инженерии малый размер инкремента был давно известен (поправки к законам, а не перевыпуск полного законодательства время от времени). Интересно, как этот подход медленно проявляется в образовании: болонская система, в которой вы можете уточнить программу через четыре года обучения в бакалавриате, а потом доучиться до магистра по выбранной специальности вместо пяти-шестилетнего обучения в специалитете «в один заход» — это отражение того же тренда, и (как это обычно бывает с трендами) тут часты откаты к более архаичным методам («специалитет» в России). Этому тренду малого размера инкремента противостоит идея «сложной смеси работ принципиально разного масштаба», ибо математика и идеи операционного менеджмента в части small batch size, использующаяся в том числе в agile методологиях инженерии, примерно соответствует математике и идеям многослойных систем управления, которые в своих работах обсуждают Matni Nicolai со товарищи[16], но массовое обсуждение этих идей и математики только-только начинается, нельзя пока считать это «трендом». В любом случае, ход на математические описания против суеверий-эвристик — он выигрышный, у него большие шансы стать реальным трендом.
- Моделеориентированность против документоориентированности — это тренд перехода к формальным (структурированные данные) компьютерным машиннообрабатываемым моделям представления инженерной информации вместо бумажных документов. В инженерии это переход к использованию информационных 3D-моделей вместо томов бумажной инженерной документации или даже переход от машинночитаемых, но не машиннообрабатываемых документов к машиннообрабатываемым (например, переход от использования бумажных документов с финансовой информацией сначала к .pdf файлам и банкам данных с этой же информацией в машинночитаемой, но не машиннообрабатываемой форме, а затем к использованию машиннообрабатываемых записей данных и даже баз данных с этой информацией. Банки данных и базы данных различаются как раз этой «машиннообрабатываемостью», часто говорят о «структурированной информации» при этом). В социальной инженерии это переход к использованию баз данных вместо архивов бумажных документов и пересылки выписок из этих баз данных в электронной форме вместо работы с бумажными документами. Нужно учитывать, что в данном случае существенно сдвигается баланс власти: один человек-чиновник при хорошем использовании компьютерных средств организации его работы может отследить выполнение бо́льшего количества ограничений свободы деятельности бо́льшего числа граждан, хотя время граждан может существенно экономиться на получение всяческих справок — но в целом мы получаем общество тотального надзора за жизнью граждан, «полицейское государство». Хорошо ли это? John Doyle (один из соавторов работы по многослойным системам управления из предыдущего пункта) говорит о «госнадзоре» и «силовиках» как об иммунной системе, защищающей от паразитов, но неизбежные следствия тут — самые разные аутоиммунные заболевания сообществ, обществ и даже человечества в целом, а также хак/взлом паразитами самой иммунной системы, вот это самое «полицейское государство» без права на творческое и продуктивное инакомыслие (мемо-иммунная система удаляет все неизвестные ей мемы/идеи и изолирует или даже уничтожает их носителей, включая потенциально полезные новые мемы и порождающих их людей и группы таких людей-новаторов, как несущих потенциальную угрозу: шанса эволюции что-то оптимизировать дальше при этом нет, «всё новое — инородно, иммунитет должен защищать от всего инородного»).
- Цифровые двойники, их применение сводится к моделеориентированному представлению (параметры модели в виде машиннообрабатываемых данных) и калибровке численных моделей системы по актуальным данным в ходе её эксплуатации, то есть цифровой двойник рассматривается уже за пределами разработки и изготовления. Раньше говорилось о важности цифрового моделирования системы в ходе её разработки и изготовления, но цифровой двойник показывает, что время эксплуатации не менее важно в части моделирования (например, можно принимать для киберфизических систем решение не просто о плановом ремонте, но ремонте только по состоянию — и для этого нужно накапливать данные об изменении состояния системы в ходе её эксплуатации). Интересно, что концепция цифрового двойника широко распространилась за пределами традиционных в инженерии киберфизических систем: говорят о цифровом двойнике пациента, цифровом двойнике студента, цифровом двойнике клиента бизнеса, цифровом двойнике предприятия. Центральное тут — численное моделирование, включая использование нейронных сетей для получения суррогатов точных моделей и намечающееся использование квантовых компьютеров для моделирования. Численное моделирование было широко распространено в физике и оттуда пришло в инженерию веществ (например, расчёты прочности), оттуда оно (в меньшей мере) перешло в инженерию киберфизических систем и стало известно там под названием «системное моделирование», ибо под «системностью» понималось объединение самых разных физических моделей, отражавших разные «системные аспекты» в одной мега-модели. Но это не было ещё современное системное многоуровневое моделирование (которое в физике называется многомасштабным моделированием), которое начало появляться в инженерии только в последнее время (скажем, для моделирования добычи нефти моделируется поведение нефти между песчинками пласта, частей пласта как пропитанных нефтью небольших объёмов песка, пласта в целом как какой-то сложной пространственной формы в недрах из пропитанных нефтью объёмов песка). В любом случае, численное моделирование по мере распространения вычислительной техники стало применяться практически повсеместно. Основной современный тренд в этом моделировании — использование машинного обучения (аппроксимирующих различные функции универсальных алгоритмов, которые обучаются этой аппроксимации на каких-то исходных данных), в частности глубоких нейронных сетей. Это моделирование используется для систем практически любой природы, находящихся на самых разных системных уровнях.
- «Платформизация» понимается чрезвычайно широко, но в общем случае означает наличие модуля-платформы с чётко определённым интерфейсом, который поддерживает набор специализированных/прикладных модулей для каких-то сервисов, отнюдь не все из которых нужны для каждого конкретного случая использования. В какой-то мере это следствие тренда на стандартизацию интерфейсов. Важно, что чётко определённый стандартом, выполнение требований которого легко проверить, интерфейс модуля-платформы позволяет разрабатывать прикладные модули разработчикам, организационно внешним по отношению к разработчикам платформы. Платформа автомобиля позволяет навешивать на неё двигатели разной мощности, салоны разной степени роскошности отделки, автоматику разной степени автономности работы — но все они используют общее автомобильное шасси, давая на выходе абсолютно разные по характеристикам автомобили. Платформа магазина интернет-приложений для смартфонов даёт возможность разработки приложений для десятков тысяч фирм и отдельных разработчиков. Мастерская инженеров-менеджеров реализует концепцию личности с сильным интеллектом как платформы: фундаментальное базовое образование (в которое включается и получение мастерства системноинженерной работы по нашему руководству) даёт мыслительное мастерство усиленного интеллекта, а на эту платформу легко добавить какой-нибудь модуль прикладного мастерства (например, инженерии личности или системного менеджмента). Часть этого тренда — стандартизация интерфейсов (открытая архитектура, open architecture). Нет стандартного интерфейса — не платформа! При разработке все интерфейсы между модулями не столько разрабатываются специально для каждого проекта, сколько берутся готовые — ориентация на «платформу со стандартным интерфейсом». Это в общем случае существенно снижает стоимость как проектирования (не нужно проектировать соединения), так и изготовления (можно использовать готовые модули, COTS[17]). Готовые системы (COTS, commercial/consumer off-the-shelf) вместо специально сделанных на заказ по индивидуальному заказу — тоже «платформенны», хотя такой взгляд и контринтуитивен. Если это одежда, то просто делается готовая всех размеров (интерфейс к разным размерам тела) и продаётся в магазинах, а не индивидуально шьётся в ателье. Если это программное обеспечение, то используется «коробочное», без длительной настройки (или с настройкой LowCode, без задействования программистов, силами «продвинутых пользователей», а сегодня и системы NoCode с естественноязыковым интерфейсом). Индивидуально под заказ сделанные инженерные системы и даже отдельные модули становятся системами для элитного потребления. Этот тренд в существенной мере следствие тренда на стандартизацию интерфейсов. Вариабельности продуктов/продуктовых линеек — это тренд платформизации (базовый модуль и отдельные модули для прикладных сервисов с чётко определёнными для них интерфейсами) с учётом хода на готовые системы (все системы должны выпускаться массово, а не индивидуально). Если присмотреться, то готовая продукция имеет множество вариантов исполнения (тренд платформизации), но эти варианты исполнения не нужно специально заказывать — они уже есть готовые (COTS). Помним, что вариабельность тут ведёт к множеству продуктов с примерно одинаковыми характеристиками, из которых трудно выбрать, и при этом появляются всё новые и новые продукты с примерно похожими характеристиками, которые очень медленно, но улучшаются, а время от времени улучшаются кардинально: это как раз «неустроенность», наличие множества субоптимальных решений с похожими характеристиками, следствие системных конфликтов и многоуровневой оптимизации в ходе меметической/техно эволюции.
- Продвинутые материалы, которые делают возможными новые инженерные системы. Тут даже не столько такое, как переход в ракетостроении от алюминия к стали в корпусах (основное в ракетах — это большая прочность при высоких температурах, эту прочность сталь на единицу веса даёт выше, чем алюминий, который выгодней по весу только при низких температурах). Но, например, новые лекарства, новые сверхпроводники, мета-материалы[18].
- … Это только примеры трендов, этих трендов много больше.
Конечно, есть тренды не совсем инженерии (хотя вопрос спорный: ведь мы договорились, что «всё — инженерия»). Например, бизнес-модель систем с открытыми исходниками (open source — термин используется и для программного обеспечения, и для электроники, и для всего остального), которая выводит на пересмотр границ того, что и как может быть разработано в рамках одного предприятия. Прибыль при такой бизнес-модели получается не за счёт продажи «интеллектуальной собственности» каких-то систем, а за счёт альтернативных способов заработка: или обслуживания, или использования сторонних разработчиков для собственных нужд, или через использование открытой документации в качестве рекламы основных сервисов. В любом случае, если два десятка лет назад открытые исходники были «исключением из правил», то теперь их использование никого не удивляет.
Чтобы отслеживать такие тренды, нужно следить за текущей литературой. Часть из них связана с распространением системного мышления (стандартизация интерфейсов), часть с лучшим пониманием математики операционной работы (small batch size как основа «аджайлизации»), но значительная часть — с успехами моделирования, в том числе порождающего моделирования (когда речь идёт не только о создании модели, но и создании по модели каких-то предположений о мире. «Порождающее моделирование» — это в какой-то мере «антимоделирование», где на основе модели нужно создать описание мира, а не на основании описания мира создать модель), а часть этих трендов получена «случайно», то есть в ходе техноэволюционного процесса порождения нового, базирующегося на случайных мутациях мемов и естественном отборе удачных мутаций.
Искусственный интеллект на основе нейронных сетей стал известен широкой публике только в 2012 году. Сфера его применения в системной инженерии практически та же самая, что и естественного интеллекта (по факту используется всегда коллективный гибридный интеллект: множество естественных интеллектов, обычных компьютерных программ и баз данных и какие-то варианты искусственного интеллекта, например, алгоритмы на основе глубоких нейронных сетей). Уже сегодня искусственный интеллект на уровне среднего человека стоит дешевле школьника (переводчик Гугла тут как раз пример). Ситуация быстро меняется, и через несколько лет (мнения расходятся, но большинство считают, что через 2-5 лет) можно ожидать появления компьютерного интеллекта, обладающего для широких классов инженерных задач сверхчеловеческой силой (сверхчеловеческой — это «более умных, чем лауреаты Нобелевской премии»). Это существенно изменит все инженерные методы, для всех системноинженерных/эволюционных уровней сложности.
Можно ожидать, что искусственный (а на самом деле гибридный, ибо речь идёт о совместном мышлении людей и машин в коллективных проектах, а ещё искусственный интеллект учится на результатах предыдущих работ естественного интеллекта людей — граница естественного и искусственного тут крайне размыта) интеллект будет использовать те же принципы устройства инженерного проекта, которые описаны в нашем руководстве. Если потребуется обучить искусственный интеллект хорошей инженерии, то мы могли бы ему посоветовать взять это наше руководство, но ещё и обязательно все руководства-пререквизиты.
https://ailev.livejournal.com/1464563.html, книга https://arxiv.org/abs/2403.14606 ↩︎
https://en.wikipedia.org/wiki/Stochastic_gradient_descent ↩︎
https://en.wikipedia.org/wiki/Integrated_development_environment ↩︎
https://www.anandtech.com/show/21408/tsmc-roadmap-at-a-glance-n3x-n2p-a16-2025-2026, к этим «проектным нормам» нужно относиться с осторожностью, https://www.iguides.ru/main/other/sovremennye_tekhprotsessy_grandioznyy_obman_razbiraemsya_v_marketingovykh_tonkostyakh_protsessorov/ ↩︎
https://en.wikipedia.org/wiki/Cognitive_behavioral_therapy на базе behavior and cognitive psychology, https://www.apa.org/ed/graduate/specialize/behavioral-cognitive ↩︎
См. про архитектурную оптимизацию в https://ailev.livejournal.com/1464563.html ↩︎