Альфы – это то, что изменяется в ходе проекта, меняя свои состояния. Альфы – это то, изменения чего в проекте мы хотим понимать, отслеживать, обеспечивать, направлять, контролировать.

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

Рабочим продуктом могут быть и какие-то мероприятия (совещания, презентации, уборка рабочего места), которые можно представлять «вещественно» как совокупность участвующих в этом мероприятии взаимно изменяющихся объектов.

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

Экономия мышления заключается в том, что часто одна альфа представляется в до десятка разных рабочих продуктах. Обсуждение и мышление тем самым ведётся только для одного объекта, и только при разбирательстве с какими-то конкретными деталями вытаскиваются отдельные рабочие продукты.

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

Рабочие продукты могут быть как входными для проекта, так и представлять собой результаты, или же быть полезными только команде, не являясь ни входными, ни результирующими для проекта.

Как и альфа меняется, проходя состояния, рабочий продукт меняется, проходя уровни детальности. Рабочие продукты в ходе инженерного, менеджерского или культурного проекта создаются, модифицируются, уничтожаются. Они вместе с их уровнями детальности наблюдаемы, в отличие от альф, о состояниях которых мы можем судить только «по приборам» – по рабочим продуктам.

 

Описание системы

 

(Полное) описание системы (system description) это рабочие продукты, реализующие альфы (полного) определения системы (system definition). Если система есть, то она обычно (полностью) определена: подразумевается, что есть её требования, есть её архитектура, есть неархитектурная часть проекта/design, их только нужно выявить и как-то записать – на бумаге или в электронном виде в базе данных тут неважно. Важно чётко различать всегда существующее определение системы-альфу (есть система – значит кто-то её выделил из окружающего мира, думает о ней. Думает – значит определяет, «система в глазах смотрящего») и не всегда существующее описание системы-рабочий продукт.

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

Стандарт ISO 42010 даёт рекомендации о том, как думать о (полном) описании системы. Сам стандарт говорит только об архитектурном описании, но его положения вполне применимы к любым описаниям. Вот задающее мышление об описаниях системы диаграмма из этого стандарта, модифицированная с использованием положений OMG Essence (Рис. 3).

Диаграмма начинается с уже знакомого нам различения воплощения (realization) и определения (definition) системы.

Каждая связь между объектами этой диаграммы может быть прочтена в двух направлениях: «воплощение системы удовлетворяет определению системы», «определение системы характеризует определение системы». «Определение системы выражается описанием системы», «описание системы документирует определение системы».

 

 

Для простоты диаграммы многие связи приведены только с одним наименованием связи, но это не значит, что не существует обратного отношения. Это общее свойство всех подобных схем: даже отношение «часть-целое» в одном направлении читается «включает_в_себя», в другом направлении читается «является_частью».

Вот схема на английском языке:

 

 

(Полное) описание системы (system description) состоит из частных описаний  системы (view) – рабочих продуктов, которые отражают частные определения системы (на диаграмме не показаны).

Частные определения системы – это как раз требования, архитектура, неархитектурные части дизайна, данные об эксплуатации: всё что угодно, что определяет интересные для стейкхолдера ипостаси/аспекты системы. Определения системы – функциональные объекты, описания системы – рабочие продукты.

Подальфы (sub-alpha) определяются по отношению к основной альфе как такие альфы, при продвижении которых к конечному их состоянию в проекте мы можем считать, что этим самым как-то продвигается и их основная альфа. Так, требования являются подальфой определения системы: чем более готовы требования, тем более готово и определение системы в целом. Архитектура это тоже подальфа определения системы: чем более готова архитектура, тем более определена система.

На диаграмме чётко видно, что частное описание отвечает на вопросы стейкхолдера, а именно на вопросы какого-то стейкхолдерского интереса. Помним, что интерес – это та тема, которая интересна стейкхолдеру для его деятельности, стейкхолдер может иметь и несколько интересов. Частное описание системы позволяет описать систему так, чтобы поддержать разговор со стейкхолдером на тему его интереса, ответить на интересующие его вопросы.

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

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

Более того, полное описание системы встречается в жизни довольно редко, много чаще встречаются частные описания системы. Поэтому view обычно переводится как «описание» – и при этом подразумевается его частичность, отражаемая на диаграмме стрелочкой с ромбиком на конце полного описания.

Какие бывают описания (view)? Прежде всего, можно выделить функциональные/компонентные описания, конструктивные/модульные описания, описания размещения. Но кроме этого может быть огромное количество описаний, интересующих самых разных стейкхолдеров: например, финансовое, синхронизации во времени, структуры владения, информационных потоков и т. д. Чем сложней система, тем бо́льшего количества (частных, на какую-то одну тему) описаний можно ожидать.

 

Модели и виды моделей

 

