ibm doors что это
О практике использования системы управления требованиями IBM DOORS в «НАМИ»
Алексей Баринов, заведующий отделом интеграции электронных систем ФГУП «НАМИ»
Рис. 1. Общий вид интерфейса программы IBM DOORS
Года два назад мы начинали работать с одним из наших европейских партнеров, вместе с которым выбирали систему для управления требованиями к электронике и электрическим компонентам автомобиля. Партнер использовал технологии IBM Rational, в частности IBM DOORS, для управления требованиями и, учитывая положительный опыт, мы тоже решили попробовать использовать это решение. Европейский партнер вел базу требований, а мы со своей стороны участвовали в их согласовании и необходимой корректировке. После этого был успешно осуществлен перенос базы требований, и все дальнейшее управление велось уже на нашей стороне.
Качество требований зависит не только от инструментов, но и от того как простроен процесс управления требованиями. Определение процессов взял на себя наш европейский партнер. Мы имели доступ только к той части процессов, которая касалась нас. Но процессы взаимодействия, структура проекта и структура требований определялись нами совместно.
Если говорить про этапность проекта, надо сказать, что процесс согласования требований в рамках нашего взаимодействия занял чуть больше времени, чем мы ожидали, так как они затрагивали реальную ответственность НАМИ перед партнером и партнера перед НАМИ в части количества и качества предоставляемой информации и тайминга. Но, как только мы согласовали эту часть, мы достаточно быстро начали работать с инструментом. Обучение как таковое нам не требовалось – наш партнер оказывал консультации там, где это было необходимо.
Рис. 2. Пример скрипта на языке DXL.
Когда назрела необходимость расширения возможностей DOORS с помощью скриптов DXL (DOORS eXtension Language), мы обратились за помощью к службе технической поддержки IBM. Нам достаточно быстро предоставили похожие примеры использования языка, а далее наши программисты самостоятельно адаптировали их под наши требования.
Хотел бы также отметить, что в НАМИ над проектом работал в основном молодой коллектив, который не был скован привычками делать все на бумаге. Поэтому работа с требованиями изначально велась в системе DOORS.
Конечно, систему управления требованиями мы в основном используем пока только в нашем направлении электрики и электроники. В работе с другими направлениями и партнерами официальным документом является скан в формате PDF, поэтому от документальной версии требований нам пока не уйти.
Однако надо признать тот факт, что многие наши партнеры, в основном западные, присылают требования именно в формате DOORS. Это позволяет нам сразу загрузить их в базу и начать работать с ними. Таким же, образом западные партнеры получают их от нас. Подобный подход позволяет значительно сэкономить время.
Помимо экономии времени важен фактор снижения ошибок. Не секрет, что на проектах по созданию сложных систем объем требований огромный. При этом, часть требований являются общими для разных подсистем, а другая часть требований — индивидуальны для конкретной подсистемы.
Допустить ошибку, работая на бумаге с таким объемом требований, очень легко. А цена ошибки может быть достаточно высока. Например, вы находитесь на стадии испытаний, а тут вдруг обнаруживается ошибка в требованиях, которая вынуждает вас возвратиться в самое начало и начать вновь переделывать многие вещи.
Возможности IBM DOORS позволили нам применить методы валидации и верификации требований. Мы тем самым избежали наличие дублирования информации и различного рода неточности, уложившись в сроки проекта.
Говоря о перспективах применения систем управления требованиями в НАМИ, можно сказать, что на текущий момент наше направление электроники – самое передовое, оно при этом достаточно молодое в плане возраста сотрудников и отличается скоростью развития. Мы первыми начали использовать такой системный подход, и я очень надеюсь, что мы сможем решить задачу масштабирования нашего опыта на другие направления нашей организации. Мои коллеги видят преимущества и нюансы каждого из подходов и думают над тем, как все же перенять наш опыт, чтобы всем в конечном итоге работать с единой базой требований и процессов.
Государственный научный центр Российской Федерации ФГУП «НАМИ» основан 16 октября 1918 года как первый научно-исследовательский институт в области автомобильной теории и технологии. «НАМИ» является современным научно- исследовательским экспериментальным центром развития производства для проектирования, конструирования и испытаний автомобильных платформ. ГНЦ РФ ФГУП «НАМИ» также является представителем Российской Федерации в Техническом комитете 22 «Дорожный транспорт» Международной организации по стандартизации.
Семейство IBM Engineering Requirements Management DOORS
Решение для управления требованиями помогает собирать информацию, отслеживать, анализировать и контролировать процессы разработки систем и сложных ИТ-приложений
Преимущества IBM DOORS Family для вашего бизнеса
IBM Engineering Requirements Management DOORS® Family — это приложение для управления требованиями, предназначенное для оптимизации обсуждения требований, совместной работы над ними и их проверки в масштабе организации и цепочки поставок. С его помощью можно создавать взаимосвязи, отслеживать зависимости, предоставлять различным командам инструменты для совместной работы практически в режиме реального времени, а также обеспечить контроль версий и управление изменениями. IBM DOORS Family — это масштабируемое решение, улучшающее управление проектами и затратами для достижения поставленных бизнес-целей. С его помощью нашим клиентам удалось сократить стоимость разработки на 57%, ускорить вывод продуктов на рынок на 20% и снизить затраты на обеспечение качества на 69%.
Преимущества
Сокращение затрат
Инструмент, специально разработанный для повышения эффективности управления требованиями, позволяет на 57% снизить затраты на разработку и на 69% — затраты на обеспечение качества.
Масштабируемая поддержка
Обеспечьте возможность расширения — вплоть до сложных глобальных проектов. Предусмотрены различные уровни проектов и папок для упрощения навигации независимо от объема базы данных.
Ускорение выхода на рынок
Эффективная классификация и визуализация требований позволяют ускорить вывод продуктов на рынок на 20%. Функции связывания путем перетаскивания повышают трассируемость, что позволяет сократить время реагирования на изменения на 50%.
Повышение производительности
Исключение ручных процессов и таблиц при отслеживании требований. Одновременная работа с документами с использованием настраиваемых представлений и функций совместной работы с документами.
Основные возможности Requirements Management DOORS Family
Отзывы
« Именно интеграция различных заинтересованных лиц и перевод всех на единую платформу помогли в конечном счете обеспечить отслеживаемость и навести мосты между командами Infosys, ее клиентами и партнерами. »
Управление требованиями к IT-проектам
Добрый день, уважаемое хабросообщество!
Я уже давно являюсь читателем этого замечательного ресурса и вот, наконец, решил попробовать и свои силы. Я заметил, что тема управления проектами на Хабре освещена довольно широко в соответствующем блоге, а вот об управлении требований ничего найди не удалось. Что ж, пришло время восполнить этот пробел!
Введение
В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами. Сокращение затрат возможно как с использованием более дешевого сырья и материалов, дешевой рабочей силы, оптимизации процессов, так и их автоматизации. Автоматизация не ведет к стопроцентному сокращению затрат, но позволяет обрабатывать большее количество информации с меньшими затратами.
Основным инструментом автоматизации деятельности являются информационные системы. Информационная система — это совокупность информационного, математического, лингвистического, технического программного и другого обеспечения, а также персонала для оперативной подготовки информации для лиц, принимающих решения.
КИС поставляются как в коробочном варианте, который предлагает стандартные решения для автоматизации задач, так и позволяют создать необходимый набор функций самостоятельно в режиме конструктора. Кроме того, многие разработчики корпоративных систем предлагают услуги по адаптации коробочных решений к нуждам конкретного предприятия — услуги кастомизации.
Корпоративные системы являются продуктом интеллектуального труда, что позволяет им без больших материальных затрат легко тиражироваться и передаваться по каналам связи, в отличие от продуктов материального производства. Информационные продукты имеют гораздо большую возможность адаптации под нужные конкретного производства, в связи с чем встает задача получения исходной информации для разработки или адаптации информационной системы.
Разработка большой и сложной системы не может быть завершена за один подход — итерацию. Это может быть связано как с большой сложностью самой системы, так и со сложностью ее адаптации. Тем не менее, возможно уменьшить объем работы для разработчиков за счет повторного использования кода из одного проекта в другом. Для того, чтобы выявить возможность повторного использования кода необходимо найти требования, которые данный код реализуют. Такие требования очень часто встречаются в продуктах, автоматизирующих одну и ту же предметную область на разных организациях, например, бухгалтерский учет или документооборот. Задача повторного использования требований является одной из задач решаемых управлением требований.
Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта.
По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований.
Управление требованиями
Перед тем, как управлять требованиями разберемся, что такое требование и что такое управление требованиями и зачем это нужно.
Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта.
Требование — это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Требованием может быть возможность, которой система должна обладать и ограничение, которому система должна удовлетворять.
Распространенное программное обеспечение для управления требованиями
В настоящее время широкое распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.
Приведу краткие переводы основных функциональных возможностей приведенных систем, взятые с сайтов производителей.
IBM Rational Requisite Pro
IBM Rational/Telelogic DOORS
IBM Rational/Telelogic DOORS — семейство решений для управления требованиями и создания сложных наукоемких изделий (авиа, судостроение, поезда, ракеты, автомобили т.п.).
Первоначально DOORS разрабатывался только как средство управления требованиями в процессе разработки программного обеспечения. Однако идеи, заложенные в DOORS, оказались успешными и в настоящий момент система используется даже в кампаниях, которые не имеют отношения к разработке программного обеспечения, но вынуждены контролировать большой объем взаимосвязанной информации, например, при разработке инженерных систем.
Borland Caliber RM
Borland Caliber RM – это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. Borland Caliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц.
Другое ПО
Новый подход к управления требованиями
Как можно понять из приведенного выше обзора программного обеспечения для управления требованиям все оно базируется на одном принципе — человек, а в данном случае, аналитик, вводит требование в систему, смотрит, нет ли такого требования в системе уже. Если требование в той или иной формулировке уже присутствует в системе, то заново его не заносит, а отмечает, как дублирующее. В связи с тем, что поиск схожих требований вручную является сложной и трудозатратной задачей, которая требует постоянного участия аналитика, то в процессе управления требованиями именно ее стоит автоматизировать в первую очередь.
Чтобы реализовать возможность поиска и повторного использования требований необходима методика идентификации требований, представленных текстом на естественном языке. Тогда, представив требование не только как текст, но и совокупность некоторых концептов или лингвистических переменных станет возможным не только выполнять поиск сходных требований, но и использовать повторно созданные в процессе реализации требования артефакты. Под артефактами в данном случае не стоит понимать только исходный код, который реализует требование, но и жизненный цикл, которое оно прошло, т.е. код не всегда можно использовать повторно из-за специфики задач, но можно получить консультацию у его разработчиков. При разработке нескольких продуктов для одной предметной области это становится актуальной задачей. Например, при адаптации системы электронного документооборота на нескольких предприятиях часто возникает ситуация, что на разных предприятиях разные документы проходят одни и те же маршруты в процессе жизненного цикла и функциональность, которая реализует эти маршрутры может быть использована повторно, пусть и без полного копирования.
Предположим, что следующие требования описывают маршруты документов соответственно на предприятиях А и Б:
А —
Б —
Здесь видно, что под F и А имеются в виду документы, а B, C, D, E — их маршруты.
Рассчитав расстояние Хэмминга между этими двумя требованиями мы получим единицу, так как они различны только в одной позиции и, следовательно, при реализации требования Б стоит обратить внимание на требование А и его реализацию. Естественно, решение о повторном использовании принимает уже разработчик или другое лицо, принимающее решение, но уже хорошо, когда есть варианты, где можно подсмотреть реализацию.
Всем спасибо за внимание, жду комментариев.
Учебное пособие Первые шаги в Rational DOORS
Данное учебное пособие позволяет быстро познакомиться с базовыми возможностями IBM Rational DOORS для документирования и совместной работы с требованиями, а также трассировки требований в процессе их дальнейшего использования. Вы также познакомитесь с дополнительной опцией IBM Rational DOORS Web Access (веб интерфейс DOORS), который предоставляет всем заинтересованным сторонам возможность просматривать требования, отслеживать связи между ними и участвовать в обсуждениях требований в безопасной онлайн-среде.
Обзор
Практики по эффективному управлению требованиями имеют очень высокую степень влияния на успех разработки систем и продуктов. IBM Rational DOORS и IBM Rational DOORS Web Access предназначены для того, чтобы помочь вам совместно документировать, трассировать, анализировать требования и управлять их изменениями. Эти продукты также помогаю соответствовать индустриальным нормам и стандартам.
В этом учебном пособии демонстрируются преимущества использования IBM Rational Doors в процессе управления требованиями. В следующих разделах пособия описывается, как в DOORS могут быть выполнены следующие задачи:
Для получения максимального эффекта от данного пособия мы рекомендуем выполнять данные задания по порядку.
Организация пробного использования
Для организации пробного использования Rational DOORS и выполнения упражнений в даном учебном пособии вам понадобится установленное программное обеспечение IBM Rational DOORS и лицензия для пробного использования (если вы ее еще не приобретали).
Пример проекта предназначен исключительно для использования в этом пособии. Не следует развертывать его в производственной среде. Следуя описанным далее шагам, скачайте архив с учебным проектом AMR_tutorial_ru.dpa (см. раздел Скачать) и восстановите его в каталоге Пробное использование вашей базы данных Rational DOORS:
Рис. 1 Войдите в Rational DOORS при помощи учетной записи, которая позволяет создавать проекты
Рис. 2 Создайте новую папку при помощи обозревателя баз данных
Рис. 4 Выберите папку Пробное использование
Рис. 5 Найдите проект в файловой системе
Рис. 6 Восстановите проект «Система АСП 1»
Документирование, классификация и анализ требований
Для успешного управления требованиями начните с их документирования таким образом, чтобы в них было легко разобраться. В Rational DOORS требования организуются иерархически, что позволяет документировать требования точно так же, как это делается в обычных документах.
Дерево навигации отражает структуру требований. Табличное представление требований позволяет просматривать и добавлять дополнительную информацию к требованиям, с использованием неограниченного числа атрибутов.
DOORS создавался для работы с документами, содержащими требования, любых размеров. Доступ к базе данных с требованиями могут одновременно получать несколько пользователей, которые могут работать с требованиями без возникновения конфликтов.
Требования описывают то, что пользователи ожидают получить от некоторого продукта, системы или сервиса.
В этом учебном пособии используется пример проекта в компании, которая планирует создать систему для автоматического снятия показаний счетчиков (система АСП). Компания разрабатывает решение для считывания показаний счетчиков потребления воды и предоставляет веб сервисы для работы с собранными данными. Система автоматического сбора показаний счетчиков создаются с целью снижения операционных расходов поставщиками воды и для более точного и быстрого получения информации о количестве израсходованной воды.
Прежде чем начать использовать управлять требованиями необходимо их хорошо задокументировать. Документы с требованиями могут включать в себя такие пункты, как:
Просмотр структуры файлов в обозревателе базы данных Rational DOORS.
После запуска DOORS вы увидите обозреватель базы данных, при помощи которого вы можете перемещаться между проектами, папками и модулями базы данных требований, как показано на Рис. 7.
Рис. 7 Обозреватель базы данных
Обратите внимание на иерархическую структуру данных: на самом верхнем уровне находится название базы данных (по умолчанию, DOORS Database), под ней следуют проекты и папки, как показано на Рис. 8
База данных может содержать несколько проектов. Проект определяет область работ и предоставляет способ организации или разбиения информации. Проект в базе DOORS не обязательно должен соответствовать реальному проекту.
Для организации документов удобно использовать папки, которые могут создаваться любым пользователем.
Рис. 8 Структура базы данных
Откройте в учебном проекте папку 01 Требования.
Документирование требований в формальных модулях DOORS
В базе данных DOORS информация о требованиях хранится в виде формальных модулей, как показано на Рис. 9. Например, компания, которая занимается разработкой системы АСП, для этих целей может создать отдельный проект. Информация о проекте системы АСП может храниться в следующих модулях:
Помимо этих модулей компания может использовать и другие модули для более детального разбиения требований проекта на уровни.
Рис. 9 Содержимое формального модуля
Модуль имеет вид обычного документа с форматированным текстом, в котором информация иерархически организована в разделы и подразделы. Он также имеет вид электронной таблицы, в столбцах которой отображаются атрибуты объектов.
Информацией в модулях можно гибко управлять: каждый объект (требование) может иметь собственные значения атрибутов, ссылки и историю.
Пользователь может получать информацию из различных источников и импортировать ее в Rational DOORS. Вы можете создавать модули, добавлять в них информацию, а также переносить информацию между инструментами для управления требованиями. При работе с модулями используется один из трех режимов редактирования, которые представлены в Таблице 1.
Таблица 1. Режимы редактирования модуля
| Режим редактирования | Описание |
|---|---|
| Только чтение | В этом режиме вы можете просматривать модуль, но не редактировать его. |
| Исключительное редактирование | Вы можете редактировать модуль, но другие пользователи могут только просматривать его. |
| Совместное редактирование | Вы можете редактировать модуль одновременно с другими пользователями. |
Строка состояния внизу окна модуля отображает какой режим редактирования используется в данный момент. После открытия модуля вы можете изменять режим редактирования.
Откройте формальный модуль «Требования заинтересованных сторон» и попробуйте изменить режим редактирования
Просмотр объектов и атрибутов, содержащих информацию о требованиях
Объект состоит из основного текста, например, заголовка или требования, и дополнительной информации, например, о том, кто его создал, или для какого релиза он запланирован. Вся эта информация хранится в атрибутах.
Внутри модуля объекты организованы в иерархическую структуру с нумерацией заголовков. Благодаря такой структуре модуль выглядит как обычный документ.
Автоматическая нумерация заголовков работает так же, как и в текстовом редакторе (например, в Microsoft Word). Нумерация дает возможность легко ориентироваться в структуре информации модуля. Нумерация автоматически изменяются при изменении структуры документа, например, при удалении объектов или добавлении новых.
Таблица 2. Атрибуты главного столбца в представлении модуля.
Перемещение по модулю при помощи обозревателя модуля.
Поиск объекта по его идентификационному номеру
Редактирование главного столбца объекта
Редактирование значений атрибутов объекта
Создание нового требования
Создание нового раздела в модуле
Просмотр информации с различных перспектив
Разным людям необходимо видеть разную информацию. К примеру,
Вы можете создавать различные представления информации в модулях, ориентированные на различных пользователей. Каждое представление отображает некоторый набор объектов и атрибутов, имеющихся в модуле.
Рис. 10 Использование представлений для быстрого просмотра необходимой информации
На Рис. 10 показаны два представления модуля с требованиями.
Переключение между представлениями
Вы можете быстро получать различные срезы данных при помощи переключения представлений.
Рис. 11 Выбор атрибута для отображения в столбце
Настройка цветового выделения в главном столбце в зависимости от значения атрибута.
Рис. 12 Заголовок и текст объекта отображаются в одном столбце
Рис. 13 Цвет шрифта и фона объекта может зависеть от значения атрибута
Поскольку значение атрибута Состояние теперь можно понять из цведа текста главного столбца, столбец Состояние больше не нужен.
Обновление существующего представления
Анализ связанных данных
Взаимодействие на основе обсуждений
Просматривающие модуль сотрудники могут обмениваться мнениями о всем модуле или каком-либо принадлежащем ему объекте посредством обсуждений.
В Rational DOORS вы можете обсуждать отдельные объекты или модуль в целом вместо того, чтобы создавать отдельные документы с рецензиями или путем создания специальных текстовых атрибутов в модуле. Обсуждения являются одним из свойств объектов и модулей.
Обсуждения модулей и объектов внутри модулей можно создавать, просматривать и изменять.
Создание темы обсуждения
С объектом требования 69 была связана значительная по объему работа. Инициируйте обсуждение, чтобы понять, работает ли команда до сих пор над этим требованием.
Рис. 14 Окно «Новое обсуждение» отображает объект 69
Отображение обсуждения в столбце
Добавьте новый столбец для отображения обсуждений.
Рис. 15 Обсуждения отображаются в столбце
Трассировка между требованиями, элементами моделей и тестами
Выполнение трассировки между уровнями требований очень важно, особенно если вам необходимо демонстрировать соответствие своих разработок стандартам и нормам. Трассировка также дает возможность легко анализировать влияние изменений в требованиях на требованиях других уровней. Для создания трассировочной связи между двумя требованиями в Rational DOORS вы можете просто перетащить одно требование на другое, как будет показано в данном разделе. Для того, чтобы перейти между связанными объектами, щелкните на значок связи, а затем на объект, к которому вы хотите перейти. В результате откроется связанный объект, как описано в разделе Переход между связанными объектами.
При помощи фильтра можно быстро найти требования, которые не связаны с другими, что помогает выявить неучтенные требования. Вы можете настроить специальные представления, позволяющие трассировать требования к нескольким документам с требованиями, а также к вариантам использования, элементам моделей, тестам и работам, которые хранятся в других инструментах.
Создание трассировочных связей
В DOORS вы можете создавать связи к информации, хранящейся, как внутри инструментов IBM Rational, так и в других источниках и инструментах. Благодаря этой возможности DOORS является чрезвычайно полезным инструментом для анализа и принятия решений.
Связи обеспечивают возможность трассировки. Например, вы можете легко проверить, что создаваемый вами продукт соответствует требованиям пользователей. Для этого вы можете связать требование пользователя с возможностью системы, которая его реализует. Возможности системы можно связать с верификационными тестами. При этом, тест-кейсы могут создаваться и храниться в другом инструменте, например, в IBM Rational Quality Manager.
Вы сможете переходить по связям в обоих направлениях. В случае неудачного прохождения теста можно проследить, какие требования имели к нему отношение, пройдя по связи между тестом и возможностью системы. Далее от возможностей системы можно перейти по связям к требованиям пользователей.
Связи помогают управлять изменениями. Вы можете быстро проследить влияние изменения одного артефакта (например, требования) на все отстальные в вашей системе.
Рис. 17 Перекрестно-связанная информация
Для примера представьте, что отдел проектирования сообщает вам, что они не смогут использовать солнечную батарею, как вы изначально предполагали. Вы можете трассировать связи от батареи наверх к соответствующим требованиям, а затем вперед, к другим возможностям системы АСП, которые зависят от использования солнечной батареи. Таким образом, вы сможете быстро оценить, к чему приведет отсутствие солнечной батареи и принять обоснованное решение о том, следует ли использовать обычную батарею или же вложить дополнительные денежные средства, время и людские ресурсы, чтобы использовать именно солнечную батарею.
Создание трассировочных связей между требованиями разного уровня
Допустим, что требование заинтересованных сторон 38 необходимо связать с системным требованием 44. Для того, чтобы создать связь, выполните следующие шаги:
Переход между связанными объектами
Индикатор связи можно использовать для перемещения между связанными объектами.
Информация на основе трассировочных связей внутри одного модуля, между модулями и даже с другими инструментами могут быть представлены в специальных столбцах модулей в Rational DOORS. Просматривая информацию о трассировке, вы можете выявить требования, не вытекающие из требований заинтересованных сторон, пропущенные требования, следить за соответствием стандартам и проводить полный анализ трассировки.
Рис. 18 Трассировка и соответствие стандартам на разных уровнях требований
Для просмотра необходимой информации можно быстро переключаться с помощью сохраненных представлений.
Изучите представления трассировки
Теперь, когда вы знаете, как работать с представлениями, внимательно изучите представления трассировки, которые уже определены в модулях с требованиями.
Анализ влияния и отслеживание изменений
Управлять изменениями абсолютно необходимо, поскольку изменения оказывают влияние на проект, приводя порой к увеличению ресурсов, времени и бюджета. Rational DOORS интегрируется с инструментами управления изменениями, что позволяет реализовать процесс формального контроля изменений, который может быть настроен под нужды вашей организации.
Изменения в требованиях могут затрагивать связанные требования, элементы моделей и тесты. Rational DOORS может автоматически сообщать о таких изменениях, визуально выделяя связи с измененными объектами, на которые необходимо обратить внимание. Просматривая такие уведомления, вы с большей вероятностью не пропустите объекты, которые необходимо обновить для приведения в соответствия с последними изменениями.
Отслеживайте изменения с помощью индикаторов изменений и всплывающих подсказок
Rational DOORS отслеживает изменения всех объектов в базе данных и хранит их историю. Например, когда вы меняете значение атрибута какого-либо объекта сохраняется как новое, так и старое значение.
Можно легко увидеть, кто был автором изменений, а также по какой причине они были сделаны, просматривать историю модуля, объекта или пользовательских сеансов для модуля.
В DOORS также присутствую индикаторы изменений, которые позволяют быстро отслеживать изменения.
Цвет индикатора, символ и всплывающая подсказка отражают статус изменения объекта.
Таблица 3. Иконки индикатора изменений и их описания
| Индикатор изменений | Описание |
|---|---|
 | Во время текущего пользовательского сеанса вы создали объект, но не сохранили изменения. |
 | Во время текущего пользовательского сеанса вы редактировали объект, но не сохранили изменения. |
 | Со времени создания последней контрольной версии модуля кто-то редактировал объект и сохранил изменения. |
 | Объект не был изменен со времени создания последней контрольной версии модуля. |
 | Объект был удален до создания последней контрольной версии модуля либо история еще не загружена. |
 | Объект был удален после создания последней контрольной версии; история загружена. |
