Инженерная наука
Инженерная наука (engineering science), ищущая компактное описание для SoTA инженерии, должна рассказать об инженерии как культуре инженерного сообщества. Она отвечает на вопрос о том, что делает создатель в роли инженера (или в одной из составляющих архироли инженера) в ходе инженерного проекта.
Отношение к системной инженерии как к науке среди системных инженеров киберфизических систем обычно отрицательное (хотя они и признают её полезность). Это отношение связано с тем, что «наука» (объяснительные теории, научное знание) обычно никогда не рассказывает, как породить ту или иную идею и потом как эту идею проверить и реализовать. Знания, которые даёт наука, как «формальная модель/теория» хороши для критики, для нахождения ошибок, они дают строгие типы, которые позволяют проще находить логические несоответствия. Вы легко заметите, что в ваших же предложениях по проекту не так, если будете знакомы с инженерной наукой, если узнаете её хотя бы в объёме нашего текущего руководства. Поэтому вы сможете выдвигать идеи, имеющие шанс быть реализованными, остальные не пройдут вашу же критику. То же самое относится к идеям других. Но вот можете ли вы выдвинуть какую-то достойную идею? Не факт. Помним, что рассуждение тут идёт по трём стадиям обучения (тут для инженерии, но это верно для любого метода работы):
- Вы изучаете материал учебника (pretraining) по инженерии, с жизнью это пока никак не связано, собранности на нужных объектах и удерживания их во внимании в длинных рассуждениях нет, каждый отдельный объект в его отношениях с другими объектами знаком, но длинных рассуждений не получается, а ещё не получается связать объекты из учебника с жизнью.
- Вы знакомитесь с тем, как работают люди (finetuning), как они мыслят в типовых ситуациях и как рассуждают про связь «яблок из учебника» (их же там считают!) с «яблоками из жизни» (их же едят! Причём тут подсчёт!). Это в обучении AI обычно называют RLHF (обучение с обратной связью от учителя), и тут засада: вы будете повторять типовые ходы уровня ваших учителей в таких проектах, которые видели ваши учителя. Но вы вряд ли сможете превзойти ваших учителей. Это как насмотреться на задачи, для которых есть пошаговые способы решения с ответами. Если вы увидите примерно такую задачу, вы её решите. Если увидите другую задачу — не решите, ибо не знаете, как решать. Собственно, именно тут знание учебника становится жизненным, а не абстрактным знанием. Поздравляю, вы хороший подмастерье, но сами ещё не способны работать мастером.
- Вы решаете много задач, для которых ответ вроде как известен (успешная система). Но вот решение «по действиям», метод достижения решения неизвестен. Поэтому приходится делать догадки (заниматься творчеством), проверять их — и запоминать паттерны уже своей работы, а не паттерны из учебника. Вот тут надо иметь предельную собранность, вот тут надо иметь хорошее знание учебника и понимание, как решать задачи пошагово, чтобы отсекать неперспективные догадки. Это обычно называют «приобретением опыта» (при этом понимаем, что у вас должно быть большое разнообразие ситуаций и придуманных вами решений, чтобы это был, например, «двадцатилетний опыт», а не «однолетний опыт, повторенный двадцать раз, безнадёжно устаревший уже на пятый год»).
Конечно, вы можете всю эту умственную работу отдать AI или (если вы начальник) любому вашему сотруднику, но это тогда можно будет отдать AI или другому сотруднику и без вас, посредники не нужны. Вы должны понимать, что оставить из мышления себе, а что отдать — и как потом собрать сделанную работу, чтобы проект с приложением ваших мозгов был более успешен, чем без вас.
Без «науки» тем самым трудно решать практические задачи, ибо предлагаемые решения будут вести к неэффективности, переделкам из-за ошибок, неудачам, но сама наука обычно ничего не говорит о том, как породить идею решения. Инженерия тут ничем не отличается от любой другой деятельности, где идеи рождаются «из шума». Конечно, какие-то закономерности в эволюции уже можно обсуждать, поэтому мутации вблизи какого-то локального оптимума динамического ландшафта приспособленности, но вам-то надо выдать догадку, которая ведёт потенциально не к текущему локальному оптимуму, а к глобальному оптимуму — и часто на то место в этом ландшафте, которое только-только должно появиться! Когда-то Bill Gates сказал, что компьютер будет на каждом рабочем столе, и на нём поэтому будет операционная система, которую разрабатывает Microsoft. Это как с Уэйном Гретцки[1], которого спросили, как он всё время оказывается там, где шайба? Он ответил, что оказываться там, где шайба — невозможно. Но можно оказываться там, куда шайба вот-вот придёт. Вот инженеры в проекте заняты именно этим: они делают догадки даже не по текущей ситуации, а догадки о той ситуации, которая будет. Недаром теория стратегирования дана сейчас в конце руководства по методологии.
В инженерной науке по факту речь идёт о «человеческой деятельности» (а сейчас уже — об «агентеческой деятельности», не забываем, что в одном из определений AGI — это алгоритм, способный реализовать проект по зарабатыванию им денег). Как устроена деятельность (виды труда, методы работы) людей, компьютеров и их организаций, объяснения того, какие важные в ней выделить объекты, как описать — это задача методологии, объяснительной теории, увенчивающей интеллект-стек как раз перед системной инженерией.
Беда в том, что если вам нужно породить новый метод, то есть стратегировать, то непонятно как сделать догадки о важных в ней объектах. Скажем, в инженерии вам надо описать целевую систему перед тем, как её изготавливать, но как догадаться, что она вообще нужна? Как догадаться, как она может быть устроена? Как описать это так, чтобы можно было воплотить эту систему в физическом мире со стоимостью меньшей, чем ожидаемые выгоды от её применения? Как обосновать эти догадки (как сделать инженерные обоснования, там ведь тоже непонятно, какие из множества известных методов инженерных обоснований задействовать)? Как потом воплотить это всё в жизнь, то есть принять решения на основе гипотез в условиях полной неопределённости, «принять всерьёз»? И это даже ещё не «сделать», результат выполнения работ по тщательно выбранному методу ведь может быть абсолютно неожиданным — если что-то может пойти не так, то оно обязательно пойдёт не так!
Методология рассказывает о том, какие есть в мире объекты, их характеристики и отношения друг с другом, что можно с этими объектами делать. Что с этими объектами делать для решения конкретных задач — неведомо, надо высказывать догадки и проверять их. Никакое знание физики не позволяет само по себе решать даже олимпиадные задачки по той же физике, что уж говорить о решении реальных проблем. Но без знания физики и олимпиадные задачки, и инженерные проблемы решать труднее, вы будете считать потенциально верными догадки, которые заведомо неверны, будете тратить на эти догадки драгоценные ресурсы, терять время и нервы.
Наука/исследования аналитичны, они посвящены критике догадок, их опровержению — при помощи теории, которая сама когда-то была хорошо прокритикованной догадкой, но выстояла перед критикой и экспериментами.
Инженерия связана с решением проблем (проблема — когда никто не знает, что делать, метод неизвестен, часто даже предметная область метода неизвестна), поэтому она требует сильного интеллекта. Инженерия связана с творчеством/изобретательством (помним про раздел, посвящённый творчеству в руководстве по системному мышлению). Творчество нельзя выполнить алгоритмически «быстрым выводом по правилу», оно связано с базирующимися на случайностях и запоминании удачных случаев меметическими алгоритмами, выполняемыми или компьютерами, или людьми, или гибридно целыми коллективами людей с их компьютерами. И да, «ум» AI-систем тоже базируется на случайности, на умении делать догадки — и критиковать их, отбрасывая заведомо неуспешные, чтобы на выходе остались только догадки с максимальной вероятностью успеха, наиболее устойчивые к критике логической и критике экспериментальной.
К сожалению, сведение всей инженерии только к науке («нет теоретического обоснования — не инженерия») и «аналитике/критике» без сопутствующих догадок по синтезу в ущерб практической деятельности по решению проблем, в том числе с помощью «ненаучных» по своей природе догадок-эвристик-гипотез-суеверий отражено и в учебных курсах по инженерии систем самых разных уровней, и в профессиональных руководствах и стандартах. Так, по отношению к киберфизическим системам руководитель NASA Michael Griffin в речи 2007 г. (и с тех пор в образовании по околовоенной и государственной системной инженерии киберфизических «железных» систем мало что изменилось, наше руководство тут сильно отличается, как и современные руководства по программной/software инженерии) «System Engineering and the Two Cultures of Engineering»[2] даёт критику расхожего инженерного образования, которое учит «аналитике/критике/объяснениям», а не инженерии:
I have always loved the view of the engineering profession captured by the great Theodore von Karman when he said, "Scientists study the world as it is; engineers create the world that has never been." Less eloquently, engineers are designers; they synthesize knowledge to produce new artifacts. Von Karman speaks to what most of us, and certainly most laymen, would consider the essence of engineering: engineers create things to solve problems.
But all of us who are engineers know that the engineering profession also has a rich scientific side, the analysis of these artifacts and the prediction of their behavior under various environmental and operational conditions. Adapting von Karman's observations, it may be said that engineering science is the study of that part of the world which has been created by man.
Sadly, many students have been led to believe that engineering science is engineering! In a curriculum of 120 or more credits leading to a bachelor's degree in a branch of engineering, the typical student is required to take one, or maybe two, courses in design. Everything else, aside from general-education requirements, focuses on the analysis, rather than the creation, of engineered objects. Graduate education often has no design orientation at all. So, engineering as taught really deals with only a part of engineering as it is practiced.
Переводя на более привычные реалии жизни, инженерное образование даёт не инженеров-синтетиков, не проектировщиков, а только аналитиков — которые умеют только критиковать (и, конечно, давать предложения без принятия на себя за них ответственности — но это неформально, этому не учат, курсов проектирования/design крайне мало).
Вы думаете, что это верно только по отношению к системной инженерии? Нет, то же самое верно по отношению к инженерии предприятия, то есть менеджменту. По идее, учебные программы MBA (магистры бизнес-администрирования) были задуманы как выпускающие менеджеров, способных развивать свои предприятия — стратегов, бизнесменов, оргпроектировщиков. Но нет. Исследователь менеджмента Henry Minzberg написал целую книгу «Managers not MBAs»[3] об этом: в программах MBA учат аналитике — после окончания этих программ у людей отличные карьеры начальников аналитических отделов (которые готовят аналитические отчёты, но которые не принимают никаких решений и не вырабатывают никаких решений), начальники финансовых служб (которые не принимают никаких управленческих решений, но зато отлично следуют правилам налогообложения). А менеджмент? Minzberg говорит ровно то же — это синтетика, не аналитика. Менеджмент как инженерия предприятия — это прежде всего творчество, умение делать догадки, решающие проблемы, снимающие противоречия — и эти догадки даже не по поводу теории, не «исследовательские», а по поводу ситуации в будущем. Менеджмент, как инженерия предприятия — он в этом, в творчестве, в синтезе, а анализ носит вспомогательную роль, он обязателен, но это только критика. Да, его можно вынести в «отдельную аппаратуру» (помним, что мы буквально пару подразделов назад обсуждали работу[4], что общее умение думать не зависит по качеству результата — отдали ли мы критику «спецаппаратуре» или критикуем сами, сразу после высказывания догадки. Но без догадок критиковать нечего!). Совсем недаром программы MBA сегодня не любят детально рассказывать о том, чему же они учат — ибо очевидно, что на выходе такой программы не будет кого-то типа Bill Gates, Jensen Huang, Elon Musk. Как ни странно, все эти великие менеджеры вышли из инженерных вузов, и это не случайно. А на что заманивают в программы MBA? Посмотрите: там заманивают на то, что у вас будет хорошая компания, статусные одногруппники, вам дадут пообщаться с разными успешными людьми. Это не похоже на обучение какой-то науке!
В какой-то мере этот тезис примата творчества/синтеза над аналитикой/критикой подтверждается опытом мастерской инженеров-менеджеров: на стажировку по системному менеджменту в мастерскую приходят выпускники программ MBA, и от многих из них после выпуска независимо поступают отзывы, что «только сейчас стало понятно, чему учили на MBA и как это использовать». Конечно, аналитика важна — если знать её место в инженерии «железной», программной, предприятия (в случае MBA), личности и мастерства в составе личности!
И то же самое можно говорить о создании и развитии систем самых разных масштабов и видов, включая общественные: инженерия всех них подразумевает создание нового, высказывание труднокритикуемых догадок, которые выживут всю рациональную критику (включая и логику, и эксперименты). Критика тут крайне важна, но вспомогательна. Критика тут играет роль естественного отбора в эволюции, она как куратор галереи. Но главный в галерее не куратор, а артист! Куратор важен только для того, чтобы отобрать достойного артиста. Эта метафора взята из биологии развития[5], но она вполне подходит не только к эволюции-инженеру, но и к людям-инженерам, AI-инженерам.
Основное, что должен уметь делать системный инженер, как создатель — это создавать успешные системы, менять мир к лучшему, придумывать, как это сделать, а анализировать*/критиковать/*объяснять эти системы и свои методы работы — это важная, экономящая ресурсы, время и нервы, но подчинённая синтезу задача. Упор на квазиоптимальный синтез и непрерывные попытки его улучшить и вписать результат в непрерывно меняющееся окружение, а не упор на «строго научный анализ и безупречное обоснование» характеризует инженера. Обоснование важно, но оно уместно только тогда, когда есть что обосновывать!
Так что в учебных программах нужно учить в том числе и создавать(а хоть и опираясь на генетические/эволюционные алгоритмы), а не только объяснять и критиковать!
Всё-таки нужно владеть методом системной инженерии (его излагает на кругозорном уровне наше руководство), а затем нужна конкретизация этого метода для целевых систем самой разной природы, которыми приходится заниматься в рабочих проектах (будь то вещества, киберфизические системы, существа, личности, организации, сообщества, общества или даже человечество в целом), то есть нужно будет освоить работу ещё и по методам самых разных прикладн****ых инженери****й (программной инженерии, механической инженерии, генной инженерии, инженерии киберфизических систем, социальной инженерии, хореографии и т.д., их огромное разнообразие). А поскольку одному человеку всё это богатство прикладных инженерий для успеха проекта познать невозможно, то дальше нужно будет думать, как учить инженерии даже не одного человека, а целую инженерную команду, каждый член которой будет хорошо выучен фундаментальной системной инженерии, но потом немного разному набору прикладных инженерий. Впрочем, это всё про людей. Опыт показывает, что AI вполне можно научить самым разным инженериям — и каждые несколько месяцев в очередной прикладной области инженерные умения AI вырастают до степени, уже сравнимой с уровнем людей, и даже превосходящей их.
Но главное — это не забывать, что инженерия сводится не к описанию мира, а изменению мира, улучшению мира. Описывать мир — это не заниматься инженерией, даже если описываешь инженерные проекты. Аналитика, глубокое знание дисциплин — это не инженерия. Один из системных инженеров NASA как-то привёл пример, в котором сравнивал инженерную науку (в том числе ту, которой обучают в университетах) с порнографией: можно сколько угодно тратить времени на «аналитический» просмотр и обобщение бесконечного числа порнофильмов, но все эти часы и часы псевдоопыта «изучения» и «аналитики» можно было бы потратить на получение собственного опыта «синтетики», опыта действия, получив при этом не меньше удовольствия, чем от «аналитического» просмотра порно. Ну, и овладение всеми возможными классификациями увиденного, знакомство с хитрой терминологией и прочие «атрибуты научности/аналитичности», почерпнутые из просмотра видео могут абсолютно не помочь (а то и помешать) в конкретной жизненной ситуации, требующей синтеза, а не анализа — ибо надо не описывать со знанием дела, а делать со знанием дела! Сегодняшние системные инженеры NASA предлагают больше уделять внимания творческой/синтетической работе в проектах, а не заниматься чтением учебников и руководств по инженерной науке. С этим сравнением нельзя согласиться:
- Инженерная наука сегодняшнего дня (эти строки пишутся в 2025), опирающаяся на современную системную методологию третьего поколения (выходящую на масштаб времени техноэволюции, а не только жизненного цикла одной версии системы), абсолютно другая, нежели даже пять лет назад, когда стало очевидно, что революция continuous delivery и в программной инженерии победила массово, и в «железной» инженерии. Чтобы заниматься инженерией прошлых дней, надо было читать учебники прошлых дней, а затем как-то продвигаться вперёд, заниматься мутацией её методов. Это видно по стилю работы SpaceX сначала над Falcon 9, затем над Starlink, затем над Starship. Инженеры SpaceX имели большой опыт работы в NASA, а затем они преодолели тамошние недостатки. NASA с тамошними технологиями и воззрениями выглядит сегодня по части творчества уже отстающей организацией, там не соблюдается баланс высказывания гениальных догадок и последующей их критики. Поэтому бесполезно не читать учебников вообще, но полезно читать современные учебники, куда вошли SoTA инженерные методы, SoTA инженерная наука. В современные учебники, конечно, вошёл опыт SpaceX и многих других передовых инженерных компаний — в том числе и то замечание, что опыт передовых «железных» компаний является по факту опытом компаний программной инженерии, причём осваиваемый с большой задержкой (лаг 5-10 лет). Современные учебники/регламенты/стандарты/руководства пытаются сократить этот лаг, как это делает и наше руководство.
- Методы обучения мастерству инженерии стали совсем другими. Так, сегодня очевидно, что наука даёт типы объектов внимания, которые являются мета-мета-моделью к типам мета-модели предметной области (общекультурной и конкретного варианта в вашем предприятии), а та в свою очередь задаёт типизацию конкретных объектов в конкретном проекте в жизни, то есть типизацию (операционной) модели. Вот этой работе с типами и нужно учить, в этом залог привязки теории к жизни. Пр****именимость знаний системной инженерии непосредственно связана с умением обращаться с абстрактными/идеальными объектами**, они же объекты** ментального пространства, но отнюдь не во всех вузах инженеров этому учат явно**, как и не учат всегда привязывать эти объекты к каким-то ситуациям в физическом мире, заниматься заземлением/grounding. Отсюда и легенды о «неприменимости знаний в жизни». Не «неприменимость», а «неумение применить»!**
- Сама инженерия стала сложнее, и просто «пробовать работать» уже не получится: слишком низка вероятность хорошего результата. Нужна теория, даже если она и не закрывает 100% встречающихся проблем. Никакая теория не закрывает 100% проблем и всегда нужно подключать фундаментальное мышление, а также всегда нужно подключать меметические алгоритмы и делать на их основе какие-то догадки, а не «всё выводить из теории». Но если не опираться на теорию, а основываться исключительно на «смекалке и натиске», то всё в проекте будет медленно и ресурснозатратно, со скоростью естественной, а не «умной» эволюции: успешной системы вы или не создадите, или успех будет очень кратким. Мутации должны быть «умными», и желательно поэтому не просто «догадываться» о них, но и проверять критикой на основе теории. Если вы догадались, что ответом на 2*2 может быть 5**—** используйте теорию, чтобы это проверить, не берите до этого вашу догадку всерьёз!
Системные инженеры постулируют примат инженерного опыта над инженерной наукой, хотя также и признают важность науки (ибо без признания важности науки можно скатиться назад, к древним временам инженерии исключительно проб и ошибок, не оптимизированной моделированием/теоретизированием эволюции), просто оформляемый эвристиками инженерный опыт на любой момент времени много, много больше той территории, которая уже отвоёвана наукой с её хорошо проведённой критикой удачных догадок, дающих компактные объяснительные модели.
Наше руководство по (безмасштабной и эволюционной/непрерывной, а также неантпропоцентричной) системной инженерии решает вопрос о балансе методов, описанных в инженерной науке и не описанных в этой науке методов инженерной «возни»/tinkering так:
- Руководство активно использует интеллект-стек фундаментальных методов мышления, хотя и не все методы этого стека (скажем, нет математики, физики, эстетики, риторики). Тем не менее, перед освоением работы по руководству надо уже как-то быть готовым к полностью новым ситуациям, которые не описаны в известных учебниках/руководствах/стандартах/регламентах, и надо уметь как-то ориентироваться в таких ситуациях (причём не только путём обращения к AI — к нему и без вас обратятся, вы лично не нужны для этого, если только не знаете, как именно надо обратиться к AI, чтобы это оказалось полезным — а другие не знают. Это то же разделение труда). Какая-то сила интеллекта — пререквизит к системноинженерной работе. Если вы освоили исследовательскую программу развития инженеров-менеджеров (руководство по интеллект-стеку как раз в ней), это сильный плюс.
- Сначала наше руководство в первой паре разделов даёт самую общую объяснительную теорию инженерной нормативной науки, включая объяснения границ применимости этой теории (объяснения границ применимости — это как раз текущий и предыдущий подразделы руководства).
- Знание принципов освобождает от знания множества фактов. Инженерам нужно сразу знать (а не догадываться по ходу проекта), каковы основные объекты, с которыми работают инженеры в их многочисленных ролях, как бы они ни назывались в разных предметных областях. Это «нужно» — нормативный аспект теории, например, «вы как архитектор должны принимать архитектурные решения в вашем проекте, понимая приоритеты в реализации архитектурных интересов», и т.д. Это основной материал руководства, он изложен в следующих разделах. И если «нужно» и «вы должны» (деонтическая модальность), значит — нужно, и должны. Это значит — мало читать и знать, ещё надо реально делать в проектной работе. У нас в руководстве наставления на работу, их нужно выполнять, брать всерьёз!
- Руководство содержит отсылки к конкретизациям методов и ролей системной инженерии главным образом для «железной» и программной системной инженерии. Есть отсылки и к конкретизациям методов системной инженерии систем другой природы, но их не очень много. Само изложение в руководстве кругозорно, его явно не будет хватать для работы инженером. Подробное (не кругозорное) знакомство с конкретными/прикладными инженерными методами для отдельных видов систем крайне важно, но оно предполагается потом и предполагает прохождение дополнительных прикладных курсов (по программной инженерии, инженерии киберфизических систем, системному менеджменту как инженерии предприятия, и т.д.). Нужно отчётливо понимать, что мастерство во владении отдельными методами набирается достаточно долго (единицы лет), причём по каждому прикладному методу работы и даже их составляющим методам есть курсы/руководства/учебники/регламенты/стандарты даже более объёмные, чем наше. Вспомните объемы вузовских учебников по много более узким дисциплинам, например двухтомные А4 учебники, отдельно двухтомники по органической и неорганической химии! Или знаменитый «ландавшиц», там формат A5, зато сразу 10 томов[6].
Вот общая схема того, как устроено инженерное знание с точки зрения нашего руководства (пропущенные строчки таблицы, конечно, знать для успешных занятий инженерии надо, в руководстве по интеллект-стеку они подробно описаны, но в конкретной текущей версии руководства полноценное владение всем интеллект-стеком фундаментальных методов мышления не предусмотрено):
| Интеллект-стек фундаментальных методов мышления | Что нужно знать для освоения системноинженерной работы по нашему руководству |
| Методология | Моделировать деятельность (типы: метод, оргроль, оргвозможность, работа). Системное описание предприятия как графа создателей: альфы и подальфы, их состояния. |
| Риторика | Опускать типы мета-мета-модели в речи. Независимость модели от формы выражения |
| Этика | |
| Эстетика | |
| Исследования | Эволюционность алгоритмов в основе методов |
| Рациональность | Стратегирование — рациональный выбор метода |
| Логика | |
| Алгоритмика | Методы — это «обобщённые алгоритмы» |
| Онтология | Мета-моделирование на пяти уровнях L0-L4 |
| Теория понятий | Типы и отношения, «машинка типов» (и доступ к ней через кинестетику — «дребезг») |
| Физика | |
| Математика | |
| Семантика | Понятия, терминология, 4D объекты в мире |
| Собранность | Модели записываем, устно не моделируем! |
| Понятизация | Давать имена объектам |
Теоретическое знание нашего руководства должно «оживляться» на материале конкретных инженерных проектов. Для простых проектов даже не предполагается умений, получаемых в прикладных курсах инженерии их целевых систем — но если вы уже работаете в каких-то не слишком простых проектах (уровень сложности выше, чем «прибить на стену полочку над кроватью»), то мы предполагаем, что вы знакомы с той предметной областью, в которой работаете (а если не знакомы, то как вы надеетесь принести пользу своей работой? «-- Умеете ли вы играть на скрипке? — Нет, не пробовал. Но думаю, у меня получится, концерт уже назначен, билеты проданы», так?).
Д****ля профессиональной работы системным инженером (помним, что эта работа отнюдь не всегда называется «системной инженерией», а роль «системным инженером», помним о «коуче», «политике»****, «агрономе» и т.д.) дополнительн****ое прикладное обучение обязательно! Кругозорного обучения хватает обычно только для любительской работы, в крайнем случае — для помощи в постановке задачи прикладному профессионалу, который с вами беседует, чтобы хотя бы примерно понимать, что он будет делать и почему, и какие его вопросы будут интересовать, и о чём с ним вообще можно говорить, а о чём нужно говорить с другими прикладными ролями.
Наше руководство не рассчитано только на «прочтение» и запоминание указанных в нём типов объектов. Нет, его наставления должны лечь в основу практической работы, в которой теоретическое знание мета-мета-модели системной инженерии соединяется с практическим знанием прикладной предметной области применения этой инженерии в её общекультурном/кругозорном варианте (метаУ-модель) и варианте, принятом в вашем предприятии (метаС-модель) — и вы должны понимать, какие там типы более абстрактных моделей аннотируют типы более конкретных моделей. После освоения системноинженерного мышления по нашему руководству его основные методы будут ещё уточнены и потренированы в прикладных предметных областях, например, описанных в руководствах по инженерии личности и системному менеджменту.
Нет ничего практичней, чем хорошая теория, но без занятий реальной инженерной деятельностью в рабочих (не учебных!) проектах эту практичность предъявить нельзя. Тот, кто прочёл много книг по танцам, но никогда не танцевал сам, вряд ли сможет станцевать при случае. К инженерам (агрономам, менеджерам, политикам, кому угодно) это тоже относится.