Выбор СУТ для отраслевого проекта с большим числом клиентов(Прочитано 60405 раз)
Re: Система управления требованиями Ответ #15 : 23 Ноября 2009, 20:16:59
Андрей, а в чем конкретно проявляются проблемы? Вы можете их описать? Хотя бы кратко, я бы тогда подергал саппорт

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

Если недай Бог, используется ссылки на внешние документы (а  у нас на паре проектов такое было) - то эти документы не попадают под версионный контроль EA. А именно для требований это серьезно (хотя и не только там - у нас цеплялись иногда XML-схемы обьектов, и некоторые эскизы GUI, в итоге - мы сами загоняли весь каталог, включая модель под CC - дешего и сердито).


 



Re: Система управления требованиями Ответ #16 : 23 Ноября 2009, 20:39:41
А именно для требований это серьезно (хотя и не только там - у нас цеплялись иногда XML-схемы обьектов, и некоторые эскизы GUI, в итоге - мы сами загоняли весь каталог, включая модель под CC - дешего и сердито).
Андрей, а вот интересно, baseline и source control, можно работать одновременно, или одно другое исключает?

Я то полагал, что baseline не включает в рассмотрение, что находится вне ее.



Re: Система управления требованиями Ответ #17 : 24 Ноября 2009, 23:13:32
Андрей, а вот интересно, baseline и source control, можно работать одновременно, или одно другое исключает?
Baseline в ЕА и source control через систему версионного контроля технически могут работать одновременно, они друг к другу никак не мешают, только зачем?



Re: Система управления требованиями Ответ #18 : 24 Ноября 2009, 23:49:35
Baseline в ЕА и source control через систему версионного контроля технически могут работать одновременно, они друг к другу никак не мешают, только зачем?
Ира, вопрос не зачем, а как правильно. Что такое бейзлайн и скажем SVN ревизия. Ясно, что это не одно и тоже.

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



Re: Система управления требованиями Ответ #19 : 24 Ноября 2009, 23:57:08
По-моему это неверно. Насколько я понимаю, бейзлайн просто фикссирует состояние на определенный момент. И потом к нему можно вернуться или сравнить его с чем-то. И все.
Вообще термин из конфигурационного управления, у Новичкова и СМ-консалт должно быть много материалов на эту тему.



Re: Система управления требованиями Ответ #20 : 25 Ноября 2009, 00:05:23
По-моему это неверно. Насколько я понимаю, бейзлайн просто фикссирует состояние на определенный момент. И потом к нему можно вернуться или сравнить его с чем-то. И все.
Вообще термин из конфигурационного управления, у Новичкова и СМ-консалт должно быть много материалов на эту тему.
Согласен с Ирой. Но, я (возможно, заблуждаясь) - ожидаю от бейзлайна полной фиксации состояния и удобного сравнения с другим состоянием.
ИМХО - в EA - реализация скорее для галочки - У вас есть? - есть!.



Re: Система управления требованиями Ответ #21 : 25 Ноября 2009, 00:23:35
Во многом ЕА как раз и подкупает своей ненавязчивостью тех или иных приемов и методик. :) Хотите - используйте, не хотите -  не используйте, а хотите - смешайте все в кучу. Это упрощает  знакомство с ним, и от этого потом сложно отвыкнуть. Да есть проблемы:
  • нельзя в текст вставить гиперлинк на что-нибудь или картинку
  • нет русской проверки орфографии (ну или мне версия такая попалась?!)
  • местами встречаются забавные проглюки типа разного поведения свойств требования при создании через иерархию объектов и через диаграмму...
  • При изменении требования матрица трассировок не подсказывает, что нужно проверить связи и связанные требования
  • выгруженный документ приходится доводить руками до корпоративного шаблона (хотя это отчасти проблема шаблона :) )
Но в целом впечатление хорошее. Разве что массовая работа участников проекта вскроет какие-то проблемы.



Re: Система управления требованиями Ответ #22 : 25 Ноября 2009, 22:16:50
ЕА - это конструктор. Гибкий и мощный. Как хотите - так и настраивайте. За что мне он и нравится :)
Русской проверки орфографии у них я не видела, но в России у них нет представителей вообще, только продавцы.



Re: Система управления требованиями Ответ #23 : 26 Ноября 2009, 13:00:43
ЕА - это конструктор. Гибкий и мощный. Как хотите - так и настраивайте. За что мне он и нравится :)
На самом деле он так не позиционируется. Если бы ЕА был классически конструктором, то он имхо имел бы нечто вроде одинэсного конструктора по созданию конфигурации.

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



Re: Система управления требованиями Ответ #24 : 26 Ноября 2009, 22:37:38
Поиски "идеальной" системы продолжаются.

Активно рассматриваются RequisitePro, DOORS и некоторые другие. Инструменты хороши, но цена...

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

