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

Фотография

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


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

#1 Shander

Shander

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

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

Отправлено 09 марта 2006 - 09:01

Господа, предлагаю обсудить эффект от использования специализированных тулов для ведения требований к продукту (Requirement Management Tool), взяв за основу сферическую тулу в вакууме (PACE, RMTrak, Reconcile, Caliber RM, DOORS, Requisite Pro ... сложить и поделить).

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

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

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

Попробуем?
  • 0

#2 SALar

SALar

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

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


Отправлено 09 марта 2006 - 14:09

Размер, тип проекта и используемую методологию будем учитывать?
  • 0

-- 

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

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

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

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

 


#3 Shander

Shander

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

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

Отправлено 09 марта 2006 - 15:01

Размер, тип проекта и используемую методологию будем учитывать?


Учитывать будем, а жестко фиксировать в "постановке задачи" не станем :blush:
Т.е. интересны возможные положительные эффекты на разных размерах, типах, и используемых методологиях.
  • 0

#4 byur

byur

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

  • Members
  • Pip
  • 7 сообщений
  • ФИО:Булуй Юрий

Отправлено 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 поддерживать, и для больших проектов!" -- профессиональное проклятье для системного аналитика :aggressive: ) + возможность видеть ВСЕ обозначенные связи конкретного требования в виде графической диаграммы (помимо матрицы трассировки).
6. Говоря о трассировке -- возможность трассировать к другим докуметам и файлам вообще, в т.ч. находящимся под конфигуправлением. И возможность трассировки к объектам StarTeam 2005 (в т.ч. к change requests, включая defects). Более шире -- на модели и тестовые сценарии (возможны вариации) и в добавок на программный код (например, в том же используя Delphi 2006)!
7. Контроль доступа -- только санкционированый доступ и гибкая настройка кто что может видеть/создавать/изменять ... удобно ли это реализовывать при работе с фоисными пакетами?
8. Возможность оповещения по e-mail об изменнии в т.ч. только в интересных лично вам, требований.
9. Для каждого требования можно определить множество атрибутов, включая ответственных лиц, оценку сложности реализации данного требования, вероятность изменения в будущем ... и т.д.
10. В конечном итоге -- возможность легкого импорта в репозитарий CaliberRM требований из тех же документов Word ... и возможность генерации по шаблонам любых документов профкессионального качества (включая таблицы, рисунки), которые вам потребуются используя Document Factory, в т.ч. ТЗ, SRS, ... :-)

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

#5 Darkus

Darkus

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

  • Members
  • PipPipPipPip
  • 424 сообщений
  • Город:Казахстан, г.Астана

Отправлено 14 марта 2006 - 03:41

Присоединяюсь к автору поста про Borland CaliberRM.
Весьма удачное и удобное решение в совокупности с их другими программными средствами.
  • 0

#6 Kaluga

Kaluga

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

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 15 марта 2006 - 10:04

про Калибер
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.
  • 0
no fate but what we make

#7 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 15 марта 2006 - 15:35

про Калибер
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.

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


see this thread :crazy:

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.
  • 0
Andrey Yegorov. Изображение

#8 byur

byur

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

  • Members
  • Pip
  • 7 сообщений
  • ФИО:Булуй Юрий

Отправлено 16 марта 2006 - 12:35

про Калибер
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.

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


Какие именно ошибки возникали, и какая версия можно узнать??? А то так вообще без конретики, как-то непонятно ... ошибки они же везде есть ... даже в создаваемом вами ПО :-).
  • 0
Булуй Юрий,
Консультант Borland

#9 byur

byur

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

  • Members
  • Pip
  • 7 сообщений
  • ФИО:Булуй Юрий

Отправлено 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.

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


А вы до сих пор этот патч не поставили? У меня так стоит уже. Действительно можно получить его обратившись в техподдержку, при условии легальности используемой вами версии ... :-)
  • 0
Булуй Юрий,
Консультант Borland

#10 Kaluga

Kaluga

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

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 16 марта 2006 - 14:36

Какие именно ошибки возникали, и какая версия можно узнать??? А то так вообще без конретики, как-то непонятно ...  ошибки они же везде есть ... даже в создаваемом вами ПО :-).

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

Я надеюсь Вы не подумали, что я это все выдумал, что бы очернить Ваше светлое имя? ;)
Попозже гляну, сохранился ли дистрибутив и тогда скажу версию. Но ошибки все я на сайте Борланда нашел. Правда их решения там не было.
  • 0
no fate but what we make

#11 Kaluga

Kaluga

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

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 19 марта 2006 - 09:51

Какие именно ошибки возникали, и какая версия можно узнать???


CaliberRM2005R2Trial.exe

Часть ошибок на сайте Борланда была. Ссылки на них искать не буду.

Сообщение отредактировал Kaluga: 19 марта 2006 - 09:56

  • 0
no fate but what we make

#12 SALar

SALar

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

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


Отправлено 23 марта 2006 - 15:54

2byur. Эта ветка не предназначена для рекламы продуктов конкретной фирмы.
  • 0

-- 

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

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

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

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

 


#13 SALar

SALar

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

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


Отправлено 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, ...)
  • 0

-- 

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

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

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

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

 


#14 Shander

Shander

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

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

Отправлено 24 марта 2006 - 14:28

Для начала определимся с задачей.
Мы рассматриваем "Управление требованиями" или "Разработку требований"? Исходя из формулировки вопроса, видимо рассматриваем и то и другое.

Если так ставить вопрос, то управление.
Допустим, что "Как правильно писать ЮзКейсы" все знают.

Поэтому, ограничимся этим:

