Оценка решений для отслеживания дефектов и изменений при помощи продукта ClearQuest от компании IBM Rational Software

Аннотация

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

Статья предназначена для менеджеров, администраторов и разработчиков, которые хотят воспользоваться преимуществами масштабируемого и надежного решения IBM Rational ClearQuest (версия 2003.06.00) для отслеживания дефектов и изменений. Предложенное решение может использоваться группой любого размера независимо от используемой ею платформы и ее географического места расположения.

О компании IBM Rational и ее решении полного жизненного цикла

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

IBM Rational Software - единственная компания, которая поставляет не только программное обеспечение, но и набор лучших методик и принципов работы, которые называются Rational Unified Process (RUP). Интегрированный набор программных инструментов охватывает весь цикл разработки ПО и предназначен для разработчиков, групп разработчиков и организаций.

Программное обеспечение IBM Rational ClearQuest предназначено не только для текущих потребностей в отслеживании дефектов и изменений. Оно является часть более широкого решения, которое называется Rational Team Unifying Platform (Унифицирующая платформа Rational для групп) и является интегрированным набором инструментов для совместной работы групп разработчиков.

Кроме IBM Rational ClearQuest, платформа IBM Rational Team Unifying Platform содержит следующие инструменты.

Платформа IBM Rational Team Unifying Platform обеспечивает тесную интеграцию указанных продуктов. Выбор между IBM Rational ClearQuest и IBM Rational Team Unifying Platform пользователь должен сделать самостоятельно.

Введение

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

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

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

Определение и документирование ваших требований

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

• Что вам нравится, а что не нравится в текущем инструменте для отслеживания дефектов и изменений?
• Какие функции обязательно должен иметь будущий инструмент? Расположите все требования в порядке их важности.
• Укажите сроки. В случае слишком быстрого перехода возможны такие риски как выбор неверного решения, лишняя трата времени в попытке оценить слишком много продуктов. Список требований поможет ограничить сферу поиска.
• Какие платформы должен поддерживать инструмент?
• Нужно ли предоставить доступ членам внешних групп, например, бета-клиентам и консультантам?

Сужение выбора

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

• Услуги. Насколько полезна и ответственна служба поддержки? Насколько она технически грамотна? Насколько она заинтересована в вашем успехе? Оказываются ли их услуги круглосуточно, то есть 7 дней в неделю и 24 часа в сутки? Возможно ли обучение? Может ли эта организация командировать своих сотрудников для помощи во внедрении?
• Стабильность компании. Это только что появившаяся компания, которая может завтра исчезнуть, или она работает уже давно? Каков уровень квалификации ее сотрудников в отслеживании дефектов и изменений?

Оценка и выбор

Итак, список сократился до 2-х или 3-х инструментов. Пора присмотреться к ним внимательнее и принять решение. Что они делают на самом деле? Может быть, их обещания - всего лишь пустая реклама? Это можно выяснить следующими способами.

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

Основные требования к отслеживанию дефектов и изменений

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

Регистрация изменений

Чтобы максимально повысить производительность и качество, заинтересованные лица должны иметь возможность предоставлять запросы на изменения удобно и быстро. Система отслеживания дефектов и изменений (далее DCT, Defect and Change Tracking) поддерживает предоставление и отслеживание различных типов запросов на изменение, а также позволяет разрабатывать уникальные схемы работы и бизнес-правила для различных типов запросов.

Готовое решение для разработки

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

Требования к многоплатформенному клиентскому интерфейсу

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

Ограниченный доступ к системе для пользователей без лицензий

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

Удобство использования

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

Отправка и изменение запросов на изменение по электронной почте

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

Поддержка множества типов запросов на изменение

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

Вложение файлов

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

Поддержка интернационализации и локализации

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

Автоматизация работы и обеспечение процессов

Чтобы максимально повысить эффективность работы, в системе отслеживания дефектов и изменений (DCT) должны быть автоматизированы все процедуры, которые можно автоматизировать. Эта система также должна обеспечивать общие процессы отправки, назначения, решения и проверки решений запросов на изменения на протяжении всего цикла разработки. Хорошее решение DCT может улучшить взаимодействие между различными ролями внутри группы, сократить количество сообщений электронной почты, собраний и конференций.

Автоматизация и настройка уведомлений по электронной почте

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

• изменено значения поля;
• изменен запрос на изменение;
• запрос на изменение оказался среди тех запросов, список которых получился в результате выполнения определенного запроса к базе данных.

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

Обязательные поля

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

Двустороннее связывание записей

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

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

Автоматическое обновление множества записей

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

Настройка обязательности выполнения процессов с помощью сценариев

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

• Установка начального значения поля
• Проверка содержимого поля
• Создание зависимого поля на основе данных, введенных пользователем
• Обнаружение повторяющихся записей
• Контроль доступа пользователей к некоторым изменениям запросов на изменения

Возможности настройки

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

Модуль настройки на основе графического интерфейса пользователя

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

Настраиваемые формы и поля

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

