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