Анатолий Левенчук
Системное мышление 2024. Том 2

Полная версия

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

Задания по системным уровням

Поставьте отметку о выполнении:

1. Написан пост с моделированием системных уровней мастерства вашего хобби (за основу поста взято описание из разделов с примером социальных танцев).

2. Написан пост с моделированием системных уровней вашего основного рабочего мастерства, (за основу поста взято описание из разделов с примером социальных танцев).

8. Графы создания

Отношения создания

Простейший граф создания метафорически (то есть весьма вольно) можно проиллюстрировать диаграммой:

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

Целевая система проявляет свои внешние свойства в надсистему «в ходе»/«во время» её работы/operations, это обозначено словами «феном⁵⁵ тут». Слова run-time часто используются в программной инженерии, чтобы обозначать время функционирования/работы/эксплуатации готовой системы. Но мы обозначили на диаграмме его другим, не менее употребимым словом – Ops-time, время работы операторов системы, когда система в рабочем состоянии, функционирует.

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

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

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

Слова для времени создания и развития из программной/software инженерии – dev-time (от «development»), часто design time. При рассмотрении создателей мы не рассматриваем работающую/эксплуатирующуюся в окружении целевую систему, а рассматриваем систему в момент её создания (замысливания/«стратегирования использования», проектирования, изготовления, ввода в эксплуатацию системы как MVP, а дальше поток инкрементального развития функциональности и конструкции). Остальные методы времени создания (инженерные обоснования, принятие архитектурных решений) тоже присутствуют, но они тоже опущены для краткости, главное, что понятно: речь идёт о ходе/времени создания, dev-time, а не ops-time. Системы создания и системы из системных уровней внутри и снаружи целевой системы рассматриваются в разные времена/realms, что отражено пунктирной вертикальной красной линией, которую пересекают стрелки отношения создания.

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

Конечно, есть проблемы и единства рассмотрения этого времени, так называемая проблема DevOps, когда разработчики/создатели системы никак не связаны с операторами/пользователями и поэтому делают систему, которой невозможно пользоваться. Эта проблема решается прежде всего организационными мерами, но сегодня часто задействуют и технические меры: операторы и даже пользователи вообще исключаются как люди, заменяются роботами, так называемый подход NoOps⁵⁶. В любом случае, в системном мышлении принято не столько считать всё происходящее в разработке и использовании принадлежащим к одному физическому времени, сколько различают «логические» времена создания (development, design, construction, implementation, enabling – везде в центре методы работы создателей, а целевая система тут пассивна, ещё не готова к работе) и времени эксплуатации (run, operation, use – функции/методы самой целевой системы, а создатели тут уже не работают, пассивны).

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

Между системами в окружении (целевой, надсистемой, системами в составе надсистемы из ближнего окружения и т. д. – если встретилось слово окружение/среда/environment, надо всегда помнить, что это «операционное окружение»/«operations environment», то есть рассмотрение времени работы) и их создателями тоже отношение создания (development, design, construction, implementation, enabling), когда один создатель::система описывает и/или меняет другую систему. И таких систем можно рассмотреть целую цепочку по отношению создания, а если поглядеть на все такие цепочки, то это будет граф создания: узлы – это системы (целевая и создатели) а рёбра – отношения создания. Внутри одного времени – отношения часть-целое/композиции, через границы времён/realms – отношения создания (X::система создаёт/«изменяет состояние» Y::система).

На диаграмме показан вариант такого графа создания. Для каждого создателя тоже было его создание, и его эксплуатация/использование/работа/operations. Поэтому на диаграмме представлено несколько разных «времён» рассмотрения (realms), и что для создателя будет его ops-time, для целевой системы будет dev-time. А что для создателя его dev-time, то для создателя создателя – ops-time.

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

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

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

Отношения создания – это не отношения часть-целое! Enabling/construction это не composition/part_of! Кастрюля, в которой варится борщ – это не кастрюля в составе борща, или борщ в составе кастрюли! Это кастрюля для создания борща!

А теперь поставьте крестик на любом из кружков этой диаграммы, которым в составе большой команды проекта будет заниматься ваша маленькая команда (возможно, в ней будете только вы один) – это будет «наша система» (system-in-hand, engineered system, MySystem, OurSystem). И повторите все рассуждения про целевую систему для нашей системы – ни на секунду не забывая про целевую систему и отношения нашей системы и целевой системы!