Настройка переходов состояний

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

Протестируйте изменения перед развертыванием

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

Открытый, задокументированный интерфейс API

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

Автоматическое распространение настроек на все платформы

Настройки должны автоматически распространяться на клиентов всех платформ, чтобы не требовалось выполнять дополнительную работу отдельно для каждой платформы. Например, добавленное администратором с помощью модуля настройки новое поле должно быть видно любому пользователю после того, как он войдет в систему, независимо от клиента - Windows, Web, Linux или UNIX.

Удобное применение настроек к нескольким проектам

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

Метрики: запросы, графики и отчеты

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

Настраиваемые отчеты, поддержка графиков и запросов

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

Готовые запросы, графики и отчеты

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

Удобный экспорт данных запросов и отчетов

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

Метрики для всех типов запросов на изменения

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

Метрики для менеджеров

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

• Сколько срочных дефектов еще не устранено?
• Равномерно ли распределены запросы на изменения между разработчиками?
• Увеличился или уменьшился поток запросов на изменения за последние 6 недель?

Персональные метрики

Менеджерам обычно нужно знать метрики всего проекта, а отдельным участникам проекта нужно знать метрики, которые показывают их объём работ и увеличивают их производительность. Например, система должна позволять автоматически показывать персональный список задач пользователя при каждом его входе в систему проекта.

Интеграция

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

Интеграция с инструментами для управления конфигурацией программного обеспечения

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

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

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

Интеграция с инструментами для управления требованиями

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

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

Интеграция с автоматизированными инструментами тестирования

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

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

Интеграция с инструментами для управления проектами

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

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

Масштабируемость

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

Готовые базы данных

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

Поддержка различных баз данных

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

Гибкие возможности перехода от одной БД к другой

Система должна позволять легко переходить от одной базы данных к другой и иметь для этого полноценные утилиты импорта и экспорта. Например, вы протестировали развертывание с применением СУБД Microsoft Access, а затем, когда начался проект, решили перейти к СУБД Oracle.

Поддержка распределенных баз данных

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

Вместе с решением для управления конфигурацией это дает полное решение для управления распределенными изменениями.

Администрирование пользователей и безопасность

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

Защита на уровне проекта

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

Защита на уровне полей

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

Возможность скрывать записи запроса на изменение

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

Гибкое администрирование пользователей

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

Отслеживание истории запросов на изменения

Система DCT должна постоянно регистрировать все изменения состояния запроса на изменение. Вы должны иметь возможность быстро увидеть, кто сделал изменение, что и когда было изменено.

Оценка поставщика

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

Опыт и знания

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

Отзывы клиентов

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

Качество поддержки в различных странах

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

Хорошая репутация и стабильность

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

Общая картина

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

Оценка по контрольному списку

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

Возможность или функция	Оцениваемый продукт 1	Оцениваемый продукт 2	Rational ClearQuest
Регистрация изменений
Готовое решение для разработки
Клиентский интерфейс для Windows, UNIX и Web
Ограниченный доступ к системе через Web для пользователей без лицензий
Интуитивно понятный, удобный для пользователей интерфейс
Отправка запросов на изменения по электронной почте
Изменение запросов на изменения по электронной почте
Вложение файлов в записи запросов на изменения
Интернационализация и локализация
Автоматизация работы и обеспечение процессов
Автоматическое уведомление по электронной почте
Настройка правил уведомления по электронной почте с помощью графического интерфейса
Поля: обязательные, необязательные, только для чтения
Логическое двустороннее связывание записей
Автоматическое обновление множества записей
Настройка обязательности выполнения процессов с помощью сценариев
Возможности настройки
Модуль настройки на основе графического интерфейса пользователя
Настраиваемые формы и поля
Настройка переходов состояний
Возможность протестировать настройки перед развертыванием системы
Открытый, задокументированный интерфейс API
Автоматическое распространение настроек на все клиентские платформы
Удобное применение настроек к нескольким проектам
Метрики
Настраиваемые запросы, графики и отчеты
Готовые запросы, графики и отчеты
Удобный экспорт результатов запросов и отчетов
Метрики для всех типов запросов на изменения
Метрики для менеджеров
Персональные метрики
Интеграция
Интеграция с инструментами для управления конфигурацией программного обеспечения
Интеграция с инструментами для управления требованиями
Интеграция с автоматизированными инструментами тестирования
Интеграция с инструментами для управления проектами
Интеграция с инструментами для управления процессами
Масштабируемость
Готовые базы данных
Поддержка нескольких стандартных баз данных
Гибкие утилиты для импорта и экспорта данных
Поддержка распределенных баз данных
Администрирование пользователей и безопасность
Защита на уровне проекта
Защита на уровне полей
Возможность скрывать записи запроса на изменение
Гибкое администрирование пользователей
Отслеживание истории запросов на изменения
Оценка поставщика
Глобальная круглосуточная техническая поддержка (7x24)
Услуги по консультированию на месте
Полные учебные программы
Стабильность компании
Отзывы о продукте

Заключение

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