Руководство по управлению требованиями VS TFS 2010 – Введение в Управление требованиями с использованием Team Foundation Server

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

Добро пожаловать в Руководство по управлению требованиями Team Foundation Server! На TechReady7 (внутренние технические встречи Microsoft) в июле 2008 года, практики проголосовали за проекты Visual Studio ALM Rangers, в которых, по их мнению, они больше всего нуждаются. Разработка требований была признана одним из двух самых важных. В этом документе будут рассмотрены люди, процессы и руководство по технологиям для Разработки требований с использованием Team Foundation Server.

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

• Общие Руководство по Разработке Требований – есть практики инженерии требований, которые реализуются, независимо от используемой методологии. Например, общее развитие представления бизнес уровня к функциональным возможностям, качеству обслуживания определено в любом случае, выполняет разработку организация по традиционному водопаду в соответствии со стандартами института инженеров по электротехнике и радиоэлектронике (IEEE) или выполняется экстремальное программирование с гибкими методами. Руководство приведено на концептуальном уровне, по возможности с использованием конкретных примеров на Visual Studio/Team Foundation Server.
• Традиционная разработка – руководство будет приведено в основном в соответствии со стандартами IEEE по инженерии требований. В руководстве будут описаны конкретные указания по выявлению бизнес требований, спецификации, а также валидации спецификаций функциональных и технических требований.
• Гибкая разработка – даже в рамках гибких методов есть несколько методологий, которые подчеркивают или выделяют различные практики в рамках этой темы. Руководство сосредоточено в основном на Scrum в качестве выбранной методологии и ссылается при необходимости на другие методологии.

Сценарий Разработки Требований

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

• Бизнес-требования и их приемо-сдаточные испытания;
• Функциональные требования и их тестовые сценарий;
• Технические требования и их нефункциональные ограничения, качество обслуживания;
• Разработка спецификации и их тесты компонентов архитектуры приложения;
• Исходный код и его модульные тесты;
• Документация пользователя.

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

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

1. Анализ Проблемы и Целей и определение Видения – бизнес-руководители спонсируют проект для решения некоторых бизнес-проблем и достижения бизнес-цели. Бизнес-аналитик будет выявлять их в качестве требований к продукту в виде набора возможностей или бизнес-требований. Мы можем хранить их в Team Foundation Server в виде рабочего элемента «Возможность».
   1. Первоначально выявление будет направлено на бизнес-руководителей. После того, как возможности продукта будут выявлены, специалисты по бизнес-областям будут дополнять этот набор функций. (Разделы Планирование управления требованиями и Выявление)
   2. Валидация на этом уровне будет проверять не только точность описанных функции, но и определять их влияние на решение проблем бизнеса и достижения бизнес-целей. (Раздел Валидация требований)
   3. Проблемы и цели, как правило, хранятся в виде документа бизнес-сценарий, где, в нормальной ИТ организации спонсируемой CIO, менеджер проекта собирает предварительную смету расходов на решение этой проблемы в проекте разработки и выполняет анализ экономических выгод. Этот вид деятельности находится вне области инженерии требований этого руководства. Анализа экономического обоснования и дальнейшего выявление спонсоров и экспертов в этой области приводит к бизнес-требованиям или возможностям продукта, которые будут определены в документах по проекту; обычно в документе Спецификация бизнес требований. (Разделы Планирование управления требованиями и Спецификация требований)
2. Переход к функциям – выполняя анализ возможностей, аналитик получает функциональную контекстную модель или диаграмму вариантов использования для всех функциональных сценариев, реализующих функции. Мы можем хранить их в качестве рабочего элемента «Пользовательское описание функциональности» (MSF для Agile) или «Требование» с типом «Функциональное» (MSF для CMMI) и связать их с каждой возможностью, которую они реализуют.
   1. Планирование требований – описано в разделе Планирование управления требованиями
   2. Аналитик анализирует возможности и готовится к выявлению функциональных требований пользователей заинтересованных сторон и бизнес экспертов по конкретным областям. Их анализ поможет им выявить правильные функциональные требования, задокументировать и выполнить их валидацию на точность. (Разделы Выявление, Анализ и Валидация требований)
   3. Полученные функциональные требования и возможности связываются – описано в разделе Трассировка требований
