© Наталия Елманова
Эта статья была опубликована на сайте КомпьютерПресс 5'2004
31 марта текущего года корпорация Borland объявила о выпуске шестой версии системы управления требованиями Borland CaliberRM. В настоящей статье рассказывается о возможностях новой версии этого продукта и о первых впечатлениях от его применения.
Какой бы ни была методология разработки при реализации того или иного проекта, этап определения требований существует всегда. В нашей стране, как правило, требования формулируются в таком документе, как техническое задание. Управление требованиями является, наверное, самой важной частью процесса разработки. Если требования сформулированы расплывчато, то в процессе реализации проекта приходится выполнять множество переделок — это связано с тем, что заказчик и исполнитель по-разному понимают нечеткие формулировки, а также с тем, что какие-то требования вообще не сформулированы. В результате исполнителю кажется, что заказчик "совсем обнаглел и сел нам на шею", а заказчику — что исполнитель "ну совершенно бестолковый".
В зависимости от методологии выполнения проекта формулировка требований или их модификация может производиться однократно или многократно. Кроме того, при проектировании приложения следует предусмотреть функции, необходимые для выполнения того или иного требования, а на этапе тестирования выявляется, удовлетворяет ли созданный продукт выдвинутым к нему требованиям.
Ниже приводится сокращенное интервью с Корне Хьюманом (Cornе` Human), менеджером, отвечающим за продажи в Европе линейки продуктов StarTeam и CaliberRM. Интервью было взято незадолго до выхода CaliberRM 6.0.
Наталия Елманова: Расскажите, пожалуйста, о назначении CaliberRM. Для России это новый продукт — ранее он был у нас практически неизвестен.
Корне Хьюман: Наши продукты предназначены для применения на различных этапах цикла разработки приложений. Они интегрируются в среды разработки, но в целом их основное назначение — повышение качества создаваемых приложений и эффективности процесса их разработки. При этом не столь принципиально, какая среда разработки применяется для создания приложения — предлагаемая Borland или какая-то другая.
Корне Хьюман (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 реализованы средства защиты данных на основе ролей.
К.Х.: Большое спасибо за интересную беседу. Хочется пожелать вам успеха на российском рынке — полагаю, он вполне возможен, поскольку ваши продукты могут составить достойную конкуренцию другим решениям для команд разработчиков, которые сейчас применяются в России.
Нередко требования формулируются просто в виде текстового документа, например технического задания. Однако в последнее время все большую популярность приобретают средства автоматизации управления требованиями, позволяющие не только сгенерировать нужный документ (в частности, то самое техническое задание) согласно стандартам, принятым в той или иной стране, но и упростить процессы, связанные с реализацией и изменением требований. Применение подобных средств особенно актуально при работе с крупными проектами, когда количество требований исчисляется сотнями и даже тысячами.
Технические требования
Средство управления требованиями 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
Говоря о применении средств поддержки жизненного цикла разработки приложений, ориентированных в определенной степени на документирование продуктов, следует учитывать, насколько продукт подходит к российским условиям. Технические задания у нас пишутся на русском языке (если, конечно, у вас не иностранный заказчик), поэтому требования и их описания, естественно, должны быть сформулированы именно на этом языке; кроме того, деление требований по категориям в российских государственных стандартах несколько отличается от аналогичного деления, принятого в западных методологиях. Как выяснилось, создать нужные русскоязычные категории требований и сами требования в CaliberRM совсем несложно (рис. 2).
Рис. 2. Русскоязычные требования и их категории
Что еще более интересно — для некоторых типов требований можно создать свойства, определяемые пользователем, которые также могут быть русскоязычными (рис. 3 и 4).
Рис. 3. Создание свойств, определяемых пользователем
Рис. 4. Отображение свойств, определяемых пользователем
Заметим, что обещания, данные Корне Хьюманом (см. врезку), были выполнены: в новой версии CaliberRM можно форматировать текст требований и добавлять в него таблицы и иллюстрации (см. рис. 4), а это, в свою очередь, позволяет использовать в требованиях диаграммы сценариев, состояний, потоков данных и иные диаграммы, которые любят создавать бизнес-аналитики, а также диаграммы классов и моделей данных — в общем, диаграммы всего, что может потребоваться при управлении требованиями.
Отчеты по данным, хранящимся в репозитарии CaliberRM, можно получить в виде XML- или HTML-документа (рис. 5).
Рис. 5. Отчет по требованиям в формате HTML
Помимо этого с помощью средства Document Factory (это отдельное приложение, которое запускается и из среды CaliberRM) можно сгенерировать документ Microsoft Word, описав с помощью несложных команд, что именно следует в него поместить, и сохранив это описание в шаблоне того же Microsoft Word вместе с заранее заданным текстом и оформлением (в документации, прилагаемой к продукту, описаны все эти команды). Не вижу причин, почему нельзя сгенерировать таким же образом и техническое задание (хотя бы частично) или спецификацию для разработчика.
Говоря об отчетах, следует упомянуть продукт CaliberRM Datamart, позволяющий создавать аналитические отчеты на основании данных об управлении требованиями проектов, ведущихся в компании, оценивать их эффективность, представлять эти данные в виде диаграмм и выполнять запросы к ним.
Из прочих особенностей отметим наличие средств ведения дискуссий по требованиям и отслеживание изменений в требованиях, их типах и формулировке (рис. 6).
Рис. 6. Дискуссионный лист, связанный с требованием
Отслеживание истории изменений требований — очень важная особенность, поскольку именно изменение требований и появление новых требований в процессе реализации проекта являются причинами выхода проектов за рамки бюджета и сроков. Эта функция представляется очень полезной: можно обязать пользователя при изменении уже созданных требований вводить комментарии к внесенным изменениям (рис. 7).
Рис. 7. История изменений требования
Кроме того, следует отметить возможность обработки событий, поддержку аутентификации пользователей с помощью LDAP-каталогов, средства интеграции с Borland StarTeam 6.0 (это средство организации коллективной работы над проектом было выпущено одновременно с CaliberRM, и о нем мы расскажем в следующий раз), с одним из самых популярных в нашей стране средств разработки Borland Delphi и с новой версией средства тестирования TestDirector 8.0 от компании Mercury Interactive.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
