Сравнение средств управления требованиями (Requirements Management Tools)(Прочитано 98812 раз)
Виталик,

А ну кались, что это за EPAM PMC?
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Привет Виталий! Волей случая - 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 - он более для программистов, имхо.
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Добрый вечер всем.

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, которая взламывается очень просто (мои коллеги по крайней мере делали это очень здорово :))

ОФФТОПИК :)))
Это все лирика. Хороший аналитик напишет хорошую постановку вне зависимости от того, какими идеологическими соображениями он руководствуется - облегчением жизни программистов или ублажением заказчика.
В общем, здесь опять человеческий фактор.
Марина, ты все время говоришь о хороших аналитиках, которые все могут и умеют :) Где таких "делают"? Подкинь контакт - хочу научиться делать хорошие спеки, чтобы программисты были довольные  у них появлялось желание их читать :).
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Виталий, так 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
   - настраиваемое представление рабочей области
   - настраиваемый список последних изменений
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19