насколько я понимаю - это фиксация baseline? Если да например в RaQuest есть такой инструмент как сохранения таких baselines и версионный контроль.
дак и в калибере baselines имеют место быть, НО практика показала, что:
нужен ЦЕНТРАЛИЗОВАННЫЙ версионный контроль всех артефактов
(в нашем случае мне пришлось вести целую войну с отщепенцами-аналитиками, чтобы приучить их хранить версии своих требований в StarTeam-е - общем для всех хранилище артефактов ),
благо - из Калибера можно вызывАть Стартимовские формы для работы с требованиями и строить в ём матрицу трассировки как между родными элементами, так и между хранящимися в СтарТиме.
Между прочим, Питерцы тоже столкнулись с этой же проблемой, только решили её заранее и кардинально:
Увидели, что аналитики сторят свой отдельный курятник - и полностью закрыли им работу в Калибере.
поймите меня правильно: я отнюдь не апологет Борландовских продуктов, они мне достались без каких-либо вариантов выбора и намучился я немеряно.
Многое из очевидной функциональности приходилось либо конструировать на механизме дополнительных пользовательских полей и ручной работы с ними,
либо дорабатывать свои "примочки".
Но в этом процессе родилось понимание как общеметодических принципов так и преимуществ Борландовской ALM-концепции и пакета приложений для её реализации.
Так вот, все красивости Калибера (трейс-мэтриксы, бейз-лайны, дизайн-туллзы) оказались менее знАчимыми, чем возможность требованиям "жить" в одном хранилище с другими артефактами.
СтарТим имеет весьма бедный набор атрибутов для Требования, но возможность слинковать его единой связью с Задачами, Тест-Кейзами, кодом и сборкой продукта,
да притом ещё и с отслеживанием версий каждой из этих сущностей, - оказалась просто забойной.
В RaQuest вместе с EA существует многопрофильная трассировка. Требования к требованиям. Требования к вариантам использования, Требования к элементам UML, где в качестве элементов могут выступать и тест-кейсы.
А вот это действительно замечательно в Архитекте и чего нет в помине у Борланда:
Создать требование, а потом "показать пальцем" на соответствующий элемент поясняющей диаграммы - это круто.
EA рулит своей гениальной простотой:
- есть ЮМЛ-модель, состоящая из Элементов,
- для модели есть проекции-вьювы: диаграммы,
- есть возможность связать трассировочной связью требование и соответствующий набор Элементов Модели,
- если для требования нет специально разработанной диаграммы, (которую тоже можно при желании притрассировать к требованию),
- то для каждого из притрассированного к требованию элемента модели остаётся возможность увидеть список диаграмм, где он присутствует и выбрать подходящую диаграмму для просмотра.
НО! вспомним пункт из моего предыдущего поста:
Менеджмент требований раньше дизайна!
Т.е. многопрофильная трассировка раньше нужна для связывания ВЕРСИЙ задач, результатов их выполнения и результатов тестирования в их самом простом виде, но в комплексе.
Насколько я знаю - версионность для ЕА - вещь внешняя, хотя и возможная в интеграции с другим соответствующим туллзом.
Вот и получается, что для проджект-манагера и других тим-мемберов нужно вначале обеспечить возможность комплексной работы с требованием в самой примитивной форме его существования: текстовое описание.
А уже потом, для "избранных", давать возможность дизайна: моделирования и трассировки требований к элементам модели.
Насколько я знаю - эволюция Телелоджиковских продуктов тоже шла по этому пути: вначале были абзацы текста со своими ИД-шками и линками на другие абзацы, а диаграммы с моделями появились намного позже.
Управление требованиями