Обратите внимание:
Вы можете настроить какие изменения будут отображаться с помощью индикатора изменений и храниться в истории базы данных. Например, если вам не важно, что какой-то пользователь изменял определенный атрибут, вы можете отключить индикаторы изменений для этого атрибута.
Использование контрольных версий для создания мгновенных снимков модуля
Контрольная версия является версией модуля, доступной только для чтения. Она отражает состояние модуля в определенный момент времени.
При создании контрольной версии модуля вы создаете его копию, недоступную для изменения пользователями.
История модуля в контрольной версии
В контрольной версии хранятся следующие части истории модуля:
Изменение истории объекта
Отслеживание изменений в модулях на основе подозрительных связей
Изменения объектов в Rational DOORS могут повлиять на актуальность связанных объектов. Когда один из связанных объектов изменяется, объект на другом конце связи помечается как имеющий подозрительные связи. Модули можно проверять на наличие подозрительных связей и просматривать информацию об изменениях, которые сделали связи подозрительными, что показано на Рис. 19. Следующие шаги демонстрирую как можно сделать связь подозрительной.
Создание подозрительной связи
Рис. 19 Индикаторы подозрительных связей и информация о них
Очистка подозрительных связей
Рис. 20 Очистка подозрительных связей
Интеграция с другими инструментами на основе OSLC
Требования лежат в основе процесса проектирования, разработки и тестирования. По этой причине инструмент управления требованиями должен обеспечивать возможность связывать требования с артефактами в других инструментах, которые используются в ходе жизненного цикла разработки систем и программного обеспечения. Rational DOORS предоставляет возможности интеграции со множеством других инструментов для разработки систем и программного обеспечения как от IBM, так и от других вендоров.
IBM реализует стратегию интеграции между инструментами на основе открытых сервисов взаимодействия в жизненном цикле OSLC (подробнее см. www.open-services.net). Rational DOORS использует OSLC для интеграции с инструментами проектирования, управления тестированием и испытаниями, управления портфелем проектов и управлением изменениями. DOORS является одним из центральных продуктов в интегрированном решении IBM Rational для разработки систем и программного обеспечения, которое включает в себя инструменты и практики для проектирования систем и встраиваемого программного обеспечения.
Например, интеграция между Rational DOORS и Rational Quality Manager позволяет улучшить трассировку между требованиями и тестами, что является важным пунктом в процессе управления качеством. Когда инструменты интегрированы, команды, которые занимаются управлением требованиями, тестированием и испытаниями могут наладить тесное взаимодействие и гарантированно проверять создаваемые продукты на соответствие всем требованиям.
Команды управления требованиями и тестированием получают от интеграции множество других дополнительных возможностей.
В итоге проект выигрывает от всех этих действий, поскольку появляется возможность работать с прошедшими валидацию требованиями и заранее написанными на их основе тест-кейсами. Это также позволяет валидировать поведение созданной системы и соответствие стандартам на более ранних этапах жизненного цикла проекта. (В разделе Ссылки есть ссылка на видео-демонстрацию, в которой показана интеграция между Rational DOORS и Rational Quality Manager).
В качестве другого примера можно привести интеграцию Rational DOORS с IBM® Rational® Rhapsody®. Определение требований является критической частью жизненного цикла разработки, но, несмотря на это, требования системного уровня зачастую оказываются неполными или противоречивыми. Плохо сформулированные или неверно истолкованные требования могут быть улучшены в ходе моделирования при помощи таких инструментов, как Rational Rhapsody.
Rational Rhapsody предоставляет возможности для моделирования с использованием языков SysML (Systems Modeling Language) и UML(Unified Modeling Language), позволяя анализировать и валидировать требования, а также заранее проверять их на основе исполняемых прототипов. Это приводит к созданию более качественных продуктов. Модель в Rational Rhapsody специфицирует и описывает систему, которую вы собираетесь создать.
При помощи визуализации требований в Rational Rhapsody можно достичь лучшего понимания желаемого поведения готовой системы. Законченная модель выступает в роли исполняемой спецификации. Результатом моделирования поведения системы является скорректированный набор требований, которые были провалидированы с помощью исполнения модели. Такая валидация помогает избежать ошибок в спецификациях, которые могут привести к большим денежным затратам на следующих этапах процесса разработки.
Моделирование требований дополняет традиционный анализ требований тремя способами:
Связывая требования с элементами модели, можно легко отслеживать какие требования уже учтены в модели. Rational Rhapsody может быть интегрирован с Rational DOORS с помощью продукта Rhapsody Design Manager, который использует OSLC для связывания требований с элементами модели. В разделе Ссылки имеется ссылка на видео с демонстрацией данной интеграции. Помимо этого, Rational Rhapsody и Rational DOORS могут быть интегрированы с использованием Rational Rhapsody Gateway. Для получения дополнительной информации перейдите в разделе Ссылки на документацию по Rational Rhapsody.
Взаимодействие с заинтересованными сторонами через веб-интерфейс
Веб-интерфейс Rational DOORS обеспечивает прозрачность требований для всех заинтересованных сторон и помогает им отслеживать связи между требованиями. Веб-интерфейс предоставляет им безопасную онлайн-среду для проведения обсуждений требований. С использованием веб-интерфейса бизнес-пользователи, разработчики, инженеры по качеству, инженеры по тестированию, маркетологи и поставщики могут просматривать и обсуждать требования, созданные другими, не устанавливая для этого клиентское приложение DOORS на своих компьютерах. В результате все заинтересованные стороны, где бы они не находились, смогут быть в курсе последних требований к проекту и связанных с ними артефактов.
Заинтересованные стороны могут просматривать требования
Благодаря наличию веб интерфейса все заинтересованные стороны могут в любой момент получить доступ к последним требованиям проекта и информации о трассировочных связях. Они могут просматривать базу данных Rational DOORS используя дерево каталогов в веб интерфейсе. При открытии документа или модуля дерево каталогов сворачивается, позволяя просматривать содержимое модуля на центральной панели. В каждый момент времени строка навигации позволяет вам соориентироваться в каком месте базы данных вы сейчас находитесь. Строка навигации также позволяет легко вернуться на более высокий уровень иерархии.Панели можно перемещать и распологать удобным образом для динамического просмотра частей больших документов.
При помощи определенных в Rational DOORS представлений вы можете гибко просматривать требования, другие артефакты и их атрибуты. При переключении между представлениями информация в веб интерфейсе автоматически обновляется на основе настроенных представлений. Как только какое-то требование выделяется на центральной панели, веб-интерфейс Rational DOORS тут же отображает значения атрибутов выделенного требования в боковой панели.Когда вы ищете в документе определенное требование, вы получаете результаты из базы данных Rational DOORS.
С помощью веб-интерфейса Rational DOORS можно одновременно просматривать несколько документов с требованиями или даже разные части одного документа в разных панелях, которые можно разместить удобным для просмотра образом. В веб-интерфейсе в документах с требованиями отображаются все виды данных: форматированный текст, графика, таблицы, и OLE-объекты.
Другой важной возможностью веб-интерфейса DOORS является использование трассировки. Для исследования связей каждого объекта, вы можете выбирать как входящие, так и исходящие связи, а также открывать несколько связанных документов или различные разделы одного документа.
Запустите веб-интерфейс Rational DOORS и перейдите к модулю требований
Изучите содержимое модуля.
Смените отображаемые данные, переключив представление. Вы видите только те объекты и значения атрибутов, к которым имеете доступ.
Рис. 21 Индикатор обсуждений для объектов
Рис. 22 Ответьте на комментарий, кликнув на «Новый комментарий»
В окне Новый комментарий введите комментарий и закройте окно. В результате комментарий отобразится в обсуждении.
Заинтересованные стороны могут обсуждать требования
По ходу работы с требованиями различным участникам команды требуется их обсуждать друг с другом, уточнять понимание требований, и предлагать улучшения или изменения. С помощью обсуждений пользователи веб-интерфейса Rational DOORS могут общаться и взаимодействовать друг с другом, а также взаимодействовать с пользователями клиентского приложения Rational DOORS. С каждым требованием может быть связано произвольное количество тем для обсуждений. Автор темы может в любое время закрыть обсуждение или вновь продолжить дискуссию. Обсуждения модулей и объектов внутри модулей можно создавать, просматривать и изменять.
В панели обсуждений пользователи могут добавлять комментарии по теме обсуждения. Иконки со значком обсуждения визуально отмечают какие требование обсуждают участники команды. С каждым комментарием связана информация об авторе, дате и времени комментария.
Заинтересованные стороны могут взаимодействовать на протяжении всей цепочки поставок
Rational DOORS предлагает множество способов обмена данными. Вот некоторые из них:
Поскольку Rational DOORS поддерживает стандарт OMG ReqIF, требования можно легко перености на другие сервера Rational DOORS и в другие инструменты управления требованиями, в том числе используемых в других организациях.
Рис. 23 Совместная работа над требованиями с двумя поставщиками
ReqIF поддерживает обмен требованиями с возможностью их обновления в первоначальной базе. Обмен может производиться как для одного, так и для нескольких модулей. Для определения состава экспортируемых данных могут использоваться представления модулей.
Вы можете блокировать объекты или атрибуты, если не хотите их обновлять при получении обновленных версий требований. Для передачи документов в одном направлении вам, вероятно, не понадобится блокировать объекты, поскольку вы не ожидаете получения обновленных версий документов. Однако вам может понадобиться блокировать все объекты, которые вы передавли исключительно для чтения или для создания ссылок на них. Вы также можете блокировать выборочные атрибуты или объекты. Такая необходимость может возникнуть, если вы работаете с несколькими поставщиками и хотите обновлять свои версии документов на основе обновленных версий.
В примере на Рис. 23 данные из исходной базы данных были переданы двум поставщикам. Каждый поставщик получил пакет ReqIF. Пакет может содержать определенные права доступа или представления данных. Каждый поставщик изменил несколько разделов данных и отослал их обратно владельцу исходной базы данных. Владелец объединил изменения, получив обновления от обоих поставщиков.