Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Анализ и Декомпозиция

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

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

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

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

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

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

• Функциональность
  
• Производительность
  
• Надежность
  
• Поддержка
  
• Эксплуатация
  
• Администрирование
  
• Безопасность
  
• Администрирование Баз данных
  
• Корпоративная архитектура
  
• Архитектура приложения
  
• Документация
  
• Руководства пользователя / Интерактивная справка
  
• Обучение
  
• Удобство и простота использования (новичок, опытные пользователи)
  
• Пользовательский опыт (т. е. 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 или в других инструментах, документы должны храниться в библиотеке документов проекта DocumentsRequirements. ‘Кружки’ или названия функций в модели используются как заголовки рабочих элементов функциональных требования. В этом пункте нет необходимости иметь весь детальный поток выполнения функционального требования, поскольку это главным образом функция для следующей задачи, которая может быть отложена до отдельной итерации или следующего шага проекта разработки приложения.
   
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) – этот рабочий лист представляет зависимую от времени диаграмму для выбранной итерации, которая показывает успехи, сделанные в течение каждого дня за определенный период, и отображает с использованием линии тенденции, которая показывает, отклоняется ли итерация от планового завершения или нет.
  

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

Заключение

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

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

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

07.07.2010

Комментарии

• YSVGWqXMpUIukNRge
  Автор: ncPv4D ezjthxmjsofm  ·  25.09.2011 21:45:39
  ncPv4D ezjthxmjsofm
• SJOwtEhvEDH
  Автор: P8PK1Y , [url=http://tuygegphhogj.com/]tuygegphhogj[/url], [link=http://velaqiavsgpv.com/]velaqiavsgpv[/link], http://vwjdtyotccjj.com/  ·  23.09.2011 16:43:19
  P8PK1Y , [url=http://tuygegphhogj.com/]tuygegphhogj[/url], [link=http://velaqiavsgpv.com/]velaqiavsgpv[/link], http://vwjdtyotccjj.com/
• JIiwxvWoJZSLv
  Автор: tRFOYJ ppvwflfcmtbh  ·  22.09.2011 21:26:01
  tRFOYJ ppvwflfcmtbh
• ZUucdyeYMQgaL
  Автор: Thank you so much for this aitrcle, it saved me time!  ·  21.09.2011 11:43:46
  Thank you so much for this aitrcle, it saved me time!
• 
  Автор:   ·  19.07.2011 11:56:56
  Every one acknowledges that men's life is expensive, nevertheless people need cash for various things and not every one gets enough cash. Therefore to get some credit loans and just secured loan should be a right solution.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"