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

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

Posts Tagged ‘требования’

Руководство по управлению требованиями VS TFS 2010 – Дополнительные интеграции

Posted by Shamrai Alexander на 17 июня, 2010

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

Различные производители программного обеспечения и партнеры Microsoft разработали интеграции с Visual Studio, которые предоставляют возможности не очень хорошо реализованные в Visual Studio Team Suite. В частности, они имеют встроенные возможности в следующих областях: выявление, спецификации, валидации и управления изменениями. Вот список некоторых из наиболее тесно интегрированных решений.

TeamSpec

TeamSolutions является компанией, которая разработала интеграцию между Microsoft Word и VisualStudio. TeamSpec позволяет вести спецификацию требований в Team Foundation Server с помощью интеграции, которая позволяет организовать синхронизацию заголовков и абзацев в Word с рабочими элементами в Visual Studio.

Для дополнительной информации:

TeamSpec компании TeamSolutions

http://www.teamsystemsolutions.com/teamspec

Joe Buys – jbuys@personifydesign.com

stpSoft

Компания stpSoft разработала подобную интеграции, но также поддерживает интеграцию для Visio и VisualStudio, которая связывает сценарии использования и диаграмм деятельности с рабочими элементами в VisualStudio. Их интеграция конкретно обеспечивает раскадровки как техники выявления.

Для дополнительной информации:

stpSoft

http://www.stpsoft.co.uk/stpbadeveloper1.html

Badr Khan – badrk@stpsoft.co.uk

Ravenflow

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

Для дополнительной информации:

Ravenflow

1900 Powell Street, Suite 500

Emeryvill, CA 94608

510-285-4600

http://www.ravenflow.com

IBM DOORs

DOORs – это мощная среда для управления требованиями, которая обеспечивает выявление, спецификацию, управление изменениями и утверждение требований. Его интеграция разработана для двунаправленной синхронизации с Visual Studio.

Для дополнительной информации:

Jared Pulham – jared.pulham@uk.ibm.com

http://www-01.ibm.com/software/awdtools/doors/

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

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 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) должна использоваться для выявления всех затрагиваемых рабочих элементов по общему запросу на изменение, оставляя остальную итерацию открытой для новых рабочих элементов по данной итерации, в противном случае полной итерации для изменения было бы достаточно.

Заключение

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

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

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 20 апреля, 2010

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

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

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

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

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

Эта тема в проекте Visual Studio ALM Rangers Requirements Management Guidance обеспечит руководство для пользователей Visual Studio/Team Foundation Server, которым необходимо эффективное средство для отслеживания от высокоуровневых требований до нижнего уровня и до разработки, тестирования и элементов исходного кода. После прочтения вступления, многие могут подумать, что эта тема тяжела и загружена большим количеством дополнительной проектной документации, что не свойственно гибким проектам. Но это не так. Гибкая команда увидит реализацию трассировки, которая поддерживает разбиение продукта, и итеративное управление журналом продукта, которое более простое, но мощное в обеспечении подотчетности и уменьшения сложности анализа влияния.

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

Общее руководство трассировки требований

Стратегия трассировки

Ниже приводится диаграмма общей трассировки, которую мы приводили в разделе Планирование Управления требованиями. Она показана снова здесь для обозначения отправной точки для различных видов информации, которая должна отслеживаться для любого проекта разработки. Как указано в разделе планирования, «золотая середина» приведенной ниже диаграммы, которая поддерживается Visual Studio и Team Foundation Server, является элемент «Потребность» (Need).

При реализации, каждый из этих элементов имеет свое место в Team Foundation Server:

Artifact Team Foundation Server Representation
Возможность (Feature) Тип рабочего элемента Возможности системы (MSF for CMMI)
Функция (Function) Тип рабочего элемента Требование с типом = Функциональное (Functional) для MSF for CMMI

Пользовательская история (User Story) для MSF for Agile

Качество обслуживания (QoS (Quality of Service)) Тип рабочего элемента Требование с типом = Качество обслуживания (Quality of Service) для MSF for CMMI

Пользовательская история (User Story) для MSF for Agile

Тестовый сценарий (Test Case) Тип рабочего элемента тестовый сценария (MSF for Agile и MSF for CMMI). Этот рабочий элемент представляет собой контейнер в Microsoft Test и Lab Manger. Он включает в себя Общие Шаги (Shared Steps), которые могут копироваться из сценария в сценарий для часто выполняющейся общей функциональности, например, процедуры входа в систему.
Тест (Test) Тест проекта тестирования в Visual Studio 2010, который представляет модульный или нагрузочный тест на уровне разработки или для «Test Driven Development» (TDD). Функциональные тесты (ручные или автоматические) теперь элементы рабочего элемента Тестового сценария, которые реализовывают шаги процедуры тестирования и тоже могут быть автоматизированы.
Задача Реализации (Implementation Task) Рабочий элемент Задача (Task) в MSF for Agile и MSF for CMMI
Код (Code) Проект (Проводник решений, Версионный контроль)

Тесты и Трассировки

Visual Studio поддерживает несколько видов тестов. Каждый из них имеет свою функцию и свой тип трассировки. Мы можем разделить тесты на две основные группы (хотя некоторые тесты несколько размыты и могут быть отнесены к любой группе)

  • Низкоуровневые тесты — тесты созданные разработчиками и хранятся в виде файлов проекта (как правило, вместе с тем же решением как код). Например, модульные тесты (кода или баз данных), автоматические тесты, написанные разработчиком как метод проверки программного обеспечения. К этой категории можно также отнести нагрузочные тесты, которые не являются функциональными тестами и направлены на проверку производительности, оценки масштабируемости и способности работать под высокой нагрузкой. Трассировка этих тестов несколько ограничена, т.к. их результаты несколько менее интересны на уровне бизнеса. Тесты производительности находятся между низкоуровневыми тестами и системным уровнем тестирования. Они имеют низкий уровень, т.к. они построены с использованием тестовых проектов в Visual Studio. Они на системном уровне, т.к. они проверят реализацию нефункциональных требований или требований качества обслуживания.
  • Функциональное тестирование — функциональные тесты имеют непосредственное отношение к бизнес-требованиям. Это могут быть системные тесты, для проведения испытаний, была ли пользовательская история реализована, как было определено, или тест приемки, который проверяет, была ли данная бизнес функция реализована в соответствии с запросами на бизнес-уровне.

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

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

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

Типы связей между артефактами

В Team Foundation Server могут быть созданы различные ссылки между следующими артефактами:

  • Набор изменений (Changeset) – связь между рабочим элементом и набором изменений
  • Элемент версионного хранения – связь между рабочим элементом и папкой или путем в системе версионного контроль
  • Рабочий элемент – тип связи между двумя рабочими элементами (см. ниже)
  • Гиперссылка – ссылка из рабочего элемента к URL
  • Результаты тестирования – ссылка рабочего элемента с результатами выполнения теста

Отметим, что в Visual Studio 2010 связи в рабочих элементах в настоящее время обеспечивают семантику направленности и информации о связи для обозначения родительских, дочерних и связей одного уровня для рабочих элементов. Эта функция обеспечивает лучшую трассировку, т.к. проще увидеть, как один рабочий элемент иерархически относится к другому. Это позволяет понять, каким образом требования могут быть переопределены в нескольких «дочерних» требований от первоначальных требований, которые слишком широки.

Ссылки рабочих элементов имеют типы и топологию последовательности. Доступные топологий:

  • Сеть

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

  • Направленная сеть

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

  • Зависимость

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

  • Дерево

Ссылки в этой топологии в основном деревья, она использует отношения один-ко-многим и не позволяет цикличность.

Типы связей, которые определены в системе:

Прямая ссылка Обратная ссылка Имя ссылки для типа связи Топология
Последователь Предшественник System.LinkTypes.Dependency Зависимость
Дочерняя Родительская System.LinkTypes.Hierarchy Дерево
Связанный Связанный System.LinkTypes.Related Сеть

Типы связей, определенные в шаблонах процессов MSF:

Прямая ссылка Обратная ссылка Имя ссылки для типа связи Topology
Тестируется Тестирует Microsoft.VSTS.Common.TestedBy Зависимость
Тестовый сценарий Общие шаги Microsoft.VSTS.TestCase.SharedStepReferencedBy Зависимость

Эти связи используются для отражения реализации отношения, которые позволят использовать декомпозицию для Возможности, Пользовательского описания функциональности и Задачи:

Рисунок 1. Возможность->Пользовательская история->Задача

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

Рисунок 2. Возможность->UAT и Пользовательская история->системный тест

Ссылки отображаются в настраиваемой форме рабочего элемента.

Связи могут быть отфильтрованы и сгруппированы по типам.

Использование ссылок с документацией

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

Если документирование слишком подробное для описания в рабочем элементе, рабочий элемент может представлять высокоуровневый дескриптор и как указатель для более подробной информации. Документ, PowerPoint слайд(ы), Visio диаграммы, таблицы Excel и другие файлы для детализации требований могут быть сохранены на портале SharePoint командного проекта. Далее, используя ссылку для рабочего элемента, эти файлы могут быть связаны с ним с использованием ссылки «URL». В самом документе идентификатор рабочего элемента как URL в Web Access (TSWA) на рабочий элемент может быть добавлен, чтобы обеспечить двунаправленную связь.

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

Настраиваемая трассировка

Рисунок и описание ниже продемонстрируют возможности, которые есть без какой-либо настройки Team Foundation Server. Благодаря своей гибкой природе, пользователи могут настроить либо из шаблонов процессов (MSF для Agile и MSF для CMMI), которые поставляются с Team Foundation Server, скачать и настроить сторонние шаблоны процесса или создать свои собственные.

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

Управление

Тема соответствия промышленным стандартам управления или юридическим законам слишком большая, чтобы описывать в этом руководстве, но использование Team Foundation Server для трассировки может помочь команде разработчиков для достижения следующих целей:

  • Соответствию CMMI Level 3 для Управления требованиями (ReqM) и Разработки Требований (RD)
  • Соответствию Правилам управления пищевых продуктов и медикаментов (Food and Drug Administration (FDA)) CFR-21, части 11, которая определяет цифровую подпись
  • Соответствию ISO 9000 на проверку соответствия разработки по контракту
  • Закон Сарбейнса-Оксли для проверки возможности финансовых операций

Существуют и другие модели, но основная идея состоит в том, чтобы понимать, что Team Foundation Server может обеспечить трассировку, которая достигает отчетности. Модель зрелости разработки или правительственные постановления направлены для защиты обычных людей от грязных бизнес-методов. Трассировка помогает защитить этих людей и Team Foundation Server является технологией, которая помогает достичь это.

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

«Неэффективные» матрицы трассировки

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

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

