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

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

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

Вот модификация диаграммы из стандарта IEC 81346—1, это иллюстрирующая:

На рисунке изображены три стейкхолдера, которых интересуют разные аспекты устройства системы, они изображены фигурками человечков. Помним, что стейкхолдеры это только роли, их может играть и один человек, и целые группы людей.

Каждый из стейкхолдеров видит свою систему разбитой на определённые виды структурных элементов, условно изображённые цветами.

Минимально в системном подходе нужно увидеть в системе три вида частей:

• Компоненты (components), или функциональные элементы, которые позволяют отвечать на вопрос о том, как взаимодействуют части системы, чтобы она выполняла свою функцию («как работает система»). На картинке нарисована принципиальная схема, на которой приведено описание компонент и их соединений (connectors). Компоненты выполняют свою функцию в системе через соединения с другими компонентами, меняя своё состояние от этого взаимодействия и меняя состояния других компонент. Если мы хотим понять, как идёт спектакль, в котором вот этот вот человек говорит своё «To-be-or-not-to-be», нам нужно понять играемую им роль в этом спектакле. Нам понятно, что в спектакле он Принц Гамлет (а не Василий Пупкин, который его играет, Василия при случае ведь и заменить можно на John Doe для пущей убедительности).

• Модули (modules), или конструктивные элементы, продукты, сборочные единицы, логистические единицы – этот вид частей позволяет отвечать на вопрос, из чего собрать и как соединить через интерфейсы (interface) части системы («как собрать систему»). Поведение модуля – это выполняемый им на интерфейсе с другими модулями сервис (service, услуга, служба). На картинке нарисована сборочная диаграмма, позволяющая понять, как собрать систему из частей-модулей – но при этом совершенно непонятно как эта система работает.

• Места (locations), или размещения (allocations), которые позволяют отвечать на вопрос, где можно найти части системы, как она скомпонована в пространстве. На картинке изображены отсеки, в которых ведётся монтаж системы и в которых она затем работает, но непонятно из чего система собрана и как она работает. Всё это ролевые части целой системы, изображённой кубиком с цветными гранями – и каждый стейкхолдер в силу специфики своих интересов видит частное определение системы как «прозрачного ящика», состоящее из интересующих его типов элементов, отвечающих на его интерес. Это «не единое» восприятие целостной системы нормально, так и должно быть! Единым в описаниях у разных стейкхолдеров может быть только единонемыслие (Салтыков-Щедрин). Реальное же единство обеспечивает 4D-экстенсионализм: воплощение системы занимает то же место в пространстве-времени, что и компоненты, модули, размещения. Это и даёт единство: это всё разные способы выделения частей одной и той же системы, разные способы организации внимания, выделения главного и отбрасывания второстепенного для стейкхолдеров. Все стейкхолдеры по-разному думают о системе, представляют её по-разному, а единство обеспечивается тем, что в реальном мире воплощение системы одно и то же – и это даёт возможность и даже требует от стейкхолдеров договорённостей по поводу системы.

У немецких инженеров-электротехников был подсмотрен приём: чтобы сразу было видно, о каком виде элемента говорится, части системы именуют с использованием специальных префиксов: компонентный префикс “=», модульный префикс “-», префикс размещения “+». А имена даются по соответствующей холархии. Так =S12=16 означает, что речь идёт о компоненте 16, входящей в состав (отношение composition, part_of) компоненты S12. Проектирование, конечно, ведётся в классах: это имя класса компонент, а не конкретной компоненты конкретной физической системы. Число уровней в таком имени неограничено. Такое имя компоненты часто называют тегом (tag).

Если имя —M87-K5, то речь идёт о модуле К5, который входит в состав модуля М87. Это тоже не конкретный физический объект с серийным номером, а класс этих объектов, продукт определённой модели.

Стандарт IEC 81346 закрепил такое именование, причём он определяет ещё и как давать коды вместо «нормальных» длинных имён. Действительно, если в каком-нибудь Boeing 787 есть 6 миллионов индивидуальных деталей, то это сразу означает, что у них даже больше имён – и лучше бы держать эти имена короткими, и каждое имя чтобы было понятно, к какой части самолёта относится.

Мы уже знакомились с ситуацией, когда Принц Гамлет и Василий Пупкин могут быть одним человеком, но называться по-разному в зависимости от того, что нам от него нужно – понять, какая фраза будет следующая в его пьесе, когда он планирует выучить новую роль в новом спектакле, или выяснить, есть ли у него дети. То же можно сказать и о системе: «измеритель давления», «манометр KLM-23 завода «Давижмимонтажавтоматика»» и «датчик в пятом ящике на третьей полке склада номер 4» вполне могут оказаться одним и тем же прибором – но разные имена свидетельствуют о том, что мы планируем совершенно разные действия с этим прибором, поэтому для нас один и тот же прибор выступает в разных ипостасях и имеет поэтому разные имена. Имя «Принц Гамлет – Василий Пупкин» вполне осмысленно, хотя на ней приведено сразу два имени отдельных ипостасей актёра: действующего лица и исполнителя роли. Так и имена систем в промышленности часто могут состоять из имён нескольких ипостасей, например, «=S12=16 —M87-K5». Обычно это относится к конкретному проекту, так же, как «Принц Гамлет – Василий Пупкин» относится к одному спектаклю, в другом спектакле распределение ролей будет другое. В силу 4D экстенсионализма все эти имена говорят о каком-то месте в пространстве, так что всегда можно разобраться.

 

Многерица: единонемыслие единого

Суть системного подхода в том, чтобы ни в один момент времени не забывать про систему в целом – воплощение системы, которое просто по-разному представляется состоящим из разных частей разными стейкхолдерами. Это очень трудно.

В христианстве есть довольно сложно осваиваемое в мышлении понятие троицы: бог представляется одновременно и единым, и существующим в трёх ипостасях (отца, сына и святого духа).

Проблема в том, что думать о боге нужно одновременно и о как едином, и как об отдельных ипостасях – такому мышлению несколько лет обучают в семинариях. Сама идея-то понимается очень легко, но не так легко эта идея осваивается в практике мышления, метанойя происходит медленно:

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

