Devprom ALM: Руководство пользователя

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

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

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

Целостность разрабатываемой системы может контролироваться относительно требований или функциональной иерархии. Например, в процессе Выполнение ТЗ целостность контролируется относительно ТЗ. В легковесных процессах целостность контролируется относительно функциональной иерархии, поскольку нет полного описания требований (или ТЗ). Вы можете выбрать наиболее подходящий вариант контроля целостности, независимо от используемого процесса.

В системе предусмотрены метрики, отслеживающие число устаревших артефактов, а также модули, например "Устаревшие сценарии" и "Устаревшие разделы документации".

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

Легковесные процессы

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

Процессы с предварительным проектированием

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

При актуализации, вместо "Новые пожелания" вы увидите поле "Новые требования".

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

Поскольку изменений в исходном требовании может быть выполнено много, более того они могут иметь чисто технический характер (разметка текста, орфография и т.п.), помечать устаревшими производные артефакты лучше на конкретных этапах жизненного цикла требования. Отметка об устаревании реализована при помощи системных действий. Например, оно вызывается при переводе требования в состояние Готово или Согласовано. Вы можете настроить удобный механизм именно для вашего процесса управления изменениями.

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

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

Включите отображение уже понесенных трудозатрат, чтобы оценить потенциальные трудозатраты на разработку, тестирование и документирование, в случае реализации изменения.

Бейзлайн - это версия документа привязанная к какому-то этапу проекта (прошлому или будущему), к релизу или итерации. Вы также можете самостоятельно определять назначение бейзлайна.

Бейзлайн может быть текущим (редактируемым, содержащим будущие изменения в продукте) или прошлым (нередактируемым). Вы можете вносить изменения только в текущий бейзлайн.

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

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

Документы или отдельные требования из разных бейзлайнов можно сравнивать между собой. Таким образом, вы можете выяснить какие изменения были внесены в требования.

Помимо изменений в тексте система отображает изменения в атрибутах требований, таких как "Оценка", "Трудозатраты", "Фактически затраты" и т.п. В режиме сравнения бейзлайнов документа, изменившиеся атрибуты автоматически отображаются над текстом требования.

Для одновременного изменения нескольких бейзлайнов документов используйте ветки.

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

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