Структурирование требований в виде плана продукта
Проанализировав требования клиента достаточно тщательно, чтобы понять, какие функции должен иметь продукт, необходимо составить план реализации продукта. Если продукт уже создан, необходимо определить отсутствующие функциональные возможности и разработать план внесения изменений. Требования не могут автоматически преобразоваться в план.
В этом разделе описывается один из способов составления плана на основе набора требований. Это лишь один из многих способов, которые можно использовать в Visual Studio, и его необходимо адаптировать в соответствии с потребностями.
Вы можно использовать невыполненную работу и невыполненные работы портфеля, чтобы определить и сопоставить требования и функции.
Требования и функции
В этом методе используется два вида требований: клиентские требования и функции. Клиентские требования — это результат анализа пожеланий клиента в отношении продукта. Функции — это элементы плана продукта, соответствующие небольшим подмножествам клиентских требований. Каждая функция может включать элементы клиентских требований, основанных на разных аспектах опыта использования продукта и разных функциональных областях.
Требования клиента
Клиентские требования определяются в ходе дискуссии с будущими пользователями и другими заинтересованными лицами.
Для анализа этих требований, как правило, создаются раскадровки и модели, а сценарии разбиваются на более мелкие шаги, образующие дерево. Элементы моделирования (варианты использования и действия) можно связать с рабочими элементами сценария.
Существует два вида клиентских требований.
Сценарии, также известные как варианты использования, представляют последовательности взаимодействия между пользователями и продуктом для достижения определенных целей. Пример сценария может называться "Пользователь покупает книгу".
Требования к качеству обслуживания включают критерии производительности, безопасности, удобства работы и т. д.
Эти требования можно представить в виде рабочих элементов требований типа, задав в поле "Тип требования" значение "Сценарий" или "Качество обслуживания". Подробнее см. в разделе Разработка требований.
Эти рабочие элементы требований необходимо связать с системными тестами, чтобы обеспечить тестирование всех требований. См. раздел Планирование ручных тестов с помощью Team Web Access.
Для перечисления этих рабочих элементов требований можно воспользоваться запросом клиентского требования или просмотром невыполненной работы.
Отчет Отчет "Ход реализации требований" (CMMI) можно использовать для отслеживания удовлетворенных требований.
Компоненты
Функция — это элемент плана продукта, представляющий группу задач. На этапе планирования продукта представители заинтересованных лиц и команды разработчиков назначают функции итерациям. Подробнее см. в разделе Планирование проекта (CMMI).
Введите функции в качестве рабочих элементов требований, задав в поле "Тип требований" значение "Функция".
Название функции описывает в терминах пользователя операции, которые пользователь сможет выполнить с помощью продукта. Это операции, которые было невозможно выполнить в предыдущих итерациях. В плане не должно быть элементов, не предоставляющих пользователю новых возможностей (либо число таких элементов должно быть минимальным).
Например, план реализации может включать следующую последовательность функций:
"Покупатель может выбрать книгу из списка и добавить ее в корзину"
"В списке книг отображаются цены. В корзине указывается общая стоимость книг"
"Поставщики могут прикреплять к книгам теги. Покупатели могут фильтровать списки книг по тегам"
Обратите внимание, что ни одна из функций не соотносится только с одним пользовательским действием и ни одна функция не затрагивает лишь один элемент архитектуры продукта. Реализация функции изменяет сразу несколько функций продукта и предоставляет пользователю несколько новых возможностей.
На этапе планирования продукта функция назначается итерации. Все задачи, связанные с определенной функцией, должны быть назначены одной итерации.
Функция описывает частичную реализацию клиентских требований. Это подмножество клиентских требований, в ограниченной степени реализующее каждое клиентское требование.
Каждую функцию можно связать с одним или несколькими тестовыми случаями, тестирующими представленную функцией часть требований. Эти тестовые случаи представляют собой подмножество системных тестов, связанных с клиентскими требованиями.
Состоянию функции не может быть присвоено значение "Завершено" до тех пор, пока тесты не будут полностью определены и пройдены.
Каждая функция представляет собой группу задач разработки и тестирования. Это корень дерева задач. Задачи разработки реализуют часть требований, описанных функцией. Тестовые задачи позволяют спроектировать и выполнить соответствующие тестовые случаи.
Для составления списка функций используется запрос требований к продукту.
Поиск функций
Разделение требований на отдельные функции представляет собой творческую задачу, над решением которой работают разработчики, аналитики и заинтересованные лица. Функция определяет элемент функциональности продукта, который можно в разумных пределах реализовать отдельно от сопутствующих функций. Следовательно рабочий набор определений функций и порядок реализации функций согласно плану отчасти зависят от архитектуры системы.
Поэтому необходимо параллельно работать над планированием и начальным проектированием продукта, особенно в итерации 0, когда составляется план в самом общем виде.
Декомпозиция сценария
Чтобы организовать требования в функции, необходимо разбить сценарии на более мелкие шаги.
Для этого чаще всего используются раскадровки. Раскадровка — это последовательность рисунков, иллюстрирующих сценарий. На схемах деятельности UML можно показать альтернативные пути, а схемы последовательностей UML позволяют обсуждать взаимодействия между несколькими субъектами. После использования этих инструментов для анализа сценария можно ввести разложенные на составные части сценарии в Team Explorer. Это позволяет связывать тестовые случаи со сценариями и обеспечивает выполнение требований. Подробнее см. в разделах UML-схемы деятельности: рекомендации и UML-схемы последовательностей: правила работы.
Функции и требования, реализуемые в каждой итерации
Функция — это требование, обобщающее возможности пользователя по завершении каждой итерации. Для каждой итерации можно создать несколько функций. Введите их в качестве рабочих элементов требований, задав в поле "Тип требований" значение "Функция".
Назначение сценариев рабочим элементам помогает определять функции. В примере ниже план функций получен на основе сценариев, назначенных итерациям в предыдущем разделе.
Итерация 1
- Клиент выбирает пункты в меню, добавляет их в заказ и добавляет адрес доставки.
Итерация 2
Клиенты выбирают один из ресторанов в отображаемом списке.
По завершении оформления заказа клиентом он отображается на экране выбранного ресторана.
В заказе отображаются цены позиций и общая стоимость заказа.
Итерация 3
Ресторан помечает заказ как "Выполнено" после отправки еды клиенту. Заказ фиксируется на счете ресторана.
Каждый ресторан может составлять и обновлять свое меню.
Клиент может просмотреть меню каждого ресторана перед выбором заведения.
Итерация 4
Клиент вводит сведения об оплате, завершая оформление заказа. Когда ресторан помечает заказ как "Выполнено", с карты клиента снимаются средства для оплаты.
Ресторан получает оплату за заказы, помеченные как "Выполнено".
Итерация 5
- Рестораны могут задавать область доставки. В начале сеанса клиент вводит почтовый индекс. На веб-сайте отображается список только тех ресторанов, которые осуществляют доставку по этому адресу.
Частично реализованные сценарии
Разбиение сценариев на более мелкие шаги позволяет отделить шаги, которые можно реализовать на более ранних этапах проекта, от более поздних.
Иногда можно отделить другие аспекты сценариев. В этом примере команда может реализовать базовые пользовательские возможности в ранних итерациях и усовершенствовать продукт на более поздних этапах. Можно добавить указанную ниже функцию.
- Итерация 6. Ресторан может выбрать цветовую схему и шрифт меню и добавить собственный логотип и изображения блюд.
Этот тип функций, как правило, не образуется непосредственно из разбиения сценариев на шаги, а возникает на этапе обсуждения раскадровок. Пользовательские функции — основные кандидаты для более поздних итераций.
Ввод и изучение функций
Создайте рабочие элементы с типом "Требование" и задайте в поле "Тип требования" значение "Функция". В названии функции укажите краткое описание.
Отслеживание функций на уровне требований
Связать функции с требованиями можно указанными ниже способами.
Свяжите рабочие элементы функций с требованиями сценариев-листьев соответствующих итераций. Их необходимо связывать с помощью ссылок "Связанный элемент", так как сценарии-листья уже имеют родительские элементы.
Свяжите рабочие элементы тестовых случаев со сценариями и требованиями к качеству обслуживания, которые они тестируют. Свяжите функции с подмножеством тестовых случаев, тесты которого должны быть пройдены после разработки функции. Таким образом, тестовые случаи выступают в качестве связующего звена между функциями и клиентскими требованиями.
Функции качества обслуживания
Требования к качеству обслуживания, как правило, не зависят от программного проекта. Например, требования безопасности обычно не связаны с конкретной задачей разработки.
Тем не менее для каждого требования к качеству обслуживания необходимо создать рабочий элемент функции, дочерние элементы которого представлены в основном задачами тестирования, обеспечивающими соблюдение критериев качества обслуживания. Эти рабочие элементы называются функциями качества обслуживания.
Некоторые функции качества обслуживания могут иметь задачи разработки. Например, в ранней итерации можно в качестве эксперимента реализовать версию системы, которая может обслуживать небольшое число пользователей. В последующих итерациях можно добавить функцию, задающую целевую пропускную способность в соответствии с клиентскими требованиями.
Планирование продукта
Перед началом каждой итерации необходимо провести собрание для анализа плана продукта. На первом собрании по планированию продукта необходимо создать план. В ходе следующих собраний он анализируется с учетом результатов предыдущих итераций. Подробнее см. в разделе Планирование проекта (CMMI).
В ходе анализа плана продукта необходимо обсудить функции с заинтересованными лицами из сферы бизнеса и подготовиться к определению их приоритетов и организации их в разные итерации. На собрании должны присутствовать заинтересованные лица из сферы бизнеса и представители команды разработчиков.
На собрании необходимо обсудить последовательность разработки функций. Для этого можно спроецировать или вывести на общий экран представление запроса требований к продукту и отсортировать функции по итерациям в Office Excel.
Кроме того, можно расположить функции в заданной последовательности и проанализировать, какие из них могут быть реализованы в каждой итерации. Например, разработчики могут обсудить, нужно ли перенести функцию "Клиент может просматривать цены" из итерации 2 в итерацию 3, не перемещая ее в последовательности. Чтобы расположить элементы в последовательности, необходимо добавить в электронную таблицу дополнительный столбец с именем "Ранг", содержащий целые числа. Отсортируйте электронную таблицу по этому столбцу. Ранги не сохраняются в Team Foundation Server, но вы можете сохранить электронную таблицу. При повторном открытии электронной таблицы нужно щелкнуть любую ячейку таблицы рабочих элементов, а затем нажать кнопку "Обновить" на вкладке "Рабочая группа".
При планировании продукта учитываются приоритеты функций и затраты на разработку. Приоритеты определяются заинтересованными лицами из сферы бизнеса с учетом предоставленных разработчиками сведений о рисках. Расчет затрат выполняется разработчиками. Точное представление о расходах можно получить только после того, как команда разработчиков проведет определенную работу с архитектурой продукта. Кроме того, может потребоваться опыт реализации предыдущих итераций. Поэтому обновлять расчеты затрат нужно при каждом рассмотрении плана продукта.
Планирование итераций
После анализа плана продукта необходимо спланировать итерацию. План продукта определяет функции, которые будут реализованы к концу итерации. План итерации определяет, какую работу придется проделать команде, чтобы реализовать и протестировать эти функции.
Планирование итераций предполагает выполнение указанных ниже действий.
Создайте задачи разработки и тестирования и свяжите их (в качестве дочерних элементов) с требованиями функций.
Создайте тестовые случаи для аспектов клиентских требований, которые реализуются в каждой функции. Тестовые случаи необходимо связать с клиентскими требованиями для отслеживания полноты реализации требований.
Кроме того, тестовые случаи можно связать с функциями, чтобы отслеживать соответствие функций и требований. Для функции можно установить состояние "Завершено" только после прохождения всех связанных тестовых случаев.
Подробнее см. в разделе Планирование итерации (CMMI).