Текст книги "Системное мышление 2024. Том 2"

«Нефункциональных требований» не было, хотя такой термин часто встречался в литературе, но обычно разъясняли, что его использовать неправильно. Чаще говорили просто о других видах требований – например, требованиях качества (-ости/-ilities, типа доступность, ремонтопригодность, надёжность), которые интересны не только разработчику, но и другим ролям в проекте, прежде всего роли архитектора. Сейчас стало очевидно, что архитектура имеет дело с архитектурными характеристиками (прежде всего эти -ости), но они относятся к системе не в части выполнения своих прикладных функций, а к общему какому-то поведению и в момент работы/operations (например, характеристики надёжности работы) или даже на момент создания и развития (например, характеристики возможности лёгкого изменения в ходе непрерывных улучшений, evolvability). И эти характеристики хотя и разные, но всё-таки более-менее одинаковые у самых разных видов систем. Например, масштабируемость/scalability: насколько легко поднять производительность системы, если это надо – нужно будет только добавить какие-то дополнительные модули (скажем, добавлять ещё пару колёс на каждую новую тонну грузоподъёмности тележки, или придётся всё разрабатывать по-новой с самого начала – ибо для увеличения грузоподъёмности менять надо в тележке и раму, и колёса, и вообще всё?). Архитектурные характеристики – описание поведения системы при работе в необычных условиях или не в момент эксплуатации: способность работать под высокой нагрузкой, ремонтопригодность, доступность по цене/affordability (помним, что совокупная стоимость владения затрагивает и стоимость расходников и обслуживания при эксплуатации, но ещё и стоимость изготовления включает не только стоимость материалов, но и стоимость работ системы создания, то есть затрагивает описание ещё и систем не из окружения, а из цепочки систем, создающих целевую систему), лёгкость монтажа. Курс «Системная инженерия» подробно разбирает работу архитектора, архитектурные характеристики, способы достижения приемлемых значений для метрик, которыми измеряют архитектурные характеристики.

Конечно, во многих и многих моделях пересекаются и концепция использования (что делает система на её внешней границе, чтобы вписаться в окружающие её системы в момент её работы, принося какую-то пользу этому миру), и архитектурные характеристики (надёжность, лёгкость изменений системы разработчиками, устойчивость к разрушению, и прочие характеристики, непосредственно не связанные с функциями системы), и концепция системы как описание внутреннего устройства системы, «прозрачного ящика». Как концепция использования при детализации превращается в набор сценариев использования, так концепция системы при детализации превращается в проект/design системы, который уточняется вплоть до описаний прозрачного ящика, достаточно детальных для изготовления системы.

Если говорить о таком же наборе описаний, но на уровне надсистемы (скажем, описывать не концепцию использования шестерёнки в механических часах, а концепцию часов с шестерёнкой в их составе как концепцию системы), то можно обнаружить, что концепция использования шестерёнки по факту – часть концепции часов, ибо в устройстве часов важна шестерёнка и что она делает безотносительно устройства самой шестерёнки.

Конечно, терминология для всех этих описаний чёрного и прозрачного ящика может меняться, особенно если смотреть не на описания, а на документы, выражающие эти описания: легко концепцию использования насоса, описывающую поведение насоса, назвать «опросным листом», рассылаемым поставщикам насосов с вопросом «можете ли вы изготовить насос с вот такими характеристиками?» В «опросном листе» не будет ни слов «концепция использования», ни более древнего слова «требования». Если и будут какие-то указания на то, что именно должно бы быть в составе насоса, то не будет и слов «концепция системы». Архитектурные характеристики (типа надёжности) будут или не будут указаны, название документа будет «опросный лист». Вы должны уметь поглядеть на такой «опросный лист» – и определить тип описания: «опросный лист»::«концепция использования» насоса (а если там есть архитектурные характеристики, то отметить и их тоже).

