Перейти к содержимому

Фотография

Управление требованиями


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 27

#21 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 27 марта 2006 - 10:21

Если рассматривать весомые преимущества специализированных средств, то это в первую очередь:
* Управление приоритетами
* Управление порядком выпуска по версиям
* Генерация и работа с матрицей прослеживаемости

Такие вещи как:
* Возможность одновременного редактирования
* История изменений требований
* Разграничение прав доступа
* и т.д.
приятные дополнения. Если они есть - хорошо, нет - можно обойтись (как правило).

Управление приоритетами и разбиением по версиям. На мой взгляд, потребность хоть какого-то учета возникает от 30-50 требований. Потребность последовательного документирования от 150-300. Необходимость специализированной системы появляется, когда требований становится около 1000.
С матрицей прослеживаемости цифры примерно те же.
Но это мое мнение.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#22 Sergio83

Sergio83

    Новый участник

  • Members
  • Pip
  • 1 сообщений

Отправлено 13 сентября 2006 - 14:33


И сравнить с использованием универсальных инструментов (Word, Excel, Notepad, MS Paint), допуская однако, что и в этих тулах управление требованиями можно вести грамотно, т.е. traceability, consistency и всё прочее будет присутствовать.

За счет чего, по вашему, (и сколько) можно сэкономить от использования RM tool?
Например, методом перебора (включая или отключая различные реквайрменты) оценивать суммарное время разработки - попадаем в сроки или нет
Или, автоматически генерировать драфт mpp (MS Project), с назначениями и сроками.
Или, например, избавиться от переписки со стейкхолдерами по почте.

Эффективную прибавку хорошо бы оценить в человековремени. Можно и в тугриках, но это сложнее, поскольку неизвестна стоимость сферической тулы.


Хм ... я конечно видел примеры расчетов ROI от использования инструментальных средств и в частности для разработки и управления требованиями, но -- там очень много project specific параметров и условностей. В частности, учитываются инвестеционная сторона -- сумма, потраченная на закупку лицензий и тренинги, Rework Cost Estimates и в частности средние величины стоимости переделок системы, связанные с требованиями. Размер проекта (в частности в LOC), затраты на проект и т.п. Вообще -- оценка достаточно условная получается. Более простой путь дать качественные оценки преимуществ использования инструментальных средств (могу говорить в данном случае о Borland CaliberRM), перед обычными офисными пакетами:

1. Многопользовательская работа над документом -- с файлом Word проблематично работать одновременно нескольким пользователям.
2. Контроль версий КАЖДОГО ТРЕБОВАНИЯ в отдельности (а не всего документа), с возможностью последующего проведения baselines с гибким включением именно конкретных ВЕРСИЙ (ревизий) требований. Гарантия что все участники имют самую свежую информацию.
3. Возможность отслеживать обсуждения требований прямо в инструментарии а не выискивать в многочисленных email (особенно если поставить web клиента или прсто клиентскую часть CaliberRM заказчику) -- тем самым максимально вовлекая его в разработку ПО -- что рекомендуют agile практики.
4. Возможность утверждения baslines путем электронной подписи, которую просто может поставить назначенные ответственные лица. Как минимум для неформального утверждения (review), но можно и с заказчиком -- если условия позволяют.
5. Возможность быстро управлять трассировкой и автоматически получать suspect traces ... ("чтоб тебе всю жизнь матрицы трассировки вручную в Excel поддерживать, и для больших проектов!" -- профессиональное проклятье для системного аналитика :acute: ) + возможность видеть ВСЕ обозначенные связи конкретного требования в виде графической диаграммы (помимо матрицы трассировки).
6. Говоря о трассировке -- возможность трассировать к другим докуметам и файлам вообще, в т.ч. находящимся под конфигуправлением. И возможность трассировки к объектам StarTeam 2005 (в т.ч. к change requests, включая defects). Более шире -- на модели и тестовые сценарии (возможны вариации) и в добавок на программный код (например, в том же используя Delphi 2006)!
7. Контроль доступа -- только санкционированый доступ и гибкая настройка кто что может видеть/создавать/изменять ... удобно ли это реализовывать при работе с фоисными пакетами?
8. Возможность оповещения по e-mail об изменнии в т.ч. только в интересных лично вам, требований.
9. Для каждого требования можно определить множество атрибутов, включая ответственных лиц, оценку сложности реализации данного требования, вероятность изменения в будущем ... и т.д.
10. В конечном итоге -- возможность легкого импорта в репозитарий CaliberRM требований из тех же документов Word ... и возможность генерации по шаблонам любых документов профкессионального качества (включая таблицы, рисунки), которые вам потребуются используя Document Factory, в т.ч. ТЗ, SRS, ... :-)