Иерархия артефактов просто поразила ПМа. "Вот это вещь". Поиск с использованием SQL... Но, но и опять но.

Бог с ней бейзлайн. В конце концов можно использовать SVN и утилиты к нему.

Но вот по матрице похоже есть прокол.
1. Отсутствие фильтрации в матрице
2. Отсутствие сигнализации по изменению в матрице (как это сделано например в RequisitePro)
3. Нельзя кроме визуально инспекции понять быстро и наглядно, а что не покрыто, где требования не привязаны или не реализованы ничем (это в случае большого количества требований). Вероятно что-то типа этого
4. Примитивная история изменений
5. Не отслеживание истории изменений в документах (хотя наверное SVN может взять это на себя, хотя не покажет что и где именно изменилось)
6. Управление изменениями можно сказать нет

Вопрос к коллегам, кто активно использует ЕА для управления требованиями. Может все это решаемо? Или по крайней мере можно найти какой-то приемлемый компромисс?

Можете поделиться опытом использования? Можно ли сделать ставку на этот продукт?
« Последнее редактирование: 26 Ноября 2009, 22:44:21 от Galogen »



Re: Система управления требованиями Ответ #25 : 26 Ноября 2009, 23:44:18
Поиски "идеальной" системы продолжаются.

Активно рассматриваются RequisitePro, DOORS и некоторые другие. Инструменты хороши, но цена...
Но вот по матрице похоже есть прокол.
1. Отсутствие фильтрации в матрице
2. Отсутствие сигнализации по изменению в матрице (как это сделано например в RequisitePro)
3. Нельзя кроме визуально инспекции понять быстро и наглядно, а что не покрыто, где требования не привязаны или не реализованы ничем (это в случае большого количества требований). Вероятно что-то типа этого
4. Примитивная история изменений
5. Не отслеживание истории изменений в документах (хотя наверное SVN может взять это на себя, хотя не покажет что и где именно изменилось)
6. Управление изменениями можно сказать нет
Можете поделиться опытом использования? Можно ли сделать ставку на этот продукт?

Я бы не делал на него ставку как на инструмент работы с требованиями. EA хорошь возможностью легко построить многоуровневую связанную модель.
Мы вели требования в ReqPro (с историей и архивацией), а в EA - переносили их и строили от них модель "вниз" (и тут он был почти идеален).
Разумеется - синхронизация была вручную.... 



Я бы не делал на него ставку как на инструмент работы с требованиями. EA хорошь возможностью легко построить многоуровневую связанную модель.
Странно, что ЕА позиционируется как система управления требованиями. И в принципе, если почитать их документацию, кажется, вполне себе.

Цитировать
Мы вели требования в ReqPro (с историей и архивацией), а в EA - переносили их и строили от них модель "вниз" (и тут он был почти идеален).
Вся проблема, что ReqPro слишком дорогой, более 3000 $ одна лицензия. Использовать контрафакт?

Цитировать
Разумеется - синхронизация была вручную.... 

А в чем она конкретно заключалась?



По совету модератора, изменил в очередной раз название темы. Возможно оно более точно описывает суть проблематики.

Действительно. Проект отраслевой (все может изменится, но пока не вижу тенденций). Клиентская база расширяется.

Организация практически продает услугу (правда вместе с продуктом), в стиле очень похожем на то, что предлагает Гольдрат: продавать пар, а не паровую машину.

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

Клиентура расширяется и становится все более серьезной по финансовым условиям, по требованиям и т.п.

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

При этом следует соблюсти баланс цены и возможностей, обеспечить использование как есть (без потребности что-то изменять и адаптировать с напильником)



Странно, что ЕА позиционируется как система управления требованиями. И в принципе, если почитать их документацию, кажется, вполне себе.

Тогда - зачем там возможность генерить код?:)
Я всегда смотрел на него именно как на полноценную замену  IBM Rational Rose - легкий способ получить полную и связанную многоуровневую UML модель вплоть до уровня реализации.
 
Вся проблема, что ReqPro слишком дорогой, более 3000 $ одна лицензия. Использовать контрафакт?

Купить 2 использовать 10:)

А в чем она конкретно заключалась?

Все требования, которые создавались в ReqPro создавались/редактировались вручную в EA. Имена и группировки брались из RP. Далее - в EA от них строилась полная модель.
При изменении состава требований или их важных свойств в RP - эти изменения переносились (они получались отчетом об изменениях) в EA человеком.



Тогда - зачем там возможность генерить код?:)
Я не говорю, что ЕА исключительно СУТ. Я лишь сказал, что его часто позиционируют как СУТ. Посмотрите многие списки по системам - ЕА там неизменно фигурирует, наряду с RaQuest, RequisitePro. Причем иные uml средства типа VisualParadigm в них нет.

Цитировать
Купить 2 использовать 10:)
7 тысяч долларов дороже 3,500. А у нас и на 3,500 нет бюджета :)




 

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