Почему нужно выделять отдельно описание чёрного ящика как концепцию использования (что делает система вовне, от границы системы в окружение), а не сразу рассказывать про концепцию системы – как она устроена внутри себя (какие подсистемы выполняют какие функции и из чего они сделаны)? Различение чёрного и прозрачного ящиков нужно, чтобы иметь возможность предложить самые разные варианты того, как устроена система, из чего она сделана – предложить разные аффордансы для выполнения функции системы.

Скажем, концепция использования дверного ключа будет описывать, что ключ переводит дверь из состояния «заперта» в «отперта» и обратно. Это будет главное, функция ключа. Архитектурные характеристики (срок службы до первой поломки, ремонтопригодность и т.д.) тут не так важны, важно для чего нужен ключ, какие изменения (поведение – это изменения, «в один момент времени было одно состояние, в другой момент времени стало другое состояние») вызывает система в своём окружении. Тут важно, не какие изменения вызывает окружение в системе, а какие изменения вызывает система в окружении. Подробней об этом будет говориться в курсе «Системная инженерия», рассказ о действиях системы на окружение – в том числе реагировании на воздействия извне, а не о действиях окружения на систему.

Если вы подробно описали ключ и его функциональность как «чёрный ящик», дальше вы можете предлагать разные конструкции ключа, которые оказываются неразделимыми с конструкцией замка. То есть вы 1. Понимаете, что ошиблись и меняете рассмотрение ключа::система на замок::система, в который входит ключ::подсистема, а уже замок::система входит в дверь::надсистема. Рассматриваете варианты механического замка с поворотным ключом, механического замка с нажимным ключом, электрического замка с программируемым электронным ключом-«таблеткой», электрического замка с управлением через приложение в смартфоне, электрического замка с управлением через биометрию (отпечаток пальца или распознавание лица), и так далее: вариантов много, можно выбирать.

Главное – это соблюсти функцию замка (ибо оказывается, это делает не ключ, а замок) в его окружении: перевод двери из состояния «заперта» в состояние «отпёрта» и обратно. А дальше рассматриваем и ключ тоже, только там будет перевод замка из состояния «заперт» в состояние «отпёрт» и обратно. И вот тут возможны варианты: например, перевод замка в состояние «заперт» может быть сделан ключом, а может быть сделан захлопыванием двери. В замке может быть переключатель режима захлопывания двери и запирания ключом, но и ключ может быть хитрым – этот переключатель может быть в ключе, если ключом служит приложение в смартфоне! Всегда рассматриваем вначале функцию::поведение системы в мире, потом выявляем аффорданс для этой функции (и тут возможны варианты, и легко можно обнаружить смену целевой системы, как в примере с ключом: оказывается, надо было рассматривать замок как целевую систему, а ключ как подсистему). По возможности откладываем рассмотрение того, как устроена система как роль/«функциональный объект», ибо если непонятно, что система должна была бы делать (непонятная функция системы) – бесполезно обсуждать устройство системы, которая будет выполнять эту функцию.

Концепция использования – это набор моделей системы, модели абстрактны и не явлены никак в физическом мире. Чтобы на них посмотреть, или кому-нибудь переслать, нужно иметь их на носителе (неважно, бумажном, электронном или оптическом), то есть иметь документацию концепции использования (а если вы находитесь в предприятии, где придерживаются идей уже устарелой системной инженерии, то вам потребуется ещё и для концепции использования разработать требования и документировать уже требования). Документация концепции использования может найтись (или быть подготовлена) в самом разном виде: документы стандартов, технические задания, файлы с диаграммами сценариев использования на каких-то языках, фрагменты базы данных с информационной моделью. Если во всех этих документах содержится описание поведения целевой системы как «чёрного ящика» в окружении в момент эксплуатации, то это и будет концепция использования. И если вы при этом слышите слово «требования», то первым делом интересуйтесь насколько это гипотезы, а насколько и впрямь «очень надо именно так, можем обосновать», интересуйтесь сценариями (поведением), и проверяйте, чего в требованиях может не хватать или быть искажено, если их готовили «аналитики». Бойтесь «испорченного телефона», поинтересуйтесь ситуацией использования системы в ходе её работы, поймите сценарии/поведение, не принимайте «требования» слепо на веру – помним, что это просто «гипотеза, которую утвердили и назвали требованием, а потом гипотеза может оказаться неверна – и что будем делать?». Не верьте, если вас будут заверять, что «это требования, выполните их, и всё у вас будет хорошо». Это рассуждения из старой системной инженерии, старого системного подхода.

