Повышение качества проектов с помощью Rational Team Concert 3.0 и ODC: Часть 1. Классификация и валидация дефектов

В этой статье объясняется, как использовать функции IBM Rational Team Concert версии 3.0 для сбора данных Orthogonal Defect Classification (ODC) в целях дальнейшего анализа. В этой первой статье цикла описываются шаги, необходимые для обеспечения процесса ODC в среде IBM Rational Jazz с точки зрения возможностей инструментария для сбора данных ODC. Во второй статье мы расскажем, как создать набор оценочных диаграмм и сделать их доступными для всех членов группы в среде Rational Team Concert.

Предварительные условия

Чтобы следовать рекомендациям этой статьи, нужно иметь установленный сервер Rational Team Concert 3.0 и соответствующим образом настроенный Eclipse-клиент Rational Team Concert. Понадобятся также разрешения на изменение определения процесса.

Преимущества ODC

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

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

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

• Находим ли мы надлежащие дефекты во время каждого вида деятельности?
• Где обычно кроются дефекты?
• Что не охвачено тестированием?
• Как меняется качество исходного кода и тестирования с течением времени?
• Привлекаем ли мы должный уровень внимания клиентов?
• Успешно ли мы прогрессируем с точки зрения полноты своего кода?
• Достигли ли мы более высокой стабильности своих продуктов?

ODC в действии

Весь процесс классификации и оценки ODC четко определен и состоит из четырех основных этапов, показанных на рисунке 1.

Этот процесс охватывает следующие мероприятия, которые проводятся в указанном порядке.

1. Классификация. На шаге классификации осуществляется сбор данных ODC. Для сбора данных требуется участие группы в двух основных функциях: Податель (Submitter) и Ответчик (Responser). Роль подателя обычно принимает на себя тестирующий, в то время как функции ответчика реализуют члены группы разработки. Классификация ― это постоянный процесс присвоения соответствующих атрибутов дефектным компонентам.
2. Валидация. Этот шаг должен выполняться квалифицированным специалистом с подходящим набором знаний по проекту и в области ODC. Проверяющий должен обеспечить обратную связь с группой по результатам обзора классифицируемых дефектов.
3. Оценка. С точки зрения ODC оценка сосредоточена на отношении между атрибутами ODC и другими данными, связанными с дефектом, такими как компонент, в котором обнаружен дефект, или степень его серьезности. Часто это означает либо анализ тенденций по входящим дефектам по определенному атрибуту ODC, либо анализ, основанный на количестве дефектов с определенным набором атрибутов в другом атрибуте ODC.
4. Действие. Это этап реализации мер, определенных в результате анализа классифицированных дефектов.

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

Концепции классификации дефектов

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

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

Деятельность (Activity)

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

Пусковой механизм (Trigger)

Условие, которое выполнялось, когда дефект был обнаружен, и строго зависит от вида деятельности. Если деятельность зависит от конкретного проекта, то набор триггеров остается неизменным.
 

Последствия (Impact)

Оценка последствий дефекта для клиента.

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

Цель

То, что было исправлено
 

Тип дефекта

Природа исправления
 

Квалификатор

Непосредственная причина дефекта
 

Источник

Идентифицирует происхождения цели, в которой обнаружен дефект.
 

Возраст

История цели
 

Примечание.
Носитель каждой роли собирает определенный поднабор данных. Rational Team Concert должен быть настроен так, чтобы способствовать разделению этих ролей. Это одна из наших задач.

Rational Team Concert и классификация данных о дефектах

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

Чтобы реализовать сбор данных ODC в Rational Team Concert, нужно дополнить артефакт рабочего элемента Rational Team Concert, определив специальные атрибуты (это стандартная возможность Rational Team Concert). Это идеально соответствует простоте модели данных ODC, которая сфокусирована на четко определенном наборе атрибутов, связанных с дефектом.

Чтобы включить сбор данных ODC, необходимо настроить тип рабочего элемента Defect. Для этого запустите Eclipse-клиент Rational Team Concert с выбранным определением проекта или шаблоном в редакторе конфигураций процессов. Вам придется работать с разделом Work Items конфигурации процесса:
Project Configuration > Configuration Data > Work Items

Перечисления

Во-первых, нужно добавить необходимые перечисления для атрибутов ODC. Процесс создания нового перечисления приведен в следующем примере ODC Activity:

1. Откройте редактор Enumerations, в открывшейся вкладке перейдите в меню Choose enumeration to edit и нажмите Add.
2. Появится диалоговое окно, показанное на рисунке 2, в котором можно указать имя и идентификатор перечисления. После ввода информации и нажатия кнопки OK новое перечисление становится доступным для редактирования.

Теперь можно определить литералы перечисления и порядок их следования, добавив эти данные в список литералов перечисления.

