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

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

Archive for Февраль 2010

Какая разница между папками и ветвями?

Posted by Шамрай Александр на Февраль 26, 2010

<< Назад в TFS Branching Guidance – Q&A

Вопрос

Какая разница между папками и ветвями?

Ответ

Начиная с TFS 2010, существует различие между ветвями и папками в системе управления версиями. С необходимыми разрешениями пользователь может конвертировать папки в ветви (и наоборот).

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

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

После обновления TFS 2008 до TFS 2010 Вы должны преобразовать папки-ветви в ветви. Примечание — не все папки в TFS 2008являются ветвями. Некоторые папки обычные и будут продолжать оставаться папками в TFS 2010.

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

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

Дополнительные ресурсы

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

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

Posted by Шамрай Александр на Февраль 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 Шамрай Александр на Февраль 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 Шамрай Александр на Февраль 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 »

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