Концепция системы и архитектура

Очень часто те люди, которые описывают систему, хотят указать не только внешние свойства системы, описать не только границы системы и её поведение как чёрного ящика, но заодно и указать какие-то детали внутреннего устройства системы: определить (define) части системы (подсистемы), указать на процесс взаимодействия подсистем. В этом случае о системе говорят как о «прозрачном ящике», в нём можно считать известными какие-то подсистемы, свойства и поведение этих подсистем. Это можно считать указаниями по концепции системы: какое поведение ожидается от внутренних частей системы (время их работы, функции подсистем), какими частями конструкции системы (конструкция подсистем) это поведение может быть реализовано, при этом важно ещё учитывать и пространственные аспекты, и аспекты полной стоимости. Концепция системы описывает «прозрачный ящик» – это минимально четыре взаимоувязанных обязательных вида системных описаний, но чаще всего этих видов описаний по разным предметам интереса больше.

В любом случае, начнём хотя бы с двух: функциональное и конструктивное описания в их взаимоувязке. Скажем, вы готовитесь изготовить дверь, и вдруг вам внешние проектные роли говорят: «замок в двери должен быть из титана».

Слово «должен» указывает на требования, а не гипотезу, и это настораживает. А вдруг вы найдёте материал лучше? Для чего это вдруг потребовалось указывать, чего в поведении двери боится тот, кто описывает эту дверь? Какой испорченный телефон тут сработал, кто задал сценарий использования, что появилось это требование? Откуда вообще в двери замок, ибо вы и не подозревали, что дверь должна была бы запираться и отпираться: этого не было в концепции использования. Мы понимаем, что это описано ограничение свободы разработчика: один разработчик::роль указал другому разработчику::роль, что там должно бы быть внутри системы, чтобы при разработке концепции системы это ограничение было учтено. Вопрос: откуда разработчик::роль взялся во внешних ролях проекта. Иногда разработчиков целевой системы на зарплате у организации-заказчика называют «инжиниринг заказчика», и им платят зарплату как раз для того, чтобы они создавали такие ограничения свободы внешних разработчиков – чтобы, например, у внешних разработчиков не возникало соблазнов излишне удешевить-упростить или задрать цену-усложнить конструкцию системы.

Обычно организация проекта (например, коллектив из нескольких команд) согласовывает с внешним заказчиком системы функции/поведение, которые должна бы выполнять целевая система как чёрный ящик, свойства этого чёрного ящика, т.е. разработчики согласовывают концепцию использования (чаще всего даже не всю, а какие-то отдельные сценарии использования по отдельным «фичам», которые будут реализовываться какой-то отдельной командой), а архитектор системы согласовывает архитектурные характеристики и их приемлемые значения для всех команд разработчиков. Не факт, что эти гипотезы по концепции системы и приемлемым архитектурным характеристикам формулирует заказчик! Это совместная с заказчиком работа. Как устроена система внутри, то есть какие функции выполняют подсистемы и какими физическими объектами реализована конструкция системы – это коллектив проекта определяет самостоятельно, заказчика больше интересует обычно надсистема, она для него «прозрачный ящик», а целевая система – «чёрный ящик». Более того, это часто делается не за один приём, а долго – и продолжается даже после того, как первая версия (MVP, minimal viable product) уже изготовлена и начала использоваться. Часто самые интересные идеи и у агентов-заказчиков в самых разных их ролях, и у агентов-исполнителей этого заказа будут появляться уже после появления MVP, в ходе последующего развития системы.