Говоря о генерации задач в терминах упрравления проектами, то они как правило базируются на требованиях -- но не всегда (зависит от процесса) требование = task. Чаще, задания на разработку нарезаются уже в средствах конфигуправления, на основе change requests соответствующего типа ... и трассируются на требования.

Просмотр сообщения



Подскажите ,уважаемые, как можно редактировать в CaliberRM предыдущие версии требований - не текущие, а именно любый предыдущие.

Спасибо. :clapping:
  • 0

#23 _Sergey_

_Sergey_

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 01 декабря 2006 - 13:53

Мы использовали Requisite Pro. Честно говоря намучались порядочно. Но в 2004г решили перейти на DOORS. Куча проблем сразу забылась как страшный сон. Сейчас конец 2006, так и живем в DOORS. Пока все устраивает. Те 10 пунктов, о которых было сказано выше, система отрабатывает полностью!

Кстати, я не соглашусь Buyr в том, что требование = task. Это разные вещи и относятся к разным областям. Task (или задание) возникает из запроса на изменение. Т.е. возникает запрос на изменение (change request), который формулирует заказчик, и который достаточно абстрактный. Далее, на основании запроса на изменение менеджер продукта/проекта и т.д. (может называться по разному) формирует конкретные задачи (task), чтобы выполнить запрос на изменение. Это уже конкретные действия, коротые необходимо выполнить, для реализации запроса на изменение. В том числе может быть task на изменение требований.
  • 0

#24 Shander

Shander

    Активный участник

  • Members
  • PipPip
  • 82 сообщений
  • ФИО:Александр
  • Город:Санкт-Петербург

Отправлено 04 декабря 2006 - 10:30

Мы использовали Requisite Pro. Честно говоря намучались порядочно. Но в 2004г решили перейти на DOORS. Куча проблем сразу забылась как страшный сон. Сейчас конец 2006, так и живем в DOORS. Пока все устраивает. Те 10 пунктов, о которых было сказано выше, система отрабатывает полностью!

Просмотр сообщения


Сергей, если можно, несколько вопросов:
1. В чем именно заключались мучения с RPro, и как это решилось DOORSом?
2. Проводились ли у вас какие-либо тренинги по пользованию DOORS, самостоятельно или с привлечением Телелоджик?
3. Как вы находите документо-ориентированный подход к построению интерфейса, используемый в Дорсе, как скоро вы к нему привыкли?
4. Как проходил процесс адаптации Дорса к вашим имеющимся артефактам (спецификации требований)? Приспосабливали ли вы Дорс под ваши артефакты, или наоборот, артефакты под Дорс?
5. Сколько людей реально пользуются Дорсом, и как устроен сам процесс?

Заранее спасибо!
  • 0

#25 _Sergey_

_Sergey_

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 04 декабря 2006 - 13:30

Мы использовали Requisite Pro. Честно говоря намучались порядочно. Но в 2004г решили перейти на DOORS. Куча проблем сразу забылась как страшный сон. Сейчас конец 2006, так и живем в DOORS. Пока все устраивает. Те 10 пунктов, о которых было сказано выше, система отрабатывает полностью!

Просмотр сообщения


Сергей, если можно, несколько вопросов:
1. В чем именно заключались мучения с RPro, и как это решилось DOORSом?
2. Проводились ли у вас какие-либо тренинги по пользованию DOORS, самостоятельно или с привлечением Телелоджик?
3. Как вы находите документо-ориентированный подход к построению интерфейса, используемый в Дорсе, как скоро вы к нему привыкли?
4. Как проходил процесс адаптации Дорса к вашим имеющимся артефактам (спецификации требований)? Приспосабливали ли вы Дорс под ваши артефакты, или наоборот, артефакты под Дорс?
5. Сколько людей реально пользуются Дорсом, и как устроен сам процесс?

Заранее спасибо!

Просмотр сообщения


