Подальфы ​

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

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

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

• Замышлено (ясно, каково будет описание системы)
• Непротиворечиво (описание системы создано и непротиворечиво)
• Используется для изготовления (описание используется для изготовления воплощения системы)
• Используется для проверки воплощения (описание используется для проведения тестов и испытаний)
• Используется для эксплуатации (используется проектными ролями для эксплуатации воплощения системы)
• Используется для вывода из эксплуатации (используется для ликвидации и/или переработки воплощения системы)

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

• Замышлена (conceived, внутренние проектные роли согласились в необходимости новой системы для удовлетворения потребностей внешних проектных ролей)
• Ограничена (bounded, основная функция/назначение новой системы понятна)
• Непротиворечива (coherent, концепция использования непротиворечиво описывает основные сценарии использования, в том числе существенные характеристики новой системы)
• Приемлема (acceptable, концепция использования описывает такую систему, которая приемлема как для внутренних, так и для внешних проектных ролей)
• Отвечена (addressed, воплощение системы удовлетворяет концепции использования настолько, что система принимается внешними проектными ролями в эксплуатацию)
• Удовлетворена (fulfilled, воплощение системы полностью отвечает концепции использования, внешние проектные роли считают систему успешной)

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

Архитектура --- это тоже подальфа описания системы: чем более готова архитектура, тем более описана система. «Рабочка» (детальные модели/чертежи, а в случае софта это исходный код, готовый для компилирования) тут тоже подальфа описания системы.

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

Входящее в системное описание ролевое описание отвечает на вопросы о предметах интереса/concerns. Проектная роль может иметь и несколько предметов интереса. Ролевое описание позволяет описать систему так, чтобы поддержать разговор с проектной ролью по предмету/теме/зоне/области её интересов, ответить на интересующие её вопросы по достижению её предпочтений в интересующих характеристиках систем. Результат? Успешная система: если стейкхолдер соглашается с описанием, то воплощение системы, удовлетворяющее этому описанию его тоже, скорее всего, удовлетворит. То есть успешность системы мы часто можем определить ещё тогда, когда воплощения системы ещё нет, а есть только описание --- использование 3D-информационных моделей, чертежей, имитационных моделей в инженерии, нот в музыке и любых других записей в проектировании и конструировании как раз имеет целью это: подробно обсудить реализацию самых разных предпочтений в важных для всех ролей в проекте характеристиках/concerns разных систем проекта ещё до того, как целевая система будет воплощена.

При этом показываем проектным ролям не описания, а документацию/рабочие продукты/артефакты: без носителя информации нет способа предъявить описания для их обсуждения. Так что первым делом все описания нужно документировать, не держать в голове!

Описаний же много: разные проектные внутренние и внешние роли интересуются крайне разными ролевыми описаниями/views системы, и отражаются важные для самых разных ролей характеристики/concerns систем самыми разными ролевыми методами описаний/viewpoints, по которым и делаются эти описания/views. И, конечно, каждое описание может быть документировано разными способами (например, с использованием разных нотаций --- числа могут быть записаны арабскими цифрами, римскими цифрами, в двоичной системе), на разных носителях.

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

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

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

В оригинальном ISO 42010, например, view вообще определено как ролевая документация/файлы, а viewpoint --- документация/файлы метода описания, но в большинстве мест самого стандарта они используются как ролевые описания, а не документация!

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

Полное системное описание встречается в жизни довольно редко (хотя всегда в проектах ведутся попытки как-то собрать в одном месте многочисленные документы с разными ролевыми описаниями), много чаще встречаются просто отдельные ролевые описания системы. Поэтому view обычно переводится просто как «описание», без указания на то, что оно ролевое, а не полное системное --- но при этом подразумевается его частичность, оно даёт ответы на вопросы только по части предметов интереса/важных характеристик, для ответов на вопросы по другим предметам интересов нужны будут другие view, подготовленные по другим методам описания/viewpoint. Концепция использования --- это тоже описание, и архитектура --- описание, и отчётность по РСБУ и МСФО --- описания, но они каждое --- не полное системное описание. Продвинуть альфу системного описания по её состояниям можно, продвигая работами проекта по их состояниям отдельные ролевые описания/views, но этих описаний довольно много. Какие подальфы чаще всего отслеживаются для альфы системного описания?

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

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

Как именно делать эти описания, рассказывается в других дисциплинах: прикладных практиках системной инженерии: классической и программной инженерии, образования и коучинга как инженерии личности, менеджмента как организационной инженерии/инженерии предприятия, социальной инженерии и так далее. Например, музыку записывают в виде партитуры в нотной записи. Как сделать партитуру для новой свежесочинённой песни? Это прикладное знание. В системном мышлении вы только должны запомнить, что если есть «песня», то она должна как-то быть описана. И это описание должно быть документировано. А уж как именно описано (нотация roll piano, или древнерусская нотация крюками, или современная нотная запись) --- это изучается прикладными дисциплинами. Но если у вас в проекте есть и партитуры с нотной записью, и чертежи, и расписание, и органиграмма, то системное мышление позволяет обсудить все эти отдельные описания, не потерять их --- оставив прикладным дисциплинам подробности того, как именно они делаются и как ими пользоваться. Системное мышление --- это фундаментальные, пронизывающие все дисциплины приёмы мышления на базе понятий системного подхода. Знания системного мышления не могут заменить знания прикладных практик. Знать о том, что «описания всегда есть на каком-то уровне абстракции мета-моделирования, но они могут быть не конкретизированы и не документированы» --- мало. Нужно ещё знать, как делать эти описания, то есть нужно знать прикладные дисциплины классической и программной инженерии, менеджмента, медицины, правоохраны, политического действия и т.д. Только системного мышления для проектной работы не хватает, нужно ещё владеть мастерством в предмете/прикладным мастерством.