Само описание (view) состоит из множества отдельных моделей (models), которые можно трактовать как разные способы формального или неформального описания, отвечающие на ещё более частные вопросы. Например, полное описание системы включает в себя финансовое описание системы, но в финансовом описании можно выделить разные модели, нужные для ответа на разные вопросы интересующегося финансами стейкхолдера: баланс, отчёт о прибылях и убытках (profit and loss, P&L) и денежный поток (cash flow). Если у вас есть только баланс, то вы не ответите на вопрос о безубыточности работы предприятия, а если у вас отчёт о прибылях и убытках и даже баланс, то вы не сможете обсудить кассовый разрыв без наличия документов по денежному потоку. Одно описание, три разные модели.

Каждая из моделей отдельных (частных, тематических) описаний должна быть выполнена с использованием одного из вида моделей (model kinds), причем каждый из видов моделей устанавливает определенные язык, правила и приёмы моделирования (соглашения), используемые при разработке модели. Так же как отдельные модели (models) одной тематики объединяются в тематическое описание (view), так и виды моделей (model kinds), определяющие язык, правила и приёмы моделирования (соглашения), используемые при разработке тематического описания, объединяются в тематический метод описания (viewpoint).

Например, для финансового описания нужно прежде всего выбрать один из методов описания – РСБУ (Российские стандарты бухгалтерского учёта), МСФО (международные стандарты финансовой отчётности). При составлении баланса (одна модель финансового описания) и отчёта о прибыли и убытках (другая модель финансового описания) нужно использовать правила для этих видов моделей из одного метода описаний – либо РСБУ, либо МСФО.

Проще всего считать, что метод описания – это набор условных обозначений для многослойных карт-моделей, которые описывают территорию. Одно из следствий рассматриваемой схемы: нельзя делать описания, если в явном виде не рассматривается метод описания. Нельзя делать карты, если неизвестна легенда карты и методы картографирования. Эти карты потом нельзя сопоставлять друг с другом. Нельзя делать карту, используя слои, подготовленные согласно разным методам картографирования – нельзя брать подготовленную геодезистами карту водных ресурсов города и подготовленную службами метрополитена карту-схему станций метро и просто накладывать их друг на друга. Нельзя брать баланс по РСБУ, а отчёт о прибылях и убытках делать в МСФО. Все модели (models) из описания (view) должны быть подготовлены с использованием видов моделей (model kinds) из одного метода описания (viewpoint).

Метод описания чаще всего бывает библиотечным (library), это означает просто, что вместо его содержания приводят просто ссылку на литературу по этому методу. Это всё равно как вместо легенды карты можно было бы просто дать ссылку на книгу, где рассматриваются условные значки для изображения деталей рельефа, флоры, фауны, полезных ископаемых, плотности населения и т. д. Но если пришлось описывать что-то таким способом, который до сих пор не использовался, то вместо этой ссылки придётся к описанию приложить и документированный метод описания. Главное – это запомнить: любое описание – это описание системы, любое описание системы сделано с использованием метода описания (даже если описывающий этого не осознаёт).

Метод описания оформляет (frame) интерес (concern) стейкхолдера. Одно из следствий рассматриваемой схемы: если у стейкхолдера нет соответствующего интереса, то описание не делается. И наоборот: если у стейкхолдера обнаруживается интерес, то описание делается обязательно  (документируется! Речь не идёт об устных ответах на вопросы! На бумаге, или в базе данных, но описание должно быть!).

Описания (views) могут быть двух видов: прожекторные (projective) и синтетические (synthetic).

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

Синтетические описания – это когда наоборот: исходные описания даны в виде отдельных моделей, причём каждая модель – это не просто часть одной общей для всех моделей базы данных, а отдельный бумажный или электронный документ. Между этими автономными моделями устанавливаются правила соответствия (correspondence rules, «этот элемент этой модели – это вон тот элемент той модели»), и общая модель тем самым получается синтетически. Рассуждения про полное и частичные описания системы при этом не меняются от того, как собираются эти описания из моделей – сразу (прожекторный подход к описаниям) или после создания отдельных моделей (синтетический подход).

 

Мультимодель и междисциплинарность

 

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

Для карты, являющейся моделью территории, мета-модель – это легенда карты. Карта содержит ничтожную часть информации о территории, но это крайне важная информация. А легенда карты указывает на то, что на этой карте важного нужно отображать. В каком-то смысле мета-модель это описание важного в модели, равно как модель это описание важного в реальном мире.

Бывают и мета-мета-модели, ибо одни описания могут моделировать другие. Так, холодильник моделируется для инженера-ремонтника его принципиальной схемой. Принципиальная схема тут модель холодильника, а вот её обозначения (легенда) будут мета-моделью холодильника. Но когда мы говорим о том, как в компьютерном редакторе принципиальных схем моделируются обозначения для принципиальных схем холодильников, речь идёт уже о мета-мета-модели холодильника. Моделирование многоуровнево, и для компьютерных структурных[125] моделей обычно бывает три-четыре уровня мета-моделирования.

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

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

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

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