Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.

Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.

Сейчас используем JIRA + Confluence + SVN.
Требования в виде вордовских файлов хранятся в свн.
По требованиям ставятся задачи в JIRA.
При изменении требований/появлении новых ставятся новые задачи в JIRA, в т.е. на доработку ТЗ/документации.
Confluence используем как дополнительный, справочный материал.

сообщение устарело

Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.

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

Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.

Чтобы оценить эффект от внедрения количественно, вам необходимо иметь зафиксированные количественные параметры вашего текущего состояния. Т.е. то, с чем вы будете сравнивать эти параметры после внедрения.

Вот так и оцените: было - стало (разница). В этом вообще говоря смысл постановки задачи - не выдвигай непроверяемые требования (см. библию папы нашего Вигерса).

ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:

• Какие задачи выбрать для измерения? Они должны быть идентичны.
• На ком проводить измерения? Должны быть одни и те же люди.
• Как определить погрешность?
• Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)

pmle, bus
ЗЛ - руководители проектов (РП), заказчики 100%. Остальные под вопросом, поясню: по идеи все, кто участвует в процессе разработки ПО (аналитики, разработчики, тестеровщики, внедренцы) однако они работают по задачам из JIRA и что будут делать больше/быстрее для этих сотрудников не важно. Если будет удобнее работать, повысится качество, то да.


Провел небольшой опрос ЗЛ, в основном РП, выявил существующие проблемы/хотелки:

• Долгое согласование требований. Например требования еще не согласованы, а работы уже ведутся.
• Необходимость дополнительных систем для согласования требований. Например множество дублей в разных гуглдокс (требование - задача - статус) + это дублируется в жире (согласованно да/нет, основание для оплаты и т.д.)
• Необходимость полностью дублировать хотелки (требования), задачи, баги в issue tracker заказчика. Например заказчик создал десяток новых функциональных требований в своей системе. Мы должны перенести в свою, отработать, проверить, отчитаться в свое, в их, + внести изменения в доки.
• Хотелось бы по описанию задачи, была возможность выполнить поиск по вики, в какой раздел это относится, что бы оперативно внести изменения в нужные места. Трассировка т.е.
• При изменении требований система предлагала перестраивать задачи, связи между задачами, определять сроки, закрывать ненужные задачи. Так называемый интеллектуальный помощник.

p.s.Мне интересно, когда IBM предлагает RequisitePro за несколько килобаксов за 1 лицензию, как они обосновывают бизнесу (топ менеджерам, техническому директору, начальнику отдела анализа), что внедрение даст вам 1, 2, 3 и окупится за N месяцев/лет?

p.p.s.Может ли СУТ проверять атрибуты качества требований? (недвусмысленность, проверяемость, полнота)?

Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.

Что-то я не понял перехода — только задумались, а уже надо делать пилотный проект.
Как так? Те, кто задумались, чего ожидают от неё? В чём и почему думают она поможет?

1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)

Вы хотите автоматизировать процесс или операции?
Если процесс, то у процесса можно определить его показатели.
У вас процесс УТ уже есть? Зачем он нужен?
Как вы меряете его эффективность сейчас?
Если не меряете, то зачем асфальтировать дороги, по которым ходят коровы?

Подсказки:
Время согласования требований — это показатель процесса разработки требований, а не управления.
Количество согласований — тоже.

Процент изменённых требований за период — показатель процесса учёта требований.
Процент требований, пропущеных по причине отсутствия централизованного учёта требований — тоже.

Денежные потери, возникшие в результате ошибочных решений о рамках релизов и итераций — вполе себе показатель процесса управления требований.

ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:

• Какие задачи выбрать для измерения? Они должны быть идентичны.
• На ком проводить измерения? Должны быть одни и те же люди.
• Как определить погрешность?
• Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)

Эээ, а почему вы задаете эти вопросы на форуме, а не самим себе? ) Вы же инициатор внедрения - значит, вы знаете, какие именно параметры вас не устраивают в текущем состоянии. Если вы не знаете, тогда зачем вам что-то внедрять?