Беглости подобного мышления «единого-ипостасного» тоже довольно долго учат, хотя идея понимается с первого предъявления.

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

По сравнению с религиями трудность в том, что речь идёт не о трёх ипостасях/аспектах, не о троице, а о множестве ипостасей системы – о многерице.

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

• ISO 15926 – две основных: функциональные объекты, физические объекты. Остальные могут вводиться по потребности.

• IEC 81346 – «по меньшей мере» три (функция, продукт, место)

• Книга Paul Clements at al., Documenting Software Architectures: Views and Beyond (2nd edition), Addison-Wesley Professional, 2010 – три стиля (компоненты, модули, размещения, и разные варианты внутри каждого стиля). Авторы этой книги тесно связаны с разработчиками ISO 42010, поэтому мы ориентируемся в нашем учебнике именно на эти названия – «компоненты, модули, места/размещения».

• Книга Косяков, Свит, Сеймур: «Системная инженерия. Принципы и практика» – функциональный элемент, компонента (в значении «модуль» из предыдущей книги: ровно обратное использование термина!), размещение.

• СМД-методология – «по меньшей мере» пять (процессы, элементы и связи, внешние функции, морфология, материал)

• … и так далее, в среднем 3—7 основных ипостасей (впрочем, «ипостаси» тоже называются везде по-разному) в разных школах системного мышления.

В нашем курсе мы примем, что системы имеют минимально три ипостаси/аспекта – компонент, модулей и размещений. И запомним, что этих ипостасей/аспектов всегда больше, плюс сами эти ипостаси/аспектов в чистом виде не встречаются и обычно тесно сплетены друг с другом («гибридны»).

Для разных стейкхолдеров система будет представляться в своих аспектах-ипостасях мышления отдельных дисциплин совершенно по-разному – но при этом в системном мышлении она будет оставаться целостной/холистичной/целокупностью всех своих ипостасей/аспектов.

 

Многерица холархий

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

Целевая система отличается тем, что для неё компонента, модуль и место совпадают, это одно и тот же экстент в пространстве.

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

ТРИЗ задачу своих изобретений видит в том, чтобы несколько разных функций выполнялись небольшим числом конструктивных элементов – в идеальной системе много функций выполняются нулевым числом элементов, нужно стремиться к этому. Так что гарантировать, что холархии функциональных элементов, конструктивных элементов, размещений совпадают нельзя.

Нельзя путать компоненты и модули. Нельзя путать Принца Гамлета и Василия Пупкина, даже если во время спектакля это одно и то же. Если вы будете за кулисами говорить Василию Пупкину «Ваше Высочество», а на сцене говорить Принцу Гамлету «как там твои жена и дети?», то окружающие на вас будут смотреть странно, а Василий Пупкин сильно озадачится.

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

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

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

Заказать можно только модули, а ручка и ножевой блок у ножниц компоненты, а не модули. Модулями в ножницах будут только две половинки ножниц (а ещё винтик).

Если делать ручки и ножевой блок отдельно как модули, а потом их как-то скреплять, то это будет плохое и ненадёжное инженерное решение.

Менеджеры же сначала внимают доводам инженеров, но потом… смотрят на ножницы в сборе, видят в действии (эксплуатации, operations) ручку и ножевой блок – и опять пытаются с ними сделать что-то по отдельности не в момент «спектакля» (когда ножницы в сборе и работают – режут), а в момент изготовления. Например, разделить работы по сборке ручки и ножевого блока, хотя при соединении половинок ножниц винтиком разделить работы по ручке и ножевому блоку принципиально невозможно. Или сделать каталог ручек и каталог ножевых блоков и потом пытаться заставить инженеров выпускать эти якобы «детали ножниц» в виде запчастей. Список ошибок и заблуждений тут бесконечен, и эти ошибки не прекратятся: менеджеры постоянно находят «ножевой блок» и «ручки» в инженерной документации и пытаются поступать с ними как со сборочными единицами.

Правда в том, что в ножницах разные стейкхолдеры усматривают две разные холархии: одна функциональной декомпозиции («аналитическая»), а вторая модульной сборки («синтетическая»):

Целевая система едина как компонента и модуль, но вот дальше структура компонент (функциональная структура, системное разбиение) и модулей (модульная структура, конструктивное разбиение) могут существенно различаться.

В инженерных языках моделирования «железной» архитектуры, равно как и в языках моделирования предприятия, компоненты и модули имеют различные значки.

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

Главное при этом – это решения создателей системы, какие элементы конструкции реализуют какие необходимые для работы системы поведения/функции, так что требуются обычно описывать и компоненты, и модули.

 

Компонентный анализ и модульный синтез

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

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

На рисунке из стандарта IEC 81346—1 (а этот стандарт взял этот рисунок из более раннего стандарта IEC 1392/09) «объект с функциональным аспектом» это компонента, «объект с продуктным аспектом» это модуль, а «объект как с продуктным, так и функциональным аспектом» – это модуль, сервис которого выполняет функцию компоненты.

Рассмотрим целевую систему, которую в начальный момент мы рассматриваем как компоненту А. Реализовать (realize) – это вынести «логический» объект-компоненту (роль) в физическую реальность модулей (исполнителей ролей). Первое что происходит – это функциональная декомпозиция: функция компоненты разбивается на более мелкие (на рисунке это B и другие четыре) и делается попытка выбрать для них модули, сервисы которых могут выполнить функции этих компонент. На рисунке видно, что на первом шаге декомпозиции это удаётся только для двух подфункций из шести. На следующем шаге это уже удаётся для всех подфункций, в то числе для подфункций компоненты B. Эта часть функциональной декомпозиции иногда называется функциональным анализом. Дальше мы должны из всех модулей, используя их интерфейсы для соединения, собрать целевую систему-модуль. Для сборки-модуля B на рисунке, реализующего функцию компоненты B это получается только в два шага – сначала собираются два промежуточных модуля, и только потом они объединяются. А на следующем шаге модуль B включается в состав модуля А, который реализует изначально задуманную функцию А. С этого момента функция и сервис совпадают, компонента и модуль совпадают. Эту часть проектирования системы как составления целой системы-модуля из её подмодулей называют модульный синтез.