БИД Бизнес-требование. ФИД Функциональное требование. ТИД Техническое требование ТСИД Тестовый сценарий Исходный код
\\sharedlibrary\project_doc\Requirements\My Project Business Requirements.doc
BR-1 Приложение должны улучшить впечатление клиентов при покупке нашей продукции, что дает нам повышение уровень удовлетворенности клиентов (CUST-SAT) и повысит наши доходы. UC-1 \\sharedlibrary\project_doc\Requirements\Customer_Self_Service_Purchase_Use_Case.doc
TR-1 Поддержка этой функции для 200000 одновременно работающих пользователей без снижения производительности TC-1 Проверить, длительность транзакции для одного пользователя и сравнить со средней продолжительностью при 200000 одновременных транзакций \\my_workspace\source\my_source.cs
\\my_workspace\source\my_source2.cs

Т.д.

TR-2 Разработка руководств по эксплуатации и устранения неисправностей для службы технической поддержки. TC-2 Проверить ля, ля, ля \\my_workspace\source\my_source.cs
\\my_workspace\source\my_source2.cs

Т.д.

Такая реализация матрицы трассировки вызовет значительные затруднения для команд:

  • Для электронной таблицы только один человек может изменять в один момент времени. Есть государственные организации, которые нанимают сотрудников, которые занимаются в проекте только поддержкой этой трассировки. Их работа включает обход каждого разработчика, бизнес-аналитика, менеджера проекта, и т.д. и сбор их изменений, чтобы включить их в матрицу и обеспечить анализ их воздействия для команды. Это выглядит (по мнению автора) пустой тратой государственных средств (так называемых наших налогов).
  • Электронные таблицы почти бесполезны для отслеживания влияния изменений или областей, пострадавших от дефектов. В 6-месячном проекте реализуемом группой из 12-15 человек (т.е. относительно небольшая) иерархия трассировки могут включать более 20000 связей трассировки. Такая таблица становится сложной для выполнения анализа влияния. В реальности в проектных командах использующих такие матрицы разработчики даже не заглядывают в нее.
  • Т.к. она разрабатывается вручную, как правило, точность этих отчетов очень низкая. В некоторых государственных проектах, этот отчет размещается вместе с высокоуровневыми данными, которые не полны в конце каждого этапа проекта водопада. Поскольку размер документа потребует дни для анализа на проверку точности, аудиторы просматривают документы на соответствие без проведения анализа.

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

Отчеты Team Foundation Server с использованием запросов для рабочих элементов в дополнение к OLAP Cube

Следующий список представляет отчеты, которые должны быть сформированы с использованием данных, которые находятся в OLAP Cube Team Foundation Server (не в SQL) или в хранилище рабочих элементов:

  • Трассировка Бизнес-Требований к Системным Требованиям – демонстрирует, что у вас есть всесторонний анализ бизнес-требований и, по крайней мере, одно функциональное требование (MSF для CMMI) или Пользовательская История (MSF для Agile) для каждого Бизнес-требования. Такой отчет (что важно) покажет, где вам не хватает трассировки. Он указывает, где необходимо провести больше аналитической работы
  • Функциональные требования к техническим требованиям – демонстрирует похожее покрытие на следующем уровне ниже. Подумайте здесь: «Что такое технические требования?». Следуя промышленным стандартам, установленными IEEE, CMMI, ISO, мы будем использовать определение технических требований как нефункциональные требования, что определяет качество услуг (Производительность, Надежность и т.д.), Удобность использования (Документация пользователя, Пользовательский опыт, Помощь, Обучение, и т.д.), Ограничения (Корпоративная архитектура решение как ОС, БД, Промежуточное ПО, Архитектура приложения, и т.д.), Операционность и Поддержка (Подотчетность, Автономная обработка, Отказоустойчивость, Обеспечение непрерывности бизнеса, и т.д.). Некоторые сообщества считают, что это покрывается проектной документацией, но это мнение является заблуждением.
  • Функциональные и нефункциональные требования к задачам – демонстрирует, что у вас есть планируемая деятельность для каждого из ваших требований. В примере прикрепленном здесь, я реально использовать эти данные для отражения статуса завершения задач. Шаблон «Conchango» имеет встроенную часть в обработчике событий, которая преобразует изменения оставшегося времени для задачи (элемент журнала спринта) в сценарий (элемент журнала продукта) автоматически (Cool Stuff).
  • Задачи к наборами изменений, тестам и дефектам (как и наоборот) – этот отчет показывает, где «резина встречает дорогу» в плане соблюдения FDA. Это дает вам отчетность, которая касается качества исходного кода. Когда у вас есть набор изменений, который не связан с задачей (или требованием), он указывает, где кто-то, возможно, внес изменения в исходный код, который может относиться к «критически опасным » характеристикам медицинского оборудования. В финансовых системах, где вы можете выявить вредоносные попытки украсть деньги (я хотел бы сослаться на сценарий фильма Superman 3 или Office Space).
  • Недостающие элементы – трассировка не только визуализирует связи между различными артефактами, но она должна также удостоверить, что элементы имеют свои желаемые микроэлементы. Например, если Возможность не имеет Пользовательский приемочный тест, то такой запрос может быть создан, чтобы показать такую Возможность. Он не обеспечит всеобъемлющее определение всех положительных и отрицательных тестов, но он покажет, где не было выполнено работы по определению Теста. На основе ссылок легко создать запрос для каждого из ссылающихся элементов и показать те, которые отсутствуют.

Примеры полезных запросов:

  • Возможности без приемочных тестов
  • Возможности без Пользовательских историй
  • Пользовательская История без задач
  • Пользовательская История без тестов

Запрос идет вразрез с текущими данными, поэтому он возвращает текущее состояние при обновлении. Это полезно, если вы заполните пробелы и определить недостающие элементы. После этого можно перезапустить запрос, чтобы узнать, что еще осталось сделать. Запрос может быть запущен внутри Visual Studio, Microsoft Excel или SharePoint Dashboard.

Примечание: отчетность Team Foundation Server с помощью Native SQL

Иногда отчет по трассировке имеет смысл лишь, если он может продемонстрировать несколько уровней иерархии. Например, если есть возможность представить отчет о наборе Бизнес-функций, показывая сценарии, которые реализовывают их имплементацию и задачи, определенные для реализации решения, в комплекте с их статусом «готово-нет» и работу, которую еще предстоит сделать для них завершения. Этот отчет непросто создать с помощью Team Foundation Server OLAP Cube. Хотя это возможно, такой же отчет может быть получен с большей гибкостью при помощи Native SQL с данными хранилища данных. В следующей таблице представлены такие запросы. Колонка слева описывает разделы запроса и где он должен быть отредактирован с учетом любых проектных особенностей трассировки иерархии и атрибутов.

  • Трассировка Возможность к Требованию к Задаче –> Общий отчет по прогрессу разработки Возможностей. Этот пример отчета показывает части запроса в виде 3-хуровневого дерева трассируемых рабочих элементов. Значение этого отчета является в том, что он показывает в одном отчете организацию различных вех проекта. В частности, для традиционного жизненного цикла разработки (водопада), он может продемонстрировать трассировку от бизнес к функциональным, к техническим требованиям. Это для вехи, где окончательные оценки разработки, как правило, сделаны. Для гибкой разработки 3-хуровневый отчет трассировки обеспечивает представление от журнала продукта к журналу спринта, к тестам. Это единственный вид иерархии элементов, который может показать ход разработки в направлении завершения плана.

Пример отчета сгенерированного по вышеприведенному запросу выглядит следующим образом:

Обратите внимание в отчете на то, что Возможности находятся на самом высоком уровне иерархии. В рамках каждой Возможности отчет показывает список Требований, с которыми они непосредственно связаны между собой. В рамках каждого Требования, отчет показывает список задач, с которыми требования связаны напрямую. В этом отчете мы продемонстрировали атрибут оставшейся работы, который поднимается от задач к требованиям. Сумма оставшейся работы по требованию вручную рассчитывается в шаблонах MSF for Agile и MSF for CMMI. В шаблоне процесса Conchango эти данные автоматически поднимались в уровень требований.

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

Руководство для трассировки Agile проектов

Гибкие проекты хорошо подходят к трассировке. Используя лозунг из Agile Манифеста «Работай над программным обеспечением, а не над Всеобъемлющей документацией», гибкая команда ищет иерархию трассировки с минималистским подходом. Однако, с учетом сказанного, должна быть достаточная трассировка к документации, которая гарантирует, что команда может эффективно покрыть все их требования и определить влияние изменений и новых требований в отношении существующего проекта. Следующая диаграмма показывает минималистский подход, который ложиться на общую иерархию трассировки приведенную выше.

Руководство для трассировки традиционных типов проектов

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

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

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 14 апреля, 2010

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

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

Управление изменениями требований осуществляется для:

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

Управление изменениями требований и утверждение описывает, как участник процесса формально получает утверждение для новых требований или изменений/расширений существующих требований. Фокус в этом разделе будет сделан на описании действий процесса изменения требований, управления базовыми линиями требований и разрешения на продолжение работ по реализации требования. Также будет уделяться большое внимание к соблюдению промышленных стандартов таких, как CMMI и ITIL, соответствие отраслевым нормам такие, как FDA CFR-21, Часть 11 и закона Сарбейнса-Оксли, тоже может рассматриваться.

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

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

Управление изменениями и утверждения — Общие сценарии

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

Новые требования

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

Запрос на расширение

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

  • Элементы Запрос на изменение – эти запросы на изменение должны включать в себя данные, необходимые для проведения анализа влияния изменений, а также обеспечивать оценки затрат и утверждение. Они будут рассматриваться в качестве требований, которые требуют выявление, анализ, проверки, а также спецификации, которые описаны в соответствующих разделах настоящего руководства.
  • Последовательность работ – каждое требование будет развиваться в соответствии с правилами и политиками, установленными в соответствии с методологией организации и стандартами.
  • Утверждение – заинтересованные стороны должны утвердить первоначальный набор бизнес-требований для начального этапа традиционного проекта, с последующими утверждениями для каждого из этапов функциональных и технических требований. Agile проекты требуют соглашения в начале каждой итерации, а утверждения для итерации имеет место только в конце итерации в течение демонстрации приложения или ретроспективы.

Дефекты требований

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

  • Элементы Запрос на изменение – эти запросы на изменение должны включать в себя данные, необходимые для проведения анализа влияния изменений, а также обеспечивать оценки затрат и утверждение. Эти вопросы можно отнести к неверному пониманию требований определенными заинтересованными лицами в проекте. Как правило, они обеспечивают изменения в первоначальные требования, но также могут быть введены новые требования или открыты требование, которые были помечены как устаревшие и на удаление.
  • Последовательность работ — каждый запрос на изменение должен обеспечить механизмы для обследования, утверждения, назначения, анализа, разработки и проверки нового запроса в ходе жизненного цикла. Этот процесс более строгий для традиционного водопадного проекта и менее формален для гибкого проекта, для гибкой команды существуют правила для внедрения новых требований.
  • Утверждение — этап утверждения необходим для каждого состояния (или «Ворот») рабочего процесса для традиционного проекта. Утверждение на окончании этапа или окончании цикла релиза необходимо для контроля для всех проектов. Релиз для традиционного проекта означает развертывание в конце проекта, а релиз для гибкого проекта выполняется в конце каждой итерации на протяжении всего проекта.

Обнаруженные «на лету»

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

Управление изменениями и утверждение – Поддержка сценариев в Team Foundation Server

Изменения для требований в гибком проекте, в смысле манифеста»Agile Manifesto», очень просты для управления, поскольку они определены и хранятся до начала новой итерации и не отличаются от определения расширений к проекту, который завершен.

Изменения требований в традиционной водопадной модели также просты, но только в механизмах создания, сравнения и утверждения базовой линии. Управление изменениями требований на лету немного сложнее, потому что методика водопада требует не только оценки изменений в требованиях, но и изменения в контексте ВСЕХ других проектных артефактов, плана проекта, последовательности выполнения, проектных зависимостей, качества обслуживания и т.д. Таким образом, управление изменениями и утверждение для традиционного проекта требует дополнительных работ и жесткой привязки к его «воротам» (условиям окончания). Даже при такой политике, предсказуемость гораздо труднее обеспечить для традиционных проектов.

Подготовка управления базовой линии

Требования описаны с помощью конкретных типов рабочих элементов в Team Foundation Server (например, типы рабочего элемента сценарий или пользовательское описание функциональности). Документация (технические характеристики и прототипы) хранятся на SharePoint-сайте проекта. Рабочие элементы связываются с документами сайта проекта с помощью гиперссылок. Эти гиперссылки могут быть размещены и в рабочих элементах, которые задают определенную часть работы в области разработки для разработчика.

Библиотека документов командного сайта построена так, чтобы отражать гибкость подхода, которая соблюдается. В библиотеке Requirements создаются папки как система записей. Это хорошая практика, когда различные виды активов организованы в их собственные папки. Например, требования описания (Stories) должны быть в одной папке, а нефункциональные (Quality of Service) требования должны быть в другой. Документы общие для всего проекта, такие как видение продукта, ограничения продукта или дополнительные характеристики нефункциональных требований, должны быть сохранены в корне папки требований.

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

Рисунок 1. Представление документов в Team Explorer и WSS

На скриншоте выше слева в Team Explorer открыта папка библиотеки документов, отображающая требования и описания. Те же документы отражены в правой части в двух представлениях портала Windows SharePoint Services (WSS). Это сравнение показывает, что члены команды Team Foundation Server могут использовать документы в любом приложении, в зависимости от того, где они больше работают. Разработчики и аналитики, например, могут работать в Team Explorer, в то время как менеджеры и бизнес-аналитики могут использовать портал.

Рисунок 2. Установка связи между рабочими элментами и документами

Документы, хранящиеся на командном сайте также доступны прямо из Visual Studio IDE. Team Foundation Server предоставляет мощный механизм для связывания документов и других артефактов на основе файлов с рабочими элементами. Если документы размещены в библиотеке документации с включенным пунктом «Versioning» в портале для изменений в документах, то связанный рабочий элемент с типом связи «гиперссылка» всегда будет ссылаться на последнюю версию.

Участники проекта могут сравнивать последнюю версию документа с его предшественниками помощью функциональности сравнения в Word, которая осуществляется с помощью возможности «Revision Tracking» версионного хранения портала SharePoint.

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

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

Продвижение базовой линии

Для любой базовой линии требований, может быть единственный набор требований, который относится к релизу. Особенно в тех случаях, когда важно управление и соблюдение требованиям таких, как контроль пищевых продуктов и медикаментов (Food and Drug Administration), для изменений, которые вносятся в требования в течение всего цикла разработки (вставка требований в поставку релиза), имеют значение только утвержденные наборы требований. С точки зрения базовых линий, окончательный набор, привязанный к сборке, поставляемой в релиз, является исходной записью о любых запросах на расширение или дефектах, определенных в поставку.

Теперь важно убедиться, что изменения клиента или заинтересованных лиц, в конечном счете, проверены, протестированы и приняты. Только затем нужны базовые линии. Этот тип базовых линий будет называться ««Системная базовая линия » в то время как базовые линии, принятые в процессе разработки до сборки релиза, будут называться «Внутрифазовая базовая линия«.

Это руководство описывает оба типа базовых линий в следующих двух подразделах.

Управление внутрифазовыми базовыми линиями

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

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

Используя структуру, которая была создана в предыдущем разделе «Подготовка управления базовой линии», базовая линия должна быть создана в конце важной вехи. Для проекта Agile это будет в конце каждой итерации.

В целях создания базовой линии, все важные артефакты должны быть получены и сохранены в местах, отведенных для базовой линии. Рекомендуется создать библиотеку документов «Project Milestones» с отдельными директориями для каждого этапа. Тут «Iteration 0», «Iteration 1», «Iteration 2» и т.д. Важные артефакты, находящиеся здесь, демонстрируют полною трассировку иерархии от требований бизнеса до кода и результатов тестов, созданных в этой вехе:

  • Выбранные Бизнес-требования – используя запросы для рабочих элементов с фильтром для рабочих элементов «Возможность» (Feature) со всеми атрибутами, которые способствуют решению для разработки приложений, можно выбрать весь набор в Excel таблицу и сохранить в каталоге вехи.
  • Выбранные Сценарии – используя запрос для рабочих элементов с фильтром по рабочим элементам «Сценарий» (Scenario), связанные только с вехой (например, «Iteration Path = Iteration 0»), со всеми их атрибутами, можно извлечь весь набор в Excel таблицу и сохранить в каталог вехи.
  • Выбранные Задачи – то же, что сценарии, но только фильтр по рабочим элементам «Задача» (Task) для итерации.
  • Описания – каждый документ, который представляет собой фрагмент сценария итерации, должен быть скопирован в каталог вехи. Хотя ревизия истории в SharePoint позволяет сравнивать документы от версии к версии, эта копия позволит легче сравнивать принятую «базовую версию» и текущие изменения. Без этой копии будет трудно понять, какой документ нужно сравнивать.
  • Другие документы — любые другие документы такие, как спецификация проектирования, документ видение, архитектура и характеристика инфраструктуры и т.д., должны быть скопированы в каталог вехи.
  • Отчет сборки — снимок окончательной сборки позволит установить связь между документацией (рабочими элементами и файлами) для базовой линии и исходными файлами, тестами и результатами тестов для той же базовой линии. Отчет по сборке – это отчет, который поставляется как стандарт с шаблонами процессов «MSF for Agile» «и «MSF for CMMI». Это список всех сборок, хранящихся в системе. Только одна имеет значение, которая является окончательной сборкой для итерации, представляющую базовую линию. Эта информация должна храниться в виде файла в папке вехи итерации.

Рисунок 3. Файлы для базовой линии итерации

Рисунок 4. Финальный отчет для сборки итерации

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

Утверждение базовой линии

Многие методики, особенно которые используют отраслевые стандарты (CMMI) или государственные регулирования (FDA, закон Сарбейнса-Оксли), требуют пересмотра и утверждения базовых линий. При создании базовых линий, как описано выше, WSS может поддерживать такой цикл утверждения.

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

Рисунок 5. Группа управления запросами на изменение

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

Рисунок 6. Утверждение базовой линии

Методы сравнения 2-х базовых линий

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

  • Веха документирования бизнес-требований (BRD) – бизнес-требования были утверждены и приняты за основу.
  • Веха документирования функциональных требований (FRD) – функциональные требования были утверждены и приняты за основу.
  • Веха документирования технических требований (TRD) – технические требования были утверждены и приняты за основу.

В проекте Agile утверждаются и принимаются за основу журнал продукта и журнал итерации.

Каждый тип требования (представленный в виде типа рабочего элемента в Team Foundation Server) должен быть выгружен из Team Foundation Server в электронную таблицу Excel. Структура всех трассируемых атрибутов для рабочих элементов должна быть задана в запросе по рабочим элементам перед началом процедуры экспорта:

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

На следующем шаге создание Excel таблицы на основе этого списка. Функция, которая это делает, выделена красным цветом на рисунке выше. Результат будет выглядеть следующим образом:

Эта таблица должна быть сохранена с именем соответствующей вехи. Например, может называться «Итерация 1– Базовая линия требований к продукту». Дополнительный лист книги может называться «Итерация 1 – Базовая линия задач».

Храниться каждый файлов, относящийся к базовой линии, в папке вехи проекта в библиотеки документов, созданной для хранения базовой линии. ВСЕ файлы, связанные с требованиями, которые входят в базовую линию, должны храниться в той же библиотеке документов в качестве базовой линии требований. Из-за особенностей этой базовой линии, такой механизм обеспечит хранение всех документов в SharePoint с фиксированием времени и идентификации пользователя, который сохранил их там. Если организация требует соблюдения правил, таких как FDA CFR-21, часть 11, то документ для подписи можно создать и хранить в общем комплекте или он может быть сгруппирован в пакет, который будет поставлен в средство, поддерживающее цифровую подпись пакета документов.

