Анатолий Левенчук – Системное мышление 2024. Том 2 (страница 30)

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

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

Главное тут:

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

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

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

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

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

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

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