Проблема в том, что обычно из имеющихся модулей трудно подобрать такие, которые в конструкции реализуют все необходимые компоненты с их функциями. Для этого приходится менять способ разбивки на функции (что эквивалентно предложению другого способа работы устройства, другого принципа работы), а модули приходится разрабатывать, если их нельзя купить готовые (купить – это ведь простейший способ эти модули реализовать/изготовить!). И всегда помним, что модульный синтез – это изобретательская деятельность: желательно научиться много функций навешивать на один модуль, уменьшая количество модулей в системе. ТРИЗ занимается именно этим.

 

Альфы и рабочие продукты

Стандарт OMG Essence предлагает предлагает особый вид компонент – альфа (ALPHA). Альфа – это функциональный объект, контроль за изменением состояния которого позволяет оценивать степень продвижения проекта в работе с этой альфой. Мышление о том, «как проект работает» посвящено альфам, ролевым объектам, они имеют функцию/назначение, вменённые им в проекте человеком.

Этот же стандарт OMG Essence для модулей, физической реализации альф предлагает имя рабочий продукт (work product, иногда используемый синоним – «артефакт», artifact, т.е. предмет искусственного происхождения) – это конструктивный объект: то, над чем работаем, из чего проект «собран», что можно обнаружить в окружающем мире.

Альфа отличается от ранее встречавшихся нам 4D-функциональных объектов тем, что она бывает и абстрактным объектом – каким-то определением системы: требованиями, архитектурой, неархитектурной частью проекта/design. В проекте приходится следить как за функциональной частью разных описаний системы (определениями), так и за функциональной частью воплощения системы (компонентами).

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

Альфы и рабочие продукты нельзя путать: альфы (роли!) существуют главным образом в голове (хотя о них мы и думаем как о реальных объектах), рабочие продукты в мире. В стандарте они изображаются разными значаками: альфа похожа на греческую α, а рабочий продукт на лист бумаги с загнутым уголком.

Стандарт разрабатывался главным образом для разработчиков информационных систем, поэтому он не совсем соответствует принципам 4D экстенсионализма (например, альфами там вполне называют описания – идеальные объекты, не имеющие в мире экстента), но эти тонкости не так важны.

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

В жизни нет ни одного слова из нашей книги, в книге нет ни одного слова из окружающей вас жизни – в книге главным образом про альфы, в жизни специфичные для каждой конкретной компании рабочие продукты. Это ключевое место для понимания системного мышления, ключевое для понимания способа его полезного использования – как описанные в нашей книге приёмы мышления (теория) связаны с практикой, с реальным миром.

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

В реальном мире мы видим артефакты «яблоки» и определённые дела с этими артефактами, например, «съесть яблоки», «сосчитать яблоки». Альфы представляют собой те объекты, которые описываются дисциплиной (теорией) – «количество предметов» и «сосчитать предметы», если вернуться к примеру со счётом яблок. Альфа тут – «предмет», а не «яблоко»! Тут нужно привести байку про яблоки из задачи и из жизни, например, в таком варианте:

Пришла в… школу учительница, которая начиталась работ о дидактической функции наглядных пособий и считала, что надо учить на наглядных пособиях. А проходили они в этот момент задачку на сложение: «3+5». И она принесла три яблока и ещё пять яблок, выложила их на стол и говорит: «Дети, вот вы видите здесь – раз—два—три – три яблока, а здесь вот – раз—два—три—четыре—пять – пять яблок. Вот я их соединяю, сколько получится всего яблок?» Дети пялятся на яблоки, слюни у них текут, но задачи не понимают. Второй день проходит, третий – рекорд: в таком классе обычно за день это проходили. Она приходит в учительскую, жалуется, что вот—де она применяет новые методы, наглядно все, а результата нет. И вот на пятый день с задней парты тянется рука, и ученик говорит: «Мэм, я теперь понял: эти яблоки, которые вы выложили на стол, не настоящие – это яблоки из задачи». – «Да, а что?» – «Ну тогда, мэм, совсем другое дело». И с этого момента, когда класс понял, что это не настоящие яблоки, а яблоки из задачи, все моментально пошло. Почему? Когда вы кладёте реальные яблоки – что с ними надо делать? Их надо есть. А чтобы считать, нужны рисуночки.

Вот ещё про то же самое:

– Мы займёмся арифметикой… У вас в кармане два яблока…

Буратино хитро подмигнул:

– Врёте, ни одного…

– Я говорю, – терпеливо повторила девочка, – предположим, что у вас в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас осталось яблок?

– Два.

– Подумайте хорошенько.

Буратино сморщился, – так здорово подумал.

– Два…

– Почему?

– Я же не отдам Некту яблоко, хоть он дерись!

– У вас нет никаких способностей к математике, – с огорчением сказала девочка.

Про физическое тело мы знаем, что при наличии силы тяжести они летят по параболе. Ускорения и масса тоже у физических тел. Если кинуть камень и не суметь соотнести его с физическим телом, то нельзя сказать, что он полетит по параболе! Нет таких учебников, в которых описываются полёты именно камней! Ричард Фейнман в своих заметках по преподаванию физики ровно об этом сожалел: по всему миру ученики физики не могут сопоставить отличные знания из учебника явлениям окружающего мира.

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

Обычно занимающиеся по нашей книге проходят следующие стадии при изучении системного мышления:

• Ничего не понимают, ибо неспособны соотнести материал книги с окружающим их миром. Действительно, в их инженерных, менеджерских, культурных проектах нет никаких альф. А в книге нет ничего, что есть в их проектах. Более того, каждый проект уникальный – в них ведь вообще нет ничего общего, а книга одна и та же для этих самых разных проектов! И эти проекты в книге не описаны, примеры из них не приведены.

• Всё понимают про приводимые в книге примеры, а также про проекты однокурсников и коллег по работе, но при этом ничего не понимают про свои собственные проекты. Конечно, ибо чужие проекты – это «проекты из чужой задачи» (помним, «яблоки из задачи – их можно считать»), а свои проекты – это «реальные мои проекты» («яблоки из жизни», их нужно есть!).

