DinoПрисоединяюсь к тем, кто рекомендует CaliberRM.
Полгода работал с сабжем, но после того как ознакомился с CaliberRM, тут же перешёл на него. О чём не жалею.

PS: справедливости ради. У Калибра то же есть свои недостатки, но мне он больше нравиться.

Можно поинтересоваться, какие именно недостатки вы отметили?

Dino1. Набор команд Document Factory не богат.
2. Поведение Document Factory иногда бывает не предсказуемо. На большом наборе требований иногда его проглючивает: генерит кучу пустых листов.
3. Проблема с копированием изображений в описание требования. В описании продукта это декларируется, но у меня (и не только) не работает.

Но для меня он всё равно лучше реквизита.

С какой версией CaliberRM вы работаете? О каком количестве требований идет речь ("большой набор")? С изображениями проблем не заметил ... вставлял фотографии в несколько мегабайт. А вообще, можно было бы в частной переписке (мой e-mail есть в профайле) обсудить более детально, что не хватает в Document Factory и вашу практику использования CaliberRM.

Добрый день!
Позволю себе дать некоторые комментарии ...
AlexTheRavenЧастной переписки не надо - давайте говорить открыто, не стесняясь недостатков, ведь идеального софта не бывает.

Возможно не всем по душе обсуждение частного вопроса использования CalierRM ... но раз настаиваете ...
AlexTheRaven А не хватает Borland Document Factory, на мой взгляд, следующего:
1) Нельзя выводить названия требований разного уровня заголовками разного уровня

Во-первых, не для всех такая практика создания документов является приемлемой. В частности, гораздо чаще (в тех организациях которые используют CaliberRM и делятся информации о практике использования) встречается шаблоны для генерации документов, где разделы заранее определены (например те же ТЗ по ГОСТ, с заранее определенным количеством/названиями разделов) и требования размещаются в нутри этих разделов, без необходимости использования разных стилей (с их точки зрения достаточно отступа или нумерации).
Во-вторых, "если нельзя, но очень нужно -- то можно!" (с) ... для этого следует использовать макросы word + 2 раза запускать DocFactory (это легко можно записать в *.bat файл и запускть этот "батник"). Т.е. реализовать это технически -- возможно .
AlexTheRaven
2) Нельзя превращать трассировки в перекрёстные ссылки MS Word

Вопрос, а зачем? И что вы хотите сказать этой ссылкой в электронном документе, какую проблему решить? Ок, предположим, что хотите показать связь м/у требованиями, в печатном виде тоже можно будет воспользоваться этими ссылками??? Трассировка, это элемент управления требованиями, если есть необходимость показать трассировку м/у требованиями в документе, то возможно, стоит для этого использовать перечисление связанных требований, и делать это желательно в одтельном разделе документа.
AlexTheRaven
3) Если какого-то раздела нет - вместо него появляется пустая строка. Удаляется это, конечно, легко, но всё равно муторно...

Не совсем понятен контекст ... можно подробнее?
AlexTheRaven
4) Так медленно генерирует документы, будто бы студентами-гуманитариями писана...

Напишите быстрее :-), для этого все есть -- есть SDK CaliberRM, есть COM-модель Word :-) ... я думаю, что вы сможете неплохо на этом заработать :-).
AlexTheRaven
И вообще, прилагался бы к ней набор шаблонов, согласованных с RUP - мир был бы лучше.

Ой ли ... а мне вот предствители разных организаций говорят, что более интересно иметь шаблоны ГОСТ ... :-). Все в ваших руках :-).

AlexTheRaven Таки реализовал... Уже... ГОСТ - это, конечно, хорошо, но и RUP забывать не стоит. А в шаблонах артефактов RUP, например RUP VISION, как раз и предусматривает разные заголовки.

Только выходит что для генерации документа бизнес-аналитик обязательно должен обладать навыками программирования? IMHO это неправильно.


Что вы имеете сказать за программирование ... где программирование а где макросы ворд! ... это ж две разницы! :-)

А серьезно -- то лично я переделал в свое время шаблон Vision -- ибо мне было не удобно работать, когда каждая фича имемла стиль Heading ... пухло содержание ... либо в содержание не включать -- либо не использовать стиль Нeading для каждого требования.
Но вот не совсем по теме -- но очень интересный вопрос -- интересно как вы определяете типы требований и мапируете их на разделы RUP Vision, или разделы ТЗ по ГОСТ?

AlexTheRaven
Если какого-то раздела нет - вместо него появляется пустая строка. Удаляется это, конечно, легко, но всё равно муторно...Ну например:
<<hierarchy>>.<<name>>
<<description>> Важность требования: <<Benefit>>

Есть требование самого нижнего уровня. Содержание требования понятно из названия, дополнительного описания не имеет, поле <<description>> - пустое. Но вместо того, чтобы не ставить ничего, Document Factory упрямо вставляет перенос каретки.


По идее пустые значения атрибутов требований -- это все равно что значение NULL в поле таблицы БД (по смыслу) ... если ПОКА не определено это значение по какой-либо причине -- имеет ставить "TBD", а если по смыслу значение отсутствует -- то об этом следует честно в документе и сказать (чтобы не напрягать читателя) -- ставить значение "отсутствует" :-) ...

AlexTheRaven
Для многих электронная форма удобнее бумажной. А перекрёстные ссылки в электронной формк - это удобно.

Удобно -- это ambiguous term, которых как известно стоит избегать в требованиях :-) ... посему я не зря спросил -- что вы хотите сказать такой ссылкой в электронном документе? Физический смысл ссылки какой?

Calm авторчто вы хотите сказать такой ссылкой в электронном документе? Физический смысл ссылки какой?

Мне кажется, уважаемый byur, вы неадекватно воспринимаете здоровую критику и уходите в словоблудство. Все прекрасно знают, что такое ссылка (гиперссылка) в документе MS Word.

авторгде программирование а где макросы ворд! ... это ж две разницы! :-)
Как ни называйте написание программного кода, суть не меняется.

С уважением.

:-) ... Уважаемы Calm, я вполне адекватно воспринимаю окружающий меня мир и людей его населяющих ... Что такое ссылка -- это общеизвестно, и не вызывает необходимости пояснять ... но я не могу добиться ответа ПОЧЕМУ трэйсы в требованиях должны быть выражены в виде ссылки и ЧТО означает в данном случае эта ссылка (т.е. по сути КАК используется трассировка в конкретном случае, как интерпретируются треэйсы) ... посему и спрашиваю. Может вы сможете адекватно пояснить?

AlexTheRaven
Я могу. Смысл ссылки в документе с требованиями прост. Одно требование связано с другими. Перед тем, как реализовывать первое - нужно обратить внимание на второе, от которого оно зависит (FROM). Щёлкнуть по ссылке, перейти и почитать. И ещё посмотреть, что от этого требования зависит (TO).


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

AlexTheRaven
Не говорите мне, что я делаю неправильно. Потому что это


"Не спрашивайте, и вам не ответят" :-) (с). (не всопринимайте это серьезно)

AlexTheRaven
а) Работает
б) Удобно для всех, кроме меня. Мне приходится проставлять эти ссылки вручную - шитьё бисером. Удобство совсем не двусмысленный термин; удобство->прирост мотивации->прирост производительности->прирост денег.


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

enter your choice ...

AlexTheRaven
В RUP Vision мапим,
1-е 3 уровня WHAT в 5.Возможности продукта
1-е 3 уровня DSGN в 9. Прочие требования к продукту.
после чего убираем слово "должен"


Все остальные разделы Vision вы заполняете прямо в Ворд?

AlexTheRaven
В RUP SRS мапим все требования, сколько бы уровней ни было.


Какие типы требований на какие разделы? Или часть разделов как в Vision заполняется прямо в шаблоне Word?

AlexTheRaven
Раздел для WHAT зависит от значения пользовательского атрибута "Area", принимающего значения
Functionality
Usability
Reliability
Performance
Supportability

DSGN всегда попадает в Design Constraints.

ГОСТом не пользуемся.

Т.е. вы не выделяете отдельный тип требований как атрибуты качества в инструментальном средстве?

AlexTheRaven Ruby ... обратите внимание на стиль ответов Calm ...
IMHO Calm классно отвечает. По-простому, без словоблудия, иногда жёстко, но по делу.

2 AlexTheRaven: Подождем ответа Calm ... пусть и он выскажет свою точку зрения ... изучим.

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

AlexTheRavenДа, Calm не применяет управление требований, но Calm ничего и не говорил про методику работы с требованиями. Он осудил ситуацию, когда пользователь (в моём лице) высказывает пожелание, а бизнес-аналитик (в лице byur) ему иносказательно говорит: это пожелание ерунда, мало ли что там вам неудобно, даже регистрировать не станем, ищите пути сами.

