Как думать о системах? Зачем необходима множественность описаний системы?
Система воплощена в физическом мире. Это физический объект, в котором мы видим ролевой/функциональный, выдающий в мир (в надсистеме в окружении) какое-то поведение, кому-то нужное. Кому оно нужно? Каким-то агентам в ролях, осуществляющих деятельность по изменению мира. Откуда берутся эти системы? Другие роли, создатели, изучают потребности первых и создают системы с нужным поведением/функциями. Для того, чтобы знать, что создавать, необходимо это описать. Так как система сложный объект и состоит из атомов, описание системы по определению есть её полезное упрощение, ментальный объект, содержащий только ту информацию о системе, которая нужна (важную), и опускающий всю остальную (неважную). Важную и неважную кому? Конкретной роли, которая взаимодействует с системой - либо в процессе её создания (внутренние проектные роли), либо в процессе её эксплуатации в надсистеме (внешние проектные роли). Ролей обоих типов множество, каждую из них интересует в системе разное. Более того, в проекте по созданию системы есть три главных типа систем (надсистема, целевая, цепочка систем создания), ещё есть подсистемы, "наши системы" и окружение, есть рекурсия (целевая система для одних будет надсистемой для создателей "нашей системы" и подсистемой для создателей надсистемы), в проекте три области интересов ролей (предпринимательская, инженерная, менеджерская), и внешних ролей много (инвестура, клиентура, агентура, пользователи). То есть, с одной стороны, множество систем в проекте, с другой - множество ролей, каждая из которых с определённым набором предметов интересов и предпочтений в них к каким-то системам проекта. Но речь идёт об одном и том же физическом мире, наборе объектов, только с точки зрения ролевых интересов множества самых разных людей. Где отражаются эти интересы, как их описать? В ролевых описаниях самых разных систем проекта, составляемых для самых разных ролей в проекте. Ролевое описание будет давать ответ роли, как её предпочтение в предмете её ролевого интереса в данном проекте удовлетворяется. Если представить ситуацию, что абсолютно для каждой роли в проекте существует ролевое описание, отражающее её предпочтения в предметах её интересов, то роль будет довольна, так как её интересы в проекте как минимум учтены, как максимум удовлетворены (а чьи интересы учитывать и удовлетворять, а чьи учитывать , но не удовлетворять -- например, халявщиков, паразитов или мошенников, выбирают основатели проекта, неся соответствующие риски и ставя "шкуру на кон"). И главное: то важное, что должно быть отражено в ролевом описании для каждой роли и отражать предмет её интереса, определяется методом описания, без знания которого нельзя составить ролевое описание (как без знания метода работы нельзя выполнить работу и получить рабочие продукты надлежащего качества по методу). Метод описания/метамодель существует и задаёт набор понятий, которые должны быть отражены в ролевом описании/модели, и определяет набор рабочих продуктов/документацию, содержащую ролевые описания. Поэтому ролевых описаний в проекте множество, и каждое составлено какой-то ролью для какой-то роли по какому-то методу. Множественность описаний систем в проекте - это не прихоть, это необходимое требование к его реализации, позволяющее быть уверенным, что интересы всех проектных ролей выявлены, учтены, команда проекта договорена и воплощает в мире одну и ту же систему.
Что необходимо для старта работ по описанию системы?
Описание системы отличается от её воплощения в физическом мире и содержится в документации на систему. Описание системы состоит из множества ролевых описаний, а те состоят из моделей. Для создания описания необходима проектная роль, которая его создаёт, понимание, для какой другой проектной роли оно создаётся, понимание предметов её ролевого интереса, и метода описания/метамодели, отражающей эти предметы интересов данной роли и позволяющей составить ролевое описание/модель, которое будет отвечать на ролевой интерес и показывать, как её предпочтение в предмете интереса к каждой из систем проекта удовлетворяется. Иными словами, чтобы составить документ, в котором содержится описание системы, нужен тот, кто его составляет, тот, для кого он составляется, и метод, по которому он составляется, задающий понятия/объекты и формы документов, которые должны быть получены в итоге (и составлять, собственно, ролевое описание/модель).
Что отражается в документации?
Ролевое описание системы, полученное по какому-то методу описания. Если существует документация, то она содержит описание/модель системы проекта, составленное для какой-то проектной роли (внешней или внутренней) по какому-то методу, отражающему предметы интересов этой роли, и составляется она какой-то проектной ролью, владеющей этим методом описания и понимающей предметы интересов ролей-адресатов. Описание системы в документации содержит модель системы для данной роли (удовлетворяющую интересы данной роли к системе, но совершенно ничего не говорящую или вообще непонятную другим проектным ролям - клиентам сервиса будет непонятен да и не нужен техрегламент или юридическая документация на организацию). Кстати, роль можно выявить не только по методу её работы и рабочим продуктам, но также по документации, которой она в проекте интересуется, так как она отражает предметы её ролевого интереса.
Что такое метод описания? Кто его использует и для чего?
Метод описания (viewpoint) задаёт способ составления ролевого описания, отражающего предметы интересов конкретных проектных ролей. Он фиксирует понятия и объекты, которые должны быть отражены в описании/модели, и рабочие продукты/документацию, которая будет содержать описания по данному методу. Без метода описания нельзя понять, как вообще создать описание/модель системы, отражающее предметы интересов конкретных ролей (даже имея представление об этих предметах интересов). Метод описания должен быть кем-то создан/разработан/предложен/принят в сообществе/утверждён стандартом, и им должна владеть роль, составляющая описание по этому методу, которое будет читать другая роль, для которой это описание составляется, чтобы убедиться, что воплощение системы, соответствующее этим описаниям, будет удовлетворять её предпочтения в предметах её ролевых интересов. Ролевого описания без метода описания не бывает. Составляя ролевое описание, нужно обязательно указывать метод, по которому это описание получено. Роли, для которых описания составляются, обычно хорошо знают метод, по которому оно должно быть составлено, и либо предлагают его, либо требуют.
Как метод описания связан с предметом интереса?
Метод описания задаёт требования к ролевому описанию/модели системы, а именно: какие понятия и объекты, имеющие отношение к системе, должны быть отражены в описании (а остальные опущены как неважные для этой роли). У каждой роли есть предметы интересов к какой-то из трёх основных систем проекта, и предпочтения в них. И она хотела бы иметь описания системы/модель, из которых явно видно, как удовлетворяются предпочтения в предметах её интересов, и удовлетворяются ли вообще. Эти предметы интересов, а также способ их отражения в ролевом описании, и задаются методом описания (как способ выполнения какой-то работы задаётся методом этой работы, содержащим понятия, принципы и рабочие продукты, которые должны быть получены). Описание можно попытаться составить и без явного метода, просто зная предметы интересов роли, для которых оно создаётся, и это может даже получиться. Но качество таких описаний будет примерно такое же , как качество рабочих продуктов работы, выполненной без понимания её метода. Как разработаны sota методы работ, позволяющих не выдумывать метод, а сразу брать готовый, обучаться ему и получать рабочие продукты надлежащего качества, так и существуют sota методы описаний, позволяющие получать качественные ролевые описания систем для типовых ролей в конкретных предметных областях, отражающие их предметы интересов.
Зачем и как появляются описания системы?
Описания системы составляются одними проектными ролями для других с использованием метода описания, sota, метамодели, отражающей понятия/принципы и объекты, то есть самое важное в системе для этой роли, информация о чём должна содержаться в модели по этому методу описания. То есть для создания ролевого описания в проекте должна быть роль с предметами интереса к какой-то из систем проекта, которые решено удовлетворить воплощением системы, и для этого надо составить для этой роли ролевое описание, выбрав соответствующий метод описания. В результате получится ролевое описание/модель системы, составленное по методу описания, отвечающая на вопрос, как предпочтения данной роли в предметах её интересов удовлетворяются воплощением системы.
Приведите пример модели, мета-модели, мульти-модели, мега-модели.
Модель - ролевое описание системы, составленное по методу описания. Пример - бухгалтерский баланс предприятия.
Мета-модель - метод описания, задающий понятия/принципы составления модели/ролевого описания. Пример - форма бухгалтерского баланса, утверждённая постановлением какого-нибудь минфина какой-то страны как типовая, по которой все юрлица данной страны обязаны предоставлять бухгалтерскую отчётность.
Мульти-модель - набор моделей одной и той же системы, полученных по разным методам описания для разных ролей. Пример - пакет финансовой и бухгалтерской отчётности предприятия для чиновников, включающий бухбаланс, пояснительную записку, кучу справок, отчёты о прибылях и убытках, и много всяких других моделей предприятия, отправляемых им в адрес чиновников раз в год. А также соответствующая отчетность для акционеров и менеджмента. То есть весь набор финансовой и бухотчётности для всех внешних и внутренних ролей, которых интересует экономическое описание предприятия как системы создания с разными их целями и интересами (у чиновников ограбить, у акционеров и менеджмента получить соответствующую прибыль, бонусы, продать предприятие или привлечь инвесторов, сделать его публичной компанией). Весь этот набор моделей должен быть между собой увязан как единое целое.
Мега-модель - набор ролевых описаний системы и методов их описаний (моделей и мета-моделей), то есть с каждой моделью рядом идёт метод описания, с помощью которого эта модель получена. В примере с бухгалтерской и финансовой отчётностью предприятия для чиновников, акционеров и менеджмента это будет отсылка на соответствующие нормативные акты госорганов, утверждающие соответствующие формы отчётности, ссылка на стандарты финансовой отчётности, по которым составлены модели для акционеров и менеджмента.
Чем отличается моделирование от мета-моделирования?
Любая модель/описание системы для определённой роли составляется не “от балды”, а по какому-то методу описания. Метод описания, он же мета-модель, задаёт самое важное для данной роли, что должно быть указано в модели системы (а остальное отброшено). Самое важное для одной роли - одно, для другой - другое, для третьей - третье и так далее. Чтобы составить описание физического объекта/системы, то есть его полезное упрощение, мы должны понимать, для какой роли упрощаем и что значит “упрощаем”- какую информацию о характеристиках/свойствах/функциях/состояниях системы мы в модели укажем, а какую выбросим как неважную для данной роли. Что для этой роли важно в системе? то, что отвечает на предметы её ролевых интересов. Откуда мы узнаём про это важное? из мета-модели, задающей метод описания, по которому можно составить ролевое описание для данной роли. Откуда берётся этот метод? Он задаётся кем-то, нередко самой ролью в виде таблиц/форм отчёта, которые надо заполнить данными о системе (получится модель экземпляра). И модель, и метамодель, и мета-мета-модель описывают один и тот же физический мир, но в разных понятиях. Модель описывает систему, мета-модель описывает принципы создания модели, что важного о моделируемом объекте в ней должно быть отражено и как (содержание и форма), а что может быть опущено как неважное для данной роли).;
Какие четыре главные описания системы как «прозрачного ящика» вы изучили?
1. Функциональное, оно же ролевое. Показывает, из каких подсистем как функциональных объектов состоит система, что они делают, в результате чего система выдаёт в надсистеме нужное внешним ролям поведение в режиме эксплуатации. Это описание называется “аналитическим”, так как отвечает на вопрос “как система работает, за счёт каких функций каких её частей”.
2. Конструктивное, оно же модульное, оно же “синтетическое”. Показывает, из каких конструкций/модулей система состоит, как её собрать. Функции модулей из такого описания не видны, о них даже сложно догадаться, не имея функционального описания. Зато видно, как её синтезировать, воплотить, из каких конструктивных частей собрать.
3. Пространственное, оно же места, оно же расположения. Конструктивные части системы, являющиеся одновременно её подсистемами, существуют не вообще в пространстве, а где-то конкретно (мы говорим “расположены где-то во Вселенной”), у них есть адрес/координаты. Ведь воплощение системы всегда существует где-то конкретно, даже если её подсистемы разбросаны далеко друг от друга (но они есть где-то), если не знать это “где они расположены”, то воплощение системы создать не получится (ибо не понятно, в какой точке Вселенной её модули должны оказаться, чтобы их там собрать в систему - это же не может быть нигде или где угодно, воплощение должно появиться там, где оно кому-то нужно).
4. Стоимостное, оно же экономическое, оно же ресурсное. Показывает общую стоимость владения системой. Компоненты же они чего-то стоят, чтобы их создать в нужной конструкции и воплотить в конкретном месте и времени, нужно понести затраты. То есть воплощение системы всегда требует затрат, которые зависят от её конструктивного и пространственного описаний.
Приведите пример несовпадения функциональных и модульных частей системы.
Несовпадение означает, что не каждый модуль/конструктивная часть системы будет одновременно являться его функциональной подсистемой. Модуль может совмещать в себе несколько функциональных частей, а одна функциональная часть может быть представлена несколькими модулями. Например, у меня дома есть кресло-груша, модульно представленная чехлом, внутри которого пакет с гранулами. Одновременно этот чехол представляет собой два функциональных объекта - сиденье для опоры седалища и спинку для опоры спины. Чайник состоит из модуля, который одновременно и опора на поверхность, и ёмкость для воды.
Что рассматривается в каждой ячейке Таблицы 3х3?
Таблица три на три сводит воедино области интересов трёх основных ролей в проекте (предпринимательской, инженерной и менеджерской) и области интересов к трём основным системам в проекте (надсистеме, целевой системе и системе создания). В каждой ячейке описываются конкретные интересы каждой роли к каждой из систем, что является предметами её интереса. Раз есть предметы интереса роли к системе, соответственно, в проекте должны быть ролевые описания, отвечающие предметам интересов данной роли к данной системе, выполненные по какому-то методу описания. Поэтому можно сказать, что в каждой ячейке рассматриваются наборы ролевых описаний, отражающих предметы интересов ролей к системам, и эти наборы будут разные. Но одно и то же описание может отвечать предметам интересов нескольких ролей, разные роли могут иметь один и тот же предмет интереса.