Рассмотрим артефакты 5-го процесса ГОСТ Р 56939-2024.
5.5.3.1 Регламент управления недостатками ПО должен содержать:
- порядок идентификации недостатков ПО;
- порядок управления недостатками ПО, включающий сведения о действиях, выполняемых при выявлении, устранении, тестировании, принятии решения об окончании работы с недостатком (закрытии недостатка).
5.5.3.2 Регламент управления запросами на изменение ПО должен содержать:
- порядок идентификации запросов на изменение ПО;
- порядок управления запросами на изменение ПО, включающий сведения о действиях, выполняемых при осуществлении запроса на изменение, тестировании, принятии решения о закрытии запроса на изменение.
Даже если явно это не прописано, на практике в командах действуют устоявшиеся правила об исправлениях, обзорах кода, тестировании правок и закрытии тикетов. Если это так, то внедрение РБПО — хороший повод их формализовать и записать в регламент. Скорее всего, существующие процессы при этом мало модифицируются, и регламент не внесёт дополнительные сложности в работу команды. Случай, когда каждый делал, что хотел, я не рассматриваю :)
У нас нет именно документа-регламента, т.к. мы пока не планируем проходить сертификацию, но есть заготовленные чек-листы для различных типов задач. Если до этого дойдёт, то думаю, эти чек-листы как раз и станут основой регламента. Как я понимаю, основная идея регламента — не пропустить этап (например, тестирование) и быть уверенным, что если задача закрыта, то значит она сделана. Для этого и нужны чек-листы.
Пример одной нашей заготовки, из которой формируется задача, когда выходит новая версия IDE Qt Creator. Т.е. на основании этой заготовленного чек-листа ставится задача провести работы по проверке совместимости PVS-Studio с новой версией Qt Creator и в случае необходимости что-то доработать. Ссылки заменил на жирный шрифт.
Описание всех указанных ниже действий можно найти в документации. В случае возникновения вопросов можно обращаться к ___. На выполнение задачи стоит закладывать не менее двух дней, т.к. часто бывают неожиданные сюрпризы. Начинать стоит только после появления дистрибутива по этой ссылке.
Примечание. Ниже не описание задачи. Как и что делать описано отдельно во внутренней статье. Это именно чек-лист, чтобы что-то не забыть. То, что вне контекста отдельные пункты смотрятся непонятно, это нормально.
Шаблон этой задачи (чек-лист)
✅Узнать требуемую версию Qt
✅Заложить новые компоненты на наше зеркало
✅Qt (Windows, Linux, macOS)
✅Qt Creator (Windows, Linux, macOS)
✅Добавить новую версию Qt в сборочное окружение
✅Windows-контейнер
✅Linux-контейнер
✅Сборочный сервер на macOS
✅Добавить CMake пресет для новой версии
✅Фиксы по коду (Windows, Linux, macOS)
✅Оттестировать новую версию на всех платформах:
✅Windows
✅Linux
✅macOS
✅Добавить новую версию в manifest плагина (extension_manifest.json)
✅Добавить / модифицировать тесты
✅Код-ревью с ___. При его отсутствии (на усмотрение тимлида)
✅Модифицировать pipeline сборки на сервере:
✅Добавить новую версию
✅Убрать прошлую
✅Проверить и актуализировать документацию по разработке плагина
✅Добавить упоминание новой версий в документации плагина
✅Удостовериться, что новая версия плагина добавляется в дистрибутив
✅Добавить новую версию плагина на страницу beta-загрузок - задача