• Всё понимают и про свои проекты, и про проекты коллег. Но ничего из понимаемого не делают, ибо системное мышление изучается не для того, чтобы его применять, а «для самообразования и развития», «для сдачи зачёта» и т. д. Применять знания мешают начальники, текучка, лень, отсутствие единомышленников, помогать применять знания некому.

• Применяют материал книги в своих проектах, ибо так работать оказывается качественней, легче и в конечном итоге быстрее. Очень часто это происходит только через год-два после знакомства с книгой. В первом разделе нашей книги об этом было подробно сказано.

 

Альфы

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

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

Альфы (alphas) – это функциональные (выполняющие определённую функцию, играющие определённую роль, идеальные) объекты, по которым мы судим о продвижении (progress, «как много мы уже сделали?») и здоровье (health, «в проекте всё идёт хорошо») проекта.

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

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

Например, учимся думать о «требованиях» – а применяем потом это мышление к конкретным рабочим продуктам, которые можно найти на производстве «в реале»: спецификациям требований, требованиям из текстов стандартов, user stories на карточках, записям в базе данных системы управления требованиями и т. д.

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

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

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

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

Формально (то есть в стандарте OMG Essence) ALPHA – это аббревиатура, Abstract-Level Progress Health Attribute, но неформально это просто способ указать на функциональный элемент/компоненту проекта. Аббревиатура про health attribute была для альфы подобрана задним числом, а слово alpha пишут поэтому маленькими буквами.

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

Рабочий продукт/артефакт представляет (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) для вынесения суждений о другом (моделируемом) объекте. Важно, что «выносит суждение» стейкхолдер: у него есть какой-то интерес, на который и отвечает эта модель. Оформляется этот интерес методом описания, а в этом методе описания как раз указывается, что самое важное в моделируемом объекте, что нужно учесть в модели. Это «самое важное» для всех моделей этого рода и называют мета-модель.

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

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

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

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

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

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

 

Метод описания и мега-модель

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

Частные описания системы (views) состоят из моделей, определяемых методами описания (viewpoints), в свою очередь состоящих из мета-моделей, задающих виды моделей (model kinds).

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

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

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

Если вы даёте кому-то описание системы, то вы обязаны также сообщить, как вы получили это описание.

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

 

Компонентные описания: принципиальные схемы

У очень и очень многих стейкхолдеров в проекте есть интерес к тому, как система работает в ходе её эксплуатации.

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

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

Вот несколько типичных примеров принципиальных схем:

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

Компоненты физичны, они выбраны так, чтобы удобно было объяснять работу системы в ходе её эксплуатации/функционирования (run time, operations). Соединения – это логические/ролевые/функциональные связи, но в 4D всегда можно найти физический объект, которые своей темпоральной частью реализует эту связь, через которую компоненты взаимно влияют друг на друга.

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

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

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

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

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

 

Модульные описания

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

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

Интерфейс обычно описывается каким-то стандартом, описывающим как свойства соединения, так и происходящее в ходе взаимодействия модулей через соединение. Интерфейсы модулей похожи на порты компонент в том плане, что это именно места присоединения, они не конструктивные элементы, они не занимают объёма в пространстве, хотя у них и может быть форма. Вилка и штепсель, гнездо и штеккер: интерфейс – это то, что между ними. А сама физическая вилка? Это интерфейсный модуль, главное назначение которого – обеспечить какой-то интерфейс. И у этого модуля два интерфейса: один целевой, а другой – присоединяющий его к какому-то модулю, для которого нужен целевой интерфейс. Вот пример такого интерфейсного модуля (который в просторечии называют USB-интерфейс, что неверно – у него есть ещё и сигнальный интерфейс к плате, и отдельный интерфейс к питанию и даже интерфейс к человеку: светодиод, который мигает, когда идёт передача данных и кнопка включения, а ещё есть механический интерфейс крепления к корпусу или другой плате):

А как же соединения, которые нужны для работы – все эти трубы, кабели, волноводы? Это тоже модули, и у них есть свои интерфейсы: они находятся между ними и теми модулями, которые они соединяют. Что проходит через эти интерфейсы и как оно связано с работой всей системы?! Неизвестно, ибо речь идёт о конструктивных единицах: функции тут не определить, для этого нужно выходить за пределы модульного описания. Единственное, что важно, это наличие соединения: монтажник должен убедиться, что соединение установлено, модуль сможет выполнять свой сервис.

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

Например, принтер и компьютер связаны через USB интерфейс, но какая информация идёт принтеру, это интерфейсу неизвестно. Утюг к электросети подсоединён через интерфейс между евровилкой и евророзеткой, но этому интерфейсу неизвестно, какой через неё пойдёт ток и зачем. С другой стороны, известны предельные значения тока, который может пройти через этот интерфейс, равно как предельное количество информации, которое может пройти через USB-интерфейс. Задача модульного синтеза выбрать такие интерфейсы, которые смогли бы выдержать соединения, предусмотренные компонентной структурой системы.

Вот ещё пример модульного описания, в этом случае речь идёт просто о списке комплектующих, которые нужно купить для изготовления какой-то старинной версии iPhone (Рис. 4)

Обратите внимание, сколько тут упоминается разных стандартов: GPS, HSPDA, DDR, Bluetooth – перечисление интерфейсов обычно для модульных описаний. Ведь вся суть модулей – это замена реализации какой-то функции путём простой замены модуля на стандартном интерфейсе.

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

 

Платформы и технологические стеки

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

Платформа – это всегда модульное рассмотрение, обсуждение платформы всегда связано с её сервисами, т.е. внешним поведением, предоставляемом на интерфейсе к другим модулям. Для программных модулей этот интерфейс обычно называется API (application program interface), программный интерфейс приложения. Если речь идёт не о программной системе, то можно говорить просто об интерфейсе приложения, или прикладном интерфейсе. Прикладной – это определяемый использующей системой платформы (согласованного в части выполнения каких-то сервисов набора модулей) или модуля. Приложение – это использующая система для платформы модуля, части приложения находятся в операционном окружении модуля.