P.S. Макрос для вставки линков написал, попутно разобравшись с частью DOM Word. Беру обратно претензию к скорости генерации Document Factory. Поразительно, как программисты MS написали настолько неэффективный код. Впрочем, можно было бы генерировать документы в RTF вместо DOC, как делает ARIS, значительно быстрее.

Я в своей практике очень часто сталкиваюсь с вопросами аналитиков, которые используют тот же CaliberRM, о необходимости иметь ту или иную фичу ... обычно я задаю вопрос "почему нужно чтобы именно такая фича была?". Т.е. необходимость наличия фичи -- это некое следствие, меня интересует причина (потребность). Поняв причину, в 80% случаев (сорри, но это моя эксперная оценка процента случаев) можно обойтись без этой фичи и удовлетворить потребность иным способом -- часто за счет организации работ ... а это дешевле, чем заказывать разработку конкретной фичи. Именно поэтому я задавал вопросы, чтобы понять истинные потребности ... а эти вопросы г-ну Calm показались словоблудием.

Винни-Пухto byur

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

1. Документации на русском языке нет.
2. CaliberRM достаточно прост в использовании, и в частности по этому никто не занимался переводом документации.
3. Есть курсы как по Разработке и управлению требованиями вообще, так и в частности по использованию CaliberRM -- на русском языке. За подробностями можно обратиться в московский офис Борланд или задать вопрос в форуме по CaliberRM на www.almportal.ru.
4. Что понимается под русификацией CaliberRM? Пункты меню на русском?
5. Если прослушать курс по RDM -- то там приводятся все термины на русском языке, и дается ссылка на аналогичный оригинальный термин. При желании -- можем помочь в постановке процессов RDM в вашей организации в рамках консалтинга.

Винни-Пух>1. Документации на русском языке нет.
Жаль, попробую разобраться сам. Мне на данный момент не очень понятен принцип совместной работы с продуктом


Изначально продукт многопользовательский. Требования вводятся и хранятся в репозитории (объектная БД, но можно выгрузить в Access). Документация требований генерируется по необходимости при помощи Document Factory. Или что понимается под совместной работой?

Винни-Пух
>4. Что понимается под русификацией CaliberRM? Пункты меню на русском?
Хочется понять главное - наличие и логику механизма отслеживания цепочек требований между базовыми линиями по категориям. А там всё на английском, это же не простые слова, а семантические термины, дословный перевод может увести в другую сторону. На ваш взгляд, методика подхода, описанная Карлом Вигерсом, подходит для CaliberRM?


Фреймворк, описанный Вигерсом как раз и положен в основу CaliberRM по-умолчанию. Но можно совершенно спокойно "посадить" и на ГОСТы. Инструмент в этом отношении гибок.
Не совсем понял, что означает "отслеживание цепочек требований между базовыми линиями по категориям". Если речь идет о связях м/у требованиями -- то это использование трассировок (в CaliberRM есть как матрицы трессировки, так и диаграммы трассировки). Базовые линии могут сравниваться м/у собой. А требования -- версионируются (т.е. при внесении изменения в требование, включая атрибуты, история изменений сохраняется). В базовые линии можно включать определенные версии требований.

Винни-Пух
>5. Если прослушать курс по RDM -- то там приводятся все термины на >русском языке, и дается ссылка на аналогичный оригинальный термин. При >желании -- можем помочь в постановке процессов RDM в вашей организации >в рамках консалтинга.
Спасибо, только вопрос по ALMPortal - я вообще не нашел информации о конференциях, курсах и планируемы датах СЛЕДУЮЩЕГО ПРОВЕДЕНИЯ оных, там только прошедшие даты.

Анонсы публичных мероприятий выкладываются по мере их планирования.

Винни-ПухПод совместной работой я понимаю, как разграничивать права, какие возможности протоколирования дискуссий (я не нашел, как темы заводить, и кроме того, дискуссии ведутся по базовым линиям?), как открывать baseline


У CaliberRM очень гибкая система управления правами доступа. Можно устанавливать право видимости и создания/редактирования -- как на типы требований целиком, так и на конкретные атрибуты. Все это как для групп пользователей, так и для конкретных пользователей. Это можно найти во Framework Administrator.
Дискуссии привязаны сами по себе к конкретному требованияю и призваны именно отразить обсуждение конкретного требования и не являются аналогом, например, форума sql.ru с его функциональностью.
Переключение м\у базовыми линиями -- выпадающий список Baseline. По-умолчанию отображается Current Baseline.