Управление требованиями
#1
Отправлено 09 марта 2006 - 09:01
И сравнить с использованием универсальных инструментов (Word, Excel, Notepad, MS Paint), допуская однако, что и в этих тулах управление требованиями можно вести грамотно, т.е. traceability, consistency и всё прочее будет присутствовать.
За счет чего, по вашему, (и сколько) можно сэкономить от использования RM tool?
Например, методом перебора (включая или отключая различные реквайрменты) оценивать суммарное время разработки - попадаем в сроки или нет
Или, автоматически генерировать драфт mpp (MS Project), с назначениями и сроками.
Или, например, избавиться от переписки со стейкхолдерами по почте.
Эффективную прибавку хорошо бы оценить в человековремени. Можно и в тугриках, но это сложнее, поскольку неизвестна стоимость сферической тулы.
Попробуем?
#2
Отправлено 09 марта 2006 - 14:09
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#3
Отправлено 09 марта 2006 - 15:01
Размер, тип проекта и используемую методологию будем учитывать?
Учитывать будем, а жестко фиксировать в "постановке задачи" не станем
Т.е. интересны возможные положительные эффекты на разных размерах, типах, и используемых методологиях.
#4
Отправлено 13 марта 2006 - 12:50
И сравнить с использованием универсальных инструментов (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 поддерживать, и для больших проектов!" -- профессиональное проклятье для системного аналитика ) + возможность видеть ВСЕ обозначенные связи конкретного требования в виде графической диаграммы (помимо матрицы трассировки).
6. Говоря о трассировке -- возможность трассировать к другим докуметам и файлам вообще, в т.ч. находящимся под конфигуправлением. И возможность трассировки к объектам StarTeam 2005 (в т.ч. к change requests, включая defects). Более шире -- на модели и тестовые сценарии (возможны вариации) и в добавок на программный код (например, в том же используя Delphi 2006)!
7. Контроль доступа -- только санкционированый доступ и гибкая настройка кто что может видеть/создавать/изменять ... удобно ли это реализовывать при работе с фоисными пакетами?
8. Возможность оповещения по e-mail об изменнии в т.ч. только в интересных лично вам, требований.
9. Для каждого требования можно определить множество атрибутов, включая ответственных лиц, оценку сложности реализации данного требования, вероятность изменения в будущем ... и т.д.
10. В конечном итоге -- возможность легкого импорта в репозитарий CaliberRM требований из тех же документов Word ... и возможность генерации по шаблонам любых документов профкессионального качества (включая таблицы, рисунки), которые вам потребуются используя Document Factory, в т.ч. ТЗ, SRS, ... :-)
Говоря о генерации задач в терминах упрравления проектами, то они как правило базируются на требованиях -- но не всегда (зависит от процесса) требование = task. Чаще, задания на разработку нарезаются уже в средствах конфигуправления, на основе change requests соответствующего типа ... и трассируются на требования.
Консультант Borland
#5
Отправлено 14 марта 2006 - 03:41
Весьма удачное и удобное решение в совокупности с их другими программными средствами.
#6
Отправлено 15 марта 2006 - 10:04
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.
#7
Отправлено 15 марта 2006 - 15:35
про Калибер
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.
see this thread
Q: With our version of CaliberRM it seems not to be possible to type a capital "Y" ??? ...We are using CaliberRM 2005 Release 2.
A1 (someone from borland): Yea, this is a very embarrassing defect that made it into the 2005 R2 release. Please contact support for the fix.
A2: This is not the only regression defect in R2. Anyone upgrading to this version should check it carefully to make sure their favorite features still work properly.
#8
Отправлено 16 марта 2006 - 12:35
про Калибер
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.
Какие именно ошибки возникали, и какая версия можно узнать??? А то так вообще без конретики, как-то непонятно ... ошибки они же везде есть ... даже в создаваемом вами ПО :-).
Консультант Borland
#9
Отправлено 16 марта 2006 - 12:38
про Калибер
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.
Q: With our version of CaliberRM it seems not to be possible to type a capital "Y" ??? ...We are using CaliberRM 2005 Release 2.
A1 (someone from borland): Yea, this is a very embarrassing defect that made it into the 2005 R2 release. Please contact support for the fix.
A2: This is not the only regression defect in R2. Anyone upgrading to this version should check it carefully to make sure their favorite features still work properly.
А вы до сих пор этот патч не поставили? У меня так стоит уже. Действительно можно получить его обратившись в техподдержку, при условии легальности используемой вами версии ... :-)
Консультант Borland
#10
Отправлено 16 марта 2006 - 14:36
Я надеюсь Вы не подумали, что я это все выдумал, что бы очернить Ваше светлое имя? ;)Какие именно ошибки возникали, и какая версия можно узнать??? А то так вообще без конретики, как-то непонятно ... ошибки они же везде есть ... даже в создаваемом вами ПО :-).
Попозже гляну, сохранился ли дистрибутив и тогда скажу версию. Но ошибки все я на сайте Борланда нашел. Правда их решения там не было.
#11
Отправлено 19 марта 2006 - 09:51
Какие именно ошибки возникали, и какая версия можно узнать???
CaliberRM2005R2Trial.exe
Часть ошибок на сайте Борланда была. Ссылки на них искать не буду.
Сообщение отредактировал Kaluga: 19 марта 2006 - 09:56
#12
Отправлено 23 марта 2006 - 15:54
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#13
Отправлено 23 марта 2006 - 16:29
Для начала определимся с задачей.Господа, предлагаю обсудить эффект от использования специализированных тулов для ведения требований к продукту (Requirement Management Tool), взяв за основу сферическую тулу в вакууме (PACE, RMTrak, Reconcile, Caliber RM, DOORS, Requisite Pro ... сложить и поделить).
И сравнить с использованием универсальных инструментов (Word, Excel, Notepad, MS Paint), допуская однако, что и в этих тулах управление требованиями можно вести грамотно, т.е. traceability, consistency и всё прочее будет присутствовать.
За счет чего, по вашему, (и сколько) можно сэкономить от использования RM tool?
Например, методом перебора (включая или отключая различные реквайрменты) оценивать суммарное время разработки - попадаем в сроки или нет
Или, автоматически генерировать драфт mpp (MS Project), с назначениями и сроками.
Или, например, избавиться от переписки со стейкхолдерами по почте.
Эффективную прибавку хорошо бы оценить в человековремени. Можно и в тугриках, но это сложнее, поскольку неизвестна стоимость сферической тулы.
Попробуем?
Мы рассматриваем "Управление требованиями" или "Разработку требований"? Исходя из формулировки вопроса, видимо рассматриваем и то и другое.
Т.е рассматриваем преимущества / недостатки различных подходов в реализации задач (по CMMI):
1. Управление требованиями
1.1 Выработка понимания требований
1.2 Принятие обязательств по реализации требований
1.3 Управление изменениями требований
1.4 Выявление несоответствий между рабочими продуктами и требованиями
1.5 Поддерживание двустороннего прослеживания требований
2. Разработка требований
2.1 Разработка требований заказчика
2.2 Разработка требований к продукту
2.3 Анализ и проверка требований
Плюс к этому нужно оценивать преимущества / недостатки для таких задач, как:
3.1 Передача требований другим членам команды
3.2 Формирование плана работ на основании требований
Рассмотрим возможные варианты решений.
1. Специализированные средства. (Сферические, в вакууме).
2. Универсальные средства.
3. "Нетрадиционные". Такие например, как белые доски и плакаты. (см. А. Коберн "Быстрая разработка программного обеспечения", стр 99-101, ...)
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#14
Отправлено 24 марта 2006 - 14:28
Если так ставить вопрос, то управление.Для начала определимся с задачей.
Мы рассматриваем "Управление требованиями" или "Разработку требований"? Исходя из формулировки вопроса, видимо рассматриваем и то и другое.
Допустим, что "Как правильно писать ЮзКейсы" все знают.
Поэтому, ограничимся этим:
Т.е рассматриваем преимущества / недостатки различных подходов в реализации задач (по CMMI):
1. Управление требованиями
Плюс к этому нужно оценивать преимущества / недостатки для таких задач, как:
3.1 Передача требований другим членам команды
3.2 Формирование плана работ на основании требований
Рассмотрим возможные варианты решений.
1. Специализированные средства. (Сферические, в вакууме).
2. Универсальные средства.
Что скажете?
#15
Отправлено 24 марта 2006 - 15:16
Я бы не стал выкидывать нетрадиционные средства. В ряде проектов они эффективней универсальных и специализированных средств. В разы.Если так ставить вопрос, то управление.
Поэтому, ограничимся этим:Т.е рассматриваем преимущества / недостатки различных подходов в реализации задач (по CMMI):
1. Управление требованиями
Плюс к этому нужно оценивать преимущества / недостатки для таких задач, как:
3.1 Передача требований другим членам команды
3.2 Формирование плана работ на основании требований
Рассмотрим возможные варианты решений.
1. Специализированные средства. (Сферические, в вакууме).
2. Универсальные средства.
Что скажете?
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#16
Отправлено 24 марта 2006 - 15:47
2byur. Эта ветка не предназначена для рекламы продуктов конкретной фирмы.
В этой ветке полно постов, описывающих работу кконкретных продуктов ..., не так ли? ...
А я описываю то, с чем я реально работаю ... год назад описывал бы работу RequisitePro :-) ... это реальная информация, не имющая отношения к рекламе.
Или я где-то соврал?
Консультант Borland
#17
Отправлено 24 марта 2006 - 15:55
Я бы не стал выкидывать нетрадиционные средства. В ряде проектов они эффективней универсальных и специализированных средств. В разы.Если так ставить вопрос, то управление.
Рассмотрим возможные варианты решений.
1. Специализированные средства. (Сферические, в вакууме).
2. Универсальные средства.
А в большом ряде проектов по разработке систем автоматизации бизнеса у заказчика нужно подписать документацию требований к ПО. А если госконтора -- то еще и ТЗ по ГОСТ 34 выложи ... в этих случаях, к сожалению фотографии с флипчарта не приложешь к ТЗ.
А исходный вопрос все-таки о преимуществах тулов перед текстовыми процессами и электронными таблицами ... так причем тут доска с фломастерами ... ???
Консультант Borland
#18
Отправлено 24 марта 2006 - 17:30
А исходный вопрос все-таки о преимуществах тулов перед текстовыми процессами и электронными таблицами ... так причем тут доска с фломастерами ... ???
мммм.... к тому, что цель - ясный и эффективный процесс ведущий у выпуску качественного программного продукта продукта within given time and budget, а не использование конкретного тула?
#19
Отправлено 25 марта 2006 - 17:53
А исходный вопрос все-таки о преимуществах тулов перед текстовыми процессами и электронными таблицами ... так причем тут доска с фломастерами ... ???
мммм.... к тому, что цель - ясный и эффективный процесс ведущий у выпуску качественного программного продукта продукта within given time and budget, а не использование конкретного тула?
Эта цель озвучена лично вами, а не автором вопроса, не так ли? ... Исходный вопрос был СФОРМУЛИРОВАН иначе. Повторюсь, что в БОЛЬШИНСТВЕ проектов, которые делаются на заказ, особенно госструктурами, одной доской с фломастерами не обойтись ... При создании shareware, или ПО типа "Печать платежного поручения" -- вполне может быть, что разработчики используют доску с фломастером. Кажому проекту -- своя методология (с) А. Cockburn
P.S. Попробуйте в Сбербанке или в ВТБ сделать проект без напасания ТЗ ... или приложите фотографии с доски в ТЗ ... :-).
Консультант Borland
#20
Отправлено 27 марта 2006 - 09:43
Я не против специализированных средств. Я против их бездумного использования.Эта цель озвучена лично вами, а не автором вопроса, не так ли? ... Исходный вопрос был СФОРМУЛИРОВАН иначе. Повторюсь, что в БОЛЬШИНСТВЕ проектов, которые делаются на заказ, особенно госструктурами, одной доской с фломастерами не обойтись ... При создании shareware, или ПО типа "Печать платежного поручения" -- вполне может быть, что разработчики используют доску с фломастером. Кажому проекту -- своя методология (с) А. Cockburn
P.S. Попробуйте в Сбербанке или в ВТБ сделать проект без напасания ТЗ ... или приложите фотографии с доски в ТЗ ... :-).
Кстати, о доске с фломастерами я не говорил. Что называется, есть варианты.
Я не спорю, что при заказной разработке используют ТЗ. Хорошо, пусть будет часто используют ТЗ. Если система умеет генерить ТЗ - это неплохо. Если умеет делать это по 34 гостам - совсем хорошо. Пусть даже это не управление требованиями, но это плюс.
PS. А что в Сбербанке больше нельзя програмить без ТЗ? Раньше можно было. Куда катится мир... ;-)
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных