Системы управления требованиями: что и зачем? (По мотивам sql.ru)

автор: Мадорская Ю.М.

Вопросы, заданные на форуме sql.ru, судя по дополнительному опросу, интересуют многих специалистов. Поэтому, оставляя «форумный» стиль изложения, привожу здесь заданные вопросы и  ответы на них, написанные мной на sql.ru.

Также можно почитать:

Познакомиться с теми, кто работает в профессиональной системе управления требованиями и задать вопросы можно здесь.

Все приведенные скриншоты сделаны в разных проектах с использованием 3SL Cradle ($200).

Первая часть

DPH3

А действительно проекты и методологии требуют такого изощренного управления требованиями, что необходим DOORS и иже с ним?
E300 и выше (по Коуберну)? 
Все-таки, зачастую вполне достаточно какого-нибудь Confluence с всевозможными плагинами — и я видел кучу проектов, вполне себе реализованных именно на таком уровне.
Очень интересно, какие проекты реально требуют CaliberRM или DOORS или RequsitePro.

 

Для того, чтобы ответить на эти вопросы, необходимо понять ключевые особенности систем управления требованиями. В чем суть-то? Что дают такие системы как 3SL Cradle, DOORS, RequisitePro?

Первое, единица управления — требование, item, элемент описания системы. Т.е. не документ. 


Второе, возможность указания связей между элементами (нетипизированных и без атрибутов в Requisite, типизированных и с атрибутами в Cradle).


Третье, возможность построения выборок в различных представлениях (матрицы трассировки и другие, в зависимости от возможностей системы)


Четвертое, функции по отслеживанию изменений, основанные на трассировке. Т.е. если что-то изменилось, то далее система, например, подсвечивает все элементы, связанные с измененным как подозреваемые на изменение.

Это некоторый базовый набор функций. Что он дает при грамотной реализации? Прежде всего — контроль ошибок проектирования! Если заложить правильную модель (а системы типа 3SL Cradle, Requisite pro это системы со свободной моделью, тогда как Caliber нет), то можно настроить такие выборки, которые будут показывать ошибки проектирования.
Второе, что может дать система такого рода — сокращение времени и повышение точности формирования оценки изменений (change estimation, impact analysis).

Кому это выгодно? Естественно, чем крупнее система и чем больше заказчиков, тем выгоднее внедрение таких систем как 3SL Cradle, DOORS. (Про Requisite pro здесь не забыто. Для крупных проектов он не подходит, на эту тему есть хорошие статьи в интернете, описывающие практический опыт, если кому интересно)
Чем крупнее система, тем дороже ошибки проектирования и тем приятнее обнаружить их на ранних этапах проектирования или не допустить вовсе.
Чем больше заказчиков, тем больше запросов на изменение от них (change request), тем больше уходит времени на то, чтобы оценить влияние каждого запроса на систему (change estimation), оценить возможность реализации, сроки, стоимость. А заказчики хотят получать такую реакцию довольно быстро, особенно, если запрос связан с ошибкой. Так вот системы управления требованиями позволяют, при грамотном внедрении, значительно сократить время ответа заказчику и точность этого ответа. Что, конечно, очень важно.

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

Вторая часть

DPH3,

Отвечаю на Ваши вопросы и заранее извиняюсь за длинный ответ, поскольку в данной области плохо устоявшаяся терминология, приходится уделять время деталям, существенным для установления одинакового понимания.

А. Как связано проектирование с системой управления требованиями? Или мы вводим и требования (со всеми связями), и проект, и реализацию — и все внутри одной системы?

1. Процесс проектирования есть логическое продолжение процесса сбора и разработки требований. Требования — те же проектные решения, проектные решения — те же требования к системе. Проектные решения также могут называться производными требованиями (derived requirements).
Формально, требование — это высказывание о системе, определяющее ее свойства. Тоже самое можно сказать и о проектных решениях. Способы классификации требований и производных решений оставим методологиям проектирования. По форме требования могут быть выражены в виде простых высказываний или моделей (сводится к высказываниям).

2. Система управления требованиями — плохое название для современного класса этих систем. Так сложилось исторически и это часто вводит в заблуждение. Действительно, одна из подгрупп данного класса систем вводит вполне определенную типизацию требований (например, Caliber) и соответственно управлять чем-то другим в рамках данных систем проблематично. Другая же группа разработчиков пошла по более эффективному пути — предоставила свободу выбора — хотите требования, хотите баги, хотите риски и т.д. (посмотрите альбом моделей трассировки требований, по нему наглядно видно сколь разнообразны категории, используемые при управлении «требованиями»). При этом механизмы управления универсальны(см. предыдущий ответ в этой теме).
Есть компании, которые,например, на базе 3SL Cradle строят систему управления рисками.
Преимущество таким систем с открытой моделью, конечно, в том, что можно организовать сквозную трассировку — оценивать покрытие требований тестами, функциональных спецификаций — багами, стейкхолдеров юзкейсами и т.д.. Полет фантазии в этом направлении ограничивается применяемыми методологиями, технологиями и мировоззрением участников процесса.