Добрый день, коллеги.
В моей компании задумались над СУТ (система управления требованиями).
Необходимо выбрать, обосновать и на пилотном проекте опробовать.

Встает вопрос как оценить внедрение? Просто грамотные фразы и красивый интерфейс не подойдут. Необходимы именно какие нибудь количественные, измеримые показатели. Например время, необходимое для внесения изменений сократилось на 20%.

Судя по комментариям, вы ищете преимущества от внедрения СУТ не столько в управлении, сколько в разработке требований (на что Денис уже указал).

Управление требованиями затрагивает все процессы, связанные с разработкой ПО, и каждый из них нужно оценивать. С требованиями работают, как минимум:
- аналитики, которые их разрабатывают;
- руководители проектов (собственно, управление требованиями - это их задача);
- разработчики, которые их реализуют;
- тестировщики, которые проверяют реализацию.

У всех этих людей свои процессы, а у каждого процесса свои показатели.

В первую очередь внедрение СУТ должно сказаться на качестве. Здесь есть где развернуться с показателями, потому что в области оценки качества их изобретено много. Наверняка у вас какие-то уже есть.

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

А во-вторых, внедрение СУТ может создать новые процессы, показатели эффективности которых просто не с чем будет сравнивать, потому что до внедрения их не было.

Самый очевидный профит от внедрения СУТ получит менеджер проекта (условное название, в разных компаниях это могут быть разные роли), которому управление требованиями даёт в руки множество новых показателей для оценки и управления, например:
- готовности продукта (процент реализованных требований - правда, при условии, что вам удастся полностью покрыть разрабатываемую функциональность документированными требованиями);
- протестированности продукта (процент выполненных тестов - в дополнение к предыдущему условию нужно, чтобы тест-кейсы тоже разрабатывались по требованиям, а не "сами по себе");
- временные оценки на разработку и тестирование - начнут работать после набора более-менее адекватной статистики по оценочной и реальной трудоёмкости работ по разработке, реализации и тестированию требований.

Но все эти показатели будут адекватными реальности только если действительно удастся внедрить управление требованиями во все перечисленные процессы. Все эти люди должны начать действительно использовать СУТ в своей работе.

ida , это понятно, вопрос в другом:
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
2.Как фиксировать? На первый взгляд поставить задачу в JIRA провести такие то изменения, и посмотреть сколько занимало времени до внедрения СУТ и после.
Тут возникает множество вопросов относительно качества измерений:

• Какие задачи выбрать для измерения? Они должны быть идентичны.
• На ком проводить измерения? Должны быть одни и те же люди.
• Как определить погрешность?
• Как минимизировать погрешность? т.к. даже у одного и того же сотрудника показатели производительности могут существенно различаться (не выспался, поругался в пробке, проблемы в семье и т.д. и т.п.)

pmle, bus
ЗЛ - руководители проектов (РП), заказчики 100%. Остальные под вопросом, поясню: по идеи все, кто участвует в процессе разработки ПО (аналитики, разработчики, тестеровщики, внедренцы) однако они работают по задачам из JIRA и что будут делать больше/быстрее для этих сотрудников не важно. Если будет удобнее работать, повысится качество, то да.


Провел небольшой опрос ЗЛ, в основном РП, выявил существующие проблемы/хотелки:

• Долгое согласование требований. Например требования еще не согласованы, а работы уже ведутся.
• Необходимость дополнительных систем для согласования требований. Например множество дублей в разных гуглдокс (требование - задача - статус) + это дублируется в жире (согласованно да/нет, основание для оплаты и т.д.)
• Необходимость полностью дублировать хотелки (требования), задачи, баги в issue tracker заказчика. Например заказчик создал десяток новых функциональных требований в своей системе. Мы должны перенести в свою, отработать, проверить, отчитаться в свое, в их, + внести изменения в доки.
• Хотелось бы по описанию задачи, была возможность выполнить поиск по вики, в какой раздел это относится, что бы оперативно внести изменения в нужные места. Трассировка т.е.
• При изменении требований система предлагала перестраивать задачи, связи между задачами, определять сроки, закрывать ненужные задачи. Так называемый интеллектуальный помощник.