Основной вопрос при обсуждении платформ – это так называемая видимость интерфейсов. Интерфейсы какого-то низкого системного уровня не должны быть видны снаружи модуля, то есть невозможно соединение модулей иначе, чем через предусмотренные в нём интерфейсы. Грубо говоря, если у вас коробочка с каким-то разъёмом, то нельзя воткнуть внешнее устройство не в этот разъём, а куда-нибудь внутрь коробочки, мимо этого разъёма. Для обсуждения видимости интерфейсов используется диаграмма модульных уровней, диаграмма холархии системных уровней. Каждый уровень отделён от другого уровня каким-то интерфейсом. Реализации нижестоящих уровней тем самым могут быть сменены так, что использующая система этого не заметит. А итоговую холархию называют платформенным стеком или технологическим стеком (stack, стопка – диаграммы похожи на стопку подносов в столовой или стопку листов бумаги в пачке). Вот пример различных технологических стеков для организации связи:

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

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

Верхняя скобка для стандарта интерфейса в использующую систему от custom code ведёт как бы в никуда при таком способе показа, поэтому чаще используется способ предыдущей картинки, где платформа обозначается не по назначениям/именам её модулей/слоёв, а назначение указывается сбоку.

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

Платформенность даёт возможность эффективного разделения труда: реализацией каждого уровня платформенного стека может заниматься отдельная команда, и команды могут соревноваться за эффективность реализации. Инженеры, использующие какие-то платформы для создания своих целевых систем, могут не задумываться, как именно и из каких систем были сделаны эти платформы. Они могут просто использовать прикладной интерфейс этих платформ. А если этот прикладной интерфейс стандартизован, то они могут ещё и выбрать подходящий им по цене и характеристикам вариант реализации. И это происходит на много уровней вверх и много уровней вниз по технологическому стеку.

Деньги обычно приходят от удачного и массового использования верхнего, прикладного уровня. Но вот «перетряхивание» всего технологического/платформенного стека, перестройка всех рынков идут тогда, когда меняется принцип реализации самого нижнего уровня модулей, меняется платформа нижнего уровня. Например, когда в компьютерах поменялись механические или пневматические элементы на лампы, компьютеры стали масштабируемы и они начали напоминать уже функционально современные компьютеры, а не калькуляторы прошлых лет. Замена ламп на дискретную полупроводниковую технику позволила наладить массовый выпуск компьютеров и это разительно изменило компьютерную технику. Замена дискретной электроники на большие полупроводниковые интегральные схемы опять перевернуло весь компьютерный рынок со всеми надстройками программного обеспечения. Замена CPU на GPU перевернула рынок искусственного интеллекта. Замена людей-исполнителей на роботов-исполнителей переворачивает все промышленные предприятия. Эта особенность делает технологические/платформенные/модульные стеки удобными для обсуждения стратегии компании – обсуждается, что из модулей будет компания делать сама, а что закупать вовне, какие стандарты интерфейсов для этих модулей она будет устанавливать сама, а какие брать уже готовыми.

 

Важность функциональных рассмотрений целевой системы

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

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

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

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

У нас стоит задача тонкого химического синтеза диметилфторидметилхлорпентилбензолтитана для задач фармацевтической промышленности. Известно, что его трудно синтезировать, и при синтезе получается много примесей, от которых потом люди умирают. Поэтому мы предложим аптекам такой чистый продукт, от которого люди не будут умирать, а маркетинг будет оригинальный: через уборщиц медицинских учреждений, которые будут подбрасывать наши буклеты врачам, а также задушевно беседовать с пациентами в очередях ко врачам. Для того, чтобы получить чистый диметилфторидметилхлорпентилбензолтитан, мы будем использовать четыре стальных реактора, соединённых трубами диаметром 56мм, последняя труба с тефлоновым покрытием. Второй реактор закажем внешним контракторам. Чистоту получающегося диметилфторидметилхлорпентилбензолтитана будем отслеживать при помощи независимой экспертной службы. Все четыре реактора должны будут пройти проверку на выдерживание давления в 156 атмосфер.

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

Теперь представим инженера, которому маркетологи говорят, что ему нужно будет решить задачу химического синтеза, но непонятно ещё какую. И они когда-нибудь потом, но вот не прямо сейчас наймут химика, который всё уточнит. Инженер соглашается и берётся за дело: ему сразу понятно, что нужны будут реакторы и трубы. Реакторов непонятно сколько, ибо непонятно, сколько там в синтезе будет химических реакций. Поэтому лучше бы этих реакторов было побольше. Он выбирает цифру 4, как «не очень мало, но и ещё не очень дорого», догадывается, что в этом синтезе может быть хитрая эндотермическая реакция, но сам он для такой реакции реактор вряд ли спроектирует. Так что этот «хитрый реактор» он отдаёт проектировать внешним контракторам и честно об этом пишет. Хотя контракторы и спрашивали, что там с массами и температурой, ответ пока никто не может дать, поэтому контракт планируется без разговора о требованиях – но контрактор, разумеется, от заказа не отказывается и говорит, что «сделаю любой реактор». Слово «любой» никого не отпугивает, ибо нет химика, который бы сказал, что же будет в этом реакторе происходить. Есть только инженеры по железу, хорошо разбирающиеся в марках стали и сварке, и маркетологи, беседующие с врачами и фармацевтами.

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

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

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

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

Мыслить только про конструкции нельзя. Отсутствие мышления о функциональности нужно как-то осознавать и исправлять. А это отсутствие мышления о функциональности заметно только в случае наличия системного мышления – оно позволяет заметить то, о чём вы забыли подумать, управляет вашим вниманием.

 

Предпринятия

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

