Вы находитесь на страницах старой версии сайта.
Переходите на новую версию Interface.Ru

Borland CaliberRM 6.0

© Наталия Елманова
Эта статья была опубликована на сайте КомпьютерПресс 5'2004

31 марта текущего года корпорация Borland объявила о выпуске шестой версии системы управления требованиями Borland CaliberRM. В настоящей статье рассказывается о возможностях новой версии этого продукта и о первых впечатлениях от его применения.

Зачем нужно управление требованиями

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

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

 


CaliberRM 6.0 — взгляд производителя

Ниже приводится сокращенное интервью с Корне Хьюманом (Cornе` Human), менеджером, отвечающим за продажи в Европе линейки продуктов StarTeam и CaliberRM. Интервью было взято незадолго до выхода CaliberRM 6.0.

Наталия Елманова: Расскажите, пожалуйста, о назначении CaliberRM. Для России это новый продукт — ранее он был у нас практически неизвестен.

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

 

Корне Хьюман (Cornе` Human), менеджер по продаже в Европе продуктов StarTeam и CaliberRM

Корне Хьюман (Cornе` Human), менеджер по продаже в Европе продуктов StarTeam и CaliberRM

Н.Е.: Cложно ли создать такие шаблоны для CaliberRM, чтобы они генерировали документы в полном соответствии со стандартами и на языке той страны, для которой разрабатывается приложение?

К.Х.: Задача создания шаблонов проектной документации, соответствующей национальным стандартам и написанной на национальном языке, в CaliberRM решается очень просто. Можно создать шаблон Microsoft Word, содержащий разделы согласно стандарту, принятому в вашей стране, и включающий заранее заданный и повторно применяемый текст, который оформлен в соответствии со стандартами на техническую документацию (включая размеры и гарнитуру шрифта, оформление рисунков). CaliberRM содержит функцию Document Factory, которая предназначена для генерации документа на основе шаблона и данных о проекте, хранящихся в соответствующем репозитарии. При этом с помощью простейшего языка запросов можно описать, какие требования или типы требований должны быть включены в данный документ. Можно почти полностью автоматизировать генерацию таких документов.

Н.Е.: Может ли CaliberRM работать с нестандартными требованиями?

К.Х.: Да, конечно. В CaliberRM реализована концепция типов требований, которые могут быть самыми разнообразными — это требования к функциональному или к нефункциональному дизайну, к тестированию и др. Вы можете создать новый тип требований, если он вам нужен, а затем внутри него — необходимые вам требования, а внутри них, в свою очередь, — более детальные требования. Можно создать иерархию требований, и нестандартное требование будет ветвью в этой иерархии. Кроме того, у нас есть мастера для упрощения создания типов. Мы отдаем себе отчет в том, что эксперты по определению требований необязательно являются разработчиками (во многих случаях это просто пользователи). Главное — им нужно уметь формулировать то, что им требуется и почему. CaliberRM действительно очень легко применять обычным пользователям, что является его важным преимуществом перед конкурирующими продуктами.

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

К.Х.: В последние два года мы проявляем определенную активность в этом направлении, делая наши продукты более «глобализованными». Мы реализовали поддержку Unicode, поэтому в тексте требований могут применяться любые наборы символов и кодовые страницы, а соответственно и любой язык. Можно определять требования на русском языке, равно как и генерировать документы. В CaliberRM есть мастер создания тестов на основе требований, а если требования сформулированы на русском языке, то создать описания тестов и план тестирования на этом же языке.

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

Н.Е.: Как хранятся требования в CaliberRM и каким образом различные участники проекта получают к ним доступ?

К.Х.: Для реализации доступа к требованиям различных участников проекта мы применяем специальную архитектуру — Unified Server Architecture. Мы можем объединить CaliberRM и средство управления конфигурациями StarTeam в единой архитектуре и создать дополнения к средам разработки, в которых разработчик может обращаться к требованиям независимо от того, с какой частью проекта он работает. Все, что относится к одному и тому же проекту (документы, модели, код), хранится на одном и том же сервере. Можно осуществлять управление этими активами, организовывать документооборот — все артефакты проекта содержатся в общем репозитарии.

Н.Е.: Похоже ли это на то, что предлагает IBM/Rational?

К.Х.: В некоторой степени. Мы вышли на рынок одновременно с Rational, и набор продуктов и решений у нас имеет определенное сходство. Rational предлагает RUP (который является частично методологией, частично продуктом), но пока не предоставляет общий репозитарий, содержащий абсолютно все данные, относящиеся к проекту, хотя там работают и над этим. У нас лучшие технические позиции в этом отношении. Имея единый репозитарий, можно обращаться и к исходному коду, и к текстам, и к моделям, отслеживать все связи между ними в процессе разработки и каждый аспект этого процесса.

Н.Е.: Если требования уже определены, можем ли мы создать, например, предварительную версию модели данных или диаграммы классов?

К.Х.: Естественно. И еще в требованиях можно нарисовать диаграмму сценариев использования — обычно требования содержат такие диаграммы. CaliberRM может выполняться внутри среды Together Control Center, при этом он имеет доступ к диаграммам «сущность—связь», диаграммам сценариев использования и др.

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

К.Х.: В CaliberRM можно делить требования на части, описывать словарь терминов, создавать связь между требованиями. Кстати, если говорить о требованиях с точки зрения заказчика, то в версии CaliberRM 6.0 можно будет применять форматирование и добавлять графику.

Н.Е.: Можно ли скрыть от участников проектной группы те части проекта, которые для них не предназначены, например какие-то конфиденциальные данные заказчика?

К.Х.: Да, конечно. В CaliberRM реализованы средства защиты данных на основе ролей.

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


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

Технические требования

Технические требования

Особенности CaliberRM 6.0

Средство управления требованиями Borland CaliberRM было приобретено корпорацией Borland в начале 2003 года вместе с компанией Starbase, поскольку именно в это время компании-разработчики начали проявлять серьезный интерес к средствам управления жизненным циклом приложений, отличным от средств разработки приложений. На российском рынке CaliberRM до приобретения его компанией Borland был практически неизвестен, но на американском и европейском рынках он считался одним из лидирующих средств управления требованиями наряду с Telelogic DOORS и Rational Rose. О назначении и основных особенностях этого продукта можно прочесть в интервью с Корне Хьюманом, помещенном во врезке. Далее я расскажу о некоторых особенностях версии 6.0 и о своем первом впечатлении от этого продукта.

Пользовательский интерфейс

Интерфейс продукта показался мне вполне удобным, интуитивно понятным и реализованным очень качественно: четкие диалоги, простая навигация по дереву требований, никаких проблем с русскими шрифтами, раскладками клавиатуры и прочих неприятностей, которые уже стали привычными для пользователей продуктов IBM/Rational и Computer Associates. То же самое можно сказать и о программе установки как клиентской, так и серверной части. На мой взгляд, по дружественности интерфейса CaliberRM намного превосходит активно применяющийся в России Rational RequisitePro.

Единственная трудность, с которой мне пришлось столкнуться, — это поиск пункта меню File => New. Как оказалось, для администрирования (в том числе и для создания новых проектов) предназначено другое приложение — Framework Administrator (рис. 1). Это, в общем-то, разумно — ни к чему предоставлять административную функциональность конечному пользователю. Зато после создания нового проекта оказалось совсем нетрудно добавить в него заготовку очередного технического задания.

Рис. 1. Framework Administrator

Рис. 1. Framework Administrator

Поддержка русскоязычных формулировок

Говоря о применении средств поддержки жизненного цикла разработки приложений, ориентированных в определенной степени на документирование продуктов, следует учитывать, насколько продукт подходит к российским условиям. Технические задания у нас пишутся на русском языке (если, конечно, у вас не иностранный заказчик), поэтому требования и их описания, естественно, должны быть сформулированы именно на этом языке; кроме того, деление требований по категориям в российских государственных стандартах несколько отличается от аналогичного деления, принятого в западных методологиях. Как выяснилось, создать нужные русскоязычные категории требований и сами требования в CaliberRM совсем несложно (рис. 2).

Рис. 2. Русскоязычные требования и их категории

Рис. 2. Русскоязычные требования и их категории

Что еще более интересно — для некоторых типов требований можно создать свойства, определяемые пользователем, которые также могут быть русскоязычными (рис. 3 и 4).

Рис. 3. Создание свойств, определяемых пользователем

Рис. 3. Создание свойств, определяемых пользователем

Рис. 4. Отображение свойств, определяемых пользователем

Рис. 4. Отображение свойств, определяемых пользователем

Форматирование текста требований

Заметим, что обещания, данные Корне Хьюманом (см. врезку), были выполнены: в новой версии CaliberRM можно форматировать текст требований и добавлять в него таблицы и иллюстрации (см. рис. 4), а это, в свою очередь, позволяет использовать в требованиях диаграммы сценариев, состояний, потоков данных и иные диаграммы, которые любят создавать бизнес-аналитики, а также диаграммы классов и моделей данных — в общем, диаграммы всего, что может потребоваться при управлении требованиями.

Отчеты и иные документы

Отчеты по данным, хранящимся в репозитарии CaliberRM, можно получить в виде XML- или HTML-документа (рис. 5).

Рис. 5. Отчет по требованиям в формате HTML

Рис. 5. Отчет по требованиям в формате HTML

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

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

Другие особенности

Из прочих особенностей отметим наличие средств ведения дискуссий по требованиям и отслеживание изменений в требованиях, их типах и формулировке (рис. 6).

Рис. 6. Дискуссионный лист, связанный с требованием

Рис. 6. Дискуссионный лист, связанный с требованием

Отслеживание истории изменений требований — очень важная особенность, поскольку именно изменение требований и появление новых требований в процессе реализации проекта являются причинами выхода проектов за рамки бюджета и сроков. Эта функция представляется очень полезной: можно обязать пользователя при изменении уже созданных требований вводить комментарии к внесенным изменениям (рис. 7).

Рис. 7. История изменений требования

Рис. 7. История изменений требования

Кроме того, следует отметить возможность обработки событий, поддержку аутентификации пользователей с помощью LDAP-каталогов, средства интеграции с Borland StarTeam 6.0 (это средство организации коллективной работы над проектом было выпущено одновременно с CaliberRM, и о нем мы расскажем в следующий раз), с одним из самых популярных в нашей стране средств разработки Borland Delphi и с новой версией средства тестирования TestDirector 8.0 от компании Mercury Interactive.

Дополнительная информация

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме Borland

Рекомендовать страницу

INTERFACE Ltd.
Телефон/Факс: +7 (495) 925-0049
Отправить E-Mail
http://www.interface.ru
Rambler's Top100
Ваши замечания и предложения отправляйте редактору
По техническим вопросам обращайтесь к вебмастеру
Дата публикации: 31.10.05