Например, предполагается, что на каждом шаге роста функциональности развиваемой системы (непрерывное развитие подразумевает не разовое создание системы, а создание и развитие системы с постепенным наращиванием её функциональности) будет осознана возможность создания очередного инкремента системы, он будет описан в концепции использования, откорректирована будет концепция системы, затем концепция системы будет детализована в проекте/design с достаточной для изготовления инкремента точностью, затем изготовлены части нового инкремента, система собрана и отлажена «в физике», проверена, введена в эксплуатацию с новым инкрементом, если будут найдены проблемы, выведена из эксплуатации с переходом на предыдущую версию, отэксплуатирована (работа оператора, мониторинг), и так далее— для каждого вида систем будет что-то подобное, хотя терминология может существенно отличаться (например, «изготовление мастерства» термин использован не будет, а будет говориться об «обучении мастерству»).
В любом случае, в проекте ожидается некоторый набор объектов, которые будут менять в ходе проекта свои состояния. Эта смена состояний проводится какими-то методами работы. Например, концепция системы делается с участием разработчиков (их предмет интереса— функциональная декомпозиция и набор конструктивов в качестве аффордансов для подсистем как функциональных объектов) и архитекторов (их интерес в том, чтобы система была построена из конструктивов с оптимальной автономией, ибо это влияет на многочисленные архитектурные характеристики— и это часто противоречит предложениям каких-то групп разработчиков). Интерес разработчиков обычно— быстрый ввод новой функциональности сейчас («быстрое и грязное решение»), интерес архитекторов— быстрый ввод новой функциональности в будущем (минимизация технического/архитектурного долга). Подробней это обсуждается в курсе «Системная инженерия», но сейчас важно, что есть методы работ по разработке и методы работ по принятию архитектурных решений, которые как-то согласованно двигают по состояниям объект «концепция системы», причём это движение происходит в ходе всего проекта, учитывая непрерывное развитие системы и выпуск очередных версий системы с новыми и новыми инкрементами, реализующими новую функциональность.
Само движение по состояниям каких-то изменяющихся в ходе проекта объектов, а также способы моделирования этого движения будут рассмотрены в курсе методологии. Какие объекты и как именно они движутся по состояниям— это будет рассмотрено в инженерных курсах (системная инженерия, инженерия личности, системный менеджмент). В этих же инженерных курсах будут рассмотрены роли, которые выполняют инженерные (менеджерские, учебные, продвиженческие и т.д.) методы работы. Каждый из этих методов работы заставляет агента, выполняющего соответствующую роль, преследовать какие-то интересы.
https://aisystant.system-school.ru/lk/#/course/practical-systems-thinking/2024-04-12T2339/27343
Тут моя “мозайка” понимания на уровне курсов вопроса, зачем на каждом курсе рассматривать одно и тоже и что именно, пришло в “четкую” картинку. И я понял в чем разница интересов разработчиков и архитектором на себе как агенте играющего две роли постоянно и не понимающего в какой я сейчас роли отстаиваю интересы. Спасибо!