Следующий уровень – это команды и прочие организационные звенья (в предприятиях – подразделения), получаемые из организованных (то есть с понятными полномочиями по использованию труда друг друга и других ресурсов) людей. Сервисы команд, сервисы подразделений, оказываемые ими на их интерфейсах, обсуждение интерфейсов-каналов для общения с ними являются типичным предметом обсуждения, сервисы пытаются стандартизовать. Предприятие буквально составлено, собрано, сделано из своих подразделений – это конструктивные, а не функциональные подразделения. Из обсуждения организационной диаграммы не скажешь, как работает предприятия, какие функции подразделений по отношению друг ко другу, и именование оргзвеньев это часто отражает. Цех №5, палата №6 – простые номера в именах, из которых не следует функций, являются типичными указателями на конструктивное рассмотрение. Функций, исполняемых конструктивными элементами предприятия, может быть множество, и самых неожиданных. С другой стороны, если «подразделение переезжает в другое здание», то это описание связи ипостасей конструктивной и размещения. «Подразделение будет выполнять новые виды деятельности» – это обсуждение связи функциональной и конструктивной ипостасей подразделения.

 

Необходимость хорошей модульности

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

Вот компьютерная симуляция зависимости от числа попыток улучшений падения стоимости разработки при улучшении n отдельных модулей, при d связей каждого из них:

Видно, что если связь одна, то стоимость разработки с каждым улучшением падает быстро по экспоненте, слабо зависящей от числа модулей. Но если связей больше, то снижение стоимости идёт плохо.

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

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

Есть множество методов, которые помогают уменьшать связность модулей в создаваемой системе. Одним из наиболее известных таких методов является DSM (design/dependency structure matrix).

Минимальная связность модулей нужна и в «железных» системах, и в программных системах, и в организационных, и даже в танцах. Это совсем не означает, что части системы/подсистемы не находятся в тесном взаимодействии друг с другом. Это означает, что эти взаимодействия ставятся под жёсткий контроль, и подсистемы можно улучшать, а в случае стандартизации интерфейса даже заменять на принципиально другие по конструкции и принципу действия, не рискуя при этом ухудшить работу всей системы в целом.

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

 

Борьба со сложностью в мышлении

Edsger Dijkstra в 1974 году ввёл понятие разделения интересов (separation of concerns) как способ упорядочивания человеческих мыслей о каком-то предмете. Этот принцип гласит, что нужно обсуждать сложные ситуации по одному интересу за раз, удерживая внимание на каком-то одном аспекте, одной ипостаси этой ситуации. Это не значит, что игнорируются все остальные. Просто это удерживание во внимании одного аспекта проблемы и одновременно всей проблемы. По словам Edsger Dijkstra про такое мышление, «It is being one – and multiple-track minded simultaneously».

И это разделение мышления по интересам проводится на каждом уровне системной холархии, поскольку ввиду эмерджентности на каждом уровне система начинает проявлять какие-то новые свойства.

Сложность обсуждения системы тем самым падает по двум направлениям:

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

• деление полного обсуждения каждого холона на обсуждение отдельных ипостасей этого холона как прозрачного ящика: принципов организации взаимодействия и структуры частей холона. Важнейшие из этих определений – это архитектура (architecture), а все остальные определения с точностью, достаточной для изготовления – это неархитектурная часть проекта (non-architectural part of design).

Тем самым детальное и в подробностях обсуждение огромных сложных систем принципиально (в силу самой сути системного подхода) может быть разбито на достаточно маленькие части, и ни одна часть этого обсуждения не будет забыта, ни одно описание не будет пропущено. Как съесть слона? По кусочку за раз!

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

Но как договориться о том, как склеивать все эти самые разные частные описания самых разных частей системы в одно целое? Как договориться всем этим людям? Это можно сделать на основании 4D экстенсионализма. Все эти описания можно совместить, если понимать, что они описывают одно и то же место в пространстве-времени, относятся к одному и тому же воплощению системы. Без системного подхода сложные проекты с задействованием большого количества разных специалистов выполнить в срок и вовремя невозможно.

 

Требования как часть определения системы

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

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

Приключения требований на этом не заканчиваются: требования анализируют, затем их наборы делают непротиворечивыми, после чего обеспечивают к ним доступ самых разных стейкхолдеров (это обеспечение доступа и называется управление требованиями/requirements management). Всё вместе называют инженерия требований (requirements engineering). Обратите внимание, что как выявление требований входит в инженерию требований, так и управление требованиями. Управлять нельзя тем, чего ещё нет, а выявленные требования это только сырьё для дальнейшей работы.

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

 

Два понимания требований

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

1. Требования (requirements) – это часть определения системы, определяющая систему как «чёрный ящик», т.е. что делает система по отношению к её системному окружению, без описания внутренней структуры системы, происходящих внутри системы взаимодействий частей системы. Прежде всего тут важно поведение системы, выполнение ей своего назначения, функции в использующей системе. Поэтому основные требования называют функциональными требованиями. Нефункциональных требований не бывает, хотя в литературе этот термин регулярно встречается, но он считается некорректным: все требования описывают какое-то поведение системы, ожидания этого поведения. Но речь не всегда идёт о поведении в использующей системе. Требования качества в отличие от функциональных, относятся прежде всего к поведению в обеспечивающих системах, в том числе обслуживающих уже готовую систему: по-английски их иногда называют – ilities (reliability, accessability и т.п.), а по-русски – ости (надёжность, доступность, и т.п.).

Требования отличают от потребностей (stakeholder needs, stakeholder requirments) как требований внешних стейкхолдеров к использующей системе. Если мы выходим за пределы инженерии, то у требований могут быть другие имена. Например, для организаций речь может идти о стратегии – но суть тут будет та же самая: описание того, что хотелось бы получить от организации. Требования, взятые вместе со временем их выполнения, называют контрольными точками (milestone). Если требование – это «помидор красный», то «помидор красный, 10 мартобря 2019 года» будет контрольной точкой. Очень часто на контроле стоят не сами требования, а контрольные точки: «дорога ложка к обеду».