Решения «прозрачного ящика» по тому, как система делится на конструктивные части (модули) и как эти модули будут взаимодействовать, чтобы значения архитектурных характеристик удерживались в приемлемых пределах (например, система в ходе улучшений продолжала оставаться легко изменяемой) называют архитектурой. Обратите внимание: архитектура – это решения по устройству системы в части конструкции (модули/конструктивы и способ их связи), равно как и концепция системы – это тоже решения по устройству системы, но включают и функциональные объекты, и конструктивные как аффордансы для этих функциональных объектов, а также пространственные (компоновка/размещение/location/allocation) и выходят на совокупную стоимость владения, и ещё могут включать какие-то важные другие аспекты (скажем, отдельно выделенные этические и юридические рассмотрения, или эстетические и художественные рассмотрения, в каждом проекте могут появляться какие-то особенности).

Концепция системы – это не архитектура (хотя ещё десяток лет назад считалось, что концепцию системы разрабатывают архитекторы), а архитектура – не концепция системы. Функциональность системы в надсистеме определяется решениями в концепции системы, а вот важные характеристики вроде «способность системы к развитию, лёгкость внесения изменений в конструкцию» определяются архитектурными решениями.

Архитектурные решения/architecture decisions оформляются самыми разными способами, например, описаниями с предписанной структурой на нескольких страницах в виде записей архитектурных решений/architecture decision records. Архитектурные решения представлены списком таких записей, или какой-то таблицей с материалом таких записей. Архитектура – это абсолютно не «диаграмма». Диаграммы в проекте чаще всего не архитектурны, а если и обнаруживаются где-то в архитектурном решении, то оказываются использованы в чисто иллюстративных целях, а не выражают архитектурные решения. Не надо путать системную архитектуру со строительной архитектурой, где прежде всего речь идёт о внешнем виде здания, а главное для архитектора умение – это умение рисовать.

Подробней об архитектурных решениях и их записи говорится в «Системной инженерии», но главное пока запомнить: вы ничего не можете сказать про «прозрачный ящик» (ни обсуждать концепцию системы, ни обсуждать архитектуру системы), пока вы не выясните, что там с «чёрным ящиком», то есть поведением системы в её окружении. Если вы не знаете, что делает сепулька, то вы ничего не сможете сказать о том, как она может быть устроена!

Это главное, что нужно запомнить в системном мышлении: первое же рассмотрение системы – это концепция использования, а не концепция системы, не архитектура системы. Сначала смотрим от границы системы в окружающий мир, в среду, причём в момент эксплуатации (если вы разрабатываете систему, то это надо вообразить, ибо эксплуатация будет в будущем), и рассматриваем поведение/функцию системы. А потом только начинаем смотреть на прозрачный ящик. Если мы начинаем рассматривать шестерёнки в механических часах, а потом вдруг смотрим в окружение часов, то можем увидеть, что часы эти расположены в ракете, и должны бы отсчитывать миллисекунды, штатно работая с перегрузками в 30G, ибо там всё вибрирует рядом с двигателем, около которого установлены эти часы. Можете забыть с этого момента про шестерёнки, это было зря потраченное время! Сначала смотрите вокруг, от границы системы наружу в момент эксплуатации, а потом только внутрь системы в момент эксплуатации, и потом только внутрь системы в момент её создания!

В любом случае, все эти описания системы (концепция использования, концепция системы и архитектурные решения) – гипотезы, готовьтесь их менять, торгуйтесь, предлагайте свои варианты, внимательно выслушивайте варианты, которые предлагают внешние проектные роли, обязательно занимайтесь обоснованиями. «Я так хочу» – это не аргумент, ибо сейчас хочу так, завтра хочу по-другому, или «вы не так меня поняли, я хотел другого», или вас в этой роли подменит какой-то другой агент, и он будет хотеть по-другому – это же «хочу» должно быть информированным мнением роли, а не простым желанием агента.

Моделирование: концепция использования и концепция системы

Запишите для целевой или вашей системы сверхкраткую концепцию использования («чёрный ящик») и сверхкраткую концепцию системы («прозрачный ящик»). Важно, чтобы вы отличали: описание «чёрного ящика» времени использования и описание «прозрачного ящика» времени создания и развития. Полнота и точность описаний тут не важны.