3. Переход к качеству обслуживания и нефункциональным требованиям – проводится дальнейший анализ возможностей и функциональных требований. Аналитик, работая с другими составляющими продукта (инфраструктура, операции, архитектура и администраторы баз данных, удобство использования, эксперты по безопасности, управление и обеспечение соблюдения требований и т.д.), определяет нефункциональные требования и качества обслуживания. Опять же, мы можем хранить их в качестве рабочих элементов в Team Foundation Server и привязать их к каждой возможности или функции, из которых они получены.
   1. Анализ функциональных требований для получения качества обслуживания и нефункциональные требований – разделы Выявление, Анализ и Спецификация требований
   2. Валидация свойств и нефункциональных требований на точность (Раздел Валидация требований)
   3. Полученные требования и функциональные требования связываются – описано в разделе Трассировка требований
4. Планирование работ – менеджер проекта определяет с командой разработчиков задачи разработки (будь то гибкий проект или водопад или что-нибудь между ними, задачи определяются и по-прежнему с оценкой трудозатрат определенным образом) на функциональные и нефункциональные требования. Их можно хранить как рабочие элементы «Задача» и связывать с функциональными или нефункциональным требованиям, для которых они были запланированы.
   1. Планирование разработки и тестирования – описано в разделе Анализ
5. Разработка Приложения и Тестов — команда разработчиков может разрабатывать код проекта приложения и модульные тесты (и тесты производительности) и связать их с исходным кодом. Во время регистрации (check-in) изменений, они связывают их с задачей, и мы можем даже заставить их это делать.
   1. Наборы изменений (Change Sets) связываются с задачами и требованиями – описано в разделе Трассировка требований
6. Проверка качества приложения — Мы выполняем модульные тесты, и мы с помощью отчета, который связан со сборкой, можем продемонстрировать, какие наборы изменений вошли в эту сборку и какие рабочие элементы были связаны с этими зарегистрированными наборами изменений. И мы можем это сделать с помощью Team Foundation Server. Мы выполняем Ручные или Web функциональные тесты, а также можно использовать общие тесты, которые доступны из внешних систем функционального тестирования (например, Quick Test Professional) и опубликовать результаты. Отчеты будут демонстрировать, что рабочие элементы покрыты всеми видами тестов, с использованием Team Foundation Server Data warehouse.
   1. Выполнить тесты, публиковать результаты, сгенерировать отчеты покрытия – описано в разделе Трассировка требований
7. Планирование тестирования – почему планирование тестирования включено в темы инжиниринга требования? Что ж, планирование тестирования гарантирует, что валидация имеет место. Влидация предусматривает проверку, которая позволяет убедиться, что команда проекта понимает цели требований и может достичь согласования с источником требования (бизнес-спонсором или заинтересованным лицом). Проверка предусматривает тесты, которые команда предоставила и согласовала для поставки. Планирование тестирования обеспечивает хранилище и трассируемость всех работ, связанных с управлением тестирования. Таким образом, после шага (1), но до шага (2), мы теперь имеем надежный механизм для планирования приемо-сдаточных тестов для функциональных требований. На самом деле, планирование тестирования на каждом уровне может быть выполнено с помощью Visual Studio 2010 Test and Lab Manager edition. Таким образом, мы можем создать несколько тестовых планов и тестовых наборов в Test and Lab Manager, которые обеспечивают разработку устойчивого отчета плана тестирования, который показывает, какие тесты не были запланированы, какие были запланированы, но не реализованы, какие были реализованы, но не выполняются, какие были выполнены, но провалены и какие были выполнены и прошли. Все эти данные есть, а у нас теперь есть возможность получить такой отчет и сортировать результаты по рабочим элементам, к которым они принадлежат.
   1. Планирование тестирования для системных требований — описано в разделах Трассировка требований, Валидация требований и Спецификация требований

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

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