Конечно, хранить, например, код в данных системах не эффективно, а вот проектирование и ввод структуры модулей и определение связей с исходными и производными требованиям — задача, результат которой весьма ценен. При изменении требования мы можем быстро увидеть с какими модулями они связаны. Когда требований два и модулей два — конечно это не надо, но я думаю при картине 50 на 50 это уже существенно облегчит процесс управления изменениями, а если разработкой системы занимаются несколько групп…На одних совещаниях можно круто сэкономить.

Автоматизированные тесты ПО также хранятся в специализированных системах, но данные о них могут быть легко импортированы и использованы для трассировки. Тесты на сами требования могут разрабатываться непосредственно в системе управления требованиями и связываться с соответствующими требованиями.

3. Таким образом, мы вводим в системы не «требования, проект, реализацию», а исходные требования, производные требования — текстовые или графические спецификации и модели реализации (например, физическую архитектуру). Если Вы это имели ввиду, то тогда совершенно правы.

В Requisite графические модели не вводятся, там эти функции разделены с Rose. В 3SL Cradle пять лет назад это тоже было реализовано двумя подсистемами, но потом они их объединили и уже давно можно делать сквозную трассировку к элементам диаграмм (UML и др.).

Например, у нас студенты в рамках курса «Инженерная графика» делали интересное задание — на первом этапе они должны были восстановить чертежи каждой детали сложного узла (с использованием Автокада или Компаса), а на втором этапе они должны быть в 3SL Cradle:
1. Описать структуру системы (узла), к элементам приложить чертежи и JPEG эскизов.
2. Разработать IDEF0 диаграммы процесса сборки данного узла, (пользуясь функциями автоматической проверки диаграмм — контроль ошибок проектирования).
3. Каждый функциональный блок IDEF0 описать по схеме Use Case.
4. Дать определение каждому потоку.
5. Оттрассировать каждый поток к элементам системы. Тем самым они показывали, что у них все элементы узла учтены в процессе сборки. (контроль ошибок проектирования).
6. Автоматически сгенерить отчет, который являлся фактически профессиональной инструкцией по сборке. (Читай ТЗ)

Получилось здорово.

В. Я хорошо понимаю, как правильное проектирование позволяет увеличивать точность. Я понимаю, как история проекта позволяет увеличивать точность. А вот как DOORS этому помогает? 

С повышением точности формирования оценки изменений — все просто. Если у Вас есть кипа документации, к тому же неполной, и масса аналитиков по разным отделам, т.е. знания о системе распределены, неполны, неоднозначны и недоступны в нужный момент времени (кто-то на больничном, кто-то у заказчика, кто-то в отпуске, кто-то просто забыл что и как реализовано), то внедрение таких систем позволяет сконцентировать знания в одном месте (более того происходит своеобразная их формализация), что естественным образом повышает точность любых выводов на данной системе знаний (Да, конечно, ее нужно поддерживать, это затраты, расчет окупаемости и т.п., но сейчас не об этом).
Точнее знания о системе — точнее оценка изменений.

С. А с какого класса систем это вообще становится выгодно? Не стоит забывать, что полное и формальное управление требованиями — офигенно дорогой процесс. Для проектов до D100 (по моему опыту) — сравним со всем проектированием и разработкой. Т.е. дешевле сделать еще один проект, нежели внедрять полноценный Requirement Managment.

Если я правильно понимаю, то Вы говорите о проектах — «сдал и забыл», т.е. без эволюционного сопровождения.
Чтобы быстро ответить на этот вопрос могу предложить аналогию — если кто-то всю жизнь выполнял резьбу по дереву перочинным ножом, то ему проще сделать еще пару работ, чем учиться работать резцами и другим специализированным инструментом. Но новый инструмент, помимо повышения производительности, часто дает и новое видение, позволяющее развивающемуся специалисту выйти на новый уровень.

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

Конечно, если технологи придумают увесистую модели трассировки, такую, что проще переписать всю систему, чем поддерживать ее модель, то это нецелесообразно. Но это уже зависит от профессионализма тех кто этим занимается. Аналогично, можно долго писать качественные детальные спецификации на ПО, делать прототипы, но так и не дойти до разработки.

В. Какие выборки могут показать ошибку проектирования? 

Некоторые примеры были по тексту. Еще пример, одна из ярких ошибок проектирования — когда забыли реализовать требование. В системе управления требованиями это легко отследить по отсутствию связей требования с другими артефактами, например, функциональной спецификацией.
Далее зависит от выбранной модели трассировки.

 

Эпилог

Приведенные ответы, конечно, не исчерпывающие,   затронутые проблемы, охватывают широкий круг вопросов, ответы на которые не укладываются в рамки форумного общения и возможно будут освещены позже.  Если у Вас возникли дополнительные вопросы или комментарии, Вам сюда .

Также можно почитать Про системы управления требованиями (классификация функций и иллюстрации)

С марта 2013 года профессиональная система управления требованиями 3SL Cradle становится доступной по стоимости для небольших рабочих групп, фрилансеров, студентов. Подробнее.

Tags:

Присоединиться в facebook или linkedin

Комментарии

комментарии

Комментарии закрыты.