Список методов описания из CPS PWG Cyber-Physical Systems (CPS) Framework
Предмет интереса/важная характеристика нам нужен, чтобы мы потом смогли сказать, как его описывать --- предмет интересаотражается/framed by методом описания/viewpoint. Например, метод описания цены::характеристика может быть правилами составления сметы в рублях, а может быть правилами указания произвольно определённой цены, но в долларах или «условных единицах». Этот метод описания нужно будет использовать, чтобы описанный при его помощи предмет интереса (цена) был потом обсуждён разными ролями (продавцом и покупателем). Тем самым дискуссия о методе описания цены (как моделировать цену, как лучше её описывать, каким способом отразить знания о цене как характеристике системы) будет отличаться от дискуссии о значении цены, то есть о том, «как снизить цену» и «как поднять цену», хотя обе эти дискуссии оказываются существенно связанными (выбор метода описания обычно влияет на переговорную позицию одной из сторон: разные методы описания интереса удобны для продвижения разных предпочтений).
И когда мы только что разделили одну сложную дискуссию по важной характеристике на две более простых (по методу описания и по уторговыванию предпочтений), задача стала немного проще --- это и есть цель системного мышления. В ряду понятий «метод работы»,«роль», «предмет интереса», «предпочтение» нужно поставить ещё одно понятие: «метод/способ описания» (viewpoint).
Разделение в мышлении методов, выполняющих их ролей, предметов ролевого интереса, предпочтений в значениях характеристик систем, метода описания предмета интереса и документирование состояния всех этих объектов--- упрощает удержание внимания в достижении договорённостей между ролями в проекте, облегчает коллективное выполнение проектов по созданию систем.
Мы не можем после составления списка предметов интереса/concerns и подготовки описаний/views по каким-то согласованным методам описаний/viewpoints забыть о том, чьи именно эти предметы интереса: сами интересы/предпочтения разных ролей для найденных общих предметов интереса/характеристик могут существенно отличаться, поэтому подготовленные описания системы --- это лишь материалы для дискуссий.
Системное мышление коллективно --- оно подразумевает непрерывные согласования предпочтений для самых разных характеристик, важных самым разным проектным ролям. Системное мышление предназначено для структурирования этих обсуждений и требует различать в них актёра, роль, предмет интереса, интерес/предпочтение (куда двигать характеристику, какое состояние предпочесть), метод описания, описание, значение характеристики как результат уторговки предпочтений.
В публичном документе (публичный документ отличается от стандарта только тем, что не предусмотрена процедура проверки на соответствие) CPS PWG Cyber-Physical Systems (CPS) Framework Release 1.0[1] приведена более полная, чем в ISO 42010 таблица предметов интереса для киберфизических систем, то есть систем, в составе которых есть датчики, эффекторы и управляющий ими универсальный-по-Тьюрингу компьютер. В этом публичном документе (выпущен в мае 2016 года) ввиду большой длины списка характеристик, они разбиты на группы, отражающие аспекты/aspects: функциональный, организационный, человеческий, доверия, времени, данных, границ, состава, жизненного цикла (functional, business, human, trustworthiness, timing, data, boundaries, composition, lifecycle).
Аспекты/aspects/area of concerns/«области интереса» отражают какие-то содержательно сгруппированные предметы интереса. Длинная таблица CPS Framework в документе выглядит так (приведём её начало и конец):
Как использовать таблицу? Эта таблица CPS Framework работает как чеклист: все ли аспекты/«области интереса» систем (целевой и дальше систем создания) вашего проекта вы обсудили, в них нашли все ли предметы интереса?
ISO 42010:2022 говорит, что аспекты --- это отражение «лучших практик» (best practices, иногда good practices, лучшие или просто хорошие, известные на сегодняшний момент методы работы) в том, чем должны интересоваться специалисты в своих предметных областях, по ним как менее детально определённым предметам интереса проще договориться, проще их вспомнить в ходе проекта--- и уже углубляться в отдельные предметы интереса, исходя из особенностей конкретного проекта. Помним, что «объективность--- это хорошо организованная субъективность», так что аспекты просто отражают мнение экспертов о том, что важно при создании и развитии каких-то систем, а «лучшая практика»--- это «лучший на сегодняшний день метод работы». Список аспектов из CPS Framework был «лучшим» (хотя и с этим можно было бы поспорить) на май 2016 года. С тех пор, например, вместо понятия «жизненный цикл» всё чаще используется «создание и развитие системы», ибо однократное прохождение разработки «от рождения до смерти» заменилось на создание MVP, то есть minimal viable product, минимально жизнеспособный продукт, и последующее непрерывное развитие без явного учёта окончания этого развития.
После того, как вы нашли предметы интереса, надо подобрать для каждого предмета интереса его метод описания (ссылка на какой-то стандарт или метод описания, созданный и документированный самостоятельно). Дальше вам надо определить: где::софт самые разные проектные роли могут найти актуальное на текущий момент проекта документированное описание состояния дел по поводу выбранного предмета интереса.
Скажем, для функциональной области интереса (functional aspect) важны функции целевой системы (functionality). Это вы вряд ли забудете выяснить. В курсе системной инженерии будет указано, что такое описание (view)--- концепция использования. Но вам нужно обязательно пройти дальше: какой будет метод описания функциональности? Скажем, вы выбрали для небольших проектов JTBD или customer journey (если не знаете, то гуглите, или спросите AI-агента! Если вы профессионально занимаетесь созданием концепций использования, то есть описываете функциональность систем, то такое нужно знать без заглядывания в гугл или вопросов к AI-ассистенту, надо иметь профессиональный кругозор), для проектов побольше use case 2.0 (то же самое: гуглите, если не знаете! Хотя мы тут уже упоминали use case даже в нашем курсе системного мышления и будем ещё упоминать в курсе системной инженерии). Теперь надо документировать выбранный метод описания и указать место (моделер--- и адрес, где в нём найти), где будут лежать самые свежие версии описания функциональности. Заодно придётся ответить на вопросы вроде «а если две команды разработчиков занимаются разными сценариями использования и делают независимые модули для их поддержки--- это должно быть одно место или два?».
И эти вопросы задаются по всем остальным аспектам (они же области интереса) и в них всем ключевым характеристикам (они же предметы интереса). Например, для области интереса создания и развития системы (заменяем термин lifecycle из CPS Framework) выбираем предмет интереса «эксплуатируемость» (operability). Если вы инженер-профессионал, то вы знаете, что именно вас должно там интересовать. Если не профессионал, то будете «изобретать велосипед». Но лучше уж изобрести велосипед, чем забыть! Предупредим: это очень непростой вопрос! Скажем, вам придётся как-то включить в рассуждения цифрового двойника--- это ж как раз для улучшений в эксплуатируемости? Теперь вам надо выбрать метод описания («предметно-ориентированный язык»/DSL/«подход к моделированию»/framework/онтологию--- или взять из литературы, или создать самостоятельно для целей проекта). Определить софт (не ваш, а тех агентов, которые будут зачем-то изменять эти описания и зачем-то смотреть эти описания) как место, в котором будет храниться документированное описание. Затем документировать это описание, стараясь учесть все предпочтения по поводу эксплуатируемости--- а у проектных ролей (внутренних и внешних) будут самые разные предпочтения. И проследить, чтобы это описание как-то претворилось в жизнь, отразилось в физически воплощённой системе (имеется ввиду не появилось внутри документированным, а отразило то, что вы описывали: воплотить в жизнь описанный трактор --- это не документировать описание трактора, а сделать работающий железный трактор). Заведомо не надо порождать оторванные от реальности описания, если только вы не писатель-фантаст.