p.s.Мне интересно, когда IBM предлагает RequisitePro за несколько килобаксов за 1 лицензию, как они обосновывают бизнесу (топ менеджерам, техническому директору, начальнику отдела анализа), что внедрение даст вам 1, 2, 3 и окупится за N месяцев/лет?

p.p.s.Может ли СУТ проверять атрибуты качества требований? (недвусмысленность, проверяемость, полнота)?

1. СУТ не предназначена для управления задачами, она позволяет создавать (точнее фиксировать) и эффективно управлять требованиями (и их изменениями)
2. Преимущества СУТ в т.ч. лежат в: возможности проведения анализа влияния (матрицы трассировки требований), быстрая генерация формальной документации требований (с учетом версионирования требований), контроль изменений требований (кто, когда и почему изменил), возможность коллективной работы над требованиями (но это можно решить и с использованием SharePpoint, например). Другой вопрос, как у вас поставлен процесс разработки и управления требованиями ... некоторые преимущества ценны будут для вас, а некоторые - нет. Кроме этого, не следует исключать такой аспект, как повышение уровня зрелости процессов разработки ПО в целом, с использованием СУТ. Как оценить - можно посмотреть посмотреть на ту же goals/practices в CMMI (REQM)
3. Согласовывать имеет смысл не отдельные требования, а требования к конкретному релизу (в совокупности). Это делать проще (согласовать документ и получить по нему замечания). Не думаю, что вы заставите заказчиков использовать СУТ для этого ... хотя бывают исключения.

сообщение устарело

Юрий, не могу согласиться.
Управлять задачами в СУТ очень удобно. Иллюстрации и пояснения здесь: http://edu.reqcenter.pro/?p=4206

Не впечатлила ссылка. При таком подходе TFS, Jira - тоже СУТ :-).

сообщение устарело

Не впечатлила ссылка. При таком подходе TFS, Jira - тоже СУТ :-).

TFS - это действительно полноценная СУТ. С управлением требованиями там всё в порядке. ALM Rangers вон целую книгу написали про управление требованиями в TFS http://vsartfsreguide.codeplex.com/

Вот с разработкой требований в TFS не очень, но это решается. Ира Сурова на ЛАФ будет рассказывать, как они скрестили TFS и Enterprise Architecht. Кроме того, ходят упорные слухи, что TFS будет интегрироваться с Borland CaliberRM.

С моей точки зрения, СУТ, не встроенная в ALM, - вещь в себе. Полноценное управление требованиями возможно, только если оно замкнуто на все процессы разработки. То есть СУТ должна быть либо частью системы ALM, либо прозрачно интегрироваться с другими инструментами.

более того, скажу вам по секрету, что IBM нашли способ поженить TFS и RRC(rational requisite composer) из их платформы Jazz
Штатные средства трассирования TFS - это выгрузка айтемов в excel. как говорится, на безрыбье и рак рыба, но это полный треш.

Для себя я нарисовал такую картину СУТ+TFS:
По факту получаются независимые подсистемы ALM: в СУТ аналитики формализуют, создают и управляют требованиями и делают постановку задачи архитектуре или сразу разработчику(в зависимости от ролей и принятого техпроцесса), а архитекторы, разработчики и тестирование ведут управление заданием уже в TFS. Таким образом аналитик выступает в роли заказчика для архитектуры и разработки(в ролевой модели проекта).

По сабжу,
мы, когда ROI на внедрение СУТ подготавливали у нас отбив стоимости продукта внедрения был 3 года с 30% приростом производительности.
по расчёту ROI в интернете полно информации + Юрий хороший пост написал