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

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

CMMI DEV v1.3 – Управление Требованиями

Posted by Шамрай Александр на Декабрь 2, 2010

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 2

Назначение

Назначение Управления Требованиями (УПТР) состоит в управлении требованиями продукта или компонентов продукта в проекте для обеспечения соответствия этих требований с планами проекта и рабочими продуктами.

Вступительный комментарий

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

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

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

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

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

Частью управления требованиями является изменения задокументированных требований, их обоснование и поддержка двунаправленной трассируемости между источником требований, всеми требованиями к продукту и его компонентам, и другими указанными рабочими продуктами. (См. определение «двунаправленная трассируемость» в глоссарии.)

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

В среде Agile, требования передаются и связываются через механизмы, такие как журнал продукта, карта истории и макеты экрана. Утверждение требований принимаются коллегиально командой или уполномоченным руководителем группы. Распределение заданий регулярно (например, ежедневно, еженедельно) корректируется на основе достижений прогресса проекта, более глубокого понимания требований и выяснения решения. Трассируемость и согласованность между требованиями и рабочими продцуктами обеспечивается механизмами, которые уже упоминались, а также во время мероприятий начало-итерации или конец-итерации, таких как «ретроспективы» и «дни демонстрации». (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессные области

См. процессную область Разработка Требований для получения дополнительной информации о выявлении, анализе и установке требований заказчика, продуктов и  компонентов продукта.

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

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

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

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

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков.

Перечень специфических целей и практик

  • CЦ 1 Управлять Требованиями
    • CП 1.1 Достигните Понимания Требования
    • CП 1.2 Принимайте Требования на Реализацию
    • CП 1.3 Управляйте Изменениями Требований
    • CП 1.4 Поддерживайте Двухстороннюю Трассируемости Требований
    • CП 1.5 Обеспечивайте Согласованность Между Рабочими Продуктами и Требованиями

Специфические практики по целям

CЦ 1 Управление Требованиями

Требования управляемы и несогласованности с планами проекта и рабочими продуктами идентифицированы

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

  • Управление всеми изменениями требований
  • Поддержка связей между требованиями, проектными планами и рабочими продуктами
  • Обеспечение согласованности между требованиями, проектными планами и рабочими продуктами
  • Обеспечение корректирующих действий

См. процессную область Разработка Требований для получения дополнительной информации о анализе и утверждении требований.

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

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

CП 1.1 Достигните Понимания Требования

Выработайте общее понимание значения требований с поставщиками требований

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

Пример рабочих продуктов

1. Список критериев, характеризующих соответствующих поставщиков требований

2. Критерии для оценки и приемки требований

3. Результаты анализов по критериям

4. Набор утвержденных требований

Подпрактики

1. Устанавливайте критерии, характеризующие соответствующих поставщиков требований.

2. Устанавливайте объективные критерии для оценки и принятия требований.

Отсутствие критериев оценки и приемки часто приводит к недостаточной проверке, дорогостоящим переделкам или отказа клиента.

Примеры критериев оценки и принятия:

  • Четкая и правильная постановка
  • Полнота
  • Соответствие с другими
  • Уникально идентифицированное
  • Соответствие с архитектурным подходом и приоритетами атрибутов качества
  • Уместное для реализации
  • Проверяемое (т. е. тестируемость)
  • Трассируемое
  • Достижимое
  • Связано со значимостью для бизнеса
  • Отмечено как приоритетное для клиентов

3. Выполняйте анализ требований на соответствие установленным критериям.

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

CП 1.2 Принимайте Требования на Реализацию

Получите подтверждение требований на реализацию от участников проекта.

См. процессную область Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге реализации.

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

Пример рабочих продуктов

1. Оценка влияния требования

2. Задокументированные подтверждения на реализацию требований и изменений требований

Подпрактики

1. Оценивайте влияние требований на существующие работы.

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

2. Согласовывайте и запротоколируйте подтверждения.

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

CП 1.3 Управляйте Изменениями Требований

Управляйте изменениями требований по мере их возникновения в ходе реализации проекта.

См. процессную область Управление Конфигурацией для получения дополнительной информации о отслеживании и контроле изменений.

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

Пример рабочих продуктов

1. Запрос на изменение требования

2. Отчеты о влиянии изменения требования

3. Состояния требований

4. База данных требований

Подпрактики

1. Документируйте все требования и изменения требований, которые поставляются или генерируются проектом.

2. Поддерживайте историю изменения требований, в том числе обоснования для изменения.

Сохранение истории изменений помогает отследить изменчивость требований.

3. Оценивайте воздействие изменения требований с точки зрения заинтересованных лиц.

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

4. Сделайте информацию о требованиях и изменениях доступными для проекта.

CП 1.4 Поддерживайте Двухстороннюю Трассируемость Требований

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

Целью данной практики является поддержка двунаправленной трассируемости требований. (См. определение «двунаправленной трассируемости» в глоссарии.) Когда требования хорошо управляемы, трассируемость может быть обеспечена от исходного требования к его требованию нижнего уровня, и из этого же требования нижнего уровня обратно к их исходному требованию. Такая двухсторонняя трассировка помогает определить, все ли исходные требования были затронуты и все ли требования нижнего уровня связанны с правильным источником.

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

Пример, какие аспекты трассируемости можно рассматривать:

  • Границы трассируемости: границы, в пределах которых трассируемость является необходимой
  • Определение трассируемости: элементы, которые должны иметь логические связи
  • Тип трассируемости: когда необходима горизонтальная и вертикальная трассировка

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

Пример рабочих продуктов

1. Матрицы трассировки требований

2. Системы отслеживания требований

Подпрактики

1. Поддерживайте трассируемость требований для гарантирования того, что источник для требования нижнего уровня (т. е. производного) документирован.

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

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

3. Создайте матрицу трассировки требования.

CП 1.5 Обеспечивайте Согласованность Между Рабочими Продуктами и Требованиями

Обеспечивайте соответствие планов проекта и рабочих продуктов с требованиями.

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

Пример рабочих продуктов

1. Документация о несоответствии между требованиями, планами проекта и рабочими продуктами, в том числе источники и условия

2. Корректирующие действия

Подпрактики

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

2. Определяйте источник несоответствия (если есть).

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

4. Инициируйте любые необходимые корректирующие действия.

Реклама

комментария 2 to “CMMI DEV v1.3 – Управление Требованиями”

  1. Александр said

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

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

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