Рекурсивное рассмотрение в системном мышлении

Если рассмотреть надсистему нашей целевой системы как чёрный ящик, то она будет целевой для команды важнейших внешних ролей проекта. И описание надсистемы как чёрного ящика будет для этих внешних ролей концепцией использования их целевой системы, которая для команды – целевая.

Когда из концепции использования ещё делали требования, то это описание часто так и называли: требования внешних проектных ролей (stakeholder requirements/stakeholder needs, не путать с system requirements, системными требованиями, которые называют просто требования, опуская слово «системные»), но чтобы меньше путать это описание надсистемы-как-чёрного-ящика с описаниями целевой системы-как-чёрного-ящика, это описание надсистемы как чёрного ящика чаще называют потребностями (stakeholder needs, нужды/потребности внешних проектных ролей), а ещё всё чаще и чаще называют их ролевыми интересами или предпочтениями. Скажем, мы::команда делаем шестерёнку к часам, то есть целевая система команды – шестерёнки. Потребности/needs – к часам::надсистема, а сценарии в концепции использования будут для шестерёнки::«целевая система».

⠀

Тем самым в проекте обычно в концепции использования описываются два «чёрных ящика»:

• надсистема – описывается интересами/предпочтениями в каких-то характеристиках надсистемы, важных для внешних проектных ролей (потребностями, stakeholder needs). По предметам интереса к надсистеме могут быть разные предпочтения, вот надо сделать гипотезу о том, какие значения характеристик всех устроят, а дальше не бояться корректировать эту гипотезу по ходу проекта. Исходить надо из того, что надсистема – это не просто что-то «данное в ощущениях», неизменяемое, «спущенное с небес». Нет, окружение целевой системы тоже сделано создателями, тоже непрерывно меняется, и можно выдавать гипотезы о том, как оно там должно быть устроено. Современная инженерия основывается на том, что вы непрерывно корректируете ваше понимание мира, корректируете ваше знание о ситуации использования целевой системы, знание о возможностях команд, которые создают надсистему подкорректировать окружение целевой, знание о том, как лучше удовлетворить потребности путём модификаций целевой системы так, чтобы она улучшила работу надсистемы. Вам надо не только учесть разнообразные предпочтения внешних проектных ролей в отношении надсистемы как окружения целевой системы, но и учесть возможные изменения в этих предпочтениях.

• целевая система – описывается как «чёрный ящик» преимущественно постепенно детализирующимися сценариями использования. По большому счёту тут то же самое рассмотрение, что и для надсистемы, в ISO 15288:2023 это называется рекурсивным применением системного мышления.

⠀

А ещё описываются два «прозрачных ящика», но один в концепции использования, а другой – в концепции системы:

• Надсистема – описывается прежде всего концепцией использования целевой системы с акцентом на роль/функцию целевой системы в надсистеме. Показывается, каким образом наличие целевой системы в составе надсистемы приводит к удовлетворению интересов/предпочтений/потребностей/needs внешних проектных ролей. Это и есть важное для нас «устройство надсистемы», прозрачный ящик. Концепция использования – это в какой-то мере концепция надсистемы (рекурсивное применение системного мышления! На каждом уровне происходит одно и то же) с точностью, достаточной для описания целевой как чёрного ящика, выполняющего какие-то функции в надсистеме так, что становится понятным удовлетворение интересов внешних проектных ролей. Для настенных часов надсистема – интерьер и люди в интерьере, надо описать, что там окружает часы и как взаимодействуют (например, мешает ли людям громкое тиканье часов по ночам).

