Продолжим рассматривать артефакты 5-го процесса ГОСТ Р 56939-2024.
5.5.3.3 Артефакты реализации требований, подтверждающие реализацию управления недостатками ПО, должны содержать зафиксированные факты изменений, связанных с недостатками, включающие следующую информацию:
- уникальный идентификатор недостатка ПО;
- описание недостатка ПО;
- версию ПО (модуля ПО, компонента ПО), к которому относится недостаток ПО;
- приоритет выполнения действий с недостатком ПО;
- текущий статус обработки изменений, связанных с недостатками ПО.
5.5.3.4 Артефакты реализации требований, подтверждающие реализации управления запросами на изменение ПО, должны содержать следующую информацию:
- уникальный идентификатор запроса на изменение ПО;
- краткую характеристику запроса на изменение ПО;
- версию ПО (модуля ПО, компонента ПО), к которому относится запрос на изменение;
- приоритет выполнения действий с запросом на изменение ПО;
- текущий статус обработки запроса на изменение ПО.
Всё это само собой будет реализовано при аккуратном использовании, наверное, любого багтрекера (системы автоматизации для управления недостатками и запросами на изменение).
Каждой задаче (тикету) автоматически присваивается уникальный идентификатор. Краткая характеристика запроса на изменение ПО, естественно, должна присутствовать при постановке задачи. Если кто-то напишет в названии задачи "Сделать X", а в описании "см. subj", то за такое надо ..... ........ ........ (принять административные меры) и без регламента :)
Естественно, указывается версия ПО, модуля и т.д., когда описывается баг, чтобы его можно было воспроизвести. Ну или где какая новая функциональность нужна. Здесь вроде всё тоже очевидно. Достаточно просто сформулировать всё это в виде регламента и договориться, как что называется и нумеруется (см. четвёртый процесс в ГОСТ Р 56939-2024 и ГОСТ 19.103-77 — Обозначение программ и программных документов).
"Приоритет выполнения действий с запросом на изменение ПО". Кажется, в любом багтрекере необходимо установить уровень важности задачи/бага. Единственное, это хороший момент более чётко сформулировать, кто и как решает, каков будет этот приоритет. Этот пункт ещё пересекается с 23-м процессом "Реагирование на информацию об уязвимостях", но про это мы поговорим позже.
"Текущий статус обработки запроса на изменение ПО". Здесь каждый сам формирует статусы задач, теги, принципы смены этих статусов и какие комментарии надо писать в процессе работы над задачей. Думаю, самые важные моменты:
• задача не должна теряться;
• открыв задачу, любой член команды должен по описанию и комментариям понять, в чём её суть и что сейчас происходит с задачей;
• задача должна закрываться, когда она сделана и всё, что нужно, было проверено.