2. Альтернативное понимание требования уже не имеет отношения к системному подходу, не связано с границами системы. Это просто любое утверждение, данное в деонтической модальности. Любое высказывание из описания системы (например, «X=10») невозможно как-то понять по отношению к деятельности без указания на модальность (modality): то, как нужно понимать значения высказывания. Скажем, «в системе [существует] X=10» это алетическая (aletic) модальность, модальность существования. «Я верю, что в системе X=10» – это модальность доксическая (doxastic), веры. Деонтическая (deontic) модальность говорит о долженствовании, разрешении, рекомендации: «Я требую, чтобы X=10». В этом втором понимании требований можно потребовать что угодно – и оно станет требованием, даже если речь идёт не о чёрном ящике. Например, «в автомобиле должен быть корпус из углепластика», «в смартфоне должны быть использованы отечественные микропроцессоры» относятся к «прозрачному ящику», но слова «должен» и «должны» указывают на деонтическую модальность.

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

 

Требования и холархия

Стандарт описания требований ISO/IEC 29148:2011 подчёркивает то, что требования есть у каждого холона в холархии. Вот пример из этого стандарта:

Чтобы лучше понять этот пример, нужно «перевести с айтишного» слово business.

Стандарт ISO/IEC 29148:2011 даёт чёткое указание, что слово бизнес (business) тут просто условный термин, обозначающий просто организацию (organization): «The term business is used even though it could apply to not-for-profit organizations such as in the public sector. Users of this standard may replace each occurrence of the term business with the term organization or organizational depending on the users’ environment».

Это относится не только к требованиям, но и ко многому другому. Так бизнес-процесс лучше называть организационным процессом.

Картинка очень неподробно и схематично показывает холархию какой-то организации, в которой внутри организационного окружения (organization environment) находится вся работающая организация (business operation), в которой содержится какая-то часть организации, работающая с системой (system operation), в которой есть система (system), в которой есть элемент системы (system element), в котором есть программное обеспечение (software). Каждый из указанных холонов в холархии имеет какие-то описания «чёрного ящика», называемые требованиями – и на картинке некоторые из них показаны зелёными стрелками, указывающими на границы соответствующих вложенных друг в друга систем-холонов.

Целевой системой тут является «система» (system), требования к ней так и называются: системные требования (system requirements).

Требования к использующей системе будут называться требования стейкхолдеров (stakeholder requirements) или потребности/нужды стейкхолдеров (stakeholder needs). Их не перепутать: они описывают разные системы на их границах (как «чёрный ящик», без подробностей про внутреннее устройство каждой из систем), на картинке это чётко видно.

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

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

 

Целеориентированная инженерия требований

Идея о том, что требования не «объективны», а их субъективно задают стейкхолдеры для того, чтобы достичь каких-то целей, не так уж стара.

В 1986 году Ивар Якобсон предложил технику выявления требований, при которой рассматриваются варианты использования (use cases).

Вариант использования определяет взаимодействие между пытающимися достичь своих целей внешними актёрами (actors) и целевой системой.

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

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

Вот типичная диаграмма вариантов использования:

В 1995 году появился подход к моделированию требований, называемый i*, и он продолжил идею взаимодействия актёров и системы для достижения своих целей. Упор был сделан не только на варианты использования системы актёрами, но и на описания взаимодействий самих актёров, а весь подход получил название целеориентированной инженерии требований (goal-oriented requirements engineering). В философии тех, кто может иметь свои цели, принято называть агентами (agents) – независимо от живой или неживой (например, системы искусственного интеллекта) природы этих агентов.

В i* приняли, что требования отражают цели, убеждения, возможности и договорённости агентов, окончательно признав социальную природу требований, их «необъективность»: «Agents attribute intentional properties (such as goals, beliefs, abilities, commitments) to each other and reason about strategic relationships. Dependencies between agents give rise to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a qualitative reasoning approach. Agents consider alternative configurations of dependencies to assess their strategic positioning in a social context».

Был предложен язык для записи взаимодействий актёров, преследующих свои цели:

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

В 2008 году международный союз телекоммуникаций принял стандарт ITU-T Z.151, в котором для моделирования требований предлагался целеориентированный язык требований подхода i* (Goal-oriented Requirements Language) и карты вариантов использования (Use Case Maps). В простейшем случае вариант целеориентированной системной инженерии предполагает написание коротких пользовательских историй (user story), в которых актёр сведён до обычной стейкхолдерской роли. Пример формата таких историй: «Я как _стейкхолдер_ хочу, чтобы _целевая-система_ _формулировка требования _, для того чтобы _потребности-для-использующей-системы_».

 

Проверка и приёмка

Проверка и приёмка (verification and validation, V&V, верификация и валидация) служат для того, чтобы убедиться в работоспособности системы. По сути, это просто тщательное тестирование системы, проведение испытаний, обоснование успешности системы. Успешность – это соответствие ожиданиям стейкхолдеров. Стейкхолдеров же у нас два набора:

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

• и внутренние, которых волнует работоспособность целевой системы – работает ли целевая система как задумано, удовлетворяет ли системным требованиям?

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

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

Испытания/тестирование разного сорта могут составлять до 85% от общей стоимости проекта. Именно потому, что недостаточно проверки/верификации, но ещё нужна и валидация, в испытаниях требуется участие не только целевой системы, но и значительной части её системного окружения. Поскольку системное окружение может быть недоступно, или очень дорого, то это требует часто создания испытательных стендов, более дорогих, чем сама целевая система. В результате какая-нибудь задвижка для атомной станции оказывается полностью идентичной задвижке для городского водопровода, но будет стоить впятеро дороже: потому что её много тщательней испытывали.

 

Понятие архитектуры

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

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

Об описании цвета или архитектуры мы говорим, или о самом цвете или архитектуре – это понимаем из контекста, или проговариваем явно. Если мы говорим «цвет нужно сделать почернее», то это про цвет, а если «цвет в кодировке RGB», то про описание цвета. С архитектурой всё то же самое.

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

Вот другое определение архитектуры, от части авторов того же ISO 42010, но данное ими в книге про документирование системных архитектур: «Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений». Там наоборот, дан акцент на структуры.

Но самых разных определений много больше, и в интернете есть место, где собрано более 150 таких определений. Самые разные стейкхолдеры определяют архитектуру по-разному, с акцентом на те или иные её свойства, те или иные классы целевых систем.