• Целевая система – описывается концепцией системы, в том числе архитектурой как дополнительными решениями по конструкции системы (с ожидаемым влиянием архитектурных решений главным образом на архитектурные характеристики/«предметы интереса», а не функциональность). Конечно, концепция системы и в том числе архитектура показывают, как удовлетворяются интересы не только внешних проектных ролей (их интересы больше описывает концепция использования), но и внутренних/командных проектных ролей, то есть интересы визионеров, разработчиков, архитекторов, инженеров производственной платформы целевой системы. Например, для часов с заданной точностью хода на их внешней границе надо принять решения по их внутреннему устройству: будут ли использованы в часах драгоценные камни для уменьшения трения и тем самым повышения точности хода, или в настенных часах это – роскошь, требуемая точность хода будет достигнута просто путём использования твёрдых сплавов для осей и подпятников. Или вообще настенные часы делать не механическими, а электронными, чтобы достичь требуемой точности хода.

На диаграмме целевая система и её подсистемы показаны красными кружками, отношение «часть-целое» показано вхождением кружков друг в друга. Окружение – синие кружки, ближайшая надсистема – синий большой кружок, в который входит и целевая система, и несколько других систем. Конечно, есть и ещё какие-то системы в окружении, которые не входят в состав надсистемы. Системных уровней много и внутри границы целевой системы, и вовне границы целевой системы.

Внешние проектные роли времени использования показаны синими человечками, но это не люди. Это роли, исполнять их могут и люди, и люди с компьютерами, и команды, и фирмы со всеми их людьми и оборудованием. В рассмотрении operations такие внешние роли, например, «пользователи», при этом мы рекомендуем общий тип «пользователь» нашей мета-мета-модели всегда заменять на тип роли из мета-модели (предметной области целевой системы) – в играх это игрок::пользователь, в бухгалтерских системах бухгалтер::пользователь и аудитор::пользователь. Но внешними проектными ролями могут быть и вредители/хакеры, и инспекторы внешних надзоров – кто угодно, кто взаимодействует с целевой системой в operations time. Эти роли показаны в кружках, чтобы подчеркнуть, что это тоже системы в окружении (роль – ролевой объект, который играется каким-то агентом как конструктивным объектом).

В рассмотрении времени создания (construction time) создатели::системы, мы просто не рисуем кружки и их вложенные/внутренние части.

На всей диаграмме отношения создания (между правой и левой частями диаграммы), и взаимодействия между системами одного уровня при их работе (между кружками одного уровня) не показываем. То, что делить на части системы можно очень по-разному (скажем, функционально и конструктивно: как ложку – «держало» и «хлебало» будут двумя функциональными частями ложки, но конструктивная часть цельнолитой или даже деревянной ложки будет одна изготавливаемая «деталь» -конструктив), тоже не показываем, хотя в концепции системы множественность согласованных между собой разных видов описаний в рамках одного системного описания будет принципиальной. Обычно рассматриваются ещё и разные варианты согласованных декомпозиций (включая ещё и размещение, и ценовую декомпозицию – что там сами изготавливаем, что отдаём). И дальше изо всех согласованных между собой вариантов разных декомпозиций оставляем только «наименее плохой согласованных вариант», ибо «лучший вариант» недостижим в эволюции, всегда удаётся достичь только локального оптимума.

Важно для этой иллюстративной диаграммы то, что «синенькие» внешние роли во время создания и развития занимаются устройством «синенького» (надсистемы) на диаграмме, а вот «красненькое» для них – «чёрный ящик». А «красненькие» внутренние проектные роли (роли команды проекта) вынуждены и выяснять прежде всего синенькое, но и дальше идти внутрь «красненького», то есть рассматривать сначала окружение «чёрного ящика» (ближайшую надсистему как «прозрачный ящик», но и надсистемы в дальнем окружении), а затем делать «чёрный ящик» прозрачным – формулировать гипотезы не только о функциональности целевой системы как чёрного ящика (концепция использования), но и о конструкции (концепция системы, в том числе начальные архитектурные решения).

