Система контроля этапов жизненного цикла ПО

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

BTS — это программные продукты, основанные на использовании базы данных и контролирующие все этапы жизненного цикла ошибок в ПО: от инициализации до момента исправления. Конечная цель BTS - улучшение менеджмента разработки программных продуктов.

Для компании по производству ПО внедрение BTS — своего рода политический ход. Информация о проекте, известная ранее лишь начальнику и нескольким программистам, становится доступной широкому кругу разработчиков и менеджеров. В результате ведение проекта превращается в реально контролируемый процесс, что позволяет в ряде случаев предотвратить появление заведомо невыполнимых прожектов ("death marсh" в терминологии Эда Йордана). Более того, облегчается коммуникация между специалистами отдела качества (QA) и программистом при работе над конкретными ошибками.

Практически все существующие стандарты на разработку и качество ПО содержат требования к регистрации (logging), классификации, регулярному пересмотру (reviewing) и процедуре устранения ошибок. Примером может служить FDA стандарт [1], соответствие которому обязательно при разработке ПО для системы здравоохранения США. Таким образом, даже сравнительно небольшая команда разработчиков состоящая всего из нескольких человек, может оказаться перед фактом, что система BTS будет жизненно необходима для развития и внедрения разрабатываемого продукта на рынках, требующих соответствия международным стандартам.

Программа класса BTS представляет собой базу данных с удаленным доступом, располагающуюся, как правило, на сервере локальной сети, и клиентских приложений установленных на машинах сотрудников компании. Единая база данных обеспечивает централизованный доступ ко всем документам (программам, спецификациям, графикам, планам и т.п.). Информация о каждом шаге работы с документом становится доступна всем заинтересованным лицам. Например, если документ помечен как "ошибка" (bug), то об этом будет оповещена вся группа разработчиков. Документ, помеченный как "запрос" (requirement), попадет в почтовые ящики отдела маркетинга и технической поддержки. Механизм контроля обращений различных пользователей к документу позволяет получить полную картину того, кем из сотрудников была найдена ошибка и кто из клиентов ожидает увидеть в следующей версии то или иное новшество.

Система может быть сконфигурирована так, чтобы пользователь мог подключиться к системе извне, посредством авторизированного доступа (web-enabled). Или, к примеру, вынести bug-report форму на Web-страничку компании, предоставив, таким образом, клиентам удобный способ сообщить об ошибке.

Основные функциональные особенности BTS

• Тип базы данных (database engine). Пользователям наверняка захочется самим выбрать тип базы данных. Автор имеет весьма печальный опыт работы с MS-Access, установленной на Windows NT Server 4.0. Даже при объеме базы в 3 Мбайт и десяти пользователях каждые три-четыре месяца требовалось восстанавливать информацию с резервной копии. В тоже время втрое большая база данных под управлением SQL-Server на сервере SGI Origin успешно справлялась с вдвое большим количеством пользователей.
• Настраиваемость (customization). Как правило, пакеты BTS содержат несколько эталонных баз данных. Однако нередко приходится пренебречь готовым примером и конфигурировать все на свой вкус.
• Оповещение пользователей (notification). Обычно это электронная почта, поэтому хорошо, если система поддерживает протоколы MAPI и SMTP.
• Клиент аппликация (client application). Если в вашей компании используются не только платформы Wintel, но и UNIX или QNX, то лучше всего задействовать пакет, где в качестве клиента применяется обычный браузер: Netscape или MSIE.
• Интеграция с другими системами. Прежде всего пакет BTS должен иметь интерфейсы к системам контроля за версиями; инструментам управления конфигурациями (software configuration tools) таким как PVCS [2], SourceSafe [3] или ClearCase [4]; средам разработки, например, Visual Studio [5]; средам автоматизированных проверок (automated testing) [6], [7].
• Отчеты (reports). Практически все системы BTS содержат минимальный набор форм (templates) для создания всякого рода статистических отчетов. Эта опция особенно понравится менеджерам, поскольку позволяет строить, например, диаграммы количества ошибок, допущенных каждым программистом (или найденных тестировщиком); графики зависимостей количества ошибок от различных версий продукта компании-разработчика; диаграммы количества жалоб, приходящих от определенных групп клиентов и т.п. Автору приходилось работать с пакетом Seagate Crystal Reports [8], который позволяет создать самый замысловатый отчет из данных, полученных из MS Access, SQL, FoxPro, Paradox и т.д.
• Динамичность (scalability). Возможность легко подключить другую базу данных или перенести уже существующую на любой компьютер локальной сети компании.
• Безопасность (security). Пока еще редкая, но в недалеком будущем необходимая особенность. Имеется в виду поддержка таких методов шифрования потоков данных как Secure Socket Layer (SSL), полезная при удаленном доступе к базам данных через Internet. Насколько автору известно, на сей момент эта возможность поддерживается только в продукте TeamTrack [9].
• Возможность подсоединения файлов любого типа к отчетам (attachment). Свойство, позволяющее при внесении в базу данных отчета об ошибке, подсоединить к нему картинку экрана в момент проявления ошибки (screenshot), исходный код модуля или библиотеки, email клиента и т.п.
• Система запросов базы данных (database queries). Совершенно необходимая особенность. Базы данных ошибок имеют свойство стремительно разрастаться и при наличии нескольких сотен (a, в случае большого проекта, тысяч) элементов инструмент создания запросов просто необходим.
• Наличие протокола изменений (history). Необходим для фиксации всех изменений, произошедших с данным элементом БД. Эта особенность, как правило, помогает контролировать потоки информации, точно фиксировать, когда и через чьи руки проходил данный отчет об ошибке. Такая возможность присутствует обычно в большинстве BTS.