Отступление

В 20-тилетней карьере лидера в области разработки, практик, внедрения передового опыта, обучения, коучинга по управлению жизненным циклом разработки для своих клиентов, мы установили, что Инженерия требования, как правило, наиболее сложная дисциплина в рамках программного обеспечения и сообществ разработки систем. Таким образом, это руководство было разработано с подходом, который напрашивается на критику и изменение. Команда из более 20 практиков из Microsoft Consulting Services, Product Management и программы MVP собрались вместе для обсуждения и определения предложения руководства, которое учитывает передовые практики индустрии и лучшие практики Microsoft в дисциплине разработки требований.

Visual Studio ALM Rangers

Эта руководство было разработано в проекте Visual Studio ALM Ranger. Visual Studio ALM Rangers особая группа в составе представителей Visual Studio Product group и Microsoft Services. Их миссия заключается в предоставлении решений для отсутствующих возможностей или руководств.

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

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

Мы надеемся, что данное руководство охватывает более 80% нужд сегмента инженерии требований. В дополнение к этому руководство вы найдете отдельные методологические сценарии, Q&A, учебные пособия и обновление трассировки и документацию по стратегии. Мы призываем участников нашего сообщества предоставлять идеи для новых сценариев, которые мы будем добавлять в пакеты. Эти новые пакеты будут доступны на CodePlex или MSDN и будут обновлены на основе отзывов пользователей.

Словарь

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

