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

Обычно потребность в формализованном процессе управления ошибками не возникает при выполнении небольших проектов. Проект длительностью в 1-2 человеко-месяца вполне может обойтись и без него. Однако проекты большего объема, особенно если продукт развивается постоянно, нуждаются в подобном процессе. Начиная с некоторого момента, отсутствие формализации в управлении ошибками начинает ускорять ход разработки.

Проблемы, возникающие при отсутствии управления ошибками:

• -    Разработчики начинают забывать об ошибках. Такое часто бывает, если ошибок достаточно много. Двигаясь вперед, устраняя эти ошибки, он может пропустить некоторые из них, посчитав их низкоприоритетными, а потом забыть к ним вернуться.

• -    Тестировщики забывают проверять качество устранения ошибок. Если разработчик исправил ошибку и попросил тестировщика проверить это, то, во-первых, тестировщик уже может не помнить, в чем она состояла (или забыть детали) и, во-вторых, также может забыть выполнить проверку, переключившись на ошибки других разработчиков.

• -    Порядок устранения ошибок разработчиками некорректен. Довольно часто такое может быть, когда разработчику хочется устранять не те ошибки, которые являются важными с точки зрения заказчика или руководителя проекта. Если в команде мало разработчиков (1-2), то, они могут напрямую контактировать с пользователями, чтобы выяснять приоритет ошибок, но даже в этом случае они могут не знать всей полноты картины.

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

важными, а какие – нет, какие из них можно отложить, а каким надо уделить первоочередное внимание [1].

Внедрение формализованного процесса способно решить подобные проблемы

Основными участниками такого процесса являются:

• -    Тестировщик;

• -    Руководитель команды;

• -    Разработчики.

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

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

Ниже приведен общий порядок действий при обнаружении ошибки.

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

• -    Ген. подрядчик регистрирует найденную ошибку в системе отслеживания дефектов.

• -    Подрядные организации оперативно отслеживают появление ошибок в системе отслеживания дефектов.

• -    В случае недостаточности сведений об ошибке подрядная организация их запрашивает. Ошибка берется в производство в соответствии с ее приоритетом.

• -    После исправления ошибки и тестирования на собственном стенде подрядная организация согласовывает с ответственным представителем ген. подрядчика выпуск новой версии подсистемы с исправлением.

• -    В случае непрограммного исправления ошибки подрядная организация публикует в системе отслеживания дефектов порядок устранения ошибки.

• -    В установленные сроки подрядная организация подготавливает и выпускает исправление в соответствии с положениями регламента управления релизами.

• -    По согласованию с Генеральный подрядчиком разворачивается новая версия с исправлениями в тестовый контур [2].