Из опыта работы с BTS

Автору приходилось работать с системой для MS-Access, установленной на отдельной машине, доступ к которой имел исключительно персонал подразделения управления качеством ПО. Этот подход, безусловно, устарел, но когда создавалась система (а было это в начале 90-х гг.), систем BTS как таковых на рынке еще не существовало.

Рис. 1. "Жизненный цикл ошибки".

Другим, более удачным примером, был опыт конфигурирования и работы с пакетом Visual Intercept [10] компании Elsinore Technologies. В этом случае выбор определили в первую очередь такие качества продукта как интеграция с Microsoft SourceSafe [3] и наличие удобного инструментария для создания запросов и отчетов. Однако эта система не лишена недостатков. Поначалу предполагалось, что база данных на основе MS-Access обладает достаточной надежностью и производительностью. Однако уже через пару месяцев стало очевидно, что система не справляется с возрастающей нагрузкой. Пришлось перейти на базу SQL типа, также поддерживаемую пакетом Visual Intercept.

В третьем случае наша компания разрабатывала продукт на UNIX платформах SGI и, одновременно, широко использовала Windows 95/NT. Решено было внедрить платформно-независимую систему ClearDDTS [11] компании Rational Software, использующую в качестве клиента обычный браузер. Однако при всех своих достоинствах ClearDDTS поражала сложностью настройки. Конфигурирование скриптов (ClearDDTS практически целиком написана на Perl) и общее администрирование оказалось весьма нетривиальной задачей. В результате система так и не была окончательно адаптирована под нужды отдела ПО. И хотя она уже второй год верой и правдой служит команде разработчиков, к сожалению, многие полезные возможности остались невостребованными.

Для начала рассмотрим группы основных пользователей системы.

• Команда отдела качества ПО, которая ежедневно проверяет текущее состояние BTS.
• Менеджер группы программистов. Раз в 2 — 3 дня он просматривает поступившие отчеты об ошибках, выставляет приоритеты их устранения, определяет исполнителей и сроки работы.
• Рядовой программист. Раз в два дня просматривает переданные на починку ошибки.
• Группа технической поддержки. В отдельных случаях инженер технической поддержки может вносить отчеты об ошибках, обнаруженных клиентами. Хотя, как правило, этой группе пользователей дается возможность только просматривать отчеты.
• Менеджмент. Текучка обычно мало интересует эту группу пользователей им, как правило, важна общая статистика ошибок. Исключение составляют ошибки, препятствующие своевременному выходу версии (show-stopper bugs).
• Пользователи бета-версий и рядовые пользователи. При работе с web-enabled BTS сообщение об ошибке заносится посредством заполнения формы отчета в специально созданной для этой цели страничке на Web-сервере компании.
• Маркетинг. Только просмотр отчетов.

