В теме 20 ответов, и 9 участников, последнее обновление сделано пользователем 
Denis Syropushchinsky 13 г, 7 мес. назад.
-
Сообщения
-
Хотелось бы узнать подробнее о Requirements tracking tools от тех, у кого есть опыт работы с таковыми. Насколько это упрощает жизнь аналитику, какие инструменты наиболее распространены, общие впечатления о работе с ними и вообще все, что связано с Requirements traceability.Enterprise Architect и Visual Paradigm имеют функциональность для отслеживания требований — "Traceability Matrix", но это только функционал. Отдельного софта исключительно преднажначенного для requirement tracking я не встречал. Думаю, что проктичестки любой достойный тул по управлению требованиями будет включать в себя traceability функциональность.Из того, что нашла я:
DOORS http://www-01.ibm.com/software/awdtools/doors/
Case Spec http://www.analysttool.com/
Workspace http://www.workspace.com/workspace/Requ … tware.html
OSRMT http://sourceforge.net/projects/osrmt/Это то, что на первый взгляд смогло меня заинтересовать. А вообще тулзов для Requirements tracking хватает, потому хотелось бы услышать мнение того, у кого есть опыт их использования.
Сразу отвечу на твой последний вопрос: ни одно из перечисленных 4ых средств я не использовал. Более того, парочки названия я раньше даже не слышал.
Что касается изначального вопроса, то у меня, как у человека, который поработал / работает, как координатор / лид / ПМ, есть мнение, что согласно принципу Бритвы Оккамы, для всех членов процесса разработки ПО я бы предпочел использовать единое средство. По крайней мере, при выборе инструмента для отслеживания / управления требованиями, у меня этот критерий (возможность использования этого же средства для остальных членов проекта) был бы одним из первых.
Я пользовался (как и все аналитики, поработавшие в нашей команде) MS TFS (Microsoft Team Foundation Server). TFS обобщает такие понятия как требование, аналитическая задача, баг в спеке и некоторые другие в понятие Work Item. Эта "единица работы" потом участвует в жизненном цикле разработки ПО, позволяя в том числе себя отслеживать (track). Также хочу напомнить, что MS TFS позволяет загружать, настраивать и применять шаблоны как различных схем работы с Work Items, так и шаблоны самих Work Items.p.s. Но я собираюсь ознакомиться хотя бы одним из предложенных тобою средств.. Спасибо..
Полностью согласна с Юрой насчет единого средства для всех членов команды. Это одна из причин, почему я всегда обходила requirement tracking tools стороной
мне казалось, это ненужное усложнение и бонусы от него весьма сомнительные.
В общем жду отзывов о работе с ними.Я согласен с Асей по поводу постановки и актуальности вопроса. Я сам неоднократно набредал на просторах интернета на описание таких тулов и у меня постоянно возникал вопрос — а что же это такое и с чем его едят? Насчет EA и TFS — да, их можно юзать для этой цели и если этого хватает для целей проекта, то прекрасно. EA — сложновато, а вот TFS — в самый раз (сам ведь юзаю ).
Но.. что меня здесь интересует еще больше… Знаете, пока не узнаешь, а ЧТО МОЖЕТ тот или иной тул, ты и не скажешь, что мне хватает того, что я использую сейчас.
К примеру, я вот когда-то интересовался такими мощными тулами как Borland Caliber или IBM Doors[/url](они позиционируются как requriements management tools, но есть подозрение, что это то же самое в рамках нашей дискуссии). Собственно, если у кого-то есть опыт использования чего-то из перечисленного, то прошу отозваться. Я попробую при наличии времени поюзать хотя бы триал чего-то из этого.Привет всем,Я тут скачал и потестил Borland CaliberRM 2008 SP1 и хочу поделиться общими впечатлениями. Особо глубоко в изучении тула я не продвинулся, поэтому расскажу то, что успел увидеть и попробовать.
Условия использования:
Это платная система и весит порядка 600 мб. Я думаю, кряк достать в нете возможно – я же пока установил триальную версию сроком на месяц.
Архитектура и компоненты:
По компонентной архитектуре тул довольно навороченный – во-первых, отдельно ставится серверная и клиентская часть, так как Caliber работает по концепции централизованного репозитория проектов. Клиенты же могут юзать один из следующих вариантов: клиентское декстопное приложение, веб интерфейс или плагин для сторонних систем (e.g . MS Visual Studio – довольно полезно в моем случае, хотя я пока его потестить не успел).
Caliber имеет довольно гибкую и мощную систему разграничения доступа к проектам. Успел заметить следующие группы пользователей – Project Administrators, Quality Assurance, Design, Development, Marketing, Guests. Есть возможность настраивать свои группы и их пермишны.
Новые проекты создаются Администраторами на уровне серверного компонента. При создании выбираются группы и конкретные люди, которые будут иметь доступ; список глоссариев проекта; baselines проекта и настройки traceability требований (есть возможность привязать к WI TFS). Выбираются типы требований, которые будут разрабатываться в данном проекте: Business Requirements, User Requirements, Functional Requirements, Design Requirements, Project Tasks (WBS), Test Scenarios и Constraints.
Обзор фич:
Когда проект настроен, начинается работа аналитика по всем перечисленным типам требований.
Business Requirement – для каждого требования заполняются много атрибутов и параметров Основные: имя, версия (есть хорошая система версионности), статус (в проге есть довольная мощная система прохождения аппрувалов у нужных участников проекта), приоритет, аттач файлов, ноутов, гиперссылок, трейсы на другие требования разных уровней. Для требования есть некоторое подобие форума –дискуссии. Кроме того, для требования можно оформить текстовое сопровождение (как в спецификации – с таблицами, встроенными рисунками и т.д.) – текстовый редактор слабее ворда, но неплох в принципе.
User Requirement – кроме вышеперечисленного есть опция задать юз кейсы со степами в текстовом режиме (заполнение полей-параметров юз кейса).
Functional Requirement - кроме вышеперечисленного есть опция задать эстимации различных уровней.
Project Task (WBS) – это, я бы сказал, урезанная версия MS Project. В принципе юзабельно, но MS Project более гибок и мощен для этих целей.
Для остальных в принципе все похоже и ничего примечательного я не нашел.
Другие фичи:
1. Генерация документов. Доки генерятся на основе стандартных .dot шаблонов. На первый взгляд кастомизация легкая и удобная. Эта фича мне понравилась.
2. Ссылки на глоссарий. Очень легко привязывать текст и описание требований к глоссарию проекта.
3. Reports. Построение отчетов различных разрезов по проекту.
4. Traceability Matrix – аналог оной в EA, только помощнее в плане фильтров и условий.
Итог:
Так как я впервые сталкиваюсь с таким тулом, то мне он понравился. Но использовать и внедрять не проектах я пока не буду. Хочется что-то помощнее – со встроенным UML-редактором, wireframes дизайнером, текстовым редактором не слабее ворда Будем искать и тестировать дальше.Хочу еще пару слов добавить о requirements management tools.Borland Caliber и IDM Doors — доволльно мощные системы, но получить от них максимум пользы можно, судя по тому, что я накопал, только если юзать и в комплекте с другими продуктами Borland/IBM. И если выстроить длинную цепочку интегрированных между собой продуктов, то получится практически идеальная система. Минус главный один — стоимость этого всего добра.
Поэтому я лично пока образу свое внимание на более простые (но потенциально не менее интересные аналоги).
Неплохой список тулзов можно найти вот тут: http://www.jiludwig.com/Requirements_Management_Tools.htmlЯ пробежался по всем позициям в списке и обратил внимание на следующие:
1. Clariys
2. TopTeam Analyst
3. Case Spec[/url]
4. AccompaНе знаю, хватит ли сил и траффика на все
. Если у кого-то есть желание помочь в изучение, буду признателен.Я имею большой опыт работы с Калибером. Последняя версия намного стабильней чем 2005. Но кряк на 2008 SP 1 до сих пор не нашел
Буду весьма признателен если коллеги поделятся.К сожалению, ключа нет. А не могли бы поделиться своим мнением о Борланде? С какой целью используете? Насколько это улучшает процесс с требованиями (к примеру сравнение "до" и "после")? Какие недостатки видите? Есть ли опыт работы с другими requirements management tools?Некоторое время назад вел проект для одного заказчика, который делегировал нам полномочия по созданию требований к продукту, а сам их ревьюил и формировал некоторое общее видение функциональности системы.Были две проблемы: удаленный заказчик и удаленная команда (фактически распределенная по нескольким городам), а также отсутствие денег на какой-либо инструментарий. В этом проекте использовал DEVPROM, который позволяет вести и "трекать" требования совместно с остальными артефактами проекта, например, тестовыми сценариями.
До этого был опыт использования RequisitePro и классического "куча MSWord-документов". Никому не пожеланию ни того, ни другого, а вот DEVPROM чем зацепил — это простотой, доступностью и связкой со всем процессом разработки.
Вообще, я считаю, что рассматривать управление требованиями в отдельности от всего процесса — это неправильно, инструмент нужно выбирать соответствующий, который позволит вам связать все проектные артефакты воедино.
saveug, спасибо за отзыв.
Можно поподробнее про Requisite Pro и DEVPROM? Сравнительный анализ, как интегрируются в процесс разработки ПО?
В целом я согласен с утвреждением про связь со всеми проектными артефактами. Но.. мы к примеру используем MS TFS в качестве системы контроля версий, хранилища документации, баг и таск трекинг системы и билд машины — короче, для всего процесса разработки. В принципе использовать его и как requirements management tool тоже можно вполне сносно. Но на первый взгляд/предположение есть аналитические системы и помощнее, причем некоторые удачно интегрируются с TFS.Скажу сразу, что я не искушенный пользователь бизнес-процесса под названием "Управление требованиями", большая часть наворотов никогда не использовалась и вряд ли будет. В этом смысле RequisitePro был отвергнут сразу же после использования на одном проекте: тяжелый (в установке и интеграции с другими инструментами), многообразие неиспользуемых атрибутов, специфичный подход в интеграции с MSWord.В итоге, больше интересуют легковесные инструменты, которые позволяют: а) готовить требования, б) обсуждать их, в) контролировать изменения и г) связывать с исходной функциональностью, с тестовыми сценариями и т.п. Ничего из этого, кроме "а" RequisitePro делать не умеет или делает это в корявой форме.
DEVPROM в этом плане понравился своей простой и легкостью в использовании. Не скажу, что это инструмент для полноценного управления требованиями, но умеет, что нужно, также есть процедура согласования с заказчиком. Хотелось бы услышать как в TFS обстоят дела по управлению требованиями. В целом мы смотрели эти возможности, но там как я понял, все через внешние документы делается. А здесь как обычно одна проблема: рождаются монолитные монстры-описания, с которыми потом сложно существовать в проекте.
Привет,Немного по вашему посту:
"а) готовить требования" Немного неясная формулировка. Что есть подготовка требований? Извлечение, документирование? Если да, то не думаю, что подобные тулы помогут в этих вопросах. Мощнее текстового процессора, чем MS Word я не встречал и уверен, что ни один RMT не содержит оного — только через интеграцию с вордом. Моделирование и рисование? Да, здесь я согласен — если бы хотя бы один тул содержал полностью фукционирующую встроенную связку (к примеру) Visio + Enterprise Architect + Expression Blend, то я бы был и сам очень рад. TFS в этом плане не помощник. В нем, как и в Борланде, можно всего лишь создать объект типа "требование" с базовыми параметрами и прикрепить к нему всякой внешней всячины (доки, гиперссылки, модели — да все что угодно).
"б) обсуждать требования" В принципе, в большинстве RMT есть встроенные discussion boards. TFS в этом плане в принципе похож (может и нет так юзабельно, конечно). Там тоже можно оставлять комменты, аттачить файлы и т.д. (причем вся история отслеживается).
"в) контролировать изменения". Да, в TFS это можно. Вот только откат на предыдущие версии, я бы сказал, реализован лишь частично. Для документации версионность есть. Для требований (как ворк айтемов) насколько я знаю нет.
г) связывать с исходной функциональностью, с тестовыми сценариями. Ну вот собственно в этом и мощь TFS, так как в первую очередь это система контроля версий, билд машина и таск-трекинг система. Насчет функционала — да, абсолютно — все увязки вплоть до кусков кода. Насчет тест сценариев — точно не скажу, но вроде бы с основными тест тулами TFS интегрируется.Еще попробуйте TopTeam Analyst. Я немного поюзал его и могу сказать, что он явно менее громоздок чем Борланд к примеру, и гораздо более приятен. Хотя по основному функционалу, который нужен не слишком привередливы пользователям, он гораздо более удобен, чем Борланд (там и диаграммки риовать можно, и мокапы элементарные и т.д.). Ссылка есть в моем посте в этой теме.
У меня есть опыт работы с Borland Caliber RM (около 2х лет). И таки не пользуйтесь им, вот что я хочу Вам сказать. Это зло. =)Я пришла к следующим выводам. Если аналитиков 1-2 и система мелкая или средняя, то оптимальный инструмент это Word и SVN (или SharepPoint, главное чтобы версионирование было и возможность комментить изменения).
Если аналитов больше и система крупная, то wiki-подобная система. У нас успешно юзают Confluence для этих целей. Есть свои нюансы, но они не значительные. А еще Confluence красиво интегрируется с Jir-ой, а значит с багтрегингом и CR-трекингом. Вот.
Вы должны авторизироваться для ответа в этой теме.