3. Нажимая кнопку Add Literal для каждого перечисления, можно определить литералы, в том числе "Unassigned" (не присвоено).
4. Затем в разделе Enumeration присвойте параметрам Default Literal и Unassigned Literal значение Unassigned, как показано на рисунке 3.

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

Созданные перечисления используются как тип специальных атрибутов дефектов ODC.

Специальные атрибуты

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

1. Откройте меню Types and Attributes и убедитесь, что выбран тип рабочего элемента Defect.

2. Найдите раздел Attributes редактора Types and Attributes и выберите Show only custom attributes.
3. Нажмите кнопку Add.
4. В новом окне (см. рис. 5) введите необходимую информацию для специального атрибута ODC Activity, включая соответствующее перечисление и тот же идентификатор, который использовался для соответствующего перечисления.

Рисунок 5. Создание нового специального атрибута

5. Повторите шаги 1 и 2 для остальных атрибутов ODC.

Настройка редактора отображения дефектов

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

1. Откройте раздел Types and Attributes, проверьте, выбран ли параметр Defect, убедитесь, что в поле Work Item Types выбран элемент Defect и проверьте, какой ID редактора отображается в разделе Work Item Editor. Рисунок 4 иллюстрирует конфигурацию типов и атрибутов.
2. Откройте Editor Presentations и выберите соответствующее представление дефекта.
3. Нажмите кнопку Add Tab и введите значения Title, Layout и ID в соответствующие разделы (см. рис. 6).
4. Нажмите кнопку OK.

5. Нажмите кнопку Add Section, назовите новый раздел ODC Submitter и выберите один из вариантов.
6. Повторите предыдущий шаг, добавив раздел ODC Responder.
7. В разделе ODC Submitter добавьте представления для ODC Activity, ODC Trigger и ODC Impact. Кнопка Add Presentation отображает диалоговое окно для создания представления. В разделе Attribute-based Presentation выберите соответствующий атрибут и выберите Enumeration из выпадающего списка Kind. При желании можно ввести заголовок, описание и идентификатор.

8. В разделе ODC Responder добавьте ODC Target, ODC Defect Type, ODC Qualifier, ODC Age и ODC Source.
9. Создайте новый образец дефектов и убедитесь, что вкладка ODC и ее разделы созданы правильно.

Зависимые перечисления

Во вкладке источника дефектов ODC могут отражаться и зависимости между атрибутами ODC. Одна взаимосвязь между ODC Activity и ODC Trigger показана в разделе Submitter. Другая, между ODC Target и ODC Defect Type, ― в разделе ODC Responder.

Возможные значения ODC Trigger зависят от текущего значения ODC Activity. То же можно наблюдать и в случае пары ODC Target и ODC Defect Type. Отношениями между ними можно управлять в функции Value Sets редактора Attribute Customization. Чтобы определить набор зависимых значений, необходимо создать новое определение набора значений Dependent Enumerations и выбрать перечисления. Для каждого выбора из исходного перечисления можно отметить значения, которые должны быть доступны в наборе значений целевого перечисления, если это значение выбрано. Значение Unassigned должно быть выбрано всегда во избежание проблем при инициализации. На рисунке 8 приведен пример ODC Activity и зависимость ODC Trigger.

Валидация ODC

Вкладку ODC в редакторе дефектов можно использовать для валидации ODC. Ей можно воспользоваться, когда требуется добавить общий раздел, где можно хранить другие данные. Дополнительные атрибуты указывают, выполнена ли валидация, и если да, то на каком уровне (перечисление значений валидации ODC: None, ODC Submitter, ODC Responder и ODC Submitter and ODC Responder).

Можно также добавить поле ODC Comments, чтобы снабдить источник и владельца сведениями о дефекте. На рисунке 9 показан этот раздел с полями Validation и Comments для обратной связи, а на рисунке 10 ― результат в Defect Editor.

Рисунок 10. Полное расширение редактора дефектов для отслеживания и валидации данных ODC

Заключение

ODC - это эффективный способ классификации дефектов, который экономит значительное количество времени на каждом этапе проекта, но только при правильной реализации и правильном использовании. Решающее значение для успеха имеет корректная интеграция этого процесса с платформой разработки. Как видно из этой статьи, Rational Team Concert 3.0 можно расширить таким образом, чтобы легко адаптировать схему ODC к рабочим элементам дефекта и действиям по валидации. В следующей статье этого цикла мы опишем метод введения в Rational Team Concert поддержки этапа анализа ODC.

В следующей статье этого цикла из двух статей объясняется, как добавить в Rational Team Concert 3.0 поддержку этапа анализа ODC.

Повышение качества проектов с помощью Rational Team Concert 3.0 и ODC: Часть 2. Дополнение ODC-анализа специализированными отчетами BIRT