Т.е рассматриваем преимущества / недостатки различных подходов в реализации задач (по CMMI):
1. Управление требованиями
Плюс к этому нужно оценивать преимущества / недостатки для таких задач, как:
3.1 Передача требований другим членам команды
3.2 Формирование плана работ на основании требований

Рассмотрим возможные варианты решений.
1. Специализированные средства. (Сферические, в вакууме).
2. Универсальные средства.


Что скажете?
  • 0

#15 SALar

SALar

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

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


Отправлено 24 марта 2006 - 15:16

Если так ставить вопрос, то управление.

Поэтому, ограничимся этим:

Т.е рассматриваем преимущества / недостатки различных подходов в реализации задач (по CMMI):
1. Управление требованиями
Плюс к этому нужно оценивать преимущества / недостатки для таких задач, как:
3.1 Передача требований другим членам команды
3.2 Формирование плана работ на основании требований

Рассмотрим возможные варианты решений.
1. Специализированные средства. (Сферические, в вакууме).
2. Универсальные средства.


Что скажете?

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

Я бы не стал выкидывать нетрадиционные средства. В ряде проектов они эффективней универсальных и специализированных средств. В разы.
  • 0

-- 

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

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

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

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

 


#16 byur

byur

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

  • Members
  • Pip
  • 7 сообщений
  • ФИО:Булуй Юрий

Отправлено 24 марта 2006 - 15:47

2byur. Эта ветка не предназначена для рекламы продуктов конкретной фирмы.

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


В этой ветке полно постов, описывающих работу кконкретных продуктов ..., не так ли? ...
А я описываю то, с чем я реально работаю ... год назад описывал бы работу RequisitePro :-) ... это реальная информация, не имющая отношения к рекламе.

Или я где-то соврал?
  • 0
Булуй Юрий,
Консультант Borland

#17 byur

byur

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

  • Members
  • Pip
  • 7 сообщений
  • ФИО:Булуй Юрий

Отправлено 24 марта 2006 - 15:55

Если так ставить вопрос, то управление.

Рассмотрим возможные варианты решений.
1. Специализированные средства. (Сферические, в вакууме).
2. Универсальные средства.

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

Я бы не стал выкидывать нетрадиционные средства. В ряде проектов они эффективней универсальных и специализированных средств. В разы.

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


А в большом ряде проектов по разработке систем автоматизации бизнеса у заказчика нужно подписать документацию требований к ПО. А если госконтора -- то еще и ТЗ по ГОСТ 34 выложи ... в этих случаях, к сожалению фотографии с флипчарта не приложешь к ТЗ.

А исходный вопрос все-таки о преимуществах тулов перед текстовыми процессами и электронными таблицами ... так причем тут доска с фломастерами ... ???
  • 0
Булуй Юрий,
Консультант Borland

#18 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 24 марта 2006 - 17:30

А исходный вопрос все-таки о преимуществах тулов перед текстовыми процессами и электронными таблицами ... так причем тут доска с фломастерами ... ???

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


мммм.... к тому, что цель - ясный и эффективный процесс ведущий у выпуску качественного программного продукта продукта within given time and budget, а не использование конкретного тула?
  • 0
Andrey Yegorov. Изображение

#19 byur

byur

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

  • Members
  • Pip
  • 7 сообщений
  • ФИО:Булуй Юрий

Отправлено 25 марта 2006 - 17:53

А исходный вопрос все-таки о преимуществах тулов перед текстовыми процессами и электронными таблицами ... так причем тут доска с фломастерами ... ???

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


мммм.... к тому, что цель - ясный и эффективный процесс ведущий у выпуску качественного программного продукта продукта within given time and budget, а не использование конкретного тула?

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


Эта цель озвучена лично вами, а не автором вопроса, не так ли? ... Исходный вопрос был СФОРМУЛИРОВАН иначе. Повторюсь, что в БОЛЬШИНСТВЕ проектов, которые делаются на заказ, особенно госструктурами, одной доской с фломастерами не обойтись ... При создании shareware, или ПО типа "Печать платежного поручения" -- вполне может быть, что разработчики используют доску с фломастером. Кажому проекту -- своя методология (с) А. Cockburn

P.S. Попробуйте в Сбербанке или в ВТБ сделать проект без напасания ТЗ ... или приложите фотографии с доски в ТЗ ... :-).
  • 0
Булуй Юрий,
Консультант Borland

#20 SALar

SALar

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

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


Отправлено 27 марта 2006 - 09:43

Эта цель озвучена лично вами, а не автором вопроса, не так ли? ... Исходный вопрос был СФОРМУЛИРОВАН иначе. Повторюсь, что в БОЛЬШИНСТВЕ проектов, которые делаются на заказ, особенно госструктурами, одной доской с фломастерами не обойтись ... При создании shareware, или ПО типа "Печать платежного поручения" -- вполне может быть, что разработчики используют доску с фломастером. Кажому проекту -- своя методология (с) А. Cockburn

P.S. Попробуйте в Сбербанке или в ВТБ сделать проект без напасания ТЗ ... или приложите фотографии с доски в ТЗ ... :-).

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

Я не против специализированных средств. Я против их бездумного использования.

Кстати, о доске с фломастерами я не говорил. Что называется, есть варианты.

Я не спорю, что при заказной разработке используют ТЗ. Хорошо, пусть будет часто используют ТЗ. Если система умеет генерить ТЗ - это неплохо. Если умеет делать это по 34 гостам - совсем хорошо. Пусть даже это не управление требованиями, но это плюс.

PS. А что в Сбербанке больше нельзя програмить без ТЗ? Раньше можно было. Куда катится мир... ;-)
  • 0

-- 

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

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

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

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

 



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

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