Системное описание, описание, метод описания
В системном описании есть различные аспектные/ролевые/частные описания (views), которые отвечают на вопросы о каких-то «областях интереса»/«area of concerns». Проектная роль может иметь и несколько областей интереса, и множество интересов в каждой из областей интереса. Это всё интересы к предметам методов работы этой роли.
Каждое ролевое/аспектное описание позволяет описать систему так, чтобы поддержать разговор с проектной ролью по предмету/теме/зоне/области её интересов, ответить на интересующие её вопросы по достижению её предпочтений в интересующих характеристиках систем. Таких описаний делается множество, значительное число таких описаний гибридны (совмещают описания каких-то областей интереса, показывают несколько аспектов системы и связи между ними, например концепция системы как ролевое описание разработчиков и архитекторов системы показывает согласованные между собой описания функциональные, конструктивные, компоновочные и стоимостные).
Каков результат использования множественных описаний одной и той же системы, да ещё и многоуровневых по разным видам системных разбиений (то есть речь идёт о системном описании — системное это не «полное по видам описаний», это «описание с учётом множества системных уровней, определяемых по различным критериям разбиения»)? Результатом тут будет успешная система: если проектная роль соглашается с описанием, то воплощение системы, удовлетворяющее этому описанию, эту роль, скорее всего, тоже удовлетворит (помним про инженерные обоснования: мы ещё и обоснуем в ходе испытаний, что воплощение системы ведёт себя так, как это описано в её системных описаниях).
Успешность системы мы часто можем определить ещё тогда, когда воплощения системы ещё нет, а есть только описание системы, и даже не полное описание (ошибки неучёта каких-то интересов могут быть видны и по частичным описаниям). Использование 3D-информационных моделей, чертежей, имитационных моделей в инженерии, нот в музыке и любых других записей в проектировании и конструировании как раз имеет целью подробно обсудить реализацию самых разных предпочтений в важных для всех ролей в проекте характеристиках/concerns разных систем проекта ещё до того, как целевая система будет воплощена. Рассуждение не меняется, если речь идёт просто о выпуске очередной улучшенной версии системы (не greenfield разработка «с нуля», создание системы, а brownfield разработка улучшений, развитие системы).
Проектные роли при этом получают доступ к описаниям, но описания сами по себе нематериальны, абстрактны. В реальности агенты-в-ролях смотрят документацию/«рабочие продукты»/артефакты: без носителя информации нет способа предъявить описания для их обсуждения. Так что первым делом все описания нужно документировать, не держать в голове**!**
Описаний же много: разные проектные внутренние и внешние роли интересуются крайне разными ролевыми**/аспектными** описаниями/views системы. В этих описаниях/views отражаются **важные для самых разных ролей характеристики/concerns систем самыми разными ролевыми/аспектными****методами описаний/viewpoints, по которым и делаются эти описания/**views. И, конечно, каждое описание может быть документировано разными способами (например, с использованием разных нотаций — числа могут быть записаны арабскими цифрами, римскими цифрами, в двоичной системе), на разных носителях (бумага, магнитная лента, компьютерная оперативная память, даже мозг живого человека — носитель очень малоёмкий, плохой и ненадёжный, но это ведь тоже носитель информации! Другое дело, что запись информации в мозг делается в нелокальных/распределённых представлениях, а запись информации на компьютерные носители делается сейчас в локальных/символьных/знаковых представлениях. В инженерии сейчас используют знаковые представления, они устойчивы к накоплению ошибок при многократной репликации/копировании. Так что важно не держать всё в голове, это крайне ненадёжно!).
Все эти многочисленные ролевые/тематические/«по интересам»/аспектные описания (views) — подальфы системного (полного/всестороннего/для всех ролей/для всех предметов интереса, для всех системных уровней) описания. Их, конечно, много больше, чем концепция использования, концепция системы, архитектура, они часто хитро структурированы (так, концепция системы в машиностроении развивается до технико-экономического проекта, затем эскизного проекта, затем рабочего проекта — который и идёт на производство). Тут и финансовые модели, и имитационные физические модели, и прогнозы надёжности, а также многочисленные описания того, что должны делать системы создания (скажем, для стройки это будет ПОС, план организации строительства — то, что должны делать строители во время возведения здания или сооружения, совмещённое описание методов работы строителей и самих работ строительства): описаний много, для какой-нибудь атомной станции в бумажном виде лет двадцать назад это было несколько грузовиков с бумагой, и это была ещё не вся документация!
Разница между описанием (альфа) и документацией (рабочие продукты) принципиальна, но в жизни очень часто в речи их путают. Так, легко путают архитектуру (часть описания системы) и архитектурную документацию (рабочие продукты/артефакты/документы/файлы, отражающие архитектурные решения на каком-то информационном носителе). Очень часто слово «документация» опускают и предупреждают читателей, что из контекста должно быть понятно — об архитектуре (описании системы) говорят или об архитектурной документации (наборе рабочих продуктов/артефактов/документов/записей баз данных с записями архитектурных решений архитектуры).
В литературе (например, ISO 42010:2022) часто слово «описание» даётся не для абстрактного объекта-альфы, а для документации/артефакта, и на английском это будет description. В системной инженерии наше абстрактное «системное описание» будет system definition. В русском языке слово «определение» путается с словарным, поэтому мы перевели более подходящим по смыслу словом «описание», а description тоже перевели более подходящим по смыслу русским словом «документация». Путаница с описаниями вездесуща. Так, онтология (или архитектура, или цвет системы) могут означать:
- То, что есть в жизни (нарезка мира на какие-то объекты, или архитектура какой-то системы, или цвет какой-то системы — они «в реальности»)
- Описание (обычно признаётся, что это какой-то аспект из разных описаний, тогда view, если это проектное описание, «как будет», то это definition). Тут часто говорят «онтология», «архитектура», «цвет» — но имеют в виду онтологическое описание (или синонимично — описание онтологии), архитектурное описание (описание архитектуры), цветовое описание (описание цвета). И это мы ещё не трогаем путаницы с «описанием»::«предмет описывания::метод». Метод/процесс/деятельность описывания ведь тоже часто называют описанием! У нас тут — предмет метода, а не сам метод. Метод описания по-английски — viewpoint.
- Документ с описанием, и тут тоже часто говорят онтология, архитектура, цвет. Но это уже название документа!
Вы вполне сможете разобраться в любом варианте терминологии, употреблённой в том или ином описании (punintended**), если понимаете, что всегда существует три разных объекта (описываемый, описание как идеальный, и ещё материальный как описание на носителе информации) — они** иногда обозначаются разными словами, принятыми в разных профессиональных сообществах или разных естественных языках, но очень часто—** одним и тем же словом.**
Слова важны (кроме слов у нас ничего больше нет), и не важны (слова обычно означают не то, что вы думаете**—** и в словаре их значение не подсмотришь, ибо словарей много, язык живой). В****нимательно отслеживайте типы тех объектов, которые скрываются за подозрительными терминами (подозрительные**—** это которые вызывают у вас онтологический дребезг, это было в руководстве по рациональной работе**)****, и всё будет в порядке.**
Какие термины могут оказаться подозрительными? Не только «описание», но почти все термины системного мышления, включая термин «система»! Очень часто ведь «система» используется в бытовом значении, просто для придания «научности» или «инженерности» говоримому, иногда как синоним слову «объект» («что угодно, что рассматриваем») — и никаких за ним системных уровней, эмерджентности, графа создателей, непрерывного развития системы — ничего подобного говорящим «система» не подразумевается, ибо не все говорящие слово «система» знакомы с современным системным подходом. И «концепция использования», «архитектура» тоже вполне могут использоваться не как подальфы для альфы системного описания (как предметы метода инженерной работы, с целью отследить изменения их состояния в ходе проекта создания и развития какой-то системы), а в каких-то совсем других значениях (например, означать документы с названиями «концепция использования» и «архитектура»).
Полное системное описание (description) встречается в жизни довольно редко, хотя всегда в проектах ведутся попытки как-то собрать в одном месте многочисленные документы с разными ролевыми описаниями. Много чаще встречаются просто отдельные ролевые описания системы, документированные в разных документах (разных информационных системах, разных базах данных).
Это только геном обязательно будет в каждой клетке организма, собран в одном «документе», на одном носителе информации. Геном[1] сам по себе — это носитель информации, «совокупность наследственного материала, заключённого в клетке организма», то есть это набор всех хромосом[2], каждая из которых образуется у эукариот одной очень длинной молекулой ДНК. Геном — это документ с описанием генетической информации. Более чем часто имеют ввиду под геномом не набор хромосом/«молекул ДНК» (документ), а саму генетическую информацию, документированную геномом! В инженерии речь идёт о мемоме (по аналогии с геномом), который хранится где-нибудь в конструкторском бюро и является результатом не биологической (дарвиновской), а техно-эволюции. Договорённости о том, что мемом — это материальные носители (проектная документация) нет, поэтому это может быть равным образом проектная/design документация, но может быть и проектное/design описание. Идея о том, чтобы собрать всю проектную документацию в одном месте — она обычно провальна. Даже если считать, что вся проектная документация находится в каком-нибудь конструкторском бюро, то немедленно окажется, что есть производство, на котором тоже есть часть документации, часть документации находится у подрядчиков (например, поставщиков заказных комплектующих), часть документации будет у наладчиков и операторов (например, какие-то настройки системы, о них даже проектировщики не будут знать). Так что идея о том, что системное описание (systems description) отражается в каком-то «супердокументе» — она провальна.
Исходя из этого, view обычно переводится просто как «описание», без указания на то, что оно ролевое/аспектное/тематическое/предметное/частное, а не (полное) системное. Каждый раз, когда вы слышите «описание», оно будет давать ответы на вопросы только по части предметов интереса/важных характеристик, для ответов на вопросы по другим предметам интересов нужны будут другие view, подготовленные по другим методам описания/viewpoint.
Концепция использования — это тоже описание системы (хотя сценарии использования считаются существующими, а в концепции использования мы имеем не сами сценарии использования, а описания сценариев использования, но слово «описание» будет пропущено), и архитектура — описание (та же ситуация: архитектура есть у системы, а архитектурные описания будут содержать описания принятых важных архитектурных решений, в жизни это всё будет называться просто «архитектура» и чаще всего будет означать описания), и отчётность по РСБУ и МСФО — описания, но они каждое — не полное системное описание.
Тем не менее, мы говорим об альфе системного описания (system definition), поскольку в проекте совокупность всех описаний необходимо отслеживать в части их готовности. Продвинуть альфу системного описания по её состояниям можно, продвигая работами проекта по их состояниям подальфы отдельных частных/аспектных/ролевых описаний (views). Этих подальф описаний/views для альфы описания системы довольно много.
Прежде всего, самые разные роли в проекте интересуются состояниями продвижения по ходу проекта для функциональных описаний, конструктивных/модульных/продуктовых описаний, описаний размещения и стоимостных описаний как частей концепции системы. Это главное, их будут проводить через состояния «концепция системы готова», «технико-экономический проект готов», «эскизный проект готов», «рабочий проект готов» (помним, что в разных сферах деятельности это будут очень разные состояния, даже в машиностроении, из которого мы позаимствовали этот пример). Но дальше может быть ещё огромное количество описаний, интересующих самые разные трудовые роли в проекте: например, синхронизации во времени разных подрядчиков, структуры владения частями окружения, информационных потоков и т.д.
Чем сложней (больше системных уровней, больше подсистем на каждом уровне) система, тем бо́льшего количества описаний/views можно ожидать. Важные для людей-в-ролях характеристики систем многообразны, и успех системы определяется как раз полнотой их учёт****а (записать!)****, а затем полнотой согласованиязначений этих характеристик. Не учёл**, а поэтому** не согласовал описания, затрагивающие, например, морозостойкость**::concern—** не получил по таким описаниям успешную систему. Или не учёл**, а поэтому** не согласовал различные описания, которые показывают поведение системы на разных системных уровнях**—** тоже не получил успешную систему**.**
Разнообразные объекты, с которыми работают в проекте разные роли, являются:
- С точки зрения методов работы этих ролей — предметами метода,
- с точки зрения мотивов, побуждающих агентов к действию, являются предметами интересов,
- с точки зрения изменения состояния этих предметов, являются альфами,
- с точки зрения мышления об этих объектах — классифицированными типами различных моделей, мета-моделей, мета-мета-моделей, и даже мета-мета-мета-моделей.
Это нормально, но это означает сразу, что самые разные объекты будут каждый описан много раз с использованием множества разных методов описаний. В системном мышлении постулируется:
- Необходимость системных описаний (system definition). Они важны, их надо делать и документировать, даже если очень лень и некогда.
- Необходимость явного указания для каждого из описаний/view в составе системного описания их методов описаний (viewpoint). Если вы не знаете, каким методом вы что-то описываете, то это не значит, что вы описываете это без метода, поэтому подумайте о методе и укажите его.
- Представленность/presentation описаний в физическом мире в виде документов/файлов/артефактов. Не держите описания в чертогах вашего разума, а делайте их в читаемом другими агентами (людьми, машинами) виде — и первым из этих людей (или машин, это руководство проходят и AI-агенты) будете вы сам, а эти описания помогут вашему биологическому (или не биологическому) мозгу быть надёжным в памяти и удержании внимания.
Документация проекта (system description) должна отражать значения важных характеристик систем в проекте, чтобы в ходе обсуждений/согласований предпочтений в этих характеристиках разных ролей проекта удерживать на них внимание не «ментально, усилием воли, хорошей памятью людей-агентов», а технически, используя «внешнюю память», экзокортекс. Об этом наставляется во всех наших руководствах, начиная с руководства по рациональной работе: человечество ушло от «мышления голыми мозгами» примерно так же далеко, как от «работы голыми руками», без каких-либо инструментов.
Как именно делать эти описания в самых разных рабочих проектах, рассказывается в соответствующих методах описания самых разных методов прикладной инженерии: классической «железной» системной инженерии, программной/software инженерии, обучения как инженерии личности, менеджмента как организационной инженерии, социальной инженерии и так далее.
Например, музыку записывают в виде партитуры[3] в нотной записи на бумажных листах. Как сделать партитуру для новой свежесочинённой песни? Это прикладное знание, и оно будет крайне разным в плане нотаций для партитуры на бумаге и может принимать совсем другую форму, если речь пойдёт о компьютерной музыке. В системном мышлении вы только должны помнить, что:
- если есть «песня» (предмет метода),
- то она должна как-то быть описана, для этого нужно использовать метод описания. Уж как именно описана (нотация roll piano, или древнерусская нотация крюками, или современная нотная запись) — это изучается прикладными методами работы с песнями.
- это описание должно быть документировано. Не документировать нельзя (хотя есть и разные другие мнения, ведь ещё есть импровизационные жанры, но там это будет не «песня»[4])!
Если у вас в проекте есть и партитуры с нотной записью, и чертежи, и расписание, и органиграмма, то системное мышление позволяет обсудить все эти отдельные описания, не потерять их — оставив прикладным дисциплинам подробности того, как именно они делаются и как ими пользоваться.
Системное мышление — это фундаментальные, пронизывающие все прикладные методы мышления приёмы («маленькие методы/способы») мышления на базе понятий системного подхода. Знания системного мышления не могут заменить знания прикладных практик**. Знать о том, что** «описания всегда есть на каком-то уровне абстракции мета-моделирования, но они могут быть не конкретизированы и не документированы**»** — мало. Нужно ещё знать, как делать эти описания**/view, то есть нужно знать прикладные** методы классической и программной инженерии, менеджмента, медицины, правоохраны**, политического действия** и т.д.****, а в этих методах ещё и знать включённые в них методы описаний (viewpoints). Только мастерства системного мышления или даже интеллекта (как фундаментального мастерства мышления в новых ситуациях, когда непонятно, что делать) для работы в проектах по созданию и развитию систем не хватает, нужно ещё владеть прикладным мастерством в том методе работы проекта, который вам надо испол****ьзовать в вашей проектной роли.
Метод описания (viewpoint) отражает (frame) важную характеристику/предмет интереса (concern), а описание (view) отвечает на вопросы о значении целевой характеристики, удовлетворяет к ней интерес. Например, «легенда карты фауны»::метод описания отражает «распределение фауны на определённой территории»::concern, а карта::описание отвечает на вопросы о «наличии или отсутствии фауны в тех или иных конкретных местах»::«значение целевой характеристики/предмета интереса».
Тем не менее, предмет интереса/concern, и «метод описания»/viewpoint, как и описание/view нещадно путают (то есть путают «распределение фауны как характеристику какой-то эко-системы/территории»::concern, «легенду карты [распределения] фауны»::viewpoint и саму «карту фауны»::view). Конечно, всё это близкие понятия, но все они привлекают внимание к разным объектам, поэтому для обсуждения нюансов они нужны все: надо найти в проекте объекты всех упоминаемых типов: concerns, viewpoints, views.
Если у меня ролевой предмет интереса/concern/важная характеристика — цвет системы, а моё предпочтение/preference/интерес — яркий цвет, у меня будет недовольство тем, что цвет неяркий. Я выбираю метод описания цвета (отражаю интересующую важную характеристику при помощи метода описания), включающий возможность описать значения насыщенности цвета — это позволит мне прогнозировать яркость цвета в системе моего интереса, испытывать полученную яркость окрашенной системы, формулировать предпочтения для яркости цвета, договариваться с другими проектными ролями по поводу насыщенности цвета. Другая проектная роль — инженер, который должен покрасить систему. И он может заботиться о том, чтобы краска была дешёвая (удовлетворять интерес ещё одной проектной роли — менеджера-финансиста), а яркость этой краски его волновать не будет. Но дешёвая краска яркой не бывает. Если я документирую нужную мне цветность, описав при помощи стандартных характеристик colorfulness, chroma, saturation, плюс учту внешнее освещение (brightness), то мы как минимум сможем провести переговоры на тему приемлемых характеристик цветности, по итогам переговоров инженер сможет подобрать дешёвую, но достаточно яркую на мой ролевой вкус краску (ролевой вкус! Как агент я могу предпочитать неяркие цвета, но в проектной роли я делаю профессиональное суждение по поводу яркости: реализую не собственное «как человека», а ролевое предпочтение) — моё ролевое предпочтение «яркого цвета»::«значение важной характеристики» будет реализовано.
Выбор метода описания оказывается нелёгким: описывать цветность и насыщенность цветов можно по-разному[5]. Мы в конечном итоге выбираем «метод/способ описания»/viewpoint, и в рамках этого выбранного метода описания обсуждаем мои хотелки/предпочтения иметь цвет поярче — моё намерение тут или заставить краску выбрать подороже, или даже сделать дополнительную подсветку (что ещё дороже, но я буду искать союзников, которым понравится эта опция для реализации каких-то своих предпочтений).
Если не договорились, то я::агент продолжаю реализовывать предпочтение своей роли иметь цвет поярче. Для этого я::агент перехожу в режим изобретательности и устраиваю какую-нибудь интригу (например, звонок какого-нибудь большого начальника::агент-с-полномочиями актёру, исполняющему роль инженера, и от этого же начальника звонок исполнителю роли финансиста). На следующих переговорах они оба сдаются, и в системную документацию попадает описание цвета системы как достаточно для меня яркого. Для того, чтобы описать эту яркость, используется тот метод описания цвета, о котором мы договорились.
Далее я убеждаюсь, что это описание будет реализовано, проверяя характеристики цветности закупаемой краски. Всё в порядке, моё предпочтение удовлетворено — против заданной в проекте насыщенности цвета инженер и финансист не возражают. Система в части цвета будет успешна (если не окажется, что есть ещё какая-то другая роль, которая, наоборот, добивается более бледного цвета и более изобретательна в реализации своих намерений).
Напомним, что описание (view) состоит из моделей, то есть отдельных маленьких описаний, отражающих какие-то важные характеристики, но не все характеристики, важные для суждения о каком-то аспекте системы, а только их часть. Метод описания состоит из мета-моделей (карта и легенда карты — это модель территории и мета-модель территории, мета-модель описывает модель, говорит о том, какие типы объектов и отношений могут появляться в модели). Мета-модели дают возможность создать модель, прогнозирующую состояние предмета моего интереса/характеристики системы. Создание viewpoints/«методы описания» — это работы мета-моделирования::метод (иногда говорят просто «моделирование», мета-модель это ведь тоже модель!).
Модели дают возможность оценить предмет моего интереса, и либо удовлетвориться, либо перейти к активным действиям по изменению ситуации, проверке того, что система действительно соответствует своим описаниям, или другим действиям, позволяющим скорректировать оценку в реализации предпочтений в сторону «ОК, успех, предпочтения удовлетворены». Модели — это про описания с использованием методов описаний, знания которых включают мета-модели.
Иерархии моделей, мета-моделей, мета-мета-моделей посвящена онтология как метод мышления из состава интеллект-стека, но в нашем руководстве мы рассматриваем только особенности моделирования и мета-моделирования в рамках системного мышления — создание системных описаний, известное как системное моделирование. Этому будет посвящён следующий раздел нашего руководства.