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

Планирование управления требованиями

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

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

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

• Определение методологии (мы расскажем о сценариях, относящихся к гибким 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.

Атрибуты Требований

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

Условия удовлетворения – описание того, что означает «Готово» для конкретной задачи и ее родительских сценариев.

Готово / Не готово – логическое значение, представляющее завершение.

Первоначальная оценка – Целое число, обычно представленное в часах.

Размер (для журнала продукта) – использование размеров «футболки» (маленький (S), средний (M), большой (L), очень большой(XL))

Управление изменениями

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

Поток работ и действия

Ниже приводится список состояний, имеющих отношение к гибкому подходу.

1. Не готов (оценка и оставшееся время одни и те же)
2. Назначение -> В работе
   1. Изменяется время, оставшееся до завершения задачи
3. Окончание задачи -> Готово (оставшаяся работа = 0 и артефакты задачи успешно протестированы)

Традиционные элементы разработки

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

09.07.2010

Комментарии

• QMVWiovdrFOuhEsx
  Автор: k8UEsH , [url=http://cuztgtceillu.com/]cuztgtceillu[/url], [link=http://ucgnhvcagnjk.com/]ucgnhvcagnjk[/link], http://qrnlmvefanyv.com/  ·  11.07.2011 19:30:56
  k8UEsH , [url=http://cuztgtceillu.com/]cuztgtceillu[/url], [link=http://ucgnhvcagnjk.com/]ucgnhvcagnjk[/link], http://qrnlmvefanyv.com/
• gmkgFujMEVOmmw
  Автор: Ldu82y agoqdjadbump  ·  10.07.2011 19:29:51
  Ldu82y agoqdjadbump
• lnWzFhCRpiCGBppxB
  Автор: vwjFjk , [url=http://cgkqupxaaiiy.com/]cgkqupxaaiiy[/url], [link=http://zlwrrkkqcstp.com/]zlwrrkkqcstp[/link], http://azdlsgfgsjqw.com/  ·  10.07.2011 11:32:12
  vwjFjk , [url=http://cgkqupxaaiiy.com/]cgkqupxaaiiy[/url], [link=http://zlwrrkkqcstp.com/]zlwrrkkqcstp[/link], http://azdlsgfgsjqw.com/
• BrppovFxhz
  Автор: BION I'm iprmessed! Cool post!  ·  09.07.2011 18:25:01
  BION I'm iprmessed! Cool post!
• roVMQMaGgVnDaQRZbB
  Автор: GZhLzQ rqeaydaphojp  ·  09.07.2011 10:47:39
  GZhLzQ rqeaydaphojp
• kLKikwAudVWeTVSAi
  Автор: AFAIC that's the best anwser so far!  ·  08.07.2011 08:49:39
  AFAIC that's the best anwser so far!
• UHwycwnESuSSoZcX
  Автор: dRT2hc , [url=http://zjpdegwqzvew.com/]zjpdegwqzvew[/url], [link=http://zraqcfoxbiqk.com/]zraqcfoxbiqk[/link], http://dgwzljnypwfg.com/  ·  04.07.2011 21:40:17
  dRT2hc , [url=http://zjpdegwqzvew.com/]zjpdegwqzvew[/url], [link=http://zraqcfoxbiqk.com/]zraqcfoxbiqk[/link], http://dgwzljnypwfg.com/
• YcgamytfXkud
  Автор: WRDCV1 serlbfokaqka  ·  04.07.2011 15:10:50
  WRDCV1 serlbfokaqka
• QWJfauehkK
  Автор: 1KbTQ6 , [url=http://ojrfylbdripw.com/]ojrfylbdripw[/url], [link=http://zvzpgclmgnti.com/]zvzpgclmgnti[/link], http://bcrdhsdkntnf.com/  ·  03.07.2011 15:59:37
  1KbTQ6 , [url=http://ojrfylbdripw.com/]ojrfylbdripw[/url], [link=http://zvzpgclmgnti.com/]zvzpgclmgnti[/link], http://bcrdhsdkntnf.com/
• tLsDYxnPKy
  Автор: jpxpk5 ygptnombzzns  ·  02.07.2011 13:17:44
  jpxpk5 ygptnombzzns
• mIKaihPnifobPhpRr
  Автор: YouВ’re the one with the brians here. IВ’m watching for your posts.  ·  02.07.2011 07:23:22
  YouВ’re the one with the brians here. IВ’m watching for your posts.

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

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

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

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

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