Если анализ должен проводиться для определения изменчивости требований или просто для понимания изменений от одной вехи к следующей, то можно использовать инструменты сравнения такие как Excel Compare от Formula Software, Inc. (http://www.formulasoft.com), которые позволят сравнить однотипные требования базовой линии от одной вехи к другой (Т. е. Iteration 0 Feature Baseline.xlsx и Iteration 1 Feature Baseline.xlsx).

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

Для традиционных проектов контроль не как естественное. Изменения требуют рабочего процесса, который включает в себя принятие незапланированного времени в процессе разработки для анализа влияния изменений, оценки рабочих затрат, а затем постановка и получение утверждения для внесения изменений в проект. Более формальные организации используют системы управления изменениями для поддержки их циклов изменений и утверждения. С помощью Team Foundation Server тип рабочего элемента Запрос на изменение может реализовывать процесс управления изменениями, где он может иметь жизненный цикл на основании состояний, что позволяет организовать переходы для анализа, оценки, постановки и утверждения. После утверждения команда может включать изменения в свою разработку. Рабочий элемент Запрос на изменение может быть связан, используя тех же механизмы ссылок, описанные выше для трассировки к требованиям или требований, которые добавляются или обновляются на основании запроса.

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

Описанный выше процесс для сравнения набора требований в базовых линиях определяет различия на макроуровне между базовыми линиями. Если различия будут найдены, то дальнейший анализ для развернутого сравнения можно выполнять на уровне документов. Используя Word, включенную возможность управления ревизиями и управления версиями WSS, аналитик может сравнивать и утверждать различия между отдельными версиями документа. Основным сценарием использования подхода может использоваться для управления изменениями «на лету».

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

Процесс управления изменениями

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

Рисунок 7. Процесс управления изменениями для гибких проектов

Бизнес требует изменение

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

Новое требование

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

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

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

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

Изменение для текущего требования в журнале

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

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

Требование в журнале будет иметь статус утверждения Черновик и младший номер версии.

Рисунок 8. Требование в журнале

Рисунок 9. Регистрация требования с младшим номером

Изменение текущих разрабатываемых требований

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

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

Должны быть определены следующие параметры:

Может ли этот запрос на изменение рассматриваться просто в качестве уточнения по требованию?

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

Рисунок 10. Версионная история документа для уточнения

Рисунок 11. Комментарий должен быть добавлен на вкладке истории рабочего документа

Требование остается полезным без изменений?

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

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

Рисунок 12. Задача, запланированная на итерацию 1

Рисунок 13. Задача более не назначена и находится в журнале

Процесс управления изменениями, характерный для традиционных проектов

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

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

Для того чтобы эти изменения были эффективно доведены до менеджера команды или команды, можно включить нотификацию в WSS для отправки уведомлений пользователям или команде об изменении. Уведомления по рабочим элементам, в частности в начале проекта, могут иметь «спам» эффект, что уменьшит положительное влияние от уведомлений.

Рисунок 14. Подробное описание в истории об изменениях очень важно

Процесс утверждения

Процесс утверждения, который представлен ниже, важен даже для гибких проектов.

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

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

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

Рисунок 15. «Легкий» процесс утверждения

Настройка сайта команды для поддержки процесса утверждения

Когда командный сайт создан для нового проекта, настройки по умолчанию не включают контроль версий и утверждение. Важно изменить эти настройки, если для команды необходим контроль версий и утверждения. Рекомендуется всегда включать версии, а также утверждения, чтобы обеспечить истории версий, обеспечить процессе изъятия/возврата на редактирование (то, что ожидается от приложения управления версиями) и точно знать, что документы, с которыми работают, являются утвержденными версиями.

Рисунок 16. Включение управления версиями и утверждения

Рисунок 17. Настройка библиотеки документов

Рисунок 18. Рекомендуемые настройки

Рисунок 19. Автор документа публикует документ с основной версией – состояние утверждения «Черновик»

Рисунок 20. Утверждение документа

Рисунок 21. Состояние утверждения документа

Заключение

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

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

  • Уменьшение «Изменчивости границ»
  • Улучшение Анализа влияния
  • Всесторонний охват тестирования требований
  • Совершенствование и повышение эффективности командной коммуникации

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

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 7 апреля, 2010

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

«Валидация гарантирует, что требования отвечают желаемым характеристикам правильно поставленных требований (полнота, правильность, возможность, необходимость, приоритеты, однозначность и проверяемость), а также правильной спецификации требований (полнота, последовательность, модифицируемость и трассируемость)» – Software requirements second edition, Karl E. Wiegers.

Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика, и помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют » Test-First Development » или » Requirements-Based Testing «. С валидацией участник проекта устанавливает критерии приемки для достижения соглашения с заинтересованными лицами о том, что будет поставлено. Это включает в себя проверку бизнес-требований, функциональных требований, нефункциональных требований, сценариев использования, моделей, прототипов и т.д.

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

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

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

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

Методы

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

Планы тестирования

V-модель является промышленным стандартом для создания модели управления тестированием на всех уровнях жизненного цикла разработки приложений. Эти принципы могут быть реализованы в водопаде или в любом варианте итеративной разработки.

Рисунок 1. V-модель для управления тестированием

При разработке каждого уровня требований, которые находятся по левую сторону, правила валидации с использованием методов, описанных выше, будут помогать в разработке тестов, которые будут использоваться для проверки после поставки приложения, компоненты или системы. Лучшие процессы, которым нужно следовать – это «Test First Development» или «Requirements-Based Testing», где составляющая часть не рассматривается как готовая, пока определенные тесты не выполняются и не проходят успешно.

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

  • Определено бизнес-требования, но оно не готово для анализа на функциональные и нефункциональные требований, пока его приемочные тесты не будут установлены и подтверждены. Определите пользовательские приемосдаточные тесты (User Acceptance Test Cases) и свяжите с требованием Возможность (Feature Requirement).
    • Откройте форму Возможность (Feature) в проекте Team Foundation Server. Перейдите на вкладку Links, чтобы увидеть дочерние пользовательские истории (если вы откроете Возможность из шаблона процесса MSF Agile).
    • Из меню Team или панели инструментов на вкладке Links выберите Add New Linked Work Item …. В появившемся диалоговом окне выберите тип связи Tested by и рабочий элемент Test Case. Затем добавьте название для нового рабочего элемента. Можно также добавить комментарий.
    • Новый рабочий элемент позволяет тестировщику планировать, разрабатывать и вести вместе с разработкой модель тестирования для проекта разработки. На вкладке Steps пользователь может определить шаги для выполнения ручного тестирования. Мы не будем показывать это здесь, но этот рабочий элемент, при открытии в клиенте Microsoft Test and Lab Manager, позволяет запускать приложения для тестирования с просмотром этих шагов и отмечать успех или неудачу для каждого шага, а также с просмотром наблюдаемых результатов (которые можно включать в стек вызовов!).
    • Поле Summary Task такое же, как и поле описания любого другого рабочего элемента. Здесь вводится высокоуровневое описание ожидания заказчика. Можно задать следующий вопрос заказчику, для того, чтоб быть уверенными, что заказчика правильно поняли: «Если будет сделана эта функция, что покажет, что она сделана правильно?» Ответ клиента, с небольшой доработкой аналитика, должен быть главным описанием процедуры приемочного теста.
    • Вкладка Tested Work Items отображает ссылку на Возможность (Feature), которая была только что связана:
    • Сохраните рабочий элемент, а затем дважды щелкните на Возможности (Feature) и выберите ее вкладку связей, чтобы увидеть новый тестовый сценарий связанный с ней.
  • Требования к функционалу и качеству обслуживания не могут быть переданы дизайнерам и архитекторам, пока их тестовые сценарии не определены (не обязательно записаны) и не утверждены. Опишите высокоуровневые шаги тестового сценария
    • Открыть дочернее требование одного из рабочих элементов возможности. Это будет рабочий элемент либо Требование (Requirement) или Пользовательское описание функциональности (User Story), в зависимости от используемого шаблона процесса. Выберите вкладку Test Cases, чтобы начать определение тестов. Выберите Add New Linked Work Item … как показано в окне ниже.
    • В появившемся диалоговом окне введите название для нового сценария тестирования. Только один вариант доступен как тип ссылки Tested By и тип рабочего элемента Тестовый сценарий (Test Case), поэтому никаких других атрибутов выбирать не нужно.
    • Результирующий рабочий элемент, как и в предыдущий процедуре, связывается с пользовательской историей, также как тестовый сценарий связывается с возможностью. Есть одно концептуальное отличие. Тестовый сценарий связанный с возможностью является Пользовательским приемочным тестом (User Acceptance Test case), а тестовый сценарий связанный с рабочим элементом системного требования является Системным тестом (System Test case).
  • Разработка приложения не может быть передана разработчикам, пока каждый компонент не имеет интеграционных тестов и тесты по методу «черный ящик» не определены и не утверждены.
    • разработчик может разрабатывать связанные модульные тесты для его кода с целью написания тестируемого кода
  • Код должен пройти весь набор написанных модульных тестов, прежде чем мы перейдем в правую часть модели.
  • После того, модульные тесты проходят, компонент, который инкапсулируется протестированным кодом, может быть протестирован. Мы можем сделать это эффективно, поскольку интеграционные тесты и тесты по методу «черного ящика» были определены в ходе разработки.
  • Как только интеграционные и тесты по методу «черного ящика» проходят, системные функциональные и нефункциональные тесты могут быть выполнены. Опять же, мы можем сделать это эффективно, потому что функциональные и нефункциональные тесты были определены и утверждены в рамках спецификации требований. Т.к. ранее были описаны функциональные шаги для каждого рабочего элемента тестового сценария, мы можем просматривать их и создавать тестовые комплекты в клиенте Visual Studio Test and Lab Manager.
  • Далее, как только системные тесты проходят, не нужно ожидать пользовательских приемочных тестов, потому что они уже определены и утверждены во время спецификации бизнес-требований.
    • Пользовательские приемочные тесты могут быть организованы в тестовые комплекты в Visual Studio Test and Lab Manager.

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

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

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

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

Ожидаемо, что требования, принятые для декомпозиции и анализа, могут быть неоднозначны на этом уровне в плане того, как они будут детализированы.

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

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

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

Модель, показанная ниже, отображает структуру Team Foundation Server, которая поддерживается V-моделью, описанной на предыдущем рисунке. Как видно, Возможность (Feature или бизнес-требование) используется как дополнение к тесту, определенного в тестовом проекте в Visual Studio. Team Foundation Server позволяет пользователю установить связь между рабочим элементом и тестом в тестовом проекте. Более тесная интеграция устанавливается, когда инженер-тестировщик регистрирует изменения проекта тестирования в системе контроля версий. При регистрации изменений, связывание рабочего элемента с набором изменений может быть выполнено в принудительном режиме с использованием политик регистрации Team Foundation Server.

Аналогичный механизм Team Foundation Server поддерживается для Сценариев (Scenario, функциональные) или QoS (качество обслуживания или нефункциональные) требования.

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

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

Контрольные списки

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

Типичные контрольные списки используются для валидации требований на всех уровнях, как показано ниже. Примеры многих из них поставляются с данным руководством Requirements Engineering Checklists.zip.

  • Product Acceptance Checklist – используется в качестве вехи для проверки, что все требования были охвачены необходимой документацией, дизайном, кодом, тестом и других критичными необходимыми артефактами.
  • Requirements Review Checklist – используется в качестве руководства при рецензировании спецификации бизнес-требований, спецификации функциональных требований или спецификации технических требований. Оно проверяет, что стандарты документации были соблюдены и требования правильно сформированы (как описано выше).
  • Requirements Style Checklist – по аналогии с предыдущим.
  • Use Case Review Checklist – Используется для обзора требований сценария и его детального описания, которое должно включать в себя все шаги потоков, графические изображения для них и любые дополнительные сопроводительные данные. В тот же список применяется для пользовательских описаний функциональности гибких проектов или традиционных функциональных требований.
  • High Level Design Review – Используется для проверки, что реализуемые требования на высоком уровне отвечают выбранной архитектуре.
  • Acceptance Test Planning, Results, Change Requests, WBS и другие списки покрывают другие требования и обязанности для проекта.

Обратите внимание, что даже присутствует список » Checklist for a Checklist » в этом пакете.

Используйте шаблон документа «Non-Functional Requirements Template» в качестве контрольного листа для выявления и проверки качества обслуживания (производительности, масштабируемости, бизнес-цикла, обслуживания, поддержки, размещения и т.д.).

Инспекция требований

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

Хороший процесс выполнения инспекций приведен ниже:

  1. Отправлять материалы, которые будут рассмотрены, независимо для каждого рецензента.
  2. Укажите, что каждый рецензент должен анализировать при инспектировании составляющих. Например, тестер должен определить тестируемость составляющих. То есть, могут ли быть тесты написаны и выполнены по завершению. Скажите им внести в документацию пометки, комментарии и критические замечания. Если они находят ошибки, они должны быть готовы для определения альтернативы по этой ошибке.
  3. Наметьте встречи, выделяя участникам достаточно времени для ознакомления с материалом. Неделю, как правило, достаточно времени для этого.
  4. Рассматривайте только те проблемы, которые были определены. Таким образом, совещания эффективно обеспечат, что рецензии будут завершены без потерь чьего-либо времени. Важно отметить, что рецензирование требований или инспекция это не мозговой штурм и сессия генерации идей. Объясните участникам важность их готовности.
  5. Документируйте любые расхождения и определите задачи для авторов на исправление и повторное внесение на инспекцию.

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

Техническая поддержка

Используйте Team Foundation Server для поддержки вышеуказанных действий. Используйте Team Foundation Server для хранения результатов инспекций и принятия рецензий требований. Рассмотрите раздел Выявление для ознакомления с библиотекой документов Team Foundation Server, где хранятся контрольные списки и конечные продукты.

Специфика CMMI

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

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

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010 – Спецификация требований

Posted by Shamrai Alexander на 25 февраля, 2010

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

Описание процесса ввода требований как рабочих элементов для каждой роли и типа рабочих элементов.

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

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

В зависимости от вашего процесса, вы можете создать рабочий элемент для требования как сценарий (функциональные требования для MSF Agile), качество обслуживания (нефункциональные требования для MSF Agile), как история (XP), сценарий использования (RUP) или как требование (MSF для CMMI или Традиционный). Рабочие элементы используются для определения и отслеживания требования. Это позволяет отображать их в вашем журнале, ранжировать, проверять, назначать и формировать отчетность.

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

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

Определение требований (Основы)

Независимо от уровня иерархии при выявлении требований (бизнес, системные или реализация), существуют некоторые основные свойства Team Foundation Server 2010, которые необходимо понимать  для определения требований и их проверки.

Создание рабочих элементов для требований

Для создания рабочих элементов можно использовать Microsoft Project, Microsoft Excel, клиент Team Foundation, Web Access или ваш собственный инструмент с использованием объектной модели Team Foundation. Шаги по созданию рабочих элементов помощью клиента Team Foundation и регистрации вашего требования заключаются в следующем:

  1. Выберите проект в клиенте Team Foundation.
  2. В меню выберите Team | Add Work Item
  3. Выберите тип рабочего элемента – Пользовательское описание функциональности, Качество обслуживания, Требование, и т.д. …

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

Например, для MSF CMMI рабочий элемент требования может определяться как на рисунке ниже (см. Рисунок 1).

Рисунок 1. Регистрация рабочего элемента Требование

Тип рабочего элемента Тестовый сценарий является новым свойством в Visual Studio2010. Этот тип рабочего элемента (РЭ) может быть связан с типом РЭ Требование следующим образом:

Связывание Тестового сценария с Рабочим элементом

Как только вы связали свои требования с РЭ, Вы можете добавить ссылку на сценарий тестирования. Чтобы связать Тестовый сценарий:

  • Откройте рабочий элемент требования, перейдите на вкладку тестирования, нажмите кнопку «Добавить».

Рисунок 2. Добавление ссылки на тестовый сценарий для РЭ требования

  • Выберите тип ссылки Тестируется (см. Рисунок 2) и перейдите к ID рабочего элемента. Можно добавить комментарий для обеспечения прозрачности. Ниже в диалоговом окне отображается рабочий элемент и его связь с Тестовым сценарием. После внесения всех деталей, нажмите кнопку ОК. Результат должен быть как на рисунке ниже (см. Рисунок 3).

Рисунок 3. Добавление тестового сценария для рабочего элемента требование

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

Границы Спецификации

В разделе «Анализ требований и декомпозиция» мы описали процесс по выявлению бизнес требования как тип рабочего элемента Возможность. Данное руководство описывает механизмы определения Возможностей и их связь с требованиями системного уровня, тестовыми сценариями Пользовательская приемка, а также определение дополнительной информации в документации, хранимой в SharePoint Portal.

Независимо от методологии, масштаб проекта диктуется новыми или расширяющими возможностями, их уровнем детализации и оценки. Возможность описывается как рабочий элемент, его детали в виде отдельных документов Word, диаграммы Visio, презентации PowerPoint и других файлов. Валидация возможности описывается в виде рабочего элемента тестовый сценарий, а системные требования определяются как Требования (MSF для CMMI) или Пользовательское описание функциональности (MSF для Agile).

Для шаблона MSF CMMI тип рабочего элемента Возможность был добавлен как часть релиза Team Foundation Server 2010. При использовании шаблона MSF для Agile, Возможность не существует, поэтому наша рекомендация следующая: используйте бизнес требования как тип рабочего элемента Возможность в целях отслеживания трассировки от бизнес границ до системных границ.

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

Процедура:

  • Выбрать пункт меню Team->Add Work Item->Feature

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

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

  • После окончания рабочие элементы (Возможность и Тестовый сценарий) будут иметь ссылки друг на друга.

Детальная информация тестового сценария определяется в Microsoft Test and Lab Manager

Спецификация системных требований

Системные требования представляют собой те требования, для которых команда будет выполнять разработку и реализацию. В MSF для CMMI они представлены рабочим элементом Требование (Requirement), который представляет собой функциональные и нефункциональные требования. Их разграничение определяется путем выбора конкретного атрибута типа требования рабочего элемента. В MSF для Agile, рабочий элемент Пользовательское описание функциональности (User Story) представляет собой функциональные требования, а также нефункциональные требования. В предыдущем выпуске шаблонов процессов рабочий элемент «Качество обслуживания» (Quality of Service) представлял нефункциональные требования. Причиной консолидации является согласованное более тесное взаимодействие метафоры пользовательского описания функциональности многих гибких методов. Пользовательское описание функциональности представляет собой «нечто, что должно быть выполнено».

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

  • В ходе анализа каждой возможности, определите каждое из системных требований, которые должны быть реализованы и опишите их. Выберите Возможность, для которого вы выполняете анализ. Выберите вкладку «Связи», затем выберите значок инструмента «Добавить новый связанный рабочий элемент …». Откроется диалоговое окно для создания связанного рабочего элемента. Выберите «Дочерний» как тип ссылки и Пользовательское описание функциональности (при использовании MSF для Agile) или Требование (при использовании MSF для CMMI) как тип рабочего элемента. Обратите внимание на визуализацию связей представленных в нижней части диалогового окна. Тип связь реализации отличается от связи тестового сценария, показанной ранее. Для дополнительной информации о новых типах связей представленных в Team Foundation Server 2010 смотрите раздел Трассировка и Отчетность.

Заметьте также, что на этом рисунке требование к системе (в данном случае пользовательская история) показано как дочерняя ссылка. Тест, который мы создали для этой возможности, показан как тип Тестируется. Эта новая таксономия обеспечивает более эффективное анализ и представление выполнения работ.

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

Спецификация реализации

Реализация выполняется командой набором задач, которые направлены на разработку исходного кода и юнит-тестов, тестовых сценариев и скриптов, документации или других поставок, которые направлены на достижение цели и завершения проекта. Тип связи Реализация – это типа связи, который используется для описания результатов анализа реализации; анализ направлен на определение задач и их оценки. Мы использовали связь реализации выше, когда указывали системные требования для возможности системы. Это отображается как «дочерние». На самом деле, есть две части для типа связи реализации: дочерний для рабочего элемента, что будет реализовываться, и родительский для требования, что представляет реализацию. Независимо от определений, типы связей позволяют визуализировать иерархию требования как родительский <- -> дочерний <- -> дочерний <- -> т.д. рабочий элемент в преставлении выборки рабочих элементов в виде дерева иерархии.

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

Другая часть спецификации реализации – это детализация системных требований. В Team Foundation Server есть несколько способов для этого.

  1. Опишите детали для каждого системного требования в поле «Описание» в виде текста. Иногда этого достаточно для ясности, но зачастую наши требования могут стать настолько сложными, что для их ясности нужно будет формировать графики, длинные описания и сценарии. По этой причине, следующий пункт описывает более эффективный механизм для подробного описания.
  2. Опишите подробные требования к системе в виде отдельного файла. Если детализация выполнена в UML, то UML проект в Visual Studio будет полезен для этих целей. Посмотрите раздел Анализа и декомпозиции для более детальной информации для создания UML конструкций к конкретным требованиям. Visual Studio для архитектора обеспечивает механизмы для создания диаграмм сценариев использования, диаграмм деятельности и диаграмм последовательности. Возможности Sketchflow обеспечивают механизм для проектирования структурной раскадровки и веб-реализаций. Затем с помощью Word, Excel, PowerPoint можно обеспечить более подробное описание системных требований. Один из наиболее популярных видов являются Пользовательское описание функциональности или Сценарий использования, которые добавляют подробное описание «потока событий». Сохраните документ в библиотеку документов для командного проекта и затем свяжите его SharePoint URL с требованием, используя тип связи «гиперссылку».

Заключение

Спецификация требований является очень тесно связанным с выполнением выявления, анализом и проектированием, управлением изменениями. Из-за этого некоторые области темы спецификации глубже охватываются и в других разделах руководства управления требованиями. Подумайте о спецификации как о концептуальной технике работы процесса и в других областях процесса. Техника, показанная здесь, одна из нескольких техник, которые могут использоваться для определения требований в проектах на основе Team Foundation Server 2010.

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

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 12 февраля, 2010

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

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

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

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

  • Определение методологии (мы расскажем о сценариях, относящихся к гибким Agile процессам с акцентом на Scrum, а также традиционному водопаду)

Методология должна быть определена в дополнение к реализации или разработки, характерной для каждого проекта, который выполняется в соответствии с методологией компании.

  • Определение трассировки составляющих

Связь с другими разделами руководства

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

Основные элементы методологий

В соответствии с руководством Комплексной Модели Зрелости (CMMI), Международной ассоциации по электротехнике и радиоэлектронике (IEEE), Международной организации по стандартизации (ISO) или других комитетов по оценке или стандартизации, естественное развитие от бизнес к функциональным и техническим требованиям должно быть поставлено и поддерживаться с использованием двунаправленной трассировки. В действительности, это означает, что организация должна идентифицировать типы требований, которые позволяют собирать и хранить требования на различных уровнях, чтобы отобразить развитие понимания требований через их жизненный цикл. Это относится ко всей разработке программного обеспечения, независимо выполняется ли традиционная разработка через водопад или с использованием экстремального программирования (XP).

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

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

Документирование плана

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

Трассировка

После того, как проект начат, возможности решения описываются в функциональные сценарии, которые могут быть назначены, оценены, далее проанализированы до оценки качества обслуживания и разработаны в течение цикла разработки программного обеспечения. Рисунок (см. Рисунок 1) представляет собой общую иерархию развития от бизнес требований до исходных кодов и их тестов с потенциальными представлением в документе видения. Большинство проектов по разработке программного обеспечения выделяют финансирование после утверждения бизнес сценариев и назначения группы управления. На этом случае, бизнес проблемы, потребности решения и альтернативы должны быть исследованы и начальный набор свойств продукта установлен. Это то место, с которого необходимо начинать работать в Team Foundation Server. Ниже изображены трассировки.

Рисунок 1. Общая стратегия трассировки

Раздел, который называется Трассировки Требований, описывает использование TFS и поддержку трассировки более подробно.

Роли и обязанности

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

Требование или уровень развития Ответственная роль
Бизнес цель Генеральный директор или представитель бизнеса
Бизнес проблема Генеральный директор или представитель бизнеса
Потребность Заинтересованные лица бизнеса (иногда включает генерального директора и представителей бизнеса, но может также включать пользователей конечного приложения или системы)
Возможность Бизнес аналитик(и)
Функциональное требование (на основе сценариев) Бизнес аналитик
Качество обслуживания Бизнес аналитик, Архитектор предприятия, Архитектор приложения, Архитектор инфраструктуры, Администратор баз данных, Инженер тестер, Инженер практик использования и т.д. определяются подтипами качества обслуживания.
Сценарий тестирования Инженер тестирования функциональных требований, Инженер тестирования требований по производительности, расширяемости, нагрузки и надежности, Разработчики для исходных блоков и компонентов, другие в соответствии с планируемыми типами тестирования.
Исходный код Разработчики и Архитекторы приложения

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

Атрибуты Требований

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

  • Идентификация — Некоторые механизм нумерации, который позволяет легко производить получение и изоляцию от остального набора требований.
  • Состояние — Новое, Назначенное, Готовое к тесту, Тест пройден, Выполнено.
  • Риск – Возможность проявления и последствия
  • Размер – Грубая оценка (Маленькое, Среднее, Большое, Очень большое)
  • Оценка – Оценка трудозатрат, необходимых для реализации и успешного проведения всех тестов
  • Влияние на архитектуру — Сложность в плане затрагиваемых функций или глубины по архитектуре приложения
  • Бизнес область — Таксономическая ссылка на подразделение, которое будет использовать.
  • Назначение — Ответственный за реализацию требования.

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

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

Отчетность

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

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

Руководство по трассировке описывает и демонстрирует эти и другие отчеты, которые необходимы для полного контроля трассировки требований.

Инструменты

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

Примеры инструментов, которые могут использоваться в жизненном цикле:

  • IRise — графический инструмент дизайна раскадровки для уточнения деталей бизнес сценариев. Артефакты из IRise должны храниться или быть связанными с конкретными рабочими элементами в TFS.
  • Рабочие элементы TFS – должны быть определены рабочий элемент «Возможность» (Feature), «Пользовательское описание функциональности» (User Story) и связаны как результат анализа возможности, используя ссылки в VSTS; должен быть определен рабочий элемент «Задача» (Task), который связан со сценариями в результате планирования итерации или проекта, и наборы изменений контроля версий и документы в Windows SharePoint Services (WSS) портала должны связываться с задачами.
  • Шаблоны и документация Результатов Работы (Work Products) — Sharepoint должен быть организован так, чтобы облегчить доступ для членов команды к шаблонам для конкретной работы, а также должен обеспечить место для хранения артефактов с шаблоном.

Управление изменениями

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

Поэтому, следующие вопросы должны решаться политикой управления изменениями требований:

  • Обработка и утверждение запроса на изменение — описывает процесс, по которому изменения требований должны быть представлены, рассмотрены и обеспечены. Должен быть включен процесс согласования изменений требований с заказчиком, который может варьировать в зависимости от традиционного или гибкого подхода, а также каких-либо договорных процессов, видов деятельности и ограничений.
  • Комитет контроля изменений — описывает, кто уполномочен утверждать запросы на внесение изменений. Часто это формально называется группа по контролю изменений (CCB), но, в случае чистого гибкого проекта, он может быть представлен заказчиком или владельцем продукта работающего со Scrum мастером. В этом разделе плана следует описать процедуры для обработки запросов о внесении изменений и согласований для последующего внесением изменений.
  • Механизм контроля изменений — В этом руководстве мы особо рекомендуем использовать рабочий элемент для хранения запросов на изменения для требований. Это может быть «Ошибка» (bug) или новый рабочий элемент, связанный с требованиями. В любом случае, рабочий элемент обеспечивает техническую реализацию работ, выполняемых в рамках процесса управления изменениями (атрибуты, документооборот, назначения и т.д.)
  • Базовая линия — должно быть приведено описание механизмов определения полного набора требований в качестве базовой линии для определенной вехи методологии. Это описание будет описывать процедуры и механизмы для определения новой базовой линии основанной на изменениях и механизм отчетности для сравнения базовых линий от одной вехи к следующей. Этот механизм часто обеспечивает техническую реализацию, которая может поддерживать соответствие с Правилами управления пищевыми продуктами и медикаментами (Food and Drug Administration’s — FDA) для цифровых подписей для требований и изменений (CFR-21, часть 11).

Поток работ и действия

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

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

Планирование задач для выявления и сбора требований

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

  • Цели
  • Существующие требования
  • Заинтересованные лица
  • Операционная среда
  • Область знаний
  • Организационная среда

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

  • Сценарии
  • Интервью
  • Прототипы
  • Общие совещания
  • Наблюдение
  • и другие

Опять же, тема выявления более глубокая.

Кроме того, Team Foundation Server поддерживает планирование мероприятий по выявлению и хорошо интегрируется с Microsoft Project для поддержки полной декомпозиции планирования работ и исполнения.

Элементы Scrum / Agile

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

Документирование плана

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

Трассировка Scrum

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

Владение продуктом отдельная дисциплина и не рассматривается в настоящем руководстве. Владелец продукта будет согласовывать по собственной методологии формирование журнала и TFS должен использоваться как хранилище. Используя диаграммы трассировки ниже (см. Рисунок 2), Scrum проект использует Функциональные требования, Требования качества обслуживания и Задачи, как содержательный рабочий элемент в иерархии.

Рисунок 2. Трассировка Scrum

Роли и обязанности

Приведенная ниже таблица описывает функции, которые необходимы для проектов Scrum.

Требование или уровень развития Ответственная роль
Функциональное требование (Сценарий или История) Владелец продукта
Качество обслуживания Член Scrum команды – охватывает различные функциональные роли, которые могут быть реализованы разработчиком, тестировщиком, Scrum мастером или любым другим членом команды. Гибкие проекты направлены на коллективное владение кодом, а, следовательно, ‘владение всеми активами’ каждого члена команды.
Тестовый сценарий Член Scrum команды разрабатывает сценарий тестирования для функциональных требований, требований расширяемости, нагрузки и надежности, исходные блоки и компоненты, и другие запланированные типы тестов.
Исходный код Член Scrum команды

Атрибуты Требований

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

Условия удовлетворения – описание того, что означает «Готово» для конкретной задачи и ее родительских сценариев.

Готово / Не готово — логическое значение, представляющее завершение.

Первоначальная оценка — Целое число, обычно представленное в часах.

Размер (для журнала продукта) — использование размеров «футболки» (маленький (S), средний (M), большой (L), очень большой(XL))

Управление изменениями

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

Поток работ и действия

Ниже приводится список состояний, имеющих отношение к гибкому подходу.

  1. Не готов (оценка и оставшееся время одни и те же)
  2. Назначение -> В работе
    1. Изменяется время, оставшееся до завершения задачи
  3. Окончание задачи -> Готово (оставшаяся работа = 0 и артефакты задачи успешно протестированы)

Традиционные элементы разработки

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

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

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

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

Posted by Shamrai Alexander на 1 февраля, 2010

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

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

Анализ и Валидация выполняются для:

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

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

Анализа требований (дефекность/изменчивость требований, изменения требований, технические критерии качества выполнения, оценка рисков)

Валидации требований со всесторонними методами (Отчет о методах анализа и результатах)

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

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

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

Процесс Анализа и Декомпозиции

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

Анализ на уровне бизнеса

Цель анализа на уровне бизнеса состоит в том, чтобы идентифицировать требования на уровне бизнеса для начала реализации или разработки программного продукта. Эти требования будут храниться в Team Foundation Server как рабочие элементы «Возможность». Любая информация, которая не может быть сохранена в рабочем элементе, должна быть сохранена в SharePoint и связана с этой Возможностью. Этот уровень анализа обычно выполняется вначале, если проектная группа использует проект водопада, или перед созданием начального журнала продукта (product backlog) для гибких проектов.

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

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

С использованием бизнес сценария (или подобной реализации) обеспечивается детальное описание проблемы, которая будет решена. Он должен уже содержать предварительную идентификацию решения и оценок для поставки. Если клиент не обеспечивает этого, он, по крайней мере, должен сделать предварительную оценку самостоятельно, чтобы группа была в состоянии начать с чего-то, клиент должен участвовать в общих мероприятиях, такие как открытое обсуждение проблемы. Анализ на этом уровне должен обеспечить обзор проблемы для гарантии, что все заинтересованные лица были идентифицированы. Кроме этого, должен быть сделан обзор первопричины проблемы или бизнес цели, затем должны быть идентифицированы возможности решения. Основная работа на этом уровне будет проводиться через мозговой штурм для определения потенциально правильных возможностей, которые решают проблему или достигают цели. Эти возможности должны быть определены рабочими элементами в Team Foundation Server с дополнительным детальным описание в документах, электронных таблицах или диаграммах, сохраненных в WSS и связанных с рабочими элементами через гиперссылки. Следующая диаграмма демонстрирует этот процесс:

Рисунок 1. Анализ бизнес уровня

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

  1. Формальный запрос на предложение клиента — в этом документе клиент должен обеспечить организованный (может и нет) список категорий, которые им нужно обеспечить в разделе документа границы системы.
  2. Документ границы/видение/устав клиента — в этом документе, клиент будет использовать шаблон из их собственной методологии. Хотя это будет вероятно разработано с использованием шаблона из общей методологии, как RUP, требования в отношении границ и стиля фиксации свойств и потребностей могут быть в различными.
  3. Электронное письмо от клиента для обсуждения границ — в этой ситуации Вам предоставлена возможность использовать свой собственный формат требований, и Вы можете использовать запланированные методики выявления, чтобы идентифицировать описанные возможности для их решения.

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

Это высокоуровневый процесс бизнес анализа:

  • Анализ проблемы — проблема для клиента может уже быть в одном из документов, который передан команде. Зачастую это описано в документах Видение или Границы как «Констатация проблемы».

Рисунок 2. Пример констатации проблемы из MCS Sample’s Scope/Vision Document

Констатация проблемы зачастую обеспечивает детальное описание, которая может быть введена в поле «Problem» на вкладке Quality Gates нового рабочего элемента возможности.

Рисунок 3. Пример свойства с проблемой

  • Идентификация всех заинтересованных лиц — определяются у клиента следующие люди и их цели:
  1. Владелец проблемы: Кому нужно разработать Ваше решение? Этот человек или люди, которые дают Вам большинство требований бизнес уровня для решения.
  2. Финансовый спонсор: Кто платит за Ваше решение? Этот человек или руководящий комитет может немного обращать внимания на фактическое решение, но его требованиях важны, поскольку они главные для владельца проблемы и необходимо удостовериться, что владелец проблемы реализует эти потребности.
  3. Эксперты по предметной области: Это люди, которые знают и понимают больше всего о бизнесе и могут помочь Вашей команде в определении требований для решения. Т.к. Вы работаете с пользователями для идентификации функциональных требований системного уровня, они могут также обеспечить бизнес руководство Вашей команде.
  4. Пользователи: Кто будет использовать решение? Часто они также владельцы проблемы, но иногда и нет. Пользователь обеспечит функциональные требования и их правила проверки во время анализа возможностей (следующий раздел).
  5. Поддержка: Кто будет выполнять операционную поддержку Вашего решения после установки или кто оказывает инфраструктурную поддержку группе ранее и на протяжении всей разработки.
    1. Операционная поддержка обеспечит требования для получения разворачиваемого решения в промышленной среде и любые инструментальные требования, которые команда разработки должна реализовать в решении. (т.е. запись журнала программы, анализ выполнения программы и т.д.)
    2. Поддержка инфраструктуры должна обеспечить аппаратные средства, программное обеспечение операционной системы, утилиты, инструментальные средства и другое программное обеспечение (как обслуживание баз данных и клиентские инсталляции) и лицензии для Вашей команды. Также они могут определить ограничения для среды, которым Вы должны будете следовать.
  6. Заинтересованные лица IT: Если нет операционной или инфраструктурной поддержки, это заинтересованные лица, обеспечивающие требования к архитектуре, базе данных, взаимодействию, интерфейсу и безопасности и ограничения, которые Ваша группа должна будет применить.

Хранение Заинтересованных лиц: Мы не создавали рабочий элемент для этой информации, поэтому команда должна будет фиксировать ее в документе и хранить ее в библиотеке SharePoint, связанной с проектом Team Project. В папке шаблонов проекта, сгенерированного шаблоном процесса, перейдите к папке Documents Library Templates и скопируйте Stakeholder Profile Template.doc.

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

Рисунок 4. Пример документа профиль заинтересованных лиц и его хранения

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

Информация о заинтересованных лицах поможет Вам в подготовке и планировании исследований требований для Вашего проекта.

  • Определите Первопричину — используя предварительное определение проблемы и работая с владельцами проблемы и экспертами по предметной области, Вы должны быть в состоянии использовать методики выявления, такие как «диаграммы причинно-следственных связей» и «Анализ Парето» (Смотрите Методики выявления в разделе Выявление требований для более детальной информации), для идентификации наибольших проблем, которые будут решены, механизмов и сценариев в пределах организации, которые вызывают проблему. Эта информация может быть также описана в документе границы/видение клиента. Если этого нет, это необходимо сформировать для себя. Мы не обеспечили рабочий элемент для этой информации, но есть шаблон документа подобный документу Видение для Unified Process, который делает хороший итоговый бизнес документ для клиента. Он должен быть заполнен также как и при определении заинтересованных лиц, и затем сохранен в библиотеке документов проекта DocumentRequirements. (см. рисунок для идентификации заинтересованного лица),
  • Идентификация альтернативных решений — Этот необязательный шаг, если клиент уже выбрал решение на высоком уровне среди нескольких альтернатив. Если нет, то этот шаг обеспечит несколько определений решения на высоком уровне, которые предоставят клиенту достаточно информации, чтобы принять правильное решение, основанное на стоимости, необходимом наборе возможностей, технических и деловых рисках, простоте архитектуры и адаптации и т.д. Исходя из реализаций большинства наших команд, мы решили, что этот шаг не будет происходить достаточно часто, чтобы определять его детально в этом руководстве. Как альтернатива, привлеките или наймите бизнес аналитика, навыки которого являются достаточными для этого типа анализа.
  • Идентификация возможностей решения — бизнес требования будут зафиксированы как рабочие элементы Возможность. Бизнес требования для решения клиента собираются с использованием интервью, обзоров требований, мозговых штурмов и другие методики исследования. Смотрите Методики выявления в разделе Выявление требований для более детального руководства по методикам выявления требований. Убедитесь, что учтены следующие категории при выявлении бизнес требования:
  • Функциональность
  • Производительность
  • Надежность
  • Поддержка
  • Эксплуатация
  • Администрирование
  • Безопасность
  • Администрирование Баз данных
  • Корпоративная архитектура
  • Архитектура приложения
  • Документация
  • Руководства пользователя / Интерактивная справка
  • Обучение
  • Удобство и простота использования (новичок, опытные пользователи)
  • Пользовательский опыт (т. е. 5 нажатий клавиши, чтобы закончить любую задачу)
  • Пользовательская доступность (поддержка для личностей с ограниченными возможностями),
  • Другие категории, которые мы не перечислили.

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

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

Документируйте каждое свойство как рабочие элементы Возможность в Team Foundation Server. Чтобы упростить работу, начните с электронной таблицы, соединитесь с Team Foundation Server как источником данных, выберите запрос рабочих элементов «All Features» как шаблон и введите Ваши рабочие элементы в электронную таблицу.

Когда все будет закончено, просто опубликуйте рабочие элементы на Team Foundation Server , используя функцию Publish на ленте инструментальной панели MS Excel.

Валидация Возможностей

Валидация Возможностей — Для каждого из зафиксированных требований задайте Вашему клиенту простой вопрос: «Когда я предоставляю это Вам, что скажет Вам, что я выполнил это успешно?» Клиент, возможно, не знает, как ответить на вопрос, таким образом, Вы и Ваша команда, возможно, должны предложить варианты и сделать их измеримыми. Когда ответ будет установлен, введите результат как Тестовый сценарий.


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

Создайте связанный пользовательский приемочный тест — выберите свойство, для которого Вы хотите создать тестовый сценарий, щелкните правой кнопкой мыши, выберите, «Add New Linked Work Item…». Выберите тип рабочего элемента «Test Case» и тип ссылки «Tested By».

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

Microsoft Test and Lab Manager (MTLM) это новый инструмент в Visual Studio 2010. MTLM, который предоставляет функциональному тестеру возможность увидеть требования и создать тестовые сценарии, чтобы соответственно проверить эти требования. Тестовые сценарии могут быть созданы в MTLM или в Visual Studio. Тестовые сценарии состоят из шагов, которые должны быть выполнены во время выполнения теста.

Когда тестовый сценарий создан из требования, то он становится связанным тестовым сценарием для этого требования.

Конфигурация плана тестирования

  • Создание плана тестирования. Зачем? Поможет определить вовлеченное средства на тестирование и работ по тестированию, чтобы гарантировать максимальное покрытие тестами.
    • Создайте План тестирования (Test Plan) и установите свойства для плана, которые включают добавление конфигурации по умолчанию и параметры тестирования по умолчанию
    • Добавьте требования или пользовательские описания функциональности, которые будут покрыты в плане, свяжите их с наборами тестов (Test Suites ) и добавьте тестовые сценарии (Test Cases) и назначать тесты тестерам
    • Сформируйте отчет по выполнению плана тестирования.

Конфигурация тестового сценария

  • Управляйте тестовыми сценариями. Зачем? Позволяет определять тестовые сценарии понятным и непротиворечивым способом. Тестовые сценарии могут быть связаны с пользовательскими описаниями функциональности, задачами, ошибками и автоматическими тестами, которые позволяют просто проследить текущее состояние тестового сценария.
    • Создайте тестовые сценарии в Team Explorer. Свяжите их с соответствующими требованиями, пользовательскими описаниями функциональности, задачами, ошибками и тестами и сгруппируйте в тестовые наборы.
    • Назначьте тестеров и выполните тесты, которые ассоциированы с тестовыми сценариями, записывающими результат.
    • Создайте отчеты по выполнению тестов.

Наборы тестов

  • Создание наборов тестов. Зачем? Облегчает управление большим количеством тестовых сценариев.
    • Определитесь, какие наборы тестов Вы хотите создать и как они будут связаны в иерархическом порядке. Например, функциональной областью или тестером.
    • Добавьте соответствующие тестовые сценарии в наборы тестов.
    • Управляйте наборами тестов в пределах своих планов тестирования.

Microsoft Test and Lab Manager

  • Lab Management легко тестирует множество конфигураций в виртуальной среде лаборатории и помогает разработчикам более легко воспроизводить ошибки, поставляя копии экрана среды через виртуализацию.
  • Автоматизированное тестирование пользовательского интерфейса с Coded UI Test с новым механизмом отчетности и воспроизведения

Анализ функционального уровня

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

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

Рисунок 5. Анализ функционального уровня

  1. Обзор списка заинтересованных лиц — как указано выше, важно идентифицировать общие параметры пользователя, даже самые мелкие, чтобы иметь возможность всесторонне идентифицировать и разбить по категориям все функциональные возможности приложения. Обзор соответствующих заинтересованных лиц позволяет идентифицировать пользовательские функциональные возможности системы и любые интеграции к другим системам, которые потребуются (SME).
  2. Определение контекста приложения — также известное как контекстное схематическое моделирование или моделирование сценария использования, эта задача позволяет сформировать функциональный вид на все цели пользователей и обозначает их как функциональные требования. Эти требования лучше представлять как рабочие элементы «Требование» с атрибутом «Тип» как «Функциональное». Эти требования обеспечат основание для технического анализа (показанного в следующем разделе) так же как проектной оценки трудозатрат и планирования. Результаты этой задачи обычно определяются требованиями, идентифицированными как рабочие элементы в Team Foundation Server, так же как контекстная модель или модель сценария использования, которая привязывается к каждому из требований. При моделировании контекста или документа сценария использования в Visio, Word или в других инструментах, документы должны храниться в библиотеке документов проекта DocumentsRequirements. ‘Кружки’ или названия функций в модели используются как заголовки рабочих элементов функциональных требования. В этом пункте нет необходимости иметь весь детальный поток выполнения функционального требования, поскольку это главным образом функция для следующей задачи, которая может быть отложена до отдельной итерации или следующего шага проекта разработки приложения.
  3. Переопределение функционального требования — функциональные требования не пригодны для использования, пока их детали не определены. Так, если требование было идентифицировано для определения в течение следующего периода или следующего шага проекта (итерации), то как раз время, чтобы определить эту дельную информацию. Последовательность процедуры выполнения функциональных сценариев необходимо описать в достаточной детализации, чтобы можно разработать приложение и описать шаги тестирования. Определите эту информацию в поле описания рабочего элемента Требование. Если описание слишком длинное, разбейте рабочий элемент на несколько рабочих элементов или определите детализацию в функциональной спецификации, одну на один рабочий элемент. Не пытайтесь использовать одну большую спецификацию для всех рабочих элементов. Такой тип спецификации не пригоден для использования в команде разработки.
  4. Организация и планирование разработки — используя функциональные требования как отправную точку, менеджеры проекта может выполнить оценку работ. Они все еще неизвестны из-за неполного нефункционального анализа (технический анализ), но есть достаточно информации, чтобы начать планирование, дизайн и разработку. Результаты этой деятельности — задачи и тестовые сценарии, которые описывают затраты, требуемые для завершения разработки приложения. Используя такую же процедуру, которая описана выше для идентификации приемочных тестов пользователя, связанных со свойствами, идентифицируйте рабочие элементы «Задача» как связанные рабочие элементы к каждому из функциональных требований.

Для детализации задач выполните следующее:

  • Заголовок (Title) задачи — название рабочего элемента, который на уровень выше, или фраза, которая описывает то, что будет выполнено.
  • Тип (Type) задачи — управление (management), разработка (development), тестирование (testing), инфраструктура (infrastructure), документирование (documentation) и т.д.
  • Оценка трудозатрат (Original Estimate) — число в часах, которое необходимо по предварительной оценке для завершения задачу.
  • Законченная Работа (Work Completed) — ноль (0) часов
  • Оставшаяся работа (Work Remaining) — это должно быть числом (в часах) равным оценке трудозатрат. По ходу выполнения, это число будет изменяться до тех пор, пока задача не будет выполнена. Но оценочная загрузка должна оставаться постоянной, таким образом, команда может научиться более точно оценивать трудозатраты и понимать их возможности по разработке.

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

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

Валидация функциональных требований

Валидация функциональных требований — для каждого из зафиксированных требований задайте Вашим заинтересованным лицам простой вопрос: «Когда я даю Вам эту функцию, что скажет Вам, что она выполнена успешно?» Заинтересованное лицо, возможно, не знает, как ответить на вопрос, поэтому Вы и Ваша группа, возможно, должны предложить варианты и сделать их измеримыми. Когда ответ будет утвержден, введите результат как «Тестовый сценарий».

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

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

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

Создание связанного системного теста — выберите требование, для которого нужно создать тестовый сценарий, щелкнуть правой кнопкой мыши, выберите «Add New Linked Work Item…». Выберите тип рабочего элемента «Тестовый сценарий» и тип ссылки «Тестируется».

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

Сделайте только короткое описание процедуры тестирования и любых подходящих данных, поскольку детальное описание будет определено, используя проект ручного теста Visual Studio, который будет связан с этим рабочим элементом во время его регистрации и его результаты будут зафиксированы и сохранены в информационном хранилище Team Foundation Server во время выполнения.

Анализ технического уровня

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

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

  1. Получение требований производительности — если у организации есть соглашения об уровне услуг, начните с них, чтобы определить измеримые требования производительности. Эти требования определяющие ограничения надежности (время работоспособности, дни безотказного обслуживания и т.д.), требования нагрузки (ожидаемое количество одновременно работающих пользователей, параллельные транзакции и т.д.), масштабируемость (число транзакций в час/минуту/секунду, число пользователей, выполняющих подобные функции, и т.д.).
  2. Получение требований удобства и простоты использования — опишите требования к простоте в использовании и доступу с точки зрения общего вида и схожести с другими приложениями, простоте в работе (пользователь должен быть в состоянии выполнить транзакцию без посторонней помощи), функциональные возможности, обеспечивающиеся различным уровням квалификации (новичок или опытный пользователь) и профилирование (доступ в пиковое время или в другое время) и т.д. Пользовательский опыт и эксперты по эргономике могут помочь с этим.
  3. Получения операционных и требований поддержки — начните с операционной поддержки организации или службы помощи, чтобы определить функциональность поддержки и возможности диагностики.
  4. Получение требований к документированию, руководства и учебным материалам — определите количество документации, которая будет поставлена с приложением. Пользователь и заинтересованные лица поддержки будут полезными при определении этих требований. Создайте отдельную библиотеку документации в командном проекте, портал проекта обеспечит единое место для хранения этих документов, которое доступно для всех участников команды так же как обеспечивает контекст для всей информации.
    ВАЖНО: Пожалуйста, запомните, что выполняемые обязательства команды основаны на подписанном документе «Перечень работ», который включает обязательства по поставкам. Поставки должны быть идентифицированы как рабочие элементы «Требование» с типом «Документация». Задачи для написания документов должны быть определены с использованием той же процедурой, описанной выше, включая предварительные оценки, оставшиеся трудозатраты и выполненную работу. Они должны отслеживаться с использованием тех же механизмов, которые используются для отслеживания других проектных требований.
  5. Получение других дополнительных технических требования и ограничений по мере необходимости — не все типы требований могут быть известны в начале проекта, уже не говоря об описании руководства спецификаций для выполнения анализа требований. Добавьте 5-ый шаг анализа технического уровня вконец и выполняйте его в зависимости от условий.

Анализ задач и планирование проекта

В управлении проектом анализ требований в отношении идентификации задач и их оценки является другой формой анализа, которая способствует декомпозиции плана работ относительно реализации этих требований. Visual Studio Team System и Team Foundation Server 2010 обеспечивают новые возможности, которые увеличивают возможности менеджера проекта при идентификации, отслеживании и управлении выполнением задач для проекта разработки программного обеспечения.

Управление рабочими элементамиVisual Studio 2010 было улучшено по сравнению с 2008, чтобы предоставить лучшие возможности при планировании проекта менеджером проекта. Одна из самых популярных утилит управления проектом, используемых на практике, является Excel Microsoft. Это связано со списковым представлением записей и возможностей свободных таблиц, которые обеспечивают богатый набор графиков и вычислений.

Проектное планирование, оценка и отслеживание для Visual Studio2010 на основе шаблона процесса MSF for Agile были спроектированы так, чтобы улучшить использование Excel в этих целях. Две рабочих книги поставляются как стандартные шаблоны с шаблоном процесса MSF for Agile. Хотя это спроектировано для работы с MSF for Agile, нет никаких причин, чтоб не использовать их для MSF for CMMI или любого другого шаблона процесса в этом отношении.

Есть также новые возможности в Visual Studio, которые дают лучшую интеграцию с Microsoft Project. Т.к. реализованы новые иерархические связи, поэтому можно применять традиционные практики управления проектом в версии 2010. Определенно, вложенные задачи теперь обеспечивают возможности объединения по предварительным и оставшимся трудозатратам, которые не были возможны в предыдущих версиях этой интеграции.

Тут мы продемонстрируем возможности планирования для гибкого проекта с помощью Excel, которые являются частью шаблона процесса MSF for Agile.

Одна книга представляет журнал продукта, а другая журнал спринта. Они обе состоят из рабочих элементов Пользовательское описание функциональности и их ссылок реализации Задача. (Смотрите RM Ranger Hands on Labs for ‘point and click’ guidance’).

Книга журнала продукта

У книги журнала продукта есть 3 рабочих листа.

  • Журнал продукта (Product Backlog) — иерархический список пользовательских описаний функциональности и их задач. Мы будем использовать этот лист, чтобы редактировать относительные размеры пользовательских описаний функциональности, изменять их ранг и целевую итерацию. Это поможет в организации итерационного планирования. Если бы это был не гибкий проект, то та же самая информация может использоваться, но итерация должна быть единственной или организованной относительно главного выпуска. Если необходимо расширить книгу для отражения MSF for CMMI или другой реализации процесса, используйте относительные размерности, оценки, ранг и приоритеты для поддержки проектной видимости.
  • Производительность (Capacity) — этот рабочий лист позволяет Вам идентифицировать все итерации для проекта, их даты, число пользователей и объема работы, который ожидается на проведение проекта. Эта информация поможет Вам получить видимость перегруженных или недогруженных итераций, позволяя перераспределить загрузку. Если используется расширение для проекта водопада, итерации могут легко поддерживать ворота качества или вехи.
  • Как использовать эту рабочую книгу (How to use this workbook) — этот лист как учебное руководство по использованию рабочих листов. Он имеет много подробной информации, которая описана в этом документе.

  • Рабочий лист Прерываний (Interruptions) обеспечивает детали, которые не сохранены в рабочих элементах, но обеспечивает данные, которые улучшают планирование и информацию по расписанию:
    • Введите даты любых выходных в плане работы

  • Рабочий лист планирования итерации (Iteration Planning) обеспечивает распределение оценки пользовательских описаний функциональности (относительная размерность) для каждой вехи. Пользователь вводит дату начала и окончания итерации и количество ресурсов в группе для определения размерности группы. Далее, он получает оставшуюся часть от суммы значений оценки описаний каждого пользовательского описания функциональности реализуемых за веху. Далее вычисляются рабочие дни из системного календаря и определенных выходных рабочего листа прерываний. Вся эта информация также используется для отражения проектной производительности ресурса в виде графика для каждой вехи. В основном, вычисляется, сколько работы запланировано на основе количества требований и их относительных размерностей (оценка).

Книга журнал спринта

У книги Журнал спринта (Sprint Backlog) есть 3 рабочих листа.

  • Журнал итерации (Iteration Backlog) — иерархический список пользовательских описаний функциональности и их задач. Этот лист позволяет нам управлять, какие описания и задачи назначены на какие итерации. Обновляйте или публикуйте данные, когда это необходимо. Кроме этого, этот список должен быть отфильтрован на итерации, которую группа планирует и управляет, чтобы сосредотачивать на представлении относительно текущих данных. В этом представлении могут быть созданы дополнительные задачи, используя ссылку Реализация (Implementation) (или родительская-дочерняя иерархия) и могут быть введены предварительные оценки, оставшаяся работа и выполненная работа. Эти данные не только синхронизируются с Team Foundation Server, но и управляют другими рабочими листами в рабочей книге.

  • Настройки (Settings) — этот рабочий лист обеспечивает механизм для установки области и итерации для данных рабочего листа и дат начала и окончания для итерации

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

  • Производительность (Capacity) — этот рабочий лист позволяет сбалансировать загрузку для участников команды.

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

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

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

Заключение

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

Методики анализа включают показы, экспертизы, приемочные контрольные списки и планы тестирования.

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

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

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

Коммуникации с заказчиком и проектной командой при сборе требований

Posted by Shamrai Alexander на 23 ноября, 2009

17 ноября 2009 года состоялась первая I конференция, посвященная работе с требованиями в ИТ-проектах. Организатор  Учебный Центр Luxoft, соорганизатор — Государственный Университет — Высшая школа Экономики. Специалисты СМ-Консалт выступили с докладом «Коммуникации с заказчиком и проектной командой при сборе требований».

Posted in Семинары | Отмечено: , , , | Leave a Comment »

В помощь требованиям TFS

Posted by Shamrai Alexander на 25 июня, 2009

teamspec_logoУправление требованиями в TFS стандартными средствами процесс не особо тривиальный. Для управления требованиями можно использовать два подхода: 

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

Что уже говорить о тех, кто попробовал IBM Rational RequisitePro или Telelogic Doors, которые позволяют не только формировать требования, но и прослеживать трассировку между требованиями, формировать документацию и т.д. Порыскав по интернету, я наткнулся на один интересный инструмент от TeamSolutions, который называется TeamSpec.

Читать далее >>

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , , | Leave a Comment »

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