Заметки консультанта

Шамрай Александр Владимирович

Руководство по управлению требованиями VS TFS 2010 – Анализ влияния

Posted by Шамрай Александр на Апрель 20, 2010

<<Содержание

«Запросы на изменения могут не только показывать новые или изменившиеся требования, но также и сбои, дефекты в рабочих продуктах. Запросы на изменение анализируются, чтобы определить влияние изменения на рабочий продукт, связанных рабочих продуктов, а также сроки и стоимость.» – CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum.

Анализ влияния выполняется для:

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

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

Примечание: руководство для оценки влияния изменений в этом разделе предполагает, что требование на уровне бизнеса, реализовано с использованием рабочего элемента «Возможность» (Feature) в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента «Возможность» (Feature) для достижения этой цели и признают, что это добавляет элемент формальности, которую можно легко избежать для небольших и более гибких команд.

Описание оценки влияния

Процесс анализа влияния – Процедурное руководство от анализа влияния до изменения

  • Процесс рассмотрения изменений и их зависимостей, а также документирование их результатов влияния.
    Когда изменения внесены, то это либо запрос от заказчика, который выходит за рамки проекта, или это неправильно понятые требования, которые должны быть переписаны для удаления недоразумения. Сначала это запрос на расширение, потом это дефект требования. То же самое применимо для разработки и тестирования изменений. Они, по сути, вновь открывшиеся обстоятельства, которые влияют на границы и поставки проекта.
    Для этих изменений важно, чтобы была сохранена Трассировка в ходе реализации проекта и процесс Управление изменениями и утверждения был внедрен и выполнялся. Смотрите соответствующие разделы для детального описания. Эти разделы описывают использование Team Foundation Server для создания и отслеживания трассировки между рабочими элементами и другими активами, а также управления изменениями, базовыми линиями и сравнения, которые необходимы для понимания влияния изменений.
    Смотрите отчеты, описанные в Трассировке требований, как вспомогательные для работ анализа влияния.

Процесс Анализа влияния

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

Рассмотрение Запроса на расширение

Эта задача похожа на бизнес-анализ или анализ границ. Задача аналитика – понять, что точно запрос значит для заказчика. Смотрите раздел Анализа и декомпозиции для более детальной информации. В основе лежит связывание запроса с рабочим элементом Возможность (Feature), Пользовательская история (User Story) или Требование (Requirement) (в зависимости от того, что используется MSF for Agile и MSF for CMMI), либо связывание Запроса на изменение с рабочим элементом Проблема(Issue)/Ошибка(bug), или создание Возможности (Feature), Пользовательской истории (User Story) или Требования (Requirement) непосредственно для его описания.

Ответственный: Менеджер проекта/Администратор

Следующий рисунок отображает рабочий элемент Возможность (Feature) (ID # 54), который необходимо изменить (Новая проблема). Пользователь Team Foundation Server находится в середине установления связи между рабочим элементом Проблема (Issue) и рабочим элементом Возможность (Feature).

Определение затрагиваемых функциональных областей

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

  1. Изменение для добавления новой функциональности
  2. Изменение для удаления функциональности
  3. Изменение для изменения существующей функциональности
  4. Добавление нефункциональных требований (например, производительность, надежность, операционная поддержка)

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

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

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

  • Для каждого из функциональных изменений создается рабочий элемент Требование (Requirement) и ссылка на документ, из которого он найден с помощью типа связи URL. Каждый новый рабочий элемент требование или пользовательская история будет иметь ссылку на тот же документ, показанный выше, и, возможно, другие документы в той же библиотеке документов на портале SharePoint.

Ответственный: Бизнес-аналитик

Определение затрагиваемых тестов

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

Ответственный: Ведущий тестер

Ниже отображена функция с пользовательскими приемо-сдаточными тестами, которые должны быть в регрессии:

И следующий рисунок показывает пользовательскую историю (# 55) и системные тесты, которые должны быть в регрессии:

Определение затрагиваемого Исходного кода

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

Ответственный: Разработчик / Архитектор

На следующем рисунке подсвечена затронутая пользовательская история и показаны ее ссылки «Реализации» (Implementation). Ссылки реализации – это задачи, которые необходимо выполнить для того, чтобы реализовать требование или пользовательскую историю.

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

Следующий рисунок показывается задача (# 78) и набор ее изменений показывает необходимые исходные файлы для изменения.

Оценка трудозатрат

Эта задача выполняется в два шага:

  1. Определить выполняемые задачи – разработчик и архитектор анализируют новые или измененные функциональные возможности и определяют новые задачи, необходимые для осуществления изменения. Задачи должны быть связаны с помощью типа связи Реализация (Implementation) (родительская/дочерняя иерархия). Рисунок ниже показывает специальный запрос, где возможность, которую необходимо изменить, была выделена в итерацию «Запрос на изменение» (change request). Используя тип запроса дерево, мы можем определить все требования, которые реализуют эту возможность в качестве кандидатов на эти изменения. Как видно из предыдущего анализа влияния, известно, что затрагивается только пользовательская история # 55, она и ее задачи реализации подчеркнуты на рисунке. Новые задачи должны быть описаны для осуществления изменений, в то время как по старым выполненным задачам будут определены исходные файлы, которые должны быть изменены.
  2. Определить задачи управления тестированием – для каждого нового требования, определяются новые тесты, которые будут проверять новые требования. Смотрите раздел Валидация для идей о комплексных подходах с положительными и отрицательными тестовыми сценариями. Свяжите новые тестовые сценарии, используя тип связи Тест (Test). Для каждого существующего требования, которое должно быть изменено, просматриваются их связанные тесты, чтобы убедиться, что их реализация покрывает изменения. После выявления тестов определяются рабочие элементы Задача (task), которые представляют собой работы, необходимые для внесения соответствующих изменений в тестовые модели. Эти задачи будут оцениваться и отслеживаться в ходе реализации изменения.

Отчет о влиянии и ожидание разрешение на осуществление

На данный момент все необходимые воздействия были выявлены. Собираются рабочие элементы и создается отчет, отражающий необходимую работу. Рекомендуемый способ сделать – это пометить каждый новый и существующий рабочий элемент с использованием значений атрибута «Область» (Area) или общей «Итерации» (Iteration), которая представляет собой усилия необходимые для изменений. Далее отчет просто создается с помощью фильтра для всех рабочих элементов на основе этого значения. При использовании итерационных моделей разработки, «Область» (Area) должна использоваться для выявления всех затрагиваемых рабочих элементов по общему запросу на изменение, оставляя остальную итерацию открытой для новых рабочих элементов по данной итерации, в противном случае полной итерации для изменения было бы достаточно.

Заключение

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

<<Содержание

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: