Исследование визуализации бизнес-процессов при проектировании интерфейса системы управления сборкой и развертыванием ПО

1. Введение

Системы управления процессами сборки и развертывания программных продуктов, основанные на методологии CI/CD (Continuous Integration / Continuous Delivery), представляют собой автоматизированные инструменты для интеграции, тестирования и развертывания изменений в коде. Непрерывная интеграция (CI) позволяет разработчикам регулярно вносить изменения в общий репозиторий, где они автоматически тестируются и собираются, что минимизирует риски ошибок и упрощает процесс отладки. Непрерывная доставка (CD) обеспечивает автоматическое развертывание обновлений на различных средах, включая продуктивную, что ускоряет выпуск новых версий продуктов и повышает их стабильность [1].

Частое обновление цифровых продуктов становится критически важным фактором в условиях современного рынка, где пользователи ожидают оперативного внедрения новых функций и исправления ошибок. Системы CI/CD играют ключевую роль в этом процессе, обеспечивая автоматизацию и сокращая время между разработкой и выпуском обновлений. Это повышает эффективность работы команд разработчиков и удовлетворенность конечных пользователей [2].

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

Использование систем CI/CD способствует сокращению времени выхода продукта на рынок (Time-to-Market), что критично для конкурентоспособности компании. Автоматизация процессов позволяет быстрее реагировать на запросы пользователей и изменения рынка, снижая затраты времени и ресурсов на ручные операции [3].

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

2. Выявление пользовательских требований

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

Релиз-инженеры играют ключевую роль в обеспечении стабильности и эффективности процессов разработки и доставки программного обеспечения. Их взаимодействие с CI/CD системами напрямую влияет на скорость релизов, качество продукта и удовлетворенность команды, а также конечного пользователя цифровых продуктов. QA-тестировщики отвечают за проверку функциональности продукта, создают и выполняют тест-кейсы, а также интегрируют автотесты в CI/CD-процессы [4]. Они гарантируют, что продукт соответствует требованиям и готов к релизу, а также хранят артефакты тестирования для анализа и повторного использования. Руководители проектов, в свою очередь, управляют сроками релиза, отслеживают метрики выполнения процессов проверки и координируют работу команды разработчиков, тестировщиков и релиз-инженеров. Они выявляют узкие места в процессе, принимают решения о выделении дополнительных ресурсов и обеспечивают эффективную коммуникацию между всеми участниками. Вместе эти роли способствуют успешной доставке качественного продукта в установленные сроки. Понимание их опыта поможет создавать более удобные и функциональные интерфейсы, которые будут соответствовать их потребностям.

По результатам интервью были определены следующие потребности целевой аудитории:

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

Основные проблемы при работе с интерфейсами CI/CD:

• сложность настройки — интерфейсы CI/CD-систем часто сложны в начальной настройке, что требует значительных временных затрат и технической экспертизы;
• недостаточная интуитивность — множество систем имеют перегруженный интерфейс или недостаточно понятный UX, что приводит к ошибкам и увеличивает время на обучение новых сотрудников;
• ограниченная масштабируемость — некоторые инструменты плохо справляются с увеличением нагрузки или сложностью проектов, что вызывает сбои в процессах релиза;
• отсутствие унифицированного подхода — релиз-инженеры сталкиваются с проблемой интеграции различных инструментов и платформ в единую экосистему, что создает дополнительные сложности в управлении процессами;
• сложность и разрозненность результатов проверок — отчеты по тестированию часто хранятся в разных системах и в некомфортном для чтения формате, что затрудняет анализ результатов.

На основании выявленных требований и проблем были сформулированы ключевые критерии для проектирования нового интерфейса системы CI/CD. Особое внимание было обращено на автоматизацию рутинных задач, повышение прозрачности процесса, удобства восприятия информации и централизованное хранение артефактов. Эти аспекты легли в основу разработки альтернативного варианта визуализации процесса релиза, который был предложен для сравнительного тестирования c общепринятым подходом к визуализации бизнесс-процессов в инструментах CI/CD, использующих нодовые связи между этапами и шагами процесса [5].

3. Эксперимент

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

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

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

Каждому респонденту давалось 3 задания в прототипе, использующем общепринятую визуализацию (А), и 3 задания в исследуемом интерфейсе с новой визуализацией (В). Для исключения влияния последовательности, задания в интерфейсах A и B выдавались респондентам в случайном порядке.

Во время выполнения заданий измерялось время, требуемое на изучение материалов и принятие решения о продолжении или остановке процесса, а также количество ошибок в принятии решения. По итогу выполнения заданий пользователям задавался вопрос о субъективной удовлетворенности интерфейсами по метрике CSI (Customer Satisfaction Index) от 0 до 10.

4. Результаты

В эксперименте приняло участие 88 человек. По результатам эксперимента было выявлено, что в разрабатываемом интерфейсе процесса релиза (B) количество допущенных ошибок меньше, чем в интерфейсе с общепринятым подходом к визуализации (А) (медиана 1, уровень доверия 98,86%, точечный ДИ 1 против  медианы 2 сек, 98,86%, точечный ДИ 2): p-value = 0,00001% (посчитан с помощью теста знаков: 15 положительных разностей при 76 ненулевых разностях) α = 0,0133 при двусторонней проверке.

Также с помощью теста Уилкоксона была доказана гипотеза о том, что при использовании предлагаемого интерфейса (B) процесса релиза субъективная оценка удовлетворенности выше (медиана оценки 8, 99% ДИ 7 — 8), чем при общепринятом подходе к визуализации процесса релиза (А) (медиана оценки 6, 99% ДИ 5-6), величина эффекта по тесту Уилкоксона  0.728, 99% ДИ 0,412-1. p-value = 0,0000000026 (W-критерий = 2851 при 84 ненулевых разностях) α = 0.01 при двусторонней проверке.

По результатам пилотного теста была обнаружена обратная корреляция между количеством неверно принятых решений и оценкой субъективной удовлетворенности использованием. В основном эксперименте гипотеза оказалась статистически значимой на уровне α = 0,02: rs(176) = -0.317, Z = -4.1975, p-value = 0,000013 при левосторонней проверке с поправкой на непрерывность. ДИ на уровне доверия 98% (-0,47)–(-0,145).

Гипотеза о влиянии подхода визуализации процесса релиза на скорость выполнения заданий получила статистически незначимый результат на уровне α = 0.04, W = -826, Z = -1.7175, p-value = 0,08589 при двусторонней проверке с поправкой на непрерывность и на повторяющиеся ранги. Величина эффекта теста Уилкоксона -0.2109, 99% ДИ -0,463-0,041.

5. Заключение

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

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

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