Запутались? Запишите все эти системы в каком-нибудь редакторе текстов или другом моделере, как шахматист записывает шахматную партию. Думайте не «в уме», думайте над текстом, или аутлайном, или таблицей!

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

Наша диаграмма графа создания (тип изображения, в котором квадратики или кружочки обозначений объектов соединены стрелками для обозначения отношений) в курсе используется исключительно в целях объяснения небольшого неизменяемого и никак не привязанного к проектам набора понятий. Она не будет модифицироваться в ходе проекта, она содержит очень мало деталей. Это иллюстрация в учебник, не рабочий инструмент системного моделирования. Мы не рекомендуем диаграммное моделирование в рабочих проектах, но мы требуем вести в проектах обязательное системное моделирование в виде текстов, аутлайнов, таблиц: форматы, которые удобно менять/редактировать, производить в них поиск, наращивать их объём без боязни запутаться в хитросплетении связей⁵⁸.

Документирование в системном мышлении важно. Внимание, которым управляют без записей, управляется ненадёжно. Люди забывчивы, поэтому документируйте/записывайте всё (всё-всё!).

Как моделировать изменения важных объектов в проекте, будет рассказано подробно в курсе «Методология».

Моделирование: цепочки создания

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

Концепция использования

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

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

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

Мы описываем систему как чёрный ящик минимально четыре раза, это и есть «системное рассмотрение»:

• Функционально: как роль (функциональный/ролевой объект) и его функцию во взаимодействии с окружением во время эксплуатации/работы/функционирования. Забивало – прикладывает усилие от руки к забиваемому острому предмету.

• Конструктивно: как конструктив, который мы создаём и развиваем во время создания. Молоток – вот этот, который мы купили в магазине (и будет реализовывать во время эксплуатации забивало).

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

• Стоимостно: Как совокупная стоимость владения чёрным ящиком. Вот эта штука, стоит 1000 рублей купить и практически нисколько эксплуатировать.

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

При системном рассмотрении мы учитываем дополнительно:

• Граф создания: кроме рассмотрения системы как «чёрного ящика» в момент его работы, мы учитываем, что кто-то эту систему создаст и будет развивать.

• Эволюцию: рассматриваем не только однократное первичное создание системы, но и развитие системы: «чёрный ящик» будет развиваться/модернизироваться, речь не идёт о каком-то однократном ходе его появления. Нет, будет MVP и множество инкрементов, «никакая версия системы не является последней».

«Описываем систему» – это или

• «прямая инженерия», то есть проектирование/design в части придумывания того, какая нужна система в составе надсистемы.

• «обратная инженерия»/reverse engineering уже существующей системы, если такое описание недоступно, но для чего-то нужно.

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

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

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

• Проверка экспериментом: мы можем выполнить какие-то измерения в реальном мире и проверить, совпадают ли в каком-то доверительном интервале эти измерения у уже существующей (изготовленной/воплощённой) системы с проектными значениями для неё.

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

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

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

Если мы меняем модальность системного описания «чёрного ящика» с доксической (веры) на деонтическую (запреты и разрешения, предписания), то описание чёрного ящика называют системными требованиями (system requirements). И раньше в конечном итоге разрабатывали именно системные требования, а сейчас разрабатывают концепцию использования/concept of operations, уточняемую и детализируемую до сценариев использования/use cases – они отличаются прежде всего вот этим онтологическим статусом, но не только. В концепции использования и дальше в сценариях использования описывают поведение системы как «чёрного ящика», то есть описывают функции системы, её роль в окружении – описывают на статусе гипотезы, что это правильно угаданное поведение успешной системы.

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

Главное тут:

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

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

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

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

• Отказ от требований привёл ещё и к тому, что начали активно использовать A|B тестирование⁶⁰, когда гипотез выдвигается сразу несколько (требования обычно требуют что-то одно!), и проверяются они все вместе, а потом выбирают вариант, который оказался по каким-то критериям лучше. Если у тебя «гипотезы», а не «требования», то ты с ними поступаешь другим образом: не столько «удовлетворяешь», сколько «проверяешь и постепенно корректируешь».

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

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