Важным элементом в BTS является определение жизненного цикла ошибки (bug-life cycle) и соответствующий сценарий использования системы. Одно из многих возможных решений иллюстрирует диаграмма, представленная на рис. 1.

NEW. Форма bug-report заполнена, сообщение об ошибке внесено в базу данных. Вероятнее всего, это будет сделано персоналом отдела качества (QA) или инженерами службы технической поддержки. Не исключено, что и программисты будут рады воспользоваться случаем известить начальство об обнаруженных ошибках коллег. Возможность сразу же закрыть сообщение, перевести его в состояние CLOSED, предусмотрена на случай, когда сообщение само по себе ошибочно.

ASSIGNED. Сообщение попадает к начальнику проекта (или лидеру группы), который определяет важность ошибки, присваивает ей соответствующий приоритет и решает как поступить с проблемой дальше:

• переслать программистам для исправления (RESOLVED), часто с указанием имени конкретного исполнителя;
• передать QA-специалистам (QA CHECKED) для перепроверки и/или уточнения сценария и условия воспроизведения ошибки;
• отложить в "долгий ящик" (POSTPONED), до лучших времен.

QA CHECKED. Перепроверив сообщение об ошибке, сотрудник отдела QA вправе "закрыть" проблему (CLOSED). Либо, удостоверившись в том, что неполадка действительно существует, возвратить ее ответственному за проект специалисту, подкрепив отчет дополнительными деталями.

POSTPONED. Исправление ошибки откладывается "до лучших времен" (в более поздних версиях). В обязанности QA группы входит помимо прочего регулярная проверка списка отчетов этого вида. Подобная ревизия особенно необходима перед выпуском очередной версии продукта. И как результат — ошибка возвращается программистам "на починку". Иногда к этому моменту, вследствие изменений исходного кода, ошибка исчезает. К примеру, проблематичный модуль попросту удаляется из проекта или целиком переделывается заново. В этом случае в результате очередной ревизии сообщение переводится в состояние CLOSED.

RESOLVED. Программисту дано задание исправить ошибку. Сделав требуемое, он передает результат QA группе на проверку (VERIFIED). Или, если исполнитель по тем или иным причинам не согласен с директивой руководства, он возвращает проблему на пересмотр начальнику (ASSIGNED). Например: конкретный разработчик не отвечает за модуль, содержащий ошибку, и не в состоянии ее устранить.

VERIFIED. Ошибка в руках у персонала отдела качества. Перепроверив программу и вновь обнаружив изъян, частенько, видоизмененный попыткой залатать дыру, отчет об ошибке возвращается начальству. Данную пересылку желательно сопроводить возмущенным комментарием типа "...до каких пор!". Если проблема решена, — с ней приходится расстаться (CLOSED).

CLOSED. Архив побед программистов. Случается, что ошибка, которую считали устраненной, дает о себе знать. В этом случае отчет о ней извлекается QA- командой для перепроверки (QA CHECKED).

Несколько комментариев

Один из важных принципов BTS: никто из пользователей не может удалить отчет из базы данных, ошибку можно перевести в разряд закрытых (CLOSED), но не удалить совсем.

При конфигурировании BTS стоит уделить внимание следующему набору критериев: воспроизводимость ошибки (100%, 50%, Random, Unknown); влияние ошибки на общую функциональность продукта (приоритет: Critical, Medium, Minor, Cosmetic); кем обнаружена ошибка (QA, клиент, бета-тестировщик);

Будущее систем BTS видится в развитии универсальных программных пакетов, объединяющих в себе такие интегрированные между собой инструменты разработчика, как вспомогательные средства отладки, система контроля версий, среда для автоматизированных проверок (automated testing tool). Примерами могут служить TestSuite [12] и QACenter [7].

Тема, которой мы коснулись в данной статье — лишь отголосок более глубокой и важной проблемы культуры разработки программного обеспечения номер 1, 1998 журнала "Открытые системы"), а стремительная эволюция такого инструмента разработчика, как bug-tracking systems, является неизбежным шагом на пути развития будущих технологий разработки ПО.

Литература