Отвечаю по Вашим пунктам:
1. Насколько я помню, работа RPro основана на документах Word и системы скрытых закладок, со всеми вытекающими последствиями. Word это просто текстовый редактор, а в случае в RPro он используется немного не по назначению, т.е. не для того, чтобы просто набивать текст, а заодно и для установления связей между документами и т.д. Конкретные проблемы с RPro назвать сейчас не готов (честно говоря не помню). Основная проблема была в том, что появлялись постоянные глюки, то ссылка полетит, то документ во время редактирования зависнет. Помню момент, когда мы решили уходить от RPro, это когда мы не смогли срочно загрузить и распечатать ТЗ, т.к. система зависала по непонятной причине. Это было последней каплей....
2. У Телелоджика много тренингов не только по DOORS, но и по всей линейке их инструментов. Мы провели тренинги по всему, что купили. Приехали преподаватели из Телелоджик и все провели. Лучше вопросы прямо к ним задавайте www.telelogic.ru
3. Привыкли достаточно быстно, всем показалось удобно. Конечно, может это потому, что коллектив молодой 25-35 лет и все готовы принимать новое, но у нас пошло все нормально. Документноотиентированный подход, мне кажется, легко воспринимается т.к. в реальной жизни мы имеем дело с документами (ТП, ТЗ, Тест. план и т.д.), поэтому получается просто моделирование реальной жизни.
4. У нас все документы были в RPro, т.е. почти в Word. На начальном этапе мы просто автоматом загрузили все в DOORS (там есть функция загрузки Вордовых документов). Сначала, правда, пришлось убивать все скрытые закладки, которые расставил RPro. Ну а потом вся работа велась в DOORS. Уже в самом DOORS ввели атрибуты, связи и т.д.
5. Реально пользует 5 бизнес-аналитиков, 10 программистов, 2 тестировщика. О самом процессе много писать. В двух словах: бизнес-аналитики пишут требования, разработчики смотрят требования и изменяют статусы, тестировщики пишут тестовые планы и тоже ставят статусы.
  • 0

#26 JimR

JimR

    Опытный участник

  • Members
  • PipPipPipPip
  • 253 сообщений
  • ФИО:Ручко Дмитрий Иванович
  • Город:Москва

Отправлено 25 декабря 2006 - 14:09

Насколько мне показалось - в DOORS все-же несколько специфичный подход. Рассматривали ли вы иные варианты работы с требованиями?

Просто я сейчас сам нахожусь на этапе поиска нужного инструмента. И так как времени не очень много - не хочется да и особо некогда ставить триалы от всех производителей. А проверять их с помощью сотрудников на реальных проектах - как-то некошерно. Это ведь тоже лишнее время на освоение. Да и ещё нужно каждому объяснить что я хочу узнать в итоге.

Я решил посмотреть в сторону Optimal Trace. Был ли у кого опыт работы с данным инструментом? Или результаты сравнения инструментов друг с другом?
  • 0
Дмитрий Ручко
InfoTeCS

#27 Shander

Shander

    Активный участник

  • Members
  • PipPip
  • 82 сообщений
  • ФИО:Александр
  • Город:Санкт-Петербург

Отправлено 27 декабря 2006 - 13:46

Насколько мне показалось - в DOORS все-же несколько специфичный подход. Рассматривали ли вы иные варианты работы с требованиями?


Совершенно согласен, мне показалось что как раз именно в DOORS практикуется документно-ориентированный подход, а в RPro более привычное иерархическое дерево.

Впрочем, он мне понравился именно своей необычностью, при том что в плане функционала там есть почти всё, что душе угодно.
  • 0

#28 _Sergey_

_Sergey_

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 27 декабря 2006 - 15:35

Насколько мне показалось - в DOORS все-же несколько специфичный подход. Рассматривали ли вы иные варианты работы с требованиями?

Просто я сейчас сам нахожусь на этапе поиска нужного инструмента. И так как времени не очень много - не хочется да и особо некогда ставить триалы от всех производителей. А проверять их с помощью сотрудников на реальных проектах - как-то некошерно. Это ведь тоже лишнее время на освоение. Да и ещё нужно каждому объяснить что я хочу узнать в итоге.

Я решил посмотреть в сторону Optimal Trace. Был ли у кого опыт работы с данным инструментом? Или результаты сравнения инструментов друг с другом?

Просмотр сообщения


Согласен, пробовать все подряд в деталях очень накладно. Сначала лучше провести "крупную" фильтрацию без триала. А в итоге один, максимум два варианта попробовать более тщательно.
В России работа с требованиями если и ведется, то все равно люди пока ее особо не осознали и не "прочувствовали" (специалистов маловато). Поэтому я бы посоветовал посмотреть на оценки систем управления требованиями на Западе в качестве "крупной" фильтрации, а дальше пользоваться личным предпочтением коллектива, интуицией и рекомендациями друзей ))). При покупке ДООРСа мы рассматтривали отчет Yphise - независимая компания (см. файл). Это последний отчет, но предыдущие имели похожую тенденцию.
Мы рассматривали DOORS, ReqPro, Caliber. На мой взгляд ReqPro больше ориентирован на документный подход. Caliber больше ориентирован на структурный подход (т.е. документ как таковой сложно отследить). DOORS стоит на стыке этих подходов, т.е. многое взято от ReqPor и Caliber (выделена как структура требований, так и документы). Это оказалось удобным при внедрении, поэтому и выбрали DOORS. Кстати, Telelogic предлагает кроме продукта подход к работе с требованиями. Есть полезная книга о требованиях на руссоком (кстати бесплатная): http://www.telelogic...-management.cfm

Удачного выбора! Всех с Новым Годом !!!!

Прикрепленные файлы


  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных