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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методики анализ и исследования должны в деталях описать бизнес уровень с помощью рабочих элементов «Feature», валидация будет обеспечиваться тестовыми сценариями типа пользовательская приемка (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. Пример документа профиль заинтересованных лиц и его хранения

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

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

• Определите Первопричину - используя предварительное определение проблемы и работая с владельцами проблемы и экспертами по предметной области, Вы должны быть в состоянии использовать методики исследования, такие как «диаграммы причинно-следственных связей» и «Анализ Парето» (Смотрите»RM Rangers – Requirements Elicitation Guidance» в Методиках Исследований для более детальной информации), для идентификации наибольших проблем, которые будут решены, механизмов и сценариев в пределах организации, которые вызывают проблему. Эта информация может быть также описана в документе границы/видение клиента. Если этого нет, это необходимо сформировать для себя. Мы не обеспечили рабочий элемент для этой информации, но есть шаблон документа подобный документу Видение для Unified Process, который делает хороший итоговый бизнес документ для клиента. Он должен быть заполнен также как и при определении заинтересованных лиц, и затем сохранен в библиотеке документов проекта DocumentRequirements. (см. рисунок для идентификации заинтересованного лица),
  

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

• Идентификация свойств решения – бизнес требования будут зафиксированы как рабочие элементы Feature. Бизнес требования для решения клиента собираются с использованием интервью, обзоров требований, мозговых штурмов и другие методики исследования. Смотрите «RM Rangers – Requirements Elicitation Guidance» в Методиках Исследования для более детального руководства по методикам выявления требований. Убедитесь, что учтены следующие категории при выявлении бизнес требования:

• Функциональность
  
• Производительность
  
• Надежность
  
• Поддержка
  
• Эксплуатация
  
• Администрирование
  
• Безопасность
  
• Администрирование Баз данных
  
• Корпоративная архитектура
  
• Архитектура приложения
  
• Документация
  
• Руководства пользователя / Интерактивная справка
  
• Обучение
  
• Удобство и простота использования (новичок, опытные пользователи)
  
• Пользовательский опыт (т. е. 5 нажатий клавиши, чтобы закончить любую задачу)
  
• Пользовательская доступность (поддержка для личностей с ограниченными возможностями),
  
• Другие категории, которые мы не перечислили.
  

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

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

Документируйте каждое свойство как рабочие элементы «Feature» в 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. Определение контекста приложения - также известно как контекстное схематическое моделирование или моделирование сценария использования, эта деятельность позволяет сформировать функциональный вид на все цели пользователей и обозначает их как функциональные требования. Эти требования лучше представлять как рабочие элементы «Requirement» с атрибутом «Type» как «Functional». Эти требования обеспечат основание для технического анализа (показанного в следующем разделе) так же как проектная оценка трудозатрат и планирование. Результаты этой задачи обычно определяются требованиями, идентифицированными как рабочие элементы в Team Foundation Server, так же как контекстная модель или модель сценария использования, которая привязывается к каждому из требований. При моделировании контекста или документа сценария использования в Visio, Word или в других инструментах, документы должны храниться в библиотеке документов проекта DocumentsRequirements. ‘Кружки’ или названия функций в модели используются как заголовки рабочих элементов функциональных требования. В этом пункте нет необходимости иметь весь детальный поток выполнения функционального требования, поскольку это главным образом функция для следующей задачи, которая может быть отложена до отдельной итерации или следующего шага проекта разработки приложения.
   
3. Переопределите функциональные требования - функциональные требования не пригодны для использования, пока их детали не определены. Так, если требование было идентифицировано для определения в течение следующего периода или следующего шага проекта (итерации), то как раз время, чтобы определить эти детали. Последовательность процедуры выполнения функциональных сценариев необходимо описать в достаточной детализации, чтобы можно разработать приложение и описать шаги тестирования. Определите эту информацию в поле описания рабочего элемента Requirement. Если описание слишком длинное, разбейте рабочий элемент на несколько рабочих элементов или определите детали в функциональной спецификации, одну на один рабочий элемент. Не пытайтесь использовать одну большую спецификацию для всех рабочих элементов. Такой тип спецификации не пригоден для использования в команде разработки.
   
4. Организация и планирование разработки - используя функциональные требования как отправную точку, менеджеры проекта может выполнить оценку работ. Они все еще неизвестны из-за неполного нефункционального анализа (технический анализ), но есть достаточно информации, чтобы начать планирование, дизайн и разработку. Результаты этой деятельности – задачи и тестовые сценарии, которые описывают затраты, требуемые для завершения разработки приложения. Используя такую же процедуру, которая описана выше для идентификации приемочных тестов пользователя, связанных со свойствами, идентифицируйте рабочие элементы «Task» как связанные рабочие элементы к каждому из функциональных требований.
   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Получение требований производительности – если у организации есть соглашения об уровне услуг, начните с них, чтобы определить измеримые требования производительности. Эти требования определяющие ограничения надежности (время работоспособности, дни безотказного обслуживания и т.д.), требования нагрузки (ожидаемое количество одновременно работающих пользователей, параллельные транзакции и т.д.), масштабируемость (число транзакций в час/минуту/секунду, число пользователей, выполняющих подобные функции, и т.д.).
2. Получение требований удобства и простоты использования – опишите требования к простоте в использовании и доступу с точки зрения общего вида и схожести с другими приложениями, простоте в работе (пользователь должен быть в состоянии выполнить транзакцию без посторонней помощи), функциональные возможности, обеспечивающиеся различным уровням квалификации (новичок или опытный пользователь) и профилирование (доступ в пиковое время или в другое время) и т.д. Пользовательский опыт и эксперты по эргономике могут помочь с этим.
3. Получения операционных и требований поддержки - начните с операционной поддержки организации или службы помощи, чтобы определить функциональность поддержки и возможности диагностики.
4. Получение требований к документированию, руководства и учебным материалам - определите количество документации, которая будет поставлена с приложением. Пользователь и заинтересованные лица поддержки будут полезными при определении этих требований. Создайте отдельную библиотеку документации в командном проекте, портал проекта обеспечит единое место для хранения этих документов, которое доступно для всех участников команды так же как обеспечивает контекст для всей информации.
   ВАЖНО: Пожалуйста, запомните, что выполняемые обязательства команды основаны на подписанном документе «Перечень работ», который включает обязательства по поставкам. Поставки должны быть идентифицированы как рабочие элементы «Requirement» с типом «Documentation». Задачи для написания документов должны быть определены с использованием той же процедурой, описанной выше, включая предварительные оценки, оставшиеся трудозатраты и выполненную работу. Они должны отслеживаться с использованием тех же механизмов, которые используются для отслеживания других проектных требований.
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.

Одна книга представляет журнал продукта, а другая журнал спринта. Они обе состоят из рабочих элементов user story и их ссылок реализации task. (Смотрите 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) – этот рабочий лист представляет зависимую от времени диаграмму для выбранной итерации, которая показывает успехи, сделанные в течение каждого дня за определенный период, и отображает с использованием линии тенденции, которая показывает, отклоняется ли итерация от планового завершения или нет.
  

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

Финальные размышления об анализе и декомпозиции

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

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

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

Microsoft Visual Studio 2010 and Team Foundation Server 2010 Beta 2 Image

Эти виртуальные машины включают все необходимое для изучения и демонстрации управления жизненным циклом разработки с использованием MS Visual Studio 2010 beta 2 (пока без Lab Management). Образы доступны для нескольких платформ:

• Visual Studio 2010 Beta 2 (Hyper-V)
• Visual Studio 2010 Beta 2 (Windows [7] Virtual PC)
• Visual Studio 2010 Beta 2 (Virtual PC 2007 SP1)

Также предлагается дополнительный набор 7-ми практических занятий. Загрузить их можно: http://cid-8c96cc4d0756cacb.skydrive.live.com/browse.aspx/Public/Blog%20Attachments/2010%20Beta%202%20Labs?uc=3. На блоге Brian Kellers http://blogs.msdn.com/briankel/ можно найти полезную дополнительную информацию, такую как прямые ссылки на скачивание образов.

TFS Branching Guide 2.0

TFS Branching Guide 2.0 довольно интересная сборка планов ветвления, которые основаны на практике применения Team Foundation Server. Будет полезно как пользователям TFS, так и интересно пользователям других систем версионного контроля. Страница проекта на CodePlex  – TFS Branching Guide 2.0

TFS Branching Guide – Main 2.0 – Это главная статья, которая коротко рассказывает о концепции ветвления и показывает 3 основные модели ветвления

TFS Branching Guide – Scenarios 2.0 – Набор наиболее общих сценариев ветвления

TFS Branching Guide – Q&A 2.0 – Частые вопросы и ответы

TFS Branching Guide – Drawings 2.0 – Изображения различных видов ветвлений в различных форматах файлов

TFS Branching Guide – Labs 2.0 – Примеры лабораторных работ с пошаговыми инструкциями их выполнения

Lab Files – Single Release Single Maintenance – Файлы для лабораторной работы «Single Release Single Maintenance»

Выполняя слияние между двумя ветвями с выбранной опцией “Все изменения до определенной версии”, какой тип версии предпочтителен (“Последняя Версия” [по умолчанию], “Набор изменений”, «Дата», «Метка» или «Версия рабочей области»)?

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

Вопрос

Выполняя слияние между двумя ветвями с выбранной опцией «Все изменения до определенной версии», какой тип версии предпочтителен («Последняя версия» [по умолчанию], «Набор изменений», «Дата», «Метка» или «Версия рабочей области»)?

Ответ

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

• «Последняя версия» – все наборы изменений, которые не были объединены из исходной ветви от последней операции слияния, будут объединены с целевым потоком. Однако с момента последнего слияния в исходной ветви может вестись активная разработка, поэтому какие точно изменения будут объединены, может быть не четко определено.
• «Набор изменений» – все наборы изменений из исходного ветви, которые были зарегистрированы до указанного набора изменений, будут объединены с целевой ветвью (определение набора изменений эквивалентно определению даты, где дата – дата регистрации набора изменений).
• «Дата» – все наборы изменений исходной ветви, которые были зарегистрированы до указанной даты, будут объединены с целевым потоком.
• «Метка» – все наборы изменений, которые помечены в исходной ветви, будут объединены с целевым потоком. Поскольку метки в TFS не включают удаления, то изменения удаления, никогда не будут объединены в целевой ветви.
• «Версия рабочей области» – все изменения ветви до версий в указанном рабочем пространстве будут объединены с целевым потоком. Также как и для опции «Метка» изменения типа «удаление» не будут объединены.

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

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

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

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

• «Deceptive Allure Of Merging With Labels» – http://blogs.msdn.com/tfsvcs/archive/2007/03/22/the-deceptive-allure-of-merging-with-labels.aspx

Можно ли удалять ветви?

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

Вопрос

Можно ли удалять ветви?

Ответ

Удаление ветви не отличается от удаления любой папки системы управления версиями. Различие в том, что необходимо знать, не повлияет ли удаление ветви на дальнейшие операции слияния. Слияние в TFS возможно или на непосредственный родительский поток разработки, или на непосредственные дочерние ветви (если не выполняется слияние без базовой версии); таким образом, если промежуточный поток будет удален, то определенные пути слияния могут быть нарушены. Рассмотрим следующий пример:

• Есть ветвь от А к B
• Есть ветвь от B к C

Слияние от А к C возможно (от А к B, от B к C) как и слияние С к А (от C к B, от B к A). Однако если поток B будет удален, то дальнейшее такое слияние становится невозможным. Поэтому, если необходимо удалить папку ветви, то нужно определить, есть ли у нее какие-нибудь дочерние потоки, созданные от нее. Если такие потоки существуют, то лучше сделать ветвь невидимой с помощью разрешений системы управления версиями, что не ограничит будущие слияния, пока папка скрыта от конечного пользователя.

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

• Смотрите раздел Baseless Merge руководства Branching Guidance
• «Team Foundation Server Permissions» – http://msdn.microsoft.com/ru-ru/library/ms252587(en-us,VS.80).aspx

Что такое слияние без базовой версии и чем оно отличается от обычного слияния?

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

Вопрос

Что такое слияние без базовой версии и чем оно отличается от обычного слияния?

Ответ

Слияние без базовой версии позволяет объединять две папки, которые не связаны ветками, создаваемыми через команду branch клиента командной строки tf или с помощью Обозревателя управления исходным кодом. Как только слияние без базы будет один раз выполнено, то в дальнейшем между этими папками можно будет выполнять обычное слияние (как будто эти папки связаны ветками). Хотя слияние без базовой версии может быть полезно для двух логически связанных каталогов, но не связанных ветками, в нем есть определенные недостатки по сравнению с обычной операцией ветвления/слияния:

• Операция слияния без базовой версии возможна только с использованием клиента командной строки tf.
• Связи, которые устанавливаются при выполнении слияния без базовой версии, не видны ни в клиенте командной строки tf, ни в Обозревателе управления исходным кодом (в том смысле, что команды tf branches и мастер слияния Обозревателя управления исходным кодом не работают с папками, которые связаны через слияние без базовой версии). Слияние без базовой версии можно определить только в истории слияний команды tf merge.
• Даже когда связь установлена через слияние без базовой версии, все дельнейшие операции слияния должны выполняться с использованием клиента командной строки tf.

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

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

• «How To: Perform a Baseless Merge» – http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=How%20To%3A%20Perform%20a%20Baseless%20Merge%20in%20Team%20Foundation%20Server&referringTitle=Whats%20New
• Смотрите раздел Baseless Merge руководства Branching Guidance

Когда создается новый командный проект, когда нужно использовать «Создать новую ветвь системы управления версиями”?

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

Вопрос

Когда создается новый командный проект, когда нужно использовать «Создать новую ветвь системы управления версиями»?

Ответ

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

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

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

Однако если существующий проект содержит несколько релизов (даже если они внутренние), то лучше использовать » Создать пустую папку системы управления версиями » для нового проекта, и затем выполнить ветвление от определенного каталога в существующем проекте, а не от корневой папки. Это позволит получить только необходимые каталоги, и даст более гибкое решение при формировании необходимой внутренней структуры нового проекта. Ниже диаграммы иллюстрируют подобную проблему:

Ветвление проекта

Ветвление каталога

Можно ли использовать ветвление между проектами?

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

Вопрос

Можно ли использовать ветвление между проектами?

Ответ

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

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

• Смотрите Branching and Team Projects в руководстве Branching Guidance

Что такое метки и когда они должны использоваться?

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

Вопрос

Что такое метки и когда они должны использоваться?

Ответ

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

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

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

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

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

Как управлять ошибками при ветвлении?

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

Вопрос

Как управлять ошибками при ветвлении?

Ответ

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

Вариант 1: Ответственность и принадлежность для ошибок должны также переноситься в новый ответвленный проект разработки.

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

• Рабочий элемент принадлежит проекту разработки, в котором он был создан, и не может быть перемещен (только дублирован) в другой проект
• Значения полей могут быть только перенесены, если в конечном типе рабочего элемента определены те же самые поля
• Необходимы соответствующие разрешения для обоих проектов

Оригинальная ошибка должна быть закрыта и со ссылкой на скопированную ошибку.

Вариант 2: Ветвление выполняется только для исходного кода (в пределах того же проекта или в другой проект разработки). Ответственность и принадлежность для ошибок останутся в оригинальном проекте.

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

Вариант 3: Ответвление в другой проект будет выполнено только для исходного кода. Ответственность за тестирование исправления ошибки лежит на обоих проектах (например, если исправление ошибки должно быть повторно протестировано в новом потоке).

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

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

• «How to: Copy a Work Item» – http://msdn.microsoft.com/en-us/library/ms181321.aspx
• «Walkthrough: Adding Links and Attachments to Work Items» – http://msdn.microsoft.com/en-us/library/ms181270.aspx