Текст книги "Системное мышление 2024. Том 2"

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

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

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

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

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

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

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

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

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