Форум Сообщества Аналитиков
Общий раздел => ПО Аналитика => Тема начата: bas от 03 Апреля 2007, 13:26:35
-
В статье К. Вигерса приведено сравнение 4 средств управления требованиями (Borland's Caliber-RM, Telelogic's DOORS, Rational’s RequisitePro, and Integrated Chipware’s RTM Workshop) :
http://www.processimpact.com/articles/rm_tools.html
Детальное сравнение средств управления требованиями (около 40 тулзов) по хар-кам:
http://www.paper-review.com/tools/rms/read.php
-
Вот еще интресные ссылки по теме, тем более если кто-то ищет бесплатные тулзы:
http://www.jiludwig.com/Requirements_Management_Tools.html
http://easyweb.easynet.co.uk/~iany/other/vendors.htm
-
Интересное (от 2008 года) обсуждение систем управления требованиями (RequsitePro, Doors, CaliberRM) было так же здесь:
http://www.sql.ru/forum/actualthread.aspx?bid=58&tid=284045&pg=-1
-
Достаточно большой список СУТ есть на сайте Volare:
http://www.volere.co.uk/tools.htm
-
Конечно можно
-
Мое почтение
Хотелось бы что бы в сравнении учавствовал и IBM Rational Requirements Composer, если кто имел с ним дело
-
IBM Rational Requirements Composer только что вышел в первой версии, русской локализации еще нет, продукт очень сырой, поэтому врядли кто-то его использовал по настоящему.
-
Мое почтение
Хотелось бы что бы в сравнении учавствовал и IBM Rational Requirements Composer, если кто имел с ним дело
Этот продукт больше заточен не на работу с требованиями, а на раскадровку, т.е. прототипирование пользовательских интерфейсов и связь их ст требованиями.
В линейку Rational добавили еще один инструмент, способный покрыть определенную часть процесса разработки, а именно - прототипирование, и получение требований на основе прототипов. Конечно, же все продукты интегрируются друг с другом, это плюс продуктов от IBM.
-
Виталий,
А ты его качал, смотрел??
-
Качал клиента, но он оказался тонким и необходимо было скачать то ли сервак, то ли базу данных Jazz - без этого не работает. На этом я остановился... Хочу теперь скачать все целиком и "погонять". Но это только в свободное время :)
-
Поэтому пока предлагаю стереть твое мнение про Композер ;) Потому что ты не прав :)
-
Поэтому пока предлагаю стереть твое мнение про Композер ;) Потому что ты не прав :)
ОК :)
Тогда скажи в чем правда?
-
Я сам его не трогал, поэтому врать не буду. Но рекомендую хотя бы посмотреть презентацию Решения IBM Rational на базе Software Delivery Platform и Jazz (http://cmcons.com/free_download/ldv.pdf) стр. 16
-
Доброго здравия, коллеги!
Очень рада, что нашла этот форум на просторах рунета :) Просто кладезь полезной информации!
Сейчас как раз занимаюсь выбором средства для управления требованиями. Нашла вот такой совсем не маленький списочек: http://www.software-pointers.com/en-requirements-tools.html (http://www.software-pointers.com/en-requirements-tools.html). Возможно кому-то из вас он будет очень полезен :) Пока из этого приходилось работать только с Калибером. Буду оценивать другие средства.. В первую очередь open source
-
Алена,
Спасибо. Присоединяйтесь.
Кстати, вот ссылки на отзыв о Polarion:
http://www.uml2.ru/index.php?option=com_content&task=view&id=193&Itemid=64
-
Виталик,
А ну кались, что это за EPAM PMC (http://www.epam-pmc.com/)?
-
Привет Виталий! Волей случая - Yandex - завел меня на форум.
Только личное мнение - Sybase PD 15.
Преимущества:
- трассировка на любой элемент любого типа модели (на шаг БП, поток, сущность, таблицу, атрибут, класс, объект, метод, парамент, элемент XML схемы и многое другое). Кроме того, умение быстро вычислять транзитивные зависимости. Т.е. если требование трассировано на бизнес процесс, а бизнес процесс декомпозирован, его шаг описан вариантом использования, который описан диаграммой взаимодействия ... то можно получить взаимосвязь между требованием и папрметром метода.
- простой в использовании генератор отчетов с возможностью расширения (надеюсь Виталий помнит, как пытался получить отчет из IBM-овских продуктов - Web Sphere Business Modeller - мучался почти 3 недели и ноль).
- возможность как декларативного расширения (новые атрибуты, списки выбора, формы, вкладки, новые типы трассировок и т.д.), так и процедурного расширения. Кто зает VB - может целые приложения писать. Лично уже наваял 4 дополнительные формы.
- отрытое описание метамодели - дополняй, программируй сколько влезет.
- совместная работа, версии, простота.....
Рекомендую.
-
leinsoo,
А теперь минусы?
Кстати для моделирования БП какие нотации поддерживаются?
-
Ответ на вопрос 1 – недостатки.
Собственно по требованиям
- формальноотсутствует syspect (по моему - так называется в requisite pro признак возможных изменений). Но может это и к лучшему, т.к. после того, как impact and Lineage Analysis выдает более 4000 зависимостей на одно требование, то только ручное снятие такого признака может занять целый день. Но несомненно, в некоторых ситуациях пригодился бы. В остальном нормально. Лучше задайте каверзный вопрос, желательно не теоретический, а сравнительный, т.е. относительно возможностей другого средства.
Общие недостатки.
- НЕ РУСИФИЦИРОВАН. Для использования предметными аналитиками требуется обучение.
- НЕТ КНИГ и учебных пособий на РУССКОМ, нигде. Уже устал лекции читать.
- Не удается под Oracle 9i запустить Repository web Browser. Точнее, типовой аналитик не может разрешить проблему с установкой (там джавийная ошибка по преобразованию типов данных оракловым JDBC драйвером). А т.к. фирма жмотится и у нас фактически нет ни админа, ни конфигуратора (точнее - они в наших интересах не работают), ни лицензии, то всем приходится иметь толстого клиента. Не критично, но жаль.
- ввиду того, что файлы моделей хранятся в XML, то при больших объемах одной модели
(более 60000 элементов, наличие встроенных рисунков /bmp скриншоты/, итоговом размере файла модели более 70 мегабайт, наличие более 142 версий в репозитарии)
бывает (раз в месяц), что при синхронизации (создании новой версии с одновременным обновлением локальной модели), зависает минут на 10-20. Ест ресурсы локально машины 100%. Указано для локальной машины - пень 4, 1 гигабайт оперативки.
- капризничает при построении диаграмм последовательностей (когда есть более 4-5 вложенных вызовов).
- отвратитьный сайт Sybase.ru и com.
Ответ на вопрос 2 – нотации по моделированию БП.
Analysis (наиболее обощенный тип модели БП);
BPMN 1.0;
DFD;
Service Oriented Architecture;
BPEL4WS 1.1;
WS-BPEL 2.0;
Sybase WorkSpace Business Process (собственная нотация, заточенная под для использования в Sybase WorkSpace);
ebXML 1.01;
ebXML 1.04.
Последние 5 поддерживают кодогенерацию.
-
Еще тогда вопросы:
1. Есть ли возможность связи с инструментами планирования и тестирования?
2. Как организована совместная работа?
3. Как работает версионность? Я имею в виду закомитить все требования для версии ПО 1.0, потом что-то менять, закомитить для версии 1.1 и сравнить требования для 1 и 1.1.
-
Привет, Андо :)
Ну не люблю я повер дезигнер ;D - он более для программистов, имхо.
-
Добрый вечер всем.
1. Сначала ответ Виталию.
Виталий: "Ну не люблю я повер дезигнер - он более для программистов, имхо."
Действительно так.
Однако самое забавное заключаетсяв том, что в большинстве компаний аналитики работают именно на программистов.
Именно программисты основные "клиенты" и "работодатели" для программистов.
Соответственно, их задачей и является перевод текстовых выражений "хотелок" в формальные спецификации, на формальном языке, который легко усвояется программистами, котрые могут работать по очреди на 4-5 проектах.
Если даже аналитик находится на стороне заказчика, то чем точнее и формальнее он выразит свои требования, тем меньше у него риск быть явно обманутым или получить "несколько другой" продукт.
Вывод - чем ближе средство управления требованими к народу, тем лучше. Идеал - кодогенерация + автотестирование. Надиктовал требование, а на выходе идеальный код.
2. Теперь по сути вопросов.
"1. Есть ли возможность связи с инструментами планирования и тестирования?"
2.1 - Тестированием пока сам не пользовался, но чуть интересовался:
- хорошо тестируется БД. Этим PD отличается сильно в лучшую сторону. Генераторы, профили, автозаполнение, проверка правил и т.д. и т.п.
- есть и связь со средствами UnitTesting, в частности под платформу .net20, тестирования web-services и прочее по мелочи. Но такое ощущение, что это один из недостатков, который я забыл перечислить. Не складывается впечатления комплексного подхода. Что может, то и тестирует.
"2. Как организована совместная работа?"
2.2 Через репозитарий, который находится в базе.
Основная фича в том, что у каждого пользователя на локальной машине есть текущая рабочая копия.
Она может быть всегда, либо получаться с репозитария при check_out.
После проведения локальных обновлений - check_in.
В процессе check_in - всегда compare (предварительное сравнения того что есть в репозитарии с тем, что есть на локальной машине).
В момент сравнения - определяются и опции (замена, интеграция версий и т.д.).
Собственно сравнение - сделано очень неплохо. Можно вычислить все что угодно, взять управление "на себя" (сливать элементы вручную и т.д.и т.п.).
Для пользователей, которым нужно только смотреть или получать отчеты, оформлять подписку на изменение элементов присутствует Repository web Browser (правда нам его удалось запустить только под postgres, под оракл - не запускается зараза.
Очень полезно именно подписка - программист отвечает за модуль, на который есть спецификации и требования (по трассировке). Подписывается на их изменения. Ему сообщается, о наличии в них изменений. К выходу очередных версий спецификации - он уже морально готов.
Недостаток – нельзя в on-line править в базе. Может это и теоретически неправильно, но такую возможность крайне уважаю (Oracle Designer помер – а жаль). В процессе работы над итерацией – версии не сильно нужны, все нестабильно, быстро меняется. Вот в Oracle Designer была такая фича, что если есть общий элемент модели на диаграмме, то если мой коллега изменил чтой-то в общем элементе, он у меня в момент отметился как измененный и всегда спрашивал, что дальше будем делать. Очень, очень полезная штука. В PD в online изменяется только статусы проекта и модели. Маловато.
"3. Как работает версионность? Я имею в виду закомитить все требования для версии ПО 1.0, потом что-то менять, закомитить для версии 1.1 и сравнить требования для 1 и 1.1."
То, что описывается в данном вопросе есть.
Введены понятия как версии, так и ветки, baseline и т.д. (правда определение baseline специфичное).
Чтоб долго не писать, попробую приложить картинку из доки.
Лично пользуемся только версионностью (у пока еще 3 года будет только линейная разработка по набору функционала).
Сравнение можно делать любой версии с любой. Прецедент был - разбор полетов, спор и ругань. Пришлось сравнить версию 12 с версией 96 (это версии спецификаций, благо не софта). Разница во времени - 14 месяцев. Заняло 5 минут.
По отдельному элементу доступны все его свойства во всех версиях.
Отличительная особенность PD в том, что он автоматически следит за версиями каждого элемента в отдельности (в автоматическом режиме). За счет чего - значительно сокращается объем БД.
-
Простите, совсем забыл про планирование.
Есть плагин для проджекта. Работает.
Но вопрос заключается в том, что он работает только с "Толстым клиентом проджекта". Т.е. может интегрировать требования в локальный или сетевой mpp файл.
У нас же ситуация следующая.
Развернут project server. Проектом "рулит" руководитель проекта.
Начльники отделов разработки и проектирования могут только "подавать предложения" в план проекта.
Угадайте как? Правильно, через project web access.
А вот с этой штукой (project web access) Powerdesigner отказывается интегрироваться.
Может у кого есть опыт того, как и какое средство управления требованиями интегрировать с тонким клиентом MS Project с учетом того, что сформированные требования это только предложения, которые будут включаться в план, превращаться в групповую задачу и т.д.???
-
Может у кого есть опыт того, как и какое средство управления требованиями интегрировать с тонким клиентом MS Project с учетом того, что сформированные требования это только предложения, которые будут включаться в план, превращаться в групповую задачу и т.д.???
Не совсем средство управления требованиями, но рулить там можно если настроить - штука классная - это JIRA. Она интегрируется с MS Project при помощи специальной программы Connector, которая взламывается очень просто (мои коллеги по крайней мере делали это очень здорово :))
ОФФТОПИК :)))
Это все лирика. Хороший аналитик напишет хорошую постановку вне зависимости от того, какими идеологическими соображениями он руководствуется - облегчением жизни программистов или ублажением заказчика.
В общем, здесь опять человеческий фактор.
Марина, ты все время говоришь о хороших аналитиках, которые все могут и умеют :) Где таких "делают"? Подкинь контакт - хочу научиться делать хорошие спеки, чтобы программисты были довольные у них появлялось желание их читать :).
-
Виталий, так Jira интегрируется с тонким клиентом????
С толстым клиентом проджекта кто только не интегрируется.
Лично пробовал с Requisite, Sybase и Jira (но тогда только в триале).
А вот с тонким клиентом - не слышал и не видел (чтоб через web access).
Еще раз проблема и критерий выбора средства управления требованиями.
План проекта опубликован на Project Server. Задачу в план можно включить только подав предложение через web интерфейс (кто пробовал это глюкавище - тот поймет).
Средство управления требованиями должно формировать предложение в план проекта и отслеживать состояние его рассмотрения (т.е. после утверждения предложения в плане проекта устанавливать у требования признак «Утверждено к исполнению»).
Средству управления требованиями, которое может проделывать такой фокус, смело можно ставить повышающий коэфф. не менее 1.5.
По поводу собственно Jira.
Connector позволяет в MS Project импортировать записи из Jira.
Но у нас: - руководителю проекта запрещено смотреть в Jira, нам нельзя напрямую использовать файл Project. Т.е. интеграции нет.
Если требования описаны просто - т.е. в виде набора дискретных утверждений «Система должна …»/ «не должна», то да, Jira подходит. Только интерфейс корявый, лично я не перевариваю. Уже долго пользуемся как багописалкой, но никак не могу привыкнуть
Для более формализованных требований – не подходит.
CleaQuest +Requiste - тогда уж намного лучше .
-
Модератор: Флуд удален.
-
А кто-то обсуждает для чего вообще необходим инструмент аналитика ?
-
Вводим в Гугле ROI Requirement Management System и получаем много ссылок :)
-
Моё почтение.
Может ли кто подсказать в каком из RMT есть все перечисленные ниже возможности? Именно все!
- поддержка типов требований (Т) (FEAT, SRS, UC…).
- поддержка иерархии Т.
- хранение Т в БД в виде форматированного текста.
- возможность вставки картинок/таблиц.
- возможность ссылаться на другие Т в виде:
- ссылок на Т.
- ссылок на конкретное место в Т.
- вставки определённого содержимого (текста/картинки/таблицы) из другого Т без возможности его модификации.
- поддержка автообновления ссылок.
- контроль изменений
- трассировка
- версионность
- разграничение доступа к Т
- настраиваемое оповещение о изменениях в Т
- экспорт
- по Baseline
- по типу Т
- по версии Т
- в один общий документ (word/html/pdf)
- в группу документов разбитых по типу Т (word/html) с поддержкой ссылок
- GUI
- настраиваемое представление рабочей области
- настраиваемый список последних изменений
-
evgenis,
ИМХО еще было бы неплохо приоритезировать фичи, на сколько они важные для вас.
Вроде все умеет Doors и RequisitePro. Не уверен в следующем:
- ссылок на конкретное место в Т.
- вставки определённого содержимого (текста/картинки/таблицы) из другого Т без возможности его модификации.
- GUI
- настраиваемое представление рабочей области
- настраиваемый список последних изменений
-
С RP работаю в данный момент.
RP умеет ссылаться на конкретное место в другой спецификации, но не умеет вставлять часть содержимого. А так же не может поддерживать корректность ссылки.
Именно не удовлетворённость RP и подталкивает на поиск альтернатив.
-
Может ли кто подсказать в каком из RMT есть все перечисленные ниже возможности? Именно все!
Все-все навряд ли где-либо есть.
Все, кроме ссылок на конкретное место в Т. и вставки содержимого из другого Т. -- есть в DOORS, как уже заметил bas.
Но полезна ли возможность ссылаться на часть Т. в принципе? Если Т. можно поделить на части, то это уже по сути несколько Т. Которые можно зарегистрировать по отдельности и ссылаться на любое из них как на целое.
Кстати, коллеги, а ведь это хороший пример на тему, которая недавно обсуждалась -- следует или нет изобретать велосипеды в ИТ. Достоинства примера: а) не отвлеченный, а имеющий непосредственное отношение к будням аналитика, б) правильный ответ для многих совсем не очевиден.
-
Но полезна ли возможность ссылаться на часть Т. в принципе?
ИМХО это полезно для создания обобщённых документов требований. Например, если требуется иметь документ отражающий все ДВИ без описания. При отсутствии данной возможности, приходится постоянно отслеживать изменения и дублировать информацию.
-
ИМХО это полезно для создания обобщённых документов требований. Например, если требуется иметь документ отражающий все ДВИ без описания.
Если я правильно понял, вы хотите создавать обобщенный документ так: создать квазитребование "Список вариантов использования", в него ссылками включить части-заголовки всех требований, являющихся ВИ.
Эту задачу можно решить, не создавая специального "требования" для обобщенного документа. Скажем, из DOORS можно экспортировать в Word требования нужного типа (например, "ВИ"), включая только нужные атрибуты требований (заголовок там является отдельным атрибутом). В итоге получится желаемый обобщенный документ.
-
А если мне из всех ДВИ нужны только их графические изображения без описания?
-
...можно экспортировать в Word..
А как поддерживать актуальность? Постоянно делать экспорт? Накладно.
-
А если мне из всех ДВИ нужны только их графические изображения без описания?
Как предположение (на практике не пробовал): создать для требований атрибут "изображение", в котором хранить диаграммы, и выводить в обобщенный документ только этот атрибут требований-ВИ.
А как поддерживать актуальность? Постоянно делать экспорт? Накладно.
Обычно обобщенные документы нужны а) для ознакомления тех, кто не работает непосредственно с СУТ, и б) для формального согласования. Т.е. обеспечивать актуальность этих документов требуется не непрерывно, а к определенным моментам времени или событиям. Если так, то раз-другой в день выгрузить требования из СУТ не особо обременительно.
Если же действительно нужен риал-тайм, то не знаю. Видимо, только изобретать...
-
Скажем, из DOORS можно экспортировать в Word требования нужного типа (например, "ВИ"), включая только нужные атрибуты требований (заголовок там является отдельным атрибутом). В итоге получится желаемый обобщенный документ.
Здесь еще можно использовать такой инструмент, как Rational Publishing Engnee Document Studio (RPE), который позволяет готовить шаблоны документов и выгружать при их помощи требования из DOORS в готовый документ. Например, мне удалось создать такой шаблон для выгрузки ТЗ по ГОСТ 34, который можно использовать для большинства проектов, ведущихся в DOORS в нашей компании.
Жаль только, что по RPE я не нашла пока русского форума, ибо в процессе работы столкнулась с некоторыми трудностями. Пришлось самой во всем разбираться, ну и форум ibm помог, конечно. Может быть стоит создать такой раздел, где агрегировать опыт коллег, как думаете?
-
Здесь еще можно использовать такой инструмент,
Катенька, поздравляю! Есть что посоветовать известному тебе коллективу? ;)
-
Может быть стоит создать такой раздел, где агрегировать опыт коллег, как думаете?
Такой раздел уже есть - База Знаний: http://lib.uml2.ru
Ее можно наполнять не стесняясь.
-
Мы в свое время (лет 7) вели документацию в sgml и делали всякие штуки, чтобы вытаскивать нужное в сводные таблицы - словари, списки форм и подобное. Но постепенно пришли к тому, что стоит менять подход. Дело в том, что описание требований в этом виде очень напоминает процедурное программирование времен фортрана и Си. Каждое требование - это такая подпрограмма, вызывающая другие. В мире программирования победил объектно-ориентированный подход, с его принципами инкапсуляции, наследования, стандартных интерфейсов и многого другого. А аналитики - по прежнему во многом находятся на уровне требований, связанных в произвольную сеть. И это тяжело. Прежде всего - тяжело эту сеть загрузить в голову, тяжело в ней ориентироваться. Фактически в полном объеме ей владеет только автор. Что не подходит для больших проектов - фактически все участники должны верить компетентности аналитика и правильности его представлений. А ошибки обнаруживаются поздно. В борьбе с этим мы начали строить модели, с приличной инкапсуляцией, минимизацией зависимостей между разными частями. Тогда мы имеем хорошее иерархическое описание, а в рамках обособленного фрагмента - материал вполне обозрим, чтобы обойтись без специальных средств поддержки.
-
Тогда мы имеем хорошее иерархическое описание, а в рамках обособленного фрагмента - материал вполне обозрим, чтобы обойтись без специальных средств поддержки.
Можете привести реальный пример? Чтобы мы поучились на вашем опыте.
-
Катенька, поздравляю! Есть что посоветовать известному тебе коллективу? ;)
Спасибо :) Готова поделиться своими знаниями, если вас заинтересовала эта тема. Мне понравились результаты, которых удалось добиться :) Конечно, подогнать все проекты под один шаблон нельзя, но доработать шаблон можно всегда, не затрачивая больших усилий. Это лучше, чем вести требования в каком-либо инструменте и отдельно создавать готовые документы.
-
ekaterinalog, с реальным примером - тяжело. Потому что это реально большие системы (10 и более человеко-лет разработки), и там ТЗ объемные. Плюс основное на верхнем уровне - это запоминающийся образ, картинка, через который идет описание конкретных кейсов на понятном для бизнеса языке. Когда мы делали управление товарным запасом для магазинов, то нам рассказали, что может быть много разных вариантов деления товарного запаса по назначению, в зависимости от ситуации, при этом разными ситуациями заведуют разные отделы и именно они определяют правила. Мы это свели к двум основным видам: запас, доступный группе магазинов и запас, поделенный по конкретным магазинам, решили что дальше будем описывать приоритеты обхода для бизнес-кейсов через специальные правила. И нарисовали для бизнеса все многообразие их существующих кейсов в этой нотации. Дальше был интерактив, они задавали вопросы - мы рассказывали и результатом было общее понимание - что может система, каковы варианты настройки. Как результат - формализм системы отразился в бизнес-терминах. И после того, как модель верхнего уровня возникла, детали - конкретные алгоритмы настройки процесса управления, или функционал рабочих мест - можно было согласовывать для конкретных групп пользователей, и они по объему - были вполне обозримыми. Примерно тоже самое было с Розничным магазином (это тоже сложный проект) - была декомпозиция на основные блоки - склад, торговый зал, касса и сквозные процессы - выкладка товара, примерка, выписка со склада - были прорисованы, именно они делают систему цельной. А дальше - можно было сосредоточиться на каждом отдельном блоке и работать с ним, формируя его модель.
То есть важно, во-первых, декомпозиция системы а, во-вторых, хорошее верхнеуровневое описание сквозных процессов в ней. Именно его, по моему опыту, обычно не хватает. Ну и все это должно быть в терминах, понятных заказчику, на его языке.
Не знаю, насколько получилось донести мысль. Если пересечемся в реале (например, на круглом столе uml2), могу попробовать рассказать более ясно.
-
Сейчас использую в своей работе Polarion Requirements Management (RM).
Из большинства распостраненных тулов идея лежащая в его основе мне нравится больше всего. Возможно реализация некоторых моментов и не идеал, но идеала и среди других тулов я тоже не видел.
Почему этот тул мне подошел? У меня следующий кейс:
- я пишу ТЗ по ГОСТУ, либо по стандартам чем-то напоминающим ГОСТ;
- документ с требованиями в бумажном (или в Word файле) виде согласовывается с заказчиком;
- заказчик в большинстве своем не технарь, не программист, поэтому я не несу ему документ с диаграммами классов, схемами баз данных и прочего что он не поймет, а если и поймет, то ему это совершенно не интересно;
- разработчики хотят видеть четкий список требований, где можно четко понимать над каким требованием он работает в данный момент, а не объемный документ с кучей воды, которая ему в данный момент не интересна.
Основная идея этого тула в том, что я пишу требования как обычный вордовский док-файл, а в этом документе уже отмечаю отдельные сущности - business case, system requirements, non-functional requirements и т.д. в зависимости от потребностей. При этом легко могу слинковать нужные мне элементы. Разработчик может уже смотреть список только нужных ему элементов. Проблем с распечаткой всего этого дела нет, так как это все уже представлено в виде документа.
Вспоминая свое общение с Doors понимаю сколько там было лишнего геморроя - убей пол дня чтобы настроить проект как тебе надо, потом каждый раз когда надо получить печатный документ Word, то после экспорта начинались танцы с бубнами по форматированию стилей, удалению лишнего и прочее-прочее и это еще на пол дня.
Может для Doors проблему с выходным документом и решит Rational Publishing Engine Document Studio, но проблема трассировки к процессу разработки все равно останется.
Упомянутый уже в этой теме обзор Polarion ALM не совсем уместен здесь, так как там рассматривается именно цельное ALM решение, а не конкретный тул для управления требованиями, коим является Polarion Requirements Management.
Коллеги, если кто-то игрался уже с песочницей RM на сайте Polarion или устанавливал себе локально, то было бы интересно послушать Ваше мнение.
UPD: Кому лень играться в песочнице на сайте могут посмотреть вебинар, ближайший по этой штуке 27 октября http://www.polarion.com/company/events/webinar.php?eventid=130
-
Тоже вот столкнулся с вопросом: а какое СУТ выбрать? Раньше использовал средство моделирования RSA, что делает логичным выбор в сторону RequisitePro... Но они оба платные, причем стоят совсем не дешево. Конечно, на первых порах можно и пофлибустьерствовать в ознакомительных целях, но в дальнейшем это чревато разными сложностями.
Поэтому, скорее речь идет о том, чтобы выбрать сразу связку из RMT и CASE средств, исходя из их совместимости, доступности и достаточной функциональности.
Конечно, в качестве самого элементарного выхода, можно было бы использовать RTF-документы для описания требований (включая ВИ) с добавлением туда диаграмм в виде обычных изображений при помощи любого текстового процессора... Но ведь очевидно, что сопровождение требований по мере роста проекта превратится в нестерпимую анальную боль. И переходить на что-то более автоматизированное все равно придется, только уже с проблемой переноса всего наработанного в новое средство.
Нужны инструменты, которые позволили бы нормально описывать ВИ, обрабатывать связи между ними. Помогли бы интегрировать ВИ, другие требования (как то: бизнес-правила, требования к интерфейсу, производительности и проч.), а также построенные в CASE-средстве модели в один проект. Например, использовать ДВИ в качестве иллюстрации к вариантам использования прямо в документе требований. И не в качестве скриншота, а как встраиваемый редактируемый объект (как, например, таблицы Excel в Word-документе).
Пошарил по форуму, нашел несколько беслпатных средств. Сразу скажу: онлайн (т.н. On-Demand) варианты не понравились тем, что проектная документация будет находиться у третьих лиц. Их сервис или накроется, или платным станет - и что тогда делать? К тому же, смущает потенциальная возможность доступа посторонних к проприетарной информации. OSRMT вроде хвалят, но похоже, проект благополучно загнулся несколько лет назад... Из оставшегося внимание привлекла только бесплатная версия RMT Axiom. Но в связке с каким CASE-средством (желательно тоже бесплатным) его лучше применять? Может, я выпустил из виду еще какие варианты?
Короче, тратить драгоценное время на самостоятельный перебор всего подряд очень уж не хочется, поэтому решил сперва посоветоваться с имеющими опыт людьми. На какой связке RMT+CASE остановить свой выбор? Преимущество, разумеется, за бесплатными средствами. Что посоветуете?
-
Brumbel, посмотрите http://devprom.ru
Начните отсюда: http://devprom.ru/product/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%BC%D0%B8-%D0%B8-%D0%B8%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%D0%BC%D0%B8-%D0%B4%D0%BB%D1%8F-%D0%BB%D0%B8%D0%BD%D0%B5%D0%B9%D0%BA%D0%B8-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%BE%D0%B2
-
а отзывы по devprom есть? Вы сами, Денис, с ним работаете?
-
Brumbel, посмотрите http://devprom.ru
Большое человеческое спасибо! :) Интересная вещь, попробую.
И вот эта штуковина тоже заинтересовала: PlantUML (http://plantuml.sourceforge.net/index.html)
Мне одному пришла в голову мысль, что неплохо было бы сделать Flash или Java апплет для графического построения и редактирования диаграм "на лету" в этом средстве? :)
-
а отзывы по devprom есть?
Есть на главной странице сайта внизу.
+ См. http://blogs.yandex.ru/search.xml?text=devprom
Вы сами, Денис, с ним работаете?
В качестве внедренца.
-
Большое человеческое спасибо! :) Интересная вещь, попробую.
И вот эта штуковина тоже заинтересовала: PlantUML (http://plantuml.sourceforge.net/index.html)
Мне одному пришла в голову мысль, что неплохо было бы сделать Flash или Java апплет для графического построения и редактирования диаграм "на лету" в этом средстве? :)
Хорошая новость, PlantUML по-умолчанию встроен в Devprom, вот на всякий случай ссылка на документацию: http://devprom.ru/docs#11712
-
Хорошая новость, PlantUML по-умолчанию встроен в Devprom, вот на всякий случай ссылка на документацию: http://devprom.ru/docs#11712
Да-да-да. Что несомненный плюс. Я, собственно, именно там о планте и узнал... ::)
-
А насколько плох или хорош Enterprise Architect качестве инструмента управления требованиями? Почему-то не нашел обсуждений. Поделитесь, пожалуйста, опытом.
-
А насколько плох или хорош Enterprise Architect качестве инструмента управления требованиями? Почему-то не нашел обсуждений. Поделитесь, пожалуйста, опытом.
Поделитесь перечнем требований, ожиданий и тестовых сценариев к СУТ — расскажем.
-
Герман,
Нужно было ехать на РекЛабс, там как раз Ирина делилась своим опытом УТ в ЕА.
-
Поделитесь перечнем требований, ожиданий и тестовых сценариев к СУТ — расскажем.
Примерный перечень требований к СУТ:
1. Должны быть возможности по созданию и структурированию (группировке) требований (иерархическое представления требований (в виде дерева требований), в котором требования делятся на категории, подкатегории);
2. Требования должны включать в себя ряд свойств, такие как статус, исполнитель, ответственный, бюджет, сроки исполнения, приоритет и этап разработки;
3. Текстовое описание должно быть основной частью требования. Желательна возможность форматирования текста (таблицы, списки);
4. Должна быть предоставлена возможность обсуждения требования участниками проекта и сохранения истории обсуждения как неотъемлемой части требования;
5. Желательно иметь возможность прикреплять файлы к требованиям;
6. Необходимо иметь возможность отслеживать взаимосвязи требований друг с другом;
7. Графическое представление в UML диаграммах.
-
Герман,
Нужно было ехать на РекЛабс, там как раз Ирина делилась своим опытом УТ в ЕА.
А может быть по результатам будет какая-нибудь презентация? Или с Ириной можно как-то связаться?
-
А может быть по результатам будет какая-нибудь презентация? Или с Ириной можно как-то связаться?
Irr (http://www.uml2.ru/forum/index.php?action=profile;u=250)
-
Так есть же презентации. Смотри Программа конференции (http://www.req-labs.ru/conf2012/agenda/522/)
-
А может быть по результатам будет какая-нибудь презентация? Или с Ириной можно как-то связаться?
Видеозаписи выступлений участников Сообщества, в том числе Ирины, будут выложены в открытый доступ.