Спасибо за подробный ответ.
Я попробую подытожить, если с чем-то не согласны - пишите.
1. Какие бы инструменты не использовались для данных процессов, должна быть обеспечена информационная интеграция.
2. Рассматриваемые нами инструменты позволяют теми или иными усилиями обеспечить такую интеграцию.
Какие-то из инструментов имеют такую интеграцию по умолчанию, какие-то требуют допиливания.
3. Удобство разнесения функций по подсистемам оценивается разными специалистами по-разному, исходя из специфики их работы, привычек и т.п.
4. И что касается темы топика, то здесь, с учетом доступных альтернатив, чем на большее количество подсистем побито информационное пространство, тем ниже ROI, т.к. выше совокупная стоимость лицензий, допиливания, скручивания, обслуживания и т.п.
Основной интерес заключается в осуществлении конкретных вещей:
1. Иметь возможность сквозной трассировки от требований к проектным решениям, коду и тестам в интересах управления изменениями и конфигурацией системы.
2. Иметь возможность осуществления ресурсного и календарного планирования в части проектного управления, при этом получая от команды данные по факту.
3. И чисто для аналитика - иметь возможность генерации документации требований в различных форматах (i.e. требований разных стандартов)
Это может быть реализовано как набором продуктов, интегрированных между собой, так и в рамках одного "комбайна". При этом, следует заметить, что как минимум конфигурационное управление и управление изменениями может быть реализовано очень даже неплохо на бесплатных продуктах, не требующих затрат на лицензирование. Что повлияет положительно на ROI, но TCO нужно будет считать кончено ... но в случае, если я делаю конфигуправление и управление изменениями на знакомых мне инструментах затраты на обслуживание будут не столь велики. В случае расчета ROI, перекладывая на деньги экономию времени, которое тратиться непродуктивно на переключение м/у системами интересно было бы получить оценку этого времени в день. Вы наверняка считали бизнес-кейсы по инструменту и этот бенефит закладывали, приведите пожалуйста ту оценку, которую вы закладываете (?). По моим ощущениям, при необходимости ежедневной отчетности, это время не составит более 5 минут в день (именно ПЕРЕКЛЮЧЕНИЕ, а не сама отчетность по факту выполнения заданий!), интересно узнать вашу оценку.
И некоторые комментарии
А. Возможно идеи, заложенные в Rational Suite были и правильные, но насколько я знаю, полная их реализация там сильно страдала. Что собственно и заставило нас 7 лет назад провести фундаментальное исследование систем, тогда мы и нашли Cradle. Со связкой с ClearQuest я не работала полноценно, с этим работали другие отделы, но связку с Rose знаю неплохо, она меня не устраивала.
Кстати, на тот момент в Cradle также было разделение на модуль управления требованиями и моделирования (как в Rational) и надо сказать, когда 3SL полностью объединил эти два модуля в одной системе, это сняло большой объем рутинных операций. Так что этот комбайн мне очень даже нравится 
.
Как пользователь и Requisite и Cradle, могу сказать однозначно - Cradle. И этот выбор был сделан еще в 2006 году (продаем мы его с 2011 года). Там просто несравнимый объем возможностей для аналитиков. Особенно, если они готовы к MBSE.
Но, всем ли нужны возможности такого глубокого анализа и контроля ситуации? Именно поэтому, в начале топика я спрашивала, а какие проблемы хочется решить?
Б. Для того, чтобы не морочить голову ненужными данными, существует система разграничения прав доступа и области видимости, а также визуально настраиваемые запросы и представления.
В. Насчет проблемы с частью таска - проблемы не поняла.
Ок, хотел бы узнать, каким образом осуществляется трассировка в Cradle на исходный код из запросов на изменения (и заданий, созданных на их основе)? При этом очень интересно еще иметь возможность трассировки на определенный релиз, выраженный в исходном коде, некоторого модуля? С трассировками на тест-кейсы более-менее понятно, их можно завести как отдельную сущность и трассировать на них и от них ... Собственно для целей управления конфигурациями интересно понимать, в рамках чего и кем было сделано то или иное изменение.
Кроме этого, как осуществляется генерация документации требований (в т.ч. с возможность получать "дельта" документы на разные релизы)?
По части таска поясняю - таск может быть назначен на группу (аналитик, разработчик, тестер) и как в этом случае Cradle позволяет делать отчет по выполнению работы аналитика, например и в итоге собирать готовность всего таска в целом?
Просмотр сообщений
.. вот честное слово, не могу себе представить зависть по отношению к топору