Сценарий выполнения вариантов использования

Когда слышишь ?сценарий выполнения вариантов использования?, первое, что приходит в голову — это, наверное, аккуратные диаграммы в каком-нибудь Visio или бесконечные таблицы в Excel, где всё расписано по шагам: ?Пользователь нажимает кнопку, система открывает окно?. В теории звучит здорово, но на практике, особенно в нашей сфере — производстве электротехнического оборудования, — эта самая теория часто разбивается о простой вопрос: ?А что, если кнопка залипла, а в сети просел??. Многие коллеги, особенно те, кто приходит из чисто IT-сектора, делают ошибку, рассматривая сценарий как нечто статичное, финальное, почти священный текст. На деле же это живой инструмент, который должен пахнуть не чернилами, а машинным маслом и лаком для обмоток. Особенно когда речь идёт о проектировании интерфейсов для систем управления высоковольтными комплексами, как те, что мы разрабатываем для подстанций. Тут каждый шаг сценария — это не просто ?открыть окно?, а цепочка физических процессов, которые нужно предусмотреть, и последствий, которые нельзя игнорировать.

Где теория встречает реальность: наш контекст

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

Этот случай заставил нас полностью пересмотреть подход. Мы перестали писать сценарии сразу в деталях. Сначала мы стали проводить сессии с технологами и сервисными инженерами, например, из команды, работающей с оборудованием OOO Шэньхэн Энергетическое Оборудование. Их экспертиза в области передачи и распределения электроэнергии бесценна. Они не думают ?потоками данных?, они думают ?состояниями контакторов?, ?временем срабатывания защиты?, ?перегревом обмотки?. И именно эти сущности должны стать ключевыми актёрами в наших сценариях, а не абстрактный ?Пользователь?.

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

Дьявол в деталях: от макета до протокола Modbus

Ещё один частый провал — это разрыв между тем, как сценарий описан, и тем, как он реализован в коде и ?железе?. Мы однажды здорово обожглись на заказе для одного сетевого оператора. Сценарий для настройки уставок релейной защиты был написан безупречно, с учётом всех ролей и подтверждений. Но когда дело дошло до интеграции с физическими контроллерами, выяснилось, что запись нового значения в устройство занимает не 100 мс, как мы предполагали, а от 800 мс до 2 секунд в зависимости от загрузки шины. Наш сценарий, построенный на мгновенном отклике, привёл к тому, что оператор, не видя быстрого подтверждения, тыкал кнопку ?Применить? несколько раз, отправляя в устройство одну и ту же команду с разными временными метками. Контроллер воспринял это как противоречивые инструкции и ушёл в ошибку.

Пришлось экстренно вносить изменения. В сценарий добавили состояние ?Ожидание подтверждения от устройства? с прогресс-баром и жёсткой блокировкой интерфейса. Более того, мы прописали в документации к сценарию техническое ограничение: ?Блокировка интерфейса длится до получения квитанции по протоколу Modbus RTU, но не более 3 секунд. При превышении таймаута — переход на сценарий обработки ошибки связи?. Теперь такие технические нюансы мы закладываем в сценарий с самого начала, на этапе обсуждения с инженерами по аппаратной части. Именно они лучше всех знают, как ведёт себя, скажем, вакуумный выключатель под управлением нашего контроллера и сколько времени занимает его цикл отключения.

Кстати, о документации. Мы отказались от громоздких текстовых описаний для каждого шага. Вместо этого используем гибридную форму: краткое описание шага, ожидаемый результат, а в соседней колонке — ссылка на спецификацию API или даже на фрагмент кода драйвера для конкретной платы управления. Это позволяет и разработчикам, и тестировщикам, и конечному эксперту по оборудованию видеть одну и ту же картину, но со своей профессиональной точки зрения. Особенно важно это при описании сценариев для сложных операций, таких как комплексные испытания ячеек КРУ, где последовательность действий критична.

Не только счастье: сценарии для исключительных ситуаций

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

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

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

Инструменты и артефакты: что остаётся в портфеле

Не буду скрывать, мы перепробовали кучу инструментов для описания сценариев: от классических UML-инструментов до Confluence и даже Miro. Со временем пришли к простому выводу: лучший инструмент — тот, который не мешает и позволяет быстро вносить правки после обсуждения с инженерами. Часто это оказывается просто структурированная таблица в том же Confluence, но с жёстко заданными колонками: ?Шаг?, ?Действие пользователя/системы?, ?Данные?, ?Состояние оборудования?, ?Возможные ошибки и реакция?. Главное — чтобы эта таблица была живой, и у любого члена команды, от проектировщика схем до монтажника на объекте, была возможность оставить комментарий прямо в ячейке.

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

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

Обратная связь и эволюция: сценарий — не догма

Финальный и, пожалуй, самый важный урок: сценарий выполнения не высечен в камне после подписания ТЗ. Он должен эволюционировать вместе с продуктом и, что ключевое, на основе обратной связи с реальной эксплуатацией. Мы наладили простой процесс: сервисные инженеры, которые выезжают на пусконаладку или обслуживание, например, оборудования от OOO Шэньхэн Энергетическое Оборудование, имеют доступ к базе наших сценариев. Если в полевых условиях они сталкиваются с ситуацией, которую сценарий не покрывает, или находят более оптимальную последовательность действий, они ставят пометку.

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

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