Требования могут рассматриваться как состоящие из нескольких типов традиционно «SRS» (спецификация требований программного обеспечения). В Agile требования обычно регистрируются в виде описания пользовательской функциональности или сценариев.
Независимо от вашего подхода к описанию требований можно использовать модели, чтобы помочь детализировать и определить именно то, что должно быть разработано:
- Диаграмма вариантов использования
- Концептуальная схема классов
- Диаграмма активности
- Диаграмма последовательности
Согласно этому представлению, каждую из этих диаграмм можно рассматривать как хранилище куска общей «голограммы требований», требование является совокупностью информации, содержащейся во всех этих частях. Границы этого сценария определяют, как установить трассировку требований от рабочих элементов к диаграммам и упомянутым UML-элементам, а также к другим архитектурным артефактам.
Связывание рабочих элементов требований с диаграммами вариантов использования
Шаблоны из коробки, поставляемые Visual Studio Team Foundation Server (TFS), не содержат вариант использования как рабочий элемент. Это оставляет диаграмму вариантов использования без прямого сопоставления для структуры декомпозиции работ (СДР) созданной по рабочим элементам. Существует несколько вариантов для реализации трассировки в этом случае:
- Создать рабочий элемент / тип рабочего элемента вариант использования (в MSF CMMI)
- Это позволит создать структуру декомпозиции работ, которая аккуратно группирует Сценарии/Пользовательские Описания Функциональности в Варианты Использования;
- Возможно использовать типизированные связи между высоким уровнем (Вариант Использования) и низкого уровня (Истории/Сценарии) (для получения дополнительной информации о типизированных ссылках, см. Руководство управлению требованиями Visual Studio Рейнджеров или документацию по продукту);
- Запросы, отчеты и метрики управления проектом поднимаются до уровня Вариантов Использования;
- Однако это создает дополнительное бремя для документирования и поддержки синхронизации модели UML и рабочего элемента. В идеале рабочий элемент просто будет представлением элемента модели UML. Другим решением может быть реализация Пользовательского обработчика ссылок рабочего элемента, который будет синхронизировать его по необходимости.
- Ссылка на нескольких рабочих элементов Описание Функциональности Пользователя (или Требований типа Сценарий) как замена для рабочего элемента Вариант Использования.
- Это позволит диаграмме Вариантов Использования использоваться в качестве агрегатора (в Agile терминах, «Эпическое») Пользовательских Описаний Функциональности/Сценариев;
- Нет необходимости синхронизировать документацию с рабочим элементом и Вариантом Использования как в предыдущем сценарии;
- Однако запросы, отчеты и метрики управления проектами не поднимутся до уровня Вариантов Использования, оставляя Планирование релизов на более детальном уровне;
- Кроме того, ссылки не типизированы, поэтому иерархия от высокого уровня (Вариант Использования) до низкого уровня (Истории/Сценарии) не дадут никакой дополнительной информации кроме как ассоциации подразумеваемой ссылкой.
- Ссылка из диаграммы Вариантов Использования к Задачам разработки
- Это предложено в текущей документации Visual Studio 2012 в статье Using Models within the Development Process;
- Это хороший вариант для UML-проектов, где все требования хранятся в Team Foundation Server и рабочие элементы Пользовательские Описания Функциональности/Сценарии не используются;
- Однако он не позволяет вести хорошего управления релизами, обычно Вариант Использования, как правило, охватывает итерацию из-за их внутреннего размера ( Writing Effective Use Cases, Advanced Use Case Modeling: Software Systems), и это создается большое количество связей на низший уровень декомпозиции с рабочими элементами Задача.
- Кроме этого, ссылки не типизированы, поэтому иерархия с высокого уровня (Вариант Использования) до низкого уровня (Истории/Сценарии) является неявной.
- Ссылка на документ, хранящийся на внешней системе
- Это вариант, который имеет наименьшее количество встроенной трассировки, но может быть полезным для существующих проектов с обширной существующей документацией.
Связывание Варианта Использования с рабочим элементом
Механизм для связывания от варианта использования на рабочий элемент показан на следующих изображениях.
- Из Варианта Использования:
Создание рабочего элемента из Варианта Использования
- Выбрать запрос по рабочим элементам:
Выбор запроса по рабочим элементам
- Обновленные свойства Варианта Использования выглядят приблизительно так:
Свойства Варианта Использования
- И диаграмма Вариантов Использования теперь показывает значок (
) на Варианте Использования, который связан с рабочим элементом:
Диаграмма Вариантов Использования и иконки связанных рабочих элементов
Обратите внимание на отсутствие типизированных ссылок. Чтобы получить двунаправленные ссылки между рабочими элементами требований и вариантами использования, необходимо установить TFS 11 (в Visual Studio 2010, вы должны были установить Visual Studio Feature Pack 2010). Без этого расширения нет ссылки из рабочего элемента обратно в элемент модели, что делает двунаправленную трассировку трудной задачей.
Для более подробной информации о том, как связать элементы, смотрите в документации:
- How to: Link a Use Case to Documents and Diagrams
- How to: Link Work Items to Model Elements
- How to Define a Work Item Link Handler
Обратная связь между рабочими элементами и элементами модели
Пакет визуализации и моделирования Microsoft ® Visual Studio ®2010 предоставляет возможность связать рабочий элемент Team Foundation Server к элементу модели. Эта функция теперь поставляется в Visual Studio 2012.
Связывание рабочего элемента с моделью
Создание отчетов Трассировок
Создание отчетов Трассировки особенно полезно для проверки, что все требования были реализованы, независимо от того как они были получены.
Одна проблема в создании отчетов в том, что информация о моделях UML публикуется в хранилище данных проекта исключительно как исходный код без других связанных семантических единиц: то есть, вся соответствующая UML информация остается с моделью. Поэтому шаги создания стандартного отчета для TFS не применимы, если для каждого элемента Варианта Использования мы не добавляем соответствующий рабочий элемент или тип Требования (в MSF CMMI). Это позволит нам использовать отчеты, описанные в документе Рейнджеров “ Руководство управлению требованиями Visual Studio“.
| НАБЛЮДЕНИЕ Этот раздел определенно кандидат на использование расширяемости и область, которую мы будем рассматривать в будущих версиях этого руководства. |
Использование отчетов трассировки для анализа влияния изменений
Руководство управлению требованиями Visual Studio Рейнджеров подробно объясняет, как создать отчеты трассировок. Основное дополнение здесь состоит в том, что самый легкий путь (в версии RTM) для реализации Вариант 1, чтобы обеспечить трассировку (раздел “Создать пользовательский Рабочий Элемент Варианта Использования / Тип Рабочего Элемента(в MSF CMMI)” выше). Это обеспечивает основу для отслеживания к задачам и коду, начиная с рабочих элементов требование. Чтобы создать отчеты для Варианта 2 и 3 в этом разделе, можно разработать расширение Visual Studio Team Architect, чтобы получить список затрагиваемых рабочих элементов.