Мы будем придерживаться неформального простого и понятного определения архитектуры, которое дал Ralf Johnson: «Архитектура – это обо всём важном. Что бы это ни было.».

Эти слова обычно указывают на важные решения, которые могут быть для «железных» систем инженерные, для предприятия организационные, менеджерские или предпринимательские, в случае танцев – постановочные решения, и т. д. Важные решения определяются как такие, в случае принятия альтернативных решений по ним придётся перепринять большинство других решений, то есть перепроектировать и затем переделать всю систему. Так, если при проектировании самолёта принято решение сделать его с реактивным двигателем, а не обычным поршневым, то это означает переделку практически всей конструкции: от устройства топливной системы до формы крыльев и фюзеляжа. Если в здании принято решение печатать его на бетонном 3D-принтере, а не выкладывать его из бетонных блоков или даже из кирпича, то смело можно переделывать всю проектную документацию – или переделывать весь дом, если он уже построен.

Если принято решение сделать какой-то винтик не с левой резьбой, а с правой, то вряд ли это приведёт к переделке всего изделия. Будет переделан лишь этот винтик и резьба в связанной с ним гайке. Такое решение не архитектурное. Весь проект/design тем самым делится на две части: архитектура и неархитектурная часть проекта (non-architectural part of design).

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

Более сложные формы архитектурных описаний включают в себя компонентные, модульные диаграммы, трассировку компонент и их функций к модулям, размещения и компоновки. То есть архитектурное описание это совсем необязательно список принятых решений: решения могут быть документированы и в других формах. Главное, чтобы они не оказались устными. Интересно, что в советской устной архитектурной традиции, когда архитектурных описаний практически не было, всё важное обозначалось словами «заделы», «опыт», «наработки». Архитектуры были, но их нельзя было предъявить, обсудить, передать, развить иным способом, кроме как задействовав ту команду, которая имела тот самый «опыт» и «заделы» в голове.

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

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

На рисунке субъективность отнесения к архитектурным решениям показана насыщенностью цвета, при этом стрелки примерно соответствуют небольшому числу взаимосвязанных решений, определяющих все остальные решения. Стейкхолдеров-архитекторов показано два: один занимается архитектурой всей системы, другой архитектурой подсистемы. Где остановиться в принятии архитектурных решений? Спускаясь по отношениям часть-целое в холархии нужно остановиться там, где стейкхолдер-архитектор считает, что там уже нет его важных решений, то есть работа уже поделена между разработчиками модулей и дальше будут их важные решения.

Требования, которые однозначно ведут к архитектурным решениям часто называют архитектурными требованиями. Например, для самолёта скорость является архитектурным требованием. Если самолёт должен обеспечивать скорость 0км/час, то его архитектура должна быть архитектурой вертикального взлёта и посадки. Если скорость должна быть 2000км/час, то это может быть обеспечено только для реактивного самолёта.

Итак, архитектура это (с точностью до разницы между определением и описанием – самой архитектурой и выражающими её рабочими продуктами):

• самые важные части функционального и конструктивного определений системы в их взаимосвязи, или оно же как

• компоненты + модули + размещения (только важные, верхнеуровневые), или оно же как

• принципиальная схема + заказная спецификация + компоновка (только важные, верхнеуровневые), или оно же как

• логическая архитектура + физическая архитектура (при учёте возражения о недопустимости «частных архитектур»), или оно же как

• список важнейших принятых конструкторских/проектных/постановочных решений

 

Понятие конфигурации

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

В ходе разработки инженерной системы обычно рассматривают самые разные варианты требований, архитектуры, неархитектурной части проекта/design. И эти описания ещё и изменяются каждое по нескольку раз. Как определить, какие из этих описаний должны быть использованы изготовителями системы? А если часть изготовителей изменили систему так, что она уже не соответствует этим описаниям, а часть изготовителей работает «как договаривались» – можно ли быть уверенным, что из изготовленных частей можно будет собрать работающую систему? Конечно, нет. Ошибки, связанные с тем, что некоторые части системы и их описания не известны, или даже известны, но не соответствуют друг другу, весьма распространены.

Конфигурация системы – это сами части системы и их описания. Сама конфигурация может быть определена (defined) и, соответственно, описана (described). Описание конфигурации (configuration description, иногда говорят и «конфигурационное описание») в речи часто сокращают до просто «конфигурация» – и разницу между конфигурацией (составом самой системы) и описанием конфигурации нужно определять из контекста так же, как разницу между архитектурой и архитектурным описанием, когда для обоих используют слово «архитектура».

Управление конфигурацией (configuration management) – отслеживание, что конфигурация воплощения системы и описания системы известны и соответствуют друг другу. Это дисциплина лежит посредине между менеджерскими и инженерными дисциплинами. Конфигурация составляется из конфигурационных единиц (configuration item) – самых мелких частей, на которые делится система в части её логистики. Речь идёт о единицах передачи частей системы и описаний этих частей от одного исполнителя работ к другому, от одной обработки к другой.

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

Чтобы не потерять эти конфигурационные единицы при учёте, иметь возможность на них сослаться в разговоре и различных описаниях системы, им даются индивидуальные обозначения (designations). Стандарт IEC 81346 представляет собой стандарт, в котором предлагается типовой способ такого описания, учитывающий системный подход – наличие нескольких альтернативных структур системы (компонентной/функциональной, модульной/продуктной, размещений, и т.д.).

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

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

Базис (baseline, конфигурационный базис) – это проверенная на целостность и утверждённая административно версия.

Управление изменениями (change management) часто включают в состав управления конфигурацией (так и пишут: «управление конфигурацией и изменениями», но обычно это отдельная дисциплина. Её не нужно путать с управлением организационными изменениями – как нужно менять организацию, чтобы это не вызывало сопротивления людей и вело к положительным результатам. Инженерное управление изменениями – это про то, как принимать решения по изменению конфигурации, чтобы минимизировать конфигурационные ошибки. Для этого в конфигурации различают обычные рабочие версии с более простыми внесениями изменений и базисы, внесение изменений в которые связано с дополнительными инженерными и административными проверками на целостность конфигурации.

 

Инженерия предприятия

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

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

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