Команда проекта создания и развития целевой системы создаёт её концепцию. При создании концепции чаще всего начинают с описания функционального разбиения, получив понимание, что там происходит внутри системы в терминах ролей подсистем (подсистем как ролевых/функциональных объектов), а также функций подсистем. Например, «чтобы часы показывали время, когда на них поглядят ночью, мы сделаем постоянно светящиеся стрелки, днём этого не будет видно, зато ночью всё будет хорошо» или «чтобы часы показывали время, когда на них поглядят ночью, мы предусмотрим, что при падении освещённости в окружении часов будет включаться подсветка» или «для удешевления часов мы не будем учитывать, что на них будут глядеть ночью, если очень надо, пусть поставят какую-нибудь подсветку комнаты, чтобы осветить циферблат». Эти описания будут концепцией использования подсистем (рекурсивное применение системного мышления!), при этом сами подсистемы ещё придётся проектировать, придумывать метод изготовления и материалы, из каких надо будет эти системы изготавливать (надо будет найти аффордансы, которые станут конструктивами системы). Скажем, в примере с «часами ночью» придётся придумывать, из чего делать подсветку циферблата – светодиоды, лампочки накаливания, люминофоры. Что-то подойдёт (аффорданс – это «подходяшка»), что-то не подойдёт для того, чтобы выполнить ожидаемую функцию подсистемы в составе целевой системы.

Системное мышление рекурсивно, оно применяется одинаково на каждом системном уровне, каждой командой-создателем систем. И каждая команда имеет свои «системные координаты» вокруг своей целевой системы и отдельно ещё и «их системы», поэтому самое важное – это договориться, что же это за системы! Договариваются, описывая прежде всего поведение системы по отношению к надсистеме (сначала вверх по уровням!), стараясь описывать систему как «чёрный ящик», чтобы потом можно было пробовать в качестве гипотез самые разные варианты устройства этой системы, то есть рассматривать самые разные варианты системы как «прозрачного ящика» (вниз по уровням – потом!).

Мы в разделе объясняем рекурсивность только на примере двух уровней (система-надсистема), но эта рекурсивность используется на всех уровнях – и для системы с подсистемами, подсистем с под-подсистемами и так далее до элементов систем, и для надсистем и окружения надсистемы, тоже на много уровней. На всех уровнях вокруг любой системы можно (и даже нужно) развернуть полное системное рассмотрение примерно так же, как развёрнуто оно вокруг целевой системы.

Системное мышление говорит, что концепция использования (раньше – потребности и требования) описывает две разные системы (надсистему как «прозрачный ящик» и целевую систему как «чёрный ящик»). Но методы/способы того, как именно выявить интересы/потребности/предпочтения внешних проектных ролей в каких-то важных характеристиках надсистемы и сформулировать концепцию использования, как их не пропустить в разговорах с внешними проектными ролями, затем не потерять в коллективном внимании участников проекта создания и развития системы, как оттрассировать (trace, соотнести) поведение целевой системы к потребностям (там же эмерджентность, появляются новый свойства, например, надо обосновать, почему использование шестерёнок из материалов с небольшим тепловым расширением приводит к увеличению точности хода в механических часах), какие нужны ещё дополнительные методы, которые позволяют не просто управлять вниманием к системам, а ещё создать и развивать эти системы, причём в конечном итоге сделать их успешными – это уже говорится в курсе «Системная инженерия», это выходит за рамки курса системного мышления. В курсе системного мышления говорится только о том, что «если вы хотите описать систему как чёрный ящик, то это вы хотите разработать её концепцию использования». Тем самым задаются важные объекты, которые нужны в мышлении.

Как именно разрабатывать концепцию использования, какой метод брать? Как выглядят результаты разработки разными методами/способами/стилями (есть много вариантов)? Это всё будет в курсе системной инженерии, а для разного вида систем (роботов, мастерства, организации и т.д.) будет ещё и уточняться в каких-то прикладных курсах инженерии.

Наш курс пока касается только понятийного наведения внимания на системы и системные описания, он пока не про то, как делать системы (методы/практики/культуры работы), а про то, как думать о системах, когда их делаешь. В нашем курсе описываются типы мета-мета-модели объектов методов работы, например типы «система», «системное описание», «концепция системы». Курс «Системное мышление» про то, что следует системно моделировать в проекте, он про мышление моделированием: какие объекты в жизни надо брать для описания в них важного (моделирования), что в них важного (какие модели нужны).