Термин	Определение
Анализ требований	Процесс рассмотрения требований на корректность, неопределенность, техническую возможность и другие характеристики качества, затем декомпозиция на более детальные требования.
Активный дизайн (Participatory Design)	Техники сбора требований, происходящие из Скандинавии. Программное обеспечение рассматривается как часть функционирования сложной организации. Пользователь понимается с точки зрения его/ее места во всей системе. Обследование выполняется по различным функциям и элементам системы, и решение принимается в отношении того, что должно быть сделано программным обеспечением, а что людьми. Используется активное участие пользователей в разработке решения.
Аппаратное требование	Требование, которым должно соответствовать аппаратное обеспечение.
Артефакт (рабочий продукт)	Документ, программное обеспечение, тренинг или какой-либо промежуточный продукт, созданный в процессе разработки; может быть только для внутреннего использования или для передачи заказчику.
Атрибуты	Качественные характеристики продукта (например, надежность, удобство использования и т.д.)
Базовая линия	Спецификации или другие артефакты, которые были официально рассмотрены и согласованы, затем служат основой для дальнейшей разработки. Содержание базовой линии может быть изменено только в рамках официальных процедур контроля изменений.
Базовая линия требований	Хранилище согласованных и утвержденных требований к системе, требований к программному обеспечению, требований к оборудованию, эксплуатационных требований, требований к обучению, моделей вариантов использования и т.д.
Бизнес-правила	Правила и ограничения, регулирующие отдельные бизнес-процессы и работы.
Валидация требований	Валидация фокусирует внимание на определении, работает ли продукт как ожидалось. Валидация требований предусматривает проверку связи между тестами (и результаты тестов) и тестируемой системой. Удовлетворяет ли построенная система требованиям?
Вариант использования	Описывает последовательность действий, выполняемых системой, которые дают значимый результат для конкретного актера.
Взаимодействие	Атрибут: возможность взаимодействия одной программной системы с другой.
Гибкость	Атрибут: возможность изменения миссии, функции, данных для удовлетворения других требований.
Группа контроля за изменениями	Группа лиц, ответственных за оценку изменений, одобрение или неодобрение предлагаемых изменений элементов конфигурации, а также обеспечение выполнения утвержденных изменений.
Группа пользователей	Формальная организация пользователей, которая периодически созывается для обсуждения использования продукта и улучшения идей.
Двунаправленная трассировка	Ассоциации между двумя или более логических объектов, которая видна в любом направлении (т. е. в и от сущности). (См. также Трассировка требований).
Дефектное требование	Требование, которое является неправильным, неоднозначным, непроверяемым, нетрассируемым, неполным и/или противоречивым.
Диаграммы взаимодействия	Техники анализа требований использующие для иллюстрации взаимодействия между различными сущностями в виде бизнес-правил, раскадровок, сценариев или вариантов использования.
Доступность	Степень, в которой система функционирует и доступна, когда она требуется для использования.
Жизненный цикл разработки программного обеспечения	Период времени, который начинается с момента, когда программный продукт задуман, и заканчивается, когда программное обеспечение уже не доступно для использования. Жизненный цикл обычно включает в себя фазу концепции, фазу требований, фазу проектирования, фазу внедрения, фазу тестирования, фазу инсталляции и проверки, фазу поддержки и промышленной эксплуатации и иногда фазу вывода из эксплуатации.
Заинтересованное лицо	Лицо, которое будет затронуто продуктом и имеет прямое или косвенное влияние на требования к продукту.
Интервью	Сессия один на один с пользователем на его рабочем месте.
Контекстно-независимые вопросы	Вопросы, заставляющие интервьюера слушать, прежде чем пытаться определить или описать потенциальное решение. Вопросы, направленные в первую очередь на получение реального понимания проблемы и какие решения уже предусмотрены. Пример контекстно-свободных вопросов: Кто является пользователем? Кто является заказчиком? Их потребности отличаются? Где еще можно найти решение этой проблемы?
Коробочное решение	Готовое решение, которое обычно поддерживает целый ряд бизнес-потребностей, функций и т.д. Обычно с закрытым исходным кодом.
Корректность	Атрибут: соответствие стандартам и техническим условиям.
Круг пользователей	Подмножество пользователей разбитых по характеристикам продукта или способам использования продукта.
Мета-вопрос	Вопрос о вопросах. Обычно используется в интервью, чтобы определить или собеседник понимает цель собеседования. Пример мета-вопроса: Мои вопросы актуальны? Понятны ли Вам мои вопросы? Ваши ответы официальны?
Моделирование требований	Работы, направленные на превращение набора требований в графическое и/или текстовое представление модели системы, как она будет работать, если требования были выполнены.
Надежность	Атрибут: работа без сбоев в течение определенного периода времени.
Нетехнические ограничения	Требования, связанные с продуктом, поставкой и выпуском (например, стоимость и сроки).
Однозначное требование	Требование однозначно только тогда, когда может быть только одна интерпретация.
Повторное использование	Атрибут: возможность переработки для использования в другом приложении.
Покупатель	Тот, кто приобретает продукт для пользователей.
Пользователь	Тот, кто будет использовать продукт.
Пользовательские требования	Высокоуровневые системные требования пользователя. Пользовательские требования не должны определять реализацию.
Портативность	Атрибут: возможность перемещения для использования в другой среде.
Представитель пользователей	Один человек, который представляет пользователей для разработчиков продукта.
Приемочные тесты	Тесты, которые выполняет заказчик в процессе окончательной валидации, чтобы удостовериться, что «продукт работает так, как заказчик заказывал». Приемо-сдаточные испытания, как правило, основываются на определенных сценариях использования, которые выполняются в пользовательской среде.
Приоритетность требований	Метод ранжирования важности требований на более и менее важные.
Проверяемое требование	Это требование, которое может быть проверено с помощью анализа, демонстрации, инспекции или тестирования.
Прототип	Частичная реализация программной системы, построенная для того, чтобы помочь разработчикам, пользователям и клиентам лучше понять требования к системе.
Разработка программного продукта	Группа мероприятий, необходимых для последовательного выполнения хорошо определенных технологических процессов, которые включают в себя все мероприятия разработки программного обеспечения для производства правильного, стабильного программного продукта эффективно и результативно.
Разработка требований	Дисциплинированные применения принципов, методов и инструментов для описания предлагаемого поведения системы и ограничения по всему жизненному циклу продукта/проекта.
Раскадровка	Графическое представление потока действий системы. Поток действий может быть основным или он может быть частным случаем, но иметь решающее значение для правильной работы.
Сбор требований	Процесс выявления, организации, анализа и утверждения требований до их включения в базовую линию требований.
Сессия совместного дизайна приложения (Joint Application Design (JAD))	Ряд совместных совещаний пользователей и технического персонала с целью определения требований. В общем, следует структурированному процессу сбора информации и анализа, облегченная сессия с определенными конечными результатами и процессом, а также документируемыми результатами.
Сценарий	Наброски или краткий обзор бизнес-правил, раскадровки или варианта использования, который ставит предназначенные функции в контексте места их работы.
Системные требования	Условия или свойства, которые должны быть выполнены или предоставлены системой или системным компонентом, чтобы удовлетворить условия или возможности необходимые пользователю для решения проблемы.
Спецификация требований	Документация, определяющая, как продукт будет построен, и описывающая ее внешнее поведение.
Спонсор	Лицо, которое выполняет финансирование этого проекта.
Тестируемость	Атрибут: возможность проверить (протестировать) указанную операцию и производительность.
Тестируемое требование	Требование, для которого однозначно может быть написан тестовый сценарий.
Техника Фокус-группы	Техникой сбора требований, которая следует сценарию, и организована из набора вопросов для интервью с группой людей. Группа состоит из 3 — 10 пользователей, экспертов или клиентов, нескольких разработчиков или маркетологов.
Технические ограничения	Характеристики среды продукта, которые влияют на выполнение и/или дизайн продукта.
Техническая рецензия	Рассмотрение экспертами по конкретным вопросам правильности технического содержания артефакта, находящего на рецензии.
Техническое требование	Свойства продукта для условий, в которых разрабатывается продукт.
Трассировка требования	Процесс обратного поиска от текущего требования к предыдущим этапам определения или разработки и прямого прохождения по отношению к текущему требованию ко всем его подчиненным требованиям (планы, проектная документация, схемы, коды, тесты и т.д.). (См. двунаправленная трассировка).
Трассируемое требование	Требование с уникальным идентификатором или меткой. Требование трассируемо только если происхождение каждого из его компонентов очевидно, и есть механизм, который дает возможность сослаться на это требование в будущей разработке.
Требование	Условия или возможности необходимые пользователю для решения проблемы или достижения поставленной цели Условия или возможности, которые должны быть выполнены или выдержаны системой или системным компонентом, чтобы удовлетворить условия контракта, стандарта, спецификации и других официально введенных документов (определение IEEE).
Требование к программному обеспечению	Технический ответ на требования пользователей, часто выраженный в спецификации требований к программному обеспечению, которая направляет разработку продукта.
Требование к системным интерфейсам	Требование, описывающее передачу данных, обработку, питание или другие интерфейсы между подсистемами.
Удобство использования	Атрибут: усилия, которые необходимо приложить пользователю, чтобы иметь возможность использовать продукт, например, время, необходимое для подготовки и обучения использования новой операции.
Управление изменениями	Элемент управления конфигурациями, состоящий из оценки, согласования, утверждения или отклонения и реализации изменений в элементы конфигурации после официального определения их конфигурационной идентификации.
Управление требованиями	Создание и поддержание базовых линий требований для разработки программного обеспечения и рационального использования. Планы программного обеспечения, продукта и работ ведутся в соответствии с базовыми линиями требований.
Функциональное требование	Свойство, необходимое продукту с точки зрения функции или обслуживания.
Целостность	Атрибут: (использование) безотказная работа при несанкционированном доступе; (данные) сохранение содержания и порядка данных и артефактов.
Эффективность	Атрибутов: относительное использование ресурсов (памяти, времени, пропускной способности сети).
Эксплуатационная надежность	Атрибут: простота обнаружения и исправления неисправности в период времени (во время использования).
Unified Modeling Language (UML)	Графический язык для визуализации, спецификации, конструирования и документирования артефактов большой программной системы. UML предоставляет набор элементов моделирования, обозначений, связей и правил использования, которые могут быть применены